Kata Containers 1.5 release
This is an exciting release for Kata, which includes support for the Firecracker* hypervisor, the s390x* architecture as well as a new method for integrated with the containerd* project. New hypervisors, new CPU architectures and significant integration improvements!
Firecracker support
Knowing that there are always trade-offs between features, footprint, and security, the Kata Containers project was designed up front to support multiple hypervisors. In the 1.4 release, NEMU, a considerable reduction from QEMU*, was added. At the end of November, Amazon Web Services announced the open sourcing of their Firecracker hypervisor. From the Firecracker GitHub* page, “ Firecracker has a minimalist design. It excludes unnecessary devices and guest-facing functionality to reduce the memory footprint and attack surface area of each microVM. This improves security, decreases the startup time, and increases hardware utilization.”
This is very exciting for the Kata Community, as it addresses end user requests for a more minimal hypervisor solution for simple use cases.
The 1.5 release of Kata Containers introduces support for the Firecracker hypervisor. This is very complimentary to the existing QEMU support. Given the tradeoff on features available in Firecracker, we expect people will use Firecracker for feature constrained workloads, and use a minimal QEMU when working with more advanced workloads (for example, if device assignment is necessary, QEMU should be used).
As an example, it’d be typical to utilize runc, kata-qemu (QEMU configuration of kata-runtime), and kata-fc (Firecracker configuration of kata-runtime) in a single cluster, as shown in diagram below:
To achieve this configuration, the cluster must be configured to use either CRI-O or containerd, and must be configured to use the runtimeClass feature of Kubernetes. While work is ongoing for containerd, today only CRI-O supports devicemapper storage driver. With runtimeClass configured in Kubernetes as well as in CRI-O, end users can select the type of isolation they’d like on a per-workload basis. This exact setup, utilizing CRI-O, Kata Containers and the Firecracker VMM, can be seen in the following screencast:
To help developers get started quickly with Kata + runtimeClass in Kubernetes, a reference vagrant box is being maintained here.
As previously mentioned, the Firecracker hypervisor is minimal by design. As a result, there will always be gaps in Kubernetes functionality when using Kata+Firecracker. One such gap is the inability to dynamically adjust memory and CPU definitions for a pod. Similarly, since Firecracker can only support block-based storage drivers and volumes, today devicemapper is required. This is available in Kubernetes + CRI-O and Docker version 18.06. Work is ongoing to add more storage driver options. See this GitHub issue for current limitations of Kata+Firecracker.
We’re excited to be working with the Firecracker team and continuing to improve our support for Firecracker VMM, and how it integrates into Kubernetes. More details are available on the AWS Open Source Blog.
s390x architecture support
With help from community members from IBM*, the 1.5 release of Kata Containers adds IBM Z-Series* support.
containerd integration
Last June, Michael Crosby began a discussion for adding a shim API to containerd in order to better support VM based runtimes, like Kata Containers. The 1.5 release includes an initial implementation meeting this shim API. This greatly simplifies how Kata Containers integrates with containerd, as show below:
Aside from the obvious component reduction, the API results in a better interface to Kata Containers. One example is the ability to directly access container level statistics from the Kata runtime, which was not possible in the command line interface interface that was utilized before. Similarly, because storage mounting is done by containerd-shim, implementing containerd-shim-kata-v2 block-based snapshotter support should be more straightforward.
The Kata community has been very active with the CRI-O project to define and utilize a comparable interface, though this is still a work in progress, targeting the 1.6 release.
Looking forward
Looking past 1.5, we have a lot of exciting work to carry out for improved integration into the ecosystem. We also have a lot of not-shiny work: reducing complexity, improving security, increasing test coverage and stability, and helping users who are putting Kata into production. I’m most enthusiastic about the not-shiny work!
Join us at the next Open Infrastructure Summit in Denver, April 29 — May 1, 2019. The Kata team will have several presentations at the Summit, as well as collaborative working sessions where we can discuss roadmap, planning, and just hands on hacking to improve the project.
In the meantime explore Kata on GitHub, KataContainers.io and get involved! Connect with the community via these channels:
- Slack or IRC Freenode: #kata-dev
- Mailing List
- Weekly meetings
*Other names and brands may be claimed as the property of others.
