Attending this event?
Back To Schedule
Friday, February 19 • 9:45am - 10:25am
Kata Containers will impact you. Yes, you!

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!

Kata Containers runs your existing containers in their own virtual machine. It lets you combine the ecosystem of containers with the features of virtual machines. In this sessions we will see why this strange project ultimately impacts so many developers, from the kernel all the way up to OpenShift.

Last year, we presented the work done to bring Kata Containers to Fedora. We were so young and naive back then! It turns out that this was only the very first step in an ongoing journey. In this introductory session, we will present the work done in 2020, outline a roadmap, tell you how this roadmap touches so many pieces, and give you a broad overview of other kata-related talks submitted by our team.

During 2020, we focused on integrating Kata Containers in the broader ecosystem, from operating system to orchestration. At the lower levels, we reinforced the integration of Kata Containers with features such as SELinux, cgroupsv2 or podman; we added support for high-performance networking using SR-IOV; we improved virtiofs, a better conduit to expose host storage to VMs and their containers. At the higher-end of the stack, we worked on bringing Kata Containers to OpenShift, and published a pre-release kata-operator for OpenShift 4.6. Finally, at the core, Kata Containers went through a major code reorganization and redesign, culminating in the release of Kata Containers 2.0, as well as numerous improvements in processes, issue triaging or continuous integration.

The purpose of this effort is to provide an alternative container runtime that you can, in most cases, transparently substitute to your traditional runc. But why would you want to do that? By exploring the overall architecture of Kata Containers, we will see how it differs from more traditional container runtimes, but also how and why version 2.0 was such a major overhaul. We will discuss some of the problems Kata Containers solves, like being able to run pods with different kernel configuration at low cost, using high-performance hardware-assisted I/O isolation with SR-IOV and DPDK, and in a not-to-distant future, be able to run containers in memory-encrypted virtual machines or migrate long-running containers between hosts. Some of these topics will be covered in more details in other talks.

We are not done, and we need a roadmap. The problem is that the Kata Containers roadmap cannot be thought of in isolation. Kata Containers interacts with many components, from virtual machine monitors to host and guest operating system to large-scale orchestration. In every case, the demands of Kata Containers push the boundaries, needing just a tiny little more than what exists today.

For example, at the kernel level, we are still putting the finishing touches on virtiofs, with things like DAX support. It is likely that we will also soon push some limits in the networking or namespace areas. In order to start containers faster and using less resources, we keep asking questions that lead others to invent interesting ways to start a kernel, like libkrun (nee libkip) or microvms. Even things like hotplugging or device discovery may need to be rethought, because as far as Kata Containers is concerned, they are so darn complicated and so darn slow!

In the hypervisor space, the Kata Containers effect was already felt, accelerating the push to make a leaner and meaner qemu, which now outperforms more specialized hypervisors; nemu is dead, it's now called qemu again. But we keep asking for more! We want an even smaller, more modular qemu. We already hinted at some of these efforts last year with qemu-mini. The particular needs of Kata Containers and other projects such as KubeVirt force libvirt and qemu to rethink how the pieces of the puzzle all fit together, from security to command-line processing. This is likely to ultimately result in a more modular design, where components may sometimes run as individual processes or as libraries.

In the OpenShift and Kubernetes space, Kata Containers pushes the envelope with respect to software packaging and delivery. We need robust and scalable solutions to install system software on various worker nodes, and this is not necessarily so easy to do on read-only operating systems. So here too, we need to invent new solutions.

Xu Wangs comes from Ant Group, one of the creators of the project, and they have a large deployment of Kata Containers in our production clusters. In this topic, the speaker will introduce the practice of Kata Containers in Ant Group and the community contributions in Kata 2.0 based on the experiences in Ant Group. In short, a virtualized container runtime could help the cluster with the strong isolation -- not only about security but also performance isolation and failure isolation

In the end, the roadmap of Kata Containers looks like a giant jigsaw puzzle where most pieces are in flight and keep changing shape.

avatar for Christophe de Dinechin

Christophe de Dinechin

SPICE developer at Red Hat, founder of the Tao3D project, Red Hat
Christophe works on SPICE and 3D virtualization at Red Hat. He's passionate about 3D, virtualization and programming languages. His GitHub page is http://github.com/c3d.
avatar for Xu Wang

Xu Wang

Senior Staff Engineer, Ant Financial
Xu Wang is a senior staff engineer at Ant Financial and an initial member of Kata Containers Architecture Committee. He was the CTO and Cofounder of hyper.sh and created hypervisor-based open source container runtime runV (secure as VM, fast as container). runV merged with clear containers... Read More →
avatar for Ariel Adam

Ariel Adam

Software engineering manager, Red Hat
Part of the virtio-networking team at Red Hat working on advanced networking technologies.

Friday February 19, 2021 9:45am - 10:25am CET
Session Room 5
Feedback form isn't open yet.