Kata Containers, Docker and Kubernetes: How They All Fit Together

By now, virtually everyone has heard of Docker containers. But you may still be unfamiliar with Kata, an open-source container project launched in December of 2017. Kata emerged at a time when the container ecosystem was already crowded with other projects, making it easy to miss.

Yet, despite being a late arrival to the containerization party, Kata is developing into an important project — not least because it promises to let developers and IT teams have their cake and eat it, too, by delivering both the performance of Docker containers and the security of virtual machines.

Here’s a look at how Kata does that, how it is similar to and different from Docker, and (the question we know you’re also asking) what all of this has to do with Kubernetes.

What are Kata containers?

In a nutshell, Kata is a container runtime designed to provide greater isolation between containers while still enabling the performance and efficiency provided by other runtimes.

Now, you may be thinking, “Why!? The last thing the world needs is yet another container runtime.” That’s a fair question to ask; between cri-o, containerd, rktlet, and Docker (to name just the most widely used runtimes), there was no shortage of runtime options before Kata came along.

But Kata is not just another container runtime. Although Kata is similar to other runtimes in most respects, there is one critical difference: the Kata runtime enforces a deeper level of isolation between containers than other runtimes.

It does this in two main ways:

In Kata, each container runs its own kernel instead of sharing the host system’s kernel with the host and other containers using cgroups. By extension, each container also gets its own I/O, memory access, and other low-level resources, without having to share them.
In most cases, Kata containers can also take advantage of security features provided by hardware-level virtualization (meaning virtualization that is built into CPUs and made available using VT extensions).

And Kata does both of these things while avoiding the heavy resource consumption that comes with traditional virtualization. Unlike virtual machines, which can take a minute or two to start and waste a fair amount of hardware resources on isolation, Kata containers aim to start just as fast and consume resources just as efficiently as other containers.

Thus, the chief objective of the Kata project is to allow developers and IT teams to enjoy all the flexibility of traditional container runtimes, without the worry that a security breach in one container will escalate to affect other containers running on the same host. It eliminates the need to deploy different sets of containers inside virtual machines in order to achieve rigid isolation between the sets — a practice that, to date, has been widespread, but which undercuts one of the core benefits of containers: their ability to run faster and more efficiently than virtual machines.

Kata vs. Docker (and other container runtimes)

Given Kata’s ambitions of doing containers better than Docker, the platform that brought containers into the mainstream starting in 2013, it’s natural to want to compare Kata to Docker.

Such a comparison only makes partial sense, though, because Kata and Docker are not the same things. Kata is just a runtime, whereas Docker is a full suite of tools (some commercial, some open source) designed to create, orchestrate, and manage containerized applications.

Still, we can draw several major distinctions between Kata and Docker (as well as other container runtimes that are not Kata):

Security and isolation: The most obvious difference is Kata’s deeper level of isolation and security between containers, as described above.
Operating system support: Currently, Kata runs only on Linux. Some other container runtimes, such as containerd, support both Linux and Windows.
Architecture support: Kata can run on CPUs built using the x86_64 architecture, as well as on ARM, IBM p-series, and IBM z-series architectures. Most other container runtimes provide full support only for x86_64. (Some also support ARM, but there are limitations in most cases.) For this reason, Kata may become an important containerization solution for enterprise infrastructures that are built using architectures that haven’t received much love from the Docker community, which has focused on commodity x86 servers.
Backers: From an ecosystem standpoint, Kata stands out because the project is led by the OpenStack Foundation, a nonprofit best-known for its role in overseeing development of the OpenStack private cloud platform. OpenStack has declined in influence in recent years, and Kata might be the OpenStack Foundation’s way of reasserting its relevance in the modern, container-focused age (which has been dominated so far by the Cloud Native Computing Foundation, the open source group behind Kubernetes). It’s unclear what, if anything, the origins of Kata might mean for how the technology is actually used, but it could have implications for which integrations for the technology are built.

Kata and Kubernetes

If you’re wondering whether Kata can be used with Kubernetes, the answer is a resounding yes. Despite the fact that Kata and Kubernetes are developed under the auspices of different organizations, they are not intended to compete with each other. Kata is a container runtime, whereas Kubernetes is a container orchestrator that can work with containers created using many different runtimes.

To put it in more technical terms, Kata adheres to the Open Container Initiative (OCI) standard, which Kubernetes supports. You can, therefore, use Kubernetes to orchestrate your Kata containers very easily.

In fact, if you want to test out Kata under Kubernetes, the Kata project has a prebuilt deployment configuration that you apply to your cluster with just a couple of Kubectl commands.

Conclusion

Kata is not a new kid on the block who is out to compete with established container technologies like Docker and Kubernetes. It’s a project that adds a fundamentally new type of functionality to the container ecosystem by providing a stronger isolation model. It squares the circle separating containers from virtual machines, allowing teams to get the best of both worlds.

Kata is well worth a look if you’ve always wanted to use containers, but were scared off by their comparatively weak isolation architecture relative to virtual machines — or if you have been deploying containers inside virtual machines in order to achieve more isolation, but are tired of waiting minutes for those virtual machines to start.

Author
Recent Posts

Platform9

Platform9 is the only container management and orchestration solution that supports the complete lifecycle of the cloud-native journey on infrastructure anywhere. Our unique management plane simplifies operations, including observability & monitoring, increases uptime, minimizes costs, and scales as you scale. Built on open foundations, our platform enables enterprises to keep up with the ever-changing cloud-native ecosystem. Our cloud-native wizards provide Always-on Assurance™ every step of the way to ensure a smooth, simplified journey. Innovative enterprises like Juniper, Kingfisher Plc, Mavenir, Redfin, and Cloudera achieve 4x faster time-to-market, up to 90% reduction in operational costs, and 99.99% uptime.Platform9 is a better way to go cloud native, paving the way for an open distributed cloud