elections-2023-10: What parts of the Kata Containers are you excited to work on?

[stevenhorsman]

Kata Containers is a big project with lots of different things going on. My question to the candidates (cc @jepio @lifupan @zvonkok @gkurz @jiangliu @fidencio) is which things are they excited to work on in kata containers in the next year and why?

[jepio]

For the next year I am excited about several things:

• aligning the CoCo branch with the Kata main branch. This is a big organizational challenge for us, but will make it easier for users to consume both feature sets.
• runtime-rs. After more time in the project i can see how runtime-rs is a chance to cleanup the structure of the runtime shim and I'm excited to see that work mature, and am interested filling in some of the gaps. One area in particular that i want to look into: can we make cloud-hypervisor support the same in-process mode of dragonball?
• image storage and pulling - this year we've started introducing support for snapshotters in kata but this is only our first attempt. There is going to be work needed here to optimize, drive compatibility and work with containerd upstream to figure out better interfaces.
• I'd like to work more on robustness and debuggability. There are still plenty of weird test cases that need lots of reruns in the CI - those intrigue me. We also need to make it easier to expose enough logging (and with the correct frequency) to make it more obvious what is causing an issue.

[zvonkok]

Some time ago we merged: Virtualization Reference Architecture that describes how hypervisors/runtimes need to be constructed or build to support advanced GPU use-cases like GPUDirect.

Device #1  (passthrough)	Device #2 (passthrough)	P2P Compatibility and Mode
GPU PF	GPU PF	GPUDirect P2P
GPU PF	NIC PF	GPUDirect RDMA
MIG-slice	MIG-slice	No GPUDirect P2P
MIG-slice	NIC PF	GPUDirect RDMA
PDevice #1  (virtualized)	Device #2 (virtualized)	P2P Compatibility and Mode
Time-slice vGPU VF	Time-slice vGPU VF	No GPUDirect P2P  but NVLINK P2P available
Time-slice vGPU VF	NIC VF	GPUDirect RDMA
MIG-slice vGPU	MIG-slice vGPU	No GPUDirect P2P
MIG-slice vGPU	NIC VF	GPUDirect RDMA

Recently I added PCIe switch ports and I am extending the PCIe topology to support all of those upper use cases. As described in the VRA, we need CDI (Container Device Interface) support, already added to the outer runtime but not yet to the inner runtime (kata-agent).

One of the more oversized work items is the rustification of CDI so that the kata-agent can take leverage and later runtime-rs. This way, we can support the upper use-cases and get DRA for free, a Kubernetes feature that we've been working on with Intel to support advanced allocation strategies on accelerators in k8s.

Currently, we have support for proper sizing of CPU and memory in a k8s environment at sandbox creation time. What needs to be added is the proper sizing of all resources that a Pod allocates or requires. A k8s KEP that will allow us to pass down all resources via CRI is also in the works. This will also include changes to containerd and other CRI backends.

Arm64 is one of the rising stars of computing HW. I showcased Arm64+GPU already with Kata. As you know, NVIDIA is building new Superchips (GraceHopper) and DPUs (BF3) that are based on Arm64, and hence, my focus will also be to enable Kata on those platforms as well.

For edge deployments, I am also looking to enable Kata on our Jetson devices like IGX or EGX, pushing Kata into fields like robotics or automotive.

Another "issue" I am working on is: QEMU instances share the very same kernel, and one VM could interfere with other VMs. The same situation that containers share. Xen is still the number one choice in the automotive space since it is a true type-1 hypervisor. The different privilege domains give us better isolation between VMs.

Another important topics is CI/CD, where I am working with internal teams to provide the right infrastructure to run some of our GPU systems as github runners.

To summarize my efforts: Make Kata ubiquitous!

[fidencio]

That's a very good question, there are a lot of parts that I'm working on, there are some parts I'm excited to work on. Hopefully there's an overlap between those.

I'm working on reconciling the CCv0 and main situation of Kata Containers, which is crucial for both Kata Containers and Confidential Containers; I'm working on image and storage pulling, which @jepio mentioned, and that's an area that will need more care; I'm working robusteness and debugabillity, as well, mainly now that our CI is actually using what we ship; and I have folks from the same team I am part of, working on the runtime-rs.

All important things, no doubt.

What I'd like to align with those is an "easy-to-use" experience of Kata Containers, which we've improved a lot over the years, but there's still a lot of work to be done. My main goal is that someone who never ever used Kata Containers could simply do something like curl -sfL https://get.katacontainers.io | sh - and get things working, with improvements on both kata-deploy and kata-manager.

In order to have this done, though, we depend a lot on the robustness and debugabillity, and we depend a lot on properly understanding and setting up things like different snapshotters, what's need to support GPU (link to @zvonkok's answer), etc. This ia a long term goal, let's see if we can achieve this.

Another thing is, regardless of the parts I'm excited to work on, there are parts of the project that do need help, and I'll keep working on those as I always did, and those the not so beautiful nor shiny things, as maintenance, CI, and so on and so forth.

[lifupan]

This question is very good and can also lead to the focus or innovation points of the kata community in the next year or period of time.

• First of all, I will pay more attention to the stability and function construction of runtime-rs, so that runtime-rs can achieve production-level stability and try to satisfy community users.

• Second, I want to promote the construction of community technology blogs and try to encourage developers or participants to write more technology blogs. This can not only achieve the purpose of promoting the community, but also attract people.

More new participants are involved and the threshold for their participation can be lowered.

• Third, I want to focus on the integration of kata and community service mesh. When we use kata security containers and use service mesh in business, we

I encountered a series of problems, which prompted me to think about whether kata containers can be better integrated with service mesh, and whether kata can be developed into a real service mesh in the future.
A distributed application runtime similar to dapr.

[jiangliu]

From my point of view, there are several interesting and "important" things in coming year.

• First I will help to make runtime-rs and Dragonball "Product Ready". There are still features missing in Dragonball, such as support of PCI. And we also need to make runtime-rs/agent pluggable.
• Second enhance Kata to support containerd Sandbox API. The containerd Sandbox API is interesting, and we may have different ways to make use of it. It would be great to investigate the best way for Kata to make use of it.
• Third help to merge CCv0 into Kata main, and enhance runtime-rs to support Coco. For support of Coco, runtime-rs is lacking behind, I think is a better way is to support Coco based on runtime-rs, because it's much more extensible.
• Fourth, I will echo @zvonkok here for "better support of GPU based workload", because it's a must for AI/ML. And hope we can enhance Coco to support GPU based workload.
• Last, I will do my best to put Kata into production environment and share the experience with community.

[gkurz]

As already outlined by the other candidates, there are many cool features in the pipeline. I'd personally be excited to work on any of them, with a some preference for runtime-rs (QEMU support) and GPUs maybe, but what I'm really motivated to work on is to help with the project health. Subjects like :

• reaching a good balance between features and stability
• improve review standards
• more tests in CI
• better distribution of work and responsibilities (e.g. stable releases)

I'll be especially very careful with the merge of CCv0 into main as this is likely the most massive addition for the upcoming monthes.