“container-d” Why Kubernetes Embraced container-d Over Docker?

Introduction:

Kubernetes, the open-source container orchestration platform, has been a game-changer in the world of containerized applications. Over the years, Kubernetes has evolved, and one noticeable shift has been the move from Docker as the default container runtime to Container-D. In this blog post, we’ll explore the reasons behind Kubernetes choosing Container-D over Docker and the implications of this strategic decision.

What is CRI and OCI?

Before going in depth, we need to understand what is CRI and OCI. In Kubernetes, CRI (Container Runtime Interface) and OCI (Open Container Initiative) are two important specifications that play crucial roles in the container ecosystem. Let’s explore each of them:

1. CRI (Container Runtime Interface):

• Definition: CRI is an interface and set of protocols that define how container runtimes (such as Docker, Container-d, cri-o, etc.) interact with the Kubernetes kubelet, which is the primary node agent that runs on each node in a Kubernetes cluster.
• Purpose: CRI was introduced to standardize the communication between Kubernetes and container runtimes, allowing Kubernetes to be agnostic to the underlying container runtime. This separation enables users to choose different container runtimes without affecting the Kubernetes control plane.
• Components: CRI consists of two primary components: CRI API and CRI Runtime. The CRI API defines the methods for kubelet-container runtime communication, while the CRI Runtime is responsible for managing containers based on the CRI API.

2. OCI (Open Container Initiative):

• Definition: OCI is an open industry standard that defines the format and runtime for container images and containers. It provides specifications for container image formats and container runtimes, ensuring interoperability between different container runtimes and image formats.
• Purpose: OCI was established to address the need for a common, open standard for container formats and runtimes, allowing developers to build and run containers consistently across different container platforms.
• Components: OCI consists of two specifications: OCI Image Specification (OCI Image) and OCI Runtime Specification (OCI Runtime). OCI Image specifies the format for container images, while OCI Runtime specifies the configuration and execution of containers.

Docker vs. Container-D: What Is The Difference?

Docker and Container-d are both container runtimes, but they serve different roles in the container ecosystem. Here’s an overview of each:

1. Docker:
   • Scope: Docker is a comprehensive containerization platform that includes a container runtime, a container image format, and a set of tools for building, distributing, and managing containers.
   • Features:
     • Docker provides a user-friendly command-line interface (CLI) and a daemon process for managing containers.
     • It includes features such as container networking, storage management, and a registry for storing and sharing container images.
     • Docker also supports the Docker Compose tool for defining and managing multi-container applications.
2. Container-d:
   • Scope: Container-d is a lightweight, industry-standard container runtime that focuses specifically on the core functionality needed to manage containers.
   • Features:
     • Container-d provides a daemon that is responsible for the basic container operations, including pulling container images, container execution, and container lifecycle management.
     • It follows the Container Runtime Interface (CRI) specifications, making it compatible with container orchestration systems like Kubernetes.
     • Container-d is designed to be modular and extensible, allowing it to be embedded into higher-level container orchestration platforms.

Relationship between Docker and Container-d:

• Docker uses Container-d as its core container runtime. In other words, Docker includes Containerd as one of its components to handle low-level container operations.
• Docker initially had its own integrated container runtime, but as the container ecosystem evolved, Docker adopted Containerd to provide a standardized and modular runtime for container operations.

Differences:

• Abstraction Level:
  • Docker provides a higher-level abstraction with a more comprehensive set of features and tools.
  • Containerd offers a lower-level abstraction, focusing primarily on the basic container runtime functionalities.
• Extensibility:
  • Docker is designed as an end-to-end solution, and while it supports plugins, it is more opinionated and less modular.
  • Containerd is designed to be modular and extensible, allowing additional features to be added through plugins or integration with other tools.
• Use Cases:
  • Docker is suitable for developers and teams looking for an all-in-one solution with a user-friendly interface.
  • Containerd is often used in scenarios where a lightweight and modular container runtime is needed, especially in container orchestration systems like Kubernetes.

Which CRI’s kubernetes is supporting? Why Container-d?

1. Docker (Deprecated):
   • Historically, Docker was the default container runtime for Kubernetes.
   • However, the default support for Docker as a container runtime in Kubernetes has been deprecated, and users are encouraged to migrate to other runtimes.
2. Container-d:
   • Containerd is a lightweight and industry-standard container runtime.
   • It is widely used in the Kubernetes ecosystem and is a popular choice as an alternative to Docker.
   • Containerd follows the CRI specifications, making it compatible with Kubernetes.
3. cri-o:
   • cri-o is a lightweight and specialized CRI implementation designed specifically for Kubernetes.
   • It focuses solely on running containers in a Kubernetes environment without additional features not needed in that context.
   • cri-o has gained popularity for its simplicity and minimalistic approach.
4. Other Runtimes (e.g., rkt):
   • There are other CRI-compliant runtimes, such as rkt (pronounced “rocket”).
   • The Kubernetes community aims to maintain compatibility with various runtimes, allowing users to choose based on their specific needs.

Considerations for Choosing a CRI:

• Compatibility: Ensure that the CRI you choose is compatible with your Kubernetes version.
• Feature Set: Consider the features provided by the runtime. Some runtimes may offer additional functionalities beyond the CRI specifications.
• Performance: Evaluate the performance characteristics of the runtime based on your workload requirements.
• Community Support: Consider the community support and the ecosystem around the runtime.

Conclusion wrt Container-d:

The shift from Docker to Container-d as the default container runtime for Kubernetes is a strategic decision driven by factors such as standardization, modularity, simplicity, and industry trends. While Docker remains a powerful and widely-used container platform, containerd’s focus on essential container functionalities makes it an optimal choice for Kubernetes orchestration. The collaboration within the CNCF and the growing community adoption of containerd underscore its significance in the ever-evolving landscape of container orchestration. As Kubernetes continues to mature, the choice of containerd as the default runtime positions it for scalability, efficiency, and compatibility with the dynamic needs of containerized applications.

References:

https://kubernetes.io/docs/concepts/containers/runtime-class/

https://kubernetes.io/docs/concepts/architecture/cri/