“Hyperscale public clouds, whether Amazon, Google or Microsoft, all had some kind of experience with containers, and yet none ran containers on their own. Containers all had some additional level of isolation around them, some kind of virtualization technology,” said Jonathan Bryce, executive director at the OpenStack Foundation, which provides a home and support for the Kata project. “The everyday IT shop and developer was looking at containers as the entire solution, but the people running the most containers in the world were not using them in that way. The people at the top of the container game were running them inside other technologies.”
And thus, Kata Containers was created to help “drive adoption of containers in multi-tenant environments where security and isolation were the top priorities,” Bryce said.
Containers were just never meant to be the end all solution that some like to see them as. And so this whole debate that we’ve been having lately, over virtual machines and multi-tenant isolation and containers — well, that’s really been the idea all along.
Where Firecracker really excels is for those more ephemeral workloads, whereas QEMU can handle the more advanced workloads that might need device or database support. The blog post announcing Firecracker support offers an example and diagram in explanation, writing that “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.”
The addition of the Firecracker hypervisor now allows Kata Containers’ users to pick on a workload-by-workload basis where they want to run a particular container — whether using Firecracker or the more traditional QEMU virtual machine. Bryce explains that Firecracker comes as a retooling of the hypervisor, leaving behind those sometimes unnecessary bits that come along with the QEMU machine emulator.
“QEMU has legacy features built into it from supporting so many things. Kata had created a different QEMU profile inside Kata, that trimmed it down and made it lighter, but it was still based on the bones of QEMU. Firecracker is based on the ChromeOS virtualization system,” said Bryce. “Rather than going back to the QEMU parent that many hypervisors have come from, AWS looked at the virtualization system Google had built for ChromeOS. It was built to be that slim, virtual manager from the beginning. AWS took that and modified it and brought in some server concepts versus just Chromebook concepts. They took the open source, modified it and released that as Firecracker, which allows even faster boot times, lower overhead, and even better performance.”
In addition to Firecracker support, Kata Containers 1.5 also includes support for the s390x architecture and the introduction of a shim API that potentially simplifies how Kata Containers integrates with containerd and provides, for example, the ability to directly access container-level statistics from the Kata runtime, heretofore unavailable from the command line.
As for what’s next for Kata Containers, Bryce says that the team is getting down to the “boring but important work” of making sure everything is stable and scales properly. After all, “some of the people using Kata Containers are public cloud providers or the largest internet companies in China, like Baidu,” explained Bryce, offering not just another reason that scalability and stability matter, but also another proof point that containers and virtual machines go hand in hand.
The OpenStack Foundation is a sponsor of The New Stack.
Feature image via Pixabay.