Introduction

We’re diving deep into the world of container runtimes, their evolution, and their crucial role in Kubernetes. We’ll explore the journey from Docker to Containerd, understand various CLI tools, and clarify some common confusions in the container ecosystem.

The Evolution of Container Runtimes

The Docker Era

Let’s start at the beginning of the container era. In the early days, Docker reigned supreme:

• Docker revolutionized containerization with its user-friendly experience.
• It quickly became the dominant container tool, overshadowing alternatives like rkt.
• Kubernetes was initially built to orchestrate Docker containers specifically.

The Need for Flexibility

As Kubernetes grew in popularity, a need for greater flexibility emerged:

• Other container runtimes (like rkt) wanted to integrate with Kubernetes.
• Kubernetes users desired support for container runtimes beyond Docker.

Enter CRI: Container Runtime Interface

To address this need, Kubernetes introduced the Container Runtime Interface (CRI):

• CRI allowed any vendor to create a container runtime for Kubernetes.
• The condition: adherence to OCI (Open Container Initiative) standards.

OCI Standards

The OCI defined two crucial specifications:

1. Imagespec: Defines how container images should be built.
2. Runtimespec: Outlines standards for developing container runtimes.

These standards ensured interoperability and consistency across different container technologies.

The Docker Dilemma

Despite the introduction of CRI, Docker posed a unique challenge:

• Docker wasn’t initially built to support CRI standards.
• Yet, it remained the most widely used container tool.

Kubernetes’ solution:

• Introduced “dockershim” – a temporary bridge to support Docker outside of CRI.
• This allowed continued Docker support while other runtimes used CRI.

Understanding Docker’s Architecture

It’s crucial to understand that Docker isn’t just a container runtime:

• Docker CLI: The user interface.
• Docker API: For programmatic interactions.
• Build tools: For creating container images.
• Volume management: For persistent storage.
• Authentication and security features.
• runC: The actual container runtime.
• Containerd: The daemon managing runC.

The Rise of Containerd

Containerd, originally part of Docker, became a standalone project:

• CRI-compatible, allowing direct interaction with Kubernetes.
• Can be used independently of Docker.
• Graduated status in the Cloud Native Computing Foundation (CNCF).

Kubernetes 1.24: A Turning Point

With the release of Kubernetes 1.24, a significant change occurred:

• Dockershim was removed.
• Direct support for Docker engine was discontinued.
• However, Docker-built images still work due to OCI compliance.

Working with Containerd

Installation and Basic Usage

• Containerd can be installed without Docker.
• Ideal for environments not requiring Docker’s additional features.

Command Line Tools

1. ctr:
   • Comes with Containerd installation.
   • Primarily for debugging Containerd.
   • Limited feature set, not user-friendly for production use.

Example commands:

ctr images pull docker.io/library/redis:latest

ctr images pull docker.io/library/redis:latest

ctr run docker.io/library/redis:latest redis

2. nerdctl (nerd control):
   • Docker-like CLI for Containerd.
   • Supports most Docker options plus additional features:
     • Encrypted container images
     • Lazy pulling of images
     • P2P image distribution
     • Image signing and verifying
     • Kubernetes namespace support

Usage is similar to Docker CLI:

nerdctl run -p 8080:80 nginx

nerdctl pull mysql:5.7

3. crictl (CRI control):
   • Developed by the Kubernetes community.
   • Works across all CRI-compatible runtimes.
   • Primarily for inspection and debugging.
   • Not ideal for creating containers (conflicts with kubelet).

Example commands:

crictl pull nginx

crictl ps

crictl exec -it container_id /bin/bash

crictl logs container_id
crictl pods

Comparing CLI Tools

ctr vs nerdctl vs crictl

Feature	ctr	nerdctl	crictl
Purpose	Debugging Containerd	General container management	Debugging CRI-compatible runtimes
User-friendliness	Low	High (Docker-like)	Medium
Feature set	Limited	Extensive	Focused on debugging
Community	Containerd	Containerd	Kubernetes
Runtime support	Containerd only	Containerd only	All CRI-compatible runtimes

Changes in Kubernetes 1.24

• Default endpoints for crictl were updated.
• dockershim.socket replaced with cri-dockerd.sock.
• Users are now encouraged to manually set endpoints.
• Refer to Kubernetes cri-tools GitHub repo (PR #869 and Issue #868) for details.

Practical Implications

1. For Developers:
   • Transition from Docker CLI to nerdctl for local development.
   • Understand basic crictl commands for debugging in Kubernetes environments.
2. For DevOps/SRE:
   • Familiarize with crictl for Kubernetes cluster troubleshooting.
   • Consider Containerd for lightweight container runtime needs.
3. For Kubernetes Administrators:
   • Update scripts and workflows to use crictl instead of Docker commands.
   • Be aware of the removal of dockershim and its implications.

Future Trends

• Increased adoption of Containerd as the primary container runtime.
• More features being developed for nerdctl, potentially surpassing Docker CLI.
• Continued standardization in the container ecosystem.

Conclusion

The container ecosystem has evolved significantly from the early days of Docker dominance. Understanding the roles of different runtimes and CLI tools is crucial for effective container and Kubernetes management. As we move forward, expect further innovations and standardizations in this rapidly evolving field.

Remember:

• Use nerdctl for Docker-like functionality with Containerd.
• Leverage crictl for debugging and inspecting containers in Kubernetes environments.
• Stay updated with the latest Kubernetes releases for changes in container runtime support.

Thank you for joining me on this deep dive into container runtimes and Kubernetes. Happy containerizing!