Kata Containers: Secure, Lightweight Virtual Machines for Container Environments
At this time last year, the Hyper.sh container platform had come to light as the alternative deployment environment for Docker that sought to make peace with the hypervisor, the component that secures and manages virtual machines. Hyper’s runV container runtime produces container images that run inside of KVM-compatible VMs, making them manageable by KVM, Xen, and as some attested, vSphere, while at the same time offering compatibility with container engines such as CRI-O.
Now, the next stage of Hyper’s improbable evolutionary path finds the platform being merged with Intel’s Clear Containers architecture to produce Kata Containers. Earlier this month, at KubeCon in Austin, Texas, Kata received the blessing and the backing of the OpenStack Foundation — the first time that organization has ever backed a project outside of its own architecture.
“This is separate from the OpenStack services,” OpenStack Foundation Executive Director Jonathan Bryce told The New Stack.
“While we’re supporting the project teams that are creating the technology around Kata,” Bryce continued, “it’s not actually a part of the traditional OpenStack cloud services projects like Nova, Swift, Neutron, and Cinder. This isn’t about what OpenStack adds to Kata. It’s actually a distinct project with separate governance, separate processes, separate teams.”
Bryce made clear to us that his firm’s financial backing and encouragement of the newly rechristened Kata project is not an effort to incorporate a complete container platform into OpenStack. Rather, it’s part of a broader strategy to ensure the existence of a secure containerized infrastructure that is more applicable to the virtual machine-oriented architecture around which OpenStack has always been based.
Put another way, Kata may maintain an open channel between OpenStack and at least one viable container platform with ties to Kubernetes. And it could accomplish this without OpenStack having to radically restructure itself, as earlier last year it appeared it might have to do.
A Merger of Isolation
As current Hyper.sh Chief Operating Officer James Kulina told The New Stack, Kata — whose GitHub page has just been launched — will incorporate Clear Containers using Hyper’s runV (run · vee) container runtime, or a form of it. From the perspective of a container engine such as Docker’s, runV is functionally equivalent to runC — meaning, any engine expecting to communicate with runC won’t be unpleasantly surprised. The runV component’s principal, and perhaps only, difference (outside of performance measurements, which for Kata have yet to be determined) is that it is geared to generate a micro-VM — a small virtual machine, but not so small that a hypervisor would treat it as a foreign object.
Hyper’s original mission was to present a truly isolated, but networked, container, using the same technology with which a hypervisor isolates a VM. Intel created that technology, so evidently Hyper had already attracted the chip maker’s attention.
“What is the problem with containers? Essentially, it’s using software-based isolation — namespaces, cgroups,” Kulina told one of Kata’s initial working group meetings. “And there’s a shared kernel problem, where if on a single host you have multiple containers, if one of those containers gets exploited, you can potentially have access to all the other containers on that host.
“What people typically do in the public cloud and other environments,” he continued, “is use hypervisors and virtualization, hardware-enforced isolation. People actually trust that. The public clouds are all based on hypervisors, all based on virtualization. And no one is complaining about the actual virtualization. What they actually complain about is the VM — the fact that you have to emulate the entire machine. With containers, you don’t emulate the entire machine; you’re just launching and deploying your application code into an Open Containers Initiative (OCI) spec, or a Docker image. We took the approach of, can we secure the container without all the bloat, all the baggage that comes along with traditional virtual machines?”
Intel’s and Hyper’s projects addressed this problem in parallel, though Kulina implied, not entirely isolated from one another. Their results were somewhat similar. And both went on to address what he characterized as a critical problem in containerized environments: the layering of environments, such as Kubernetes on OpenStack, or OpenStack on Kubernetes, or even Kubernetes on OpenStack on Kubernetes — all of which were demonstrated (with straight faces) at OpenStack Summit in Boston last May.“Container orchestration is a layer in the stack, and what Kata does is remove an entire layer,” Kulina told The New Stack.
“Instead of having a container orchestration layer and an infrastructure-as-a-service layer, they’re basically combined,” he continued. “You have containers as first-class citizens, and that’s the only thing you work with or care about — it’s the thing that’s actually being orchestrated by Kubernetes or Swarm, or whatever engine you’re using. With Kata, you’re able to reduce that stack, and create a true Containers-as-a-Service system.”
Interchangeable Parts
Bryce told us he expects the new platform to be able to leverage existing OpenStack community projects to their benefit. One such platform he named specifically was Zun, an independent effort to enable an API to launch and provision containers managed by OpenStack. He compared Zun to AWS’ Fargate service, which completely abstracts the VM management process from AWS customers who spin up containers in its public cloud.
Clear Containers are Intel’s implementation of containerization that follows the OCI specification, but which utilizes its own VT technology to enable a direct link between the VM and the hypervisor, bypassing the operating system. This way, malicious code that infiltrates the OS through a browser cannot hijack a VM, since the OS effectively tolerates, so to speak, the VM without managing it directly.
While Intel is officially contributing Clear to the Kata project, it’s doubtful that Intel’s marketing for Clear will be replaced with Kata. Hyper’s Kulina told The New Stack that, for the next few weeks or maybe months, the Clear platform and the Hyper platform will continue to be identified separately, until their respective development teams achieve what he called “parity” with respect to their platforms’ contents, at which time they’ll begin being presented as a joint platform to the open source community.
Already, word of the Kata project’s launch has generated some confusion, which is often the case with first impressions. The Hyper runtime which will be incorporated into Kata is runV, which is actually the “executive” that runs commands. There is another container runtime that receives commands from API calls, and for most standardized containers, that’s containerd — the component that Docker Inc. donated to the Cloud Native Computing Foundation last year. (A stable 1.0 version of containerd has just been released.) In a Kata system, containerd would not be replaced with runV. Indeed, they would work together, and as Hyper’s James Kulina told us, his group has already been collaborating with the CNCF to ensure smooth operation.
More accurately, runV is an alternate to runc (run · see), the container runtime executive originally introduced by Docker Inc. and contributed to the Linux Foundation in 2015.
(It’s also worth reiterating that Hyper’s runV is not at all related to Microsoft’s Hyper-V, its hypervisor for Windows.)
The Kata platform will support container orchestration, but will not absorb the functionality of an orchestrator — meaning, it won’t compete with Kubernetes, nor will it try to be Kubernetes. Last year, Hyper CEO Peng Zhao introduced The New Stack to what he called at the time “Hypernetes,” describing it as a fusion between Kubernetes and OpenStack’s Neutron component for managing software-defined networks.
That element will continue to be supported, Hyper’s Kulina told us, but in the form of Stackube, now a separate and independent project spun off from Zhao’s efforts. Stackube is a distribution of OpenStack that does not refer to itself as a “fork,” combining Neutron and the Cinder storage service with Kubernetes in place of Nova as the compute fabric controller.
Stand Alone
Last May at OpenStack Summit, Bryce told the audience he perceives a forthcoming time when the unit of compute power which cloud services customers purchased and provisioned, would be smaller than it is now. He did not go into further detail, but he didn’t have to. Containers-as-a-Service (CaaS) would give these customers the means of spinning up applications without being concerned with the underlying VM. They wouldn’t be leasing hosts, in other words, but images.
So does Bryce perceive Kata as the means by which OpenStack could deliver CaaS as an effective and complete alternative to what has been, and continues to be, the instrument of the cloud: the instance?
“I think that’s definitely an approach that we see gaining traction with new applications that are being developed,” responded Bryce, stopping well short of declaring CaaS as the future system of record. “I think that virtual machines will be around for many years to come, just because they provide a standard environment that looks and acts like a server — which means that it can run any workload out there. It doesn’t require a lot of customization [or] custom development. Virtual machines are not going to go away. But what containerization does is allow you to think about how you package the elements of your application, the specific code that you’re running, in a way that is more manageable on the infrastructure side.”
The OpenStack Foundation’s investment in the Kata project could effectively legitimize a means by which the OpenStack platform may utilize secure containers, and even Kubernetes, without the creation of new OpenStack components or the overhaul of existing ones. Indeed, that may be the factor that makes Kata valuable to the platform: the doors it opens for OpenStack, without OpenStack having to relocate the doors it’s already built.
Although Kata would not officially be a component of the OpenStack platform, it would give OpenStack a clear path to a self-service system for instantiating and provisioning containers on a hybrid cloud. And although Capital One, CERN, eBay, and other OpenStack customers have already rolled their own solutions for integrating OpenStack with Kubernetes, Kata could potentially present other organizations with an alternative to having to follow in their footsteps.
