A Guide to Container Runtimes

Kubernetes, also known as K8S, is an open-source container orchestration system that is used for automating the deployment, scaling, and management of containerized workloads. 

Containers are at the heart of the Kubernetes ecosystem and are the building blocks of the services built and managed by K8S. Understanding how containers are run is key to optimizing your Kubernetes environment.

What Are Containers and Container Runtimes?

Containers bundle applications and their dependencies in a lightweight, efficient way. Many people think Docker runs containers directly, but that's not quite accurate. Docker is actually a collection of tools sitting on top of a high-level container runtime, which in turn uses a low-level runtime implementation. Runtime systems dictate how the image being deployed by a container is managed. 

Container runtimes are the actual operators that run the containers in the most efficient way, and they affect how resources such as network, disk, performance, I/O, etc., are managed. So while Kubernetes orchestrates the containers, such as where to run containers, it is the runtime that executes those decisions. Picking a container runtime thus influences the application performance.

Container runtimes themselves come in two flavors: high-level container runtimes that handle image management and container lifecycle, and low-level OCI-compliant runtimes that actually create and run the containers.

Low-level runtimes are basically libraries that a developer of high-level runtimes can make use of while developing high-level runtimes to make use of the low-level features. A high-level runtime receives instructions, manages the necessary image, and then calls a low-level runtime to create and run the actual container process.

What High-Level Container Runtime Should You Choose?

There are various studies that compare the low-level runtimes, but it is also important that high-level container runtimes are chosen carefully.

• Docker: This is a container runtime that includes container creation, packing, sharing, and execution. Docker was created as a monolithic daemon, dockerd, and the docker client program, and features a client/server design. The daemon handled the majority of the logic for creating containers, managing images, and operating containers, as well as providing an API.
• ContainerD: This was created to be used by Docker and Kubernetes, as well as any other container technology that desires to abstract out syscalls and OS-specific functionality in order to operate containers on Linux, Windows, SUSE, as well as other operating systems.
• CRI-O: This was created specifically as a lightweight runtime only for Kubernetes and can handle only those kinds of operations.

The runtimes mentioned are popular and are being offered by every major cloud provider. While Docker, as the high-level container runtime, is on its way out, the other two are here to stay.

Parameters to Consider

• Performance: ContainerD or CRI-O is generally known to have better performance since the overhead of operations is lower. Docker is a monolithic system that has all the feature bits required, which increases the overhead. Although the network performance between the two is not very different, either can be chosen if that is an important factor.
• Features: Since ContainerD is a lightweight system, it does not always have all the features if that is an important consideration, whereas Docker has a large feature set. When comparing ContainerD to CRI-O, CRI-O has a smaller feature set since it only targets Kubernetes.
• Defaults: A lot of the cloud providers have recommendations for the managed container runtimes. There are benefits to using them directly since they should have longer support.

Why Should You Consider Manual Deployment?

Till now, I have talked about managed K8S deployment, which is provided by the major cloud providers such as Amazon, Microsoft, Google, etc. But there is another way of hosting your infrastructure — manage it on your own.

This is where manual deployment comes in. You have full control over every single component in your system, giving you the ability to remove unnecessary features. But it introduces the overhead of managing the deployment.

Conclusion

It becomes vital to jot down the use case that is being tried to achieve while making decisions. For some cases, a manual deployment would be better, whereas in other cases, a managed deployment would win. By understanding these different components and trade-offs, you can make better informed decisions about configuring your high-level container runtime for optimal performance and manageability.