Kubernetes, a leading platform for container orchestration, continually evolves to meet the demands of modern applications. One significant advancement is the deprecation of Dockershim support, as announced in the Kubernetes 1.20 release. This deprecation reflects Kubernetes' shift towards Container Runtime Interface (CRI) compatibility, with `containerd` emerging as a popular alternative. One prominent use case in this context is "Docker-In-Docker" (DIND) on `containerd`. In this article, we delve into the technicalities of Dockershim deprecation, DIND's role, and how `containerd` fits into this architecture.

Understanding Dockershim Deprecation

Dockershim was an intermediate layer in Kubernetes, allowing it to interact with Docker for container runtime services. However, Dockershim introduced additional complexity, deviation from the CRI, and maintenance overhead. Consequently, Kubernetes announced its deprecation to encourage users to adopt direct CRI-compatible runtimes, thereby improving efficiency and simplification.

Key Reasons for Deprecation:

• CRI Conformity: Kubernetes aims for compatibility with CRI-based runtimes, allowing smoother integration and standardized communication with various container technologies.
• Reduced Complexity: The presence of Dockershim added an extra abstraction layer, complicating the Kubernetes-Docker interaction.
• Performance Improvements: Native CRI-compatible runtimes often provide direct performance enhancements by eliminating additional translation layers.

Docker-In-Docker (DIND) and containerd

Docker-In-Docker is a concept where Docker runs inside a Docker container. Developers frequently use DIND for CI/CD pipelines, allowing containers to build and run other containers. With the transition from Dockershim to `containerd`, using DIND with `containerd` becomes pertinent.

Setting Up DIND with containerd

Running DIND over `containerd` involves setting up containers that can execute Docker commands. Here's a step-by-step guide:

1. Environment Setup:
   • Install `containerd` based on your OS.
   • Ensure container runtime integration.
2. Configuring containerd:
   • Utilize the `cri` plugin available in `containerd` for optimal Kubernetes integration.
   • Configure `containerd` using its default configuration file located at `/etc/containerd/config.toml`.
3. Running DIND:
   • Launch a base container that can run Docker:
   • Inside this container, Docker commands can execute to run further containers.
   • Ensure the DIND container has appropriate network access to manage containers.
   • Persistent volumes may be necessary for building images or maintaining state.

• Security: Running DIND necessitates heightened security measures since it requires privileged access. Use network policies and stringent IAM roles.
• Compatibility Testing: Always test application compatibility with `containerd`, as subtle differences might exist when compared to Docker.
• Monitoring: Leverage monitoring tools that are compatible with CRI runtimes to gain insight into container health and performance.
• Lightweight Runtime: `containerd` is specifically designed to be a lightweight runtime suitable for managing the entire container lifecycle.
• Enhanced Integration: `containerd` closely integrates with Kubernetes via CRI, fostering improved performance and stability.
• Community Support: Active community development ensures that `containerd` remains a cutting-edge tool.