Kubernetes has made a significant architectural change: the removal of Dockershim with the release of v1.24. This means Kubernetes now relies exclusively on containerd as its container runtime interface (CRI).

Let's explore why this change happened, the implications for Kubernetes users, and what it means specifically for AWS EKS.

Why containerd?

  • CRI Alignment: Containerd was designed specifically to align with the Container Runtime Interface (CRI) specification created for Kubernetes. This ensures seamless integration and reduces unnecessary complexity.
  • Simplicity and Stability: Containerd has a smaller footprint and streamlined architecture compared to Docker. This translates to less overhead, improved efficiency, and a more stable runtime environment.
  • Feature Focus: Containerd focuses on core container runtime operations like image management and container execution. Docker has numerous additional features (swarm, etc.) not essential for Kubernetes.
  • Community Momentum: Many cloud and containerization projects adopted containerd due to its focus and stability, creating a broader and more active ecosystem.

Deprecation and Removal

  • Deprecation: The deprecation of Dockershim was announced in Kubernetes version 1.20.
  • Removal: Dockershim was officially removed in Kubernetes version 1.24.

AWS EKS Alignment

AWS EKS followed suit in aligning with this container runtime change. Here's what you need to know:

  • New AMIs: Starting with Kubernetes version 1.24, official EKS AMIs (Amazon Machine Images) include containerd as the only runtime.
  • Migration Process: If you were using EKS with Docker before version 1.24, you'll need to follow migration steps to transition your nodes to containerd. AWS provides detailed guidance on this process.

What about Docker?

It's important to emphasize that Docker, the larger product, is still alive and well! It's the Docker engine, specifically the runtime component, that's less relevant within Kubernetes. Docker remains a powerful development tool for building and packaging container images.

Key Impacts for Kubernetes Users (Including EKS)

  1. Operational Change: If you previously used Docker commands directly on Kubernetes nodes, you'll need to switch to tools like ctr (containerd CLI) or crictl (for CRI interactions).
  2. Upgrade Considerations: Ensure you understand the implications of the transition when upgrading Kubernetes clusters, especially on EKS. Check compatibility and follow official migration guides.
  3. Long-term Simplification: While a transition period exists, moving to containerd simplifies the Kubernetes stack and potentially reduces troubleshooting complexity.

What To Do

  • Read the Docs: Refer to official Kubernetes and AWS EKS documentation for the most up-to-date information and migration guides.
  • Assess Dependencies: Check if any tooling or scripts you use directly interact with the Docker engine. You may need to update these.
  • Educate Your Teams: Make sure developers and operators are aware of the change and any adjustments needed in workflows.

Additional Sources