containerd

### Overview This presentation examines the architecture of containerd, its integration with Kubernetes via the Container Runtime Interface (CRI), and its application within Google Kubernetes Engine (GKE) and GKE Sandbox using gVisor. The speakers highlight the benefits of migrating from Docker (dockershim) to containerd, demonstrate performance and operational improvements, and explain how containerd's extensible plugin system and runtime architecture accommodate security sandboxing technologies.

### Key Topics - **containerd Architecture & Modularity**: containerd provides modular boundaries separating storage formats, namespaces, snapshotters, and content management. It offers extensibility through internal and proxy plugins without requiring back-end code modifications. - **Kubernetes CRI Integration**: Moving from dockershim to direct containerd CRI integration eliminates intermediate layers, improving stability and performance in pod startup benchmarks and management overhead. - **GKE Adoption**: GKE's transition path from Docker to containerd across master nodes and worker nodes, progressing from beta toward default/General Availability (GA). - **GKE Sandbox & gVisor Security**: Addressing shared Linux host kernel escape risks by running an OCI-conformant user-space kernel (gVisor) in Go. containerd's Shim v2 abstraction standardizes interactions between Kubernetes and distinct container runtimes. - **containerd vs. CRI-O**: Runtime alternatives in Kubernetes, noting industry backing (e.g., Google, Docker, Microsoft maintaining containerd; Red Hat and Intel backing CRI-O).

### Technical Details - **Extensibility via Plugins**: containerd supports proxy plugins that allow third-party upstream request forwarding (for custom snapshotters or content management) over defined service APIs. - **Performance Benchmarks**: Benchmarks conducted with 105 pods (the default supported pod limit) demonstrate that direct containerd CRI integration outperforms dockershim in startup time, management overhead, and resource consumption. - **Transitioning from Docker**: Systems running Docker 18.x already package containerd. Users can configure CRI flags and plugins to bypass dockershim and point Kubernetes directly to containerd. - **Isolation with gVisor & Shim v2**: In standard runC execution, containers share the host Linux kernel. With gVisor, application system calls are handled by an independent user-space kernel, preventing direct host kernel access. Because standard container monitoring (process monitoring, exit signaling, and stats collection) cannot read the host kernel for gVisor processes, the containerd community introduced **Shim v2**. Shim v2 acts as an abstraction layer to manage custom runtime behaviors, which integrates into Kubernetes via the `RuntimeClass` API. - **Alternative Sandboxing**: The Shim v2 approach also accommodates virtualization-based runtimes such as Kata Containers.

### Takeaways - Kubernetes clusters should transition away from legacy dockershim to direct CRI implementations like containerd to ensure continued maintenance, feature support, and security fixes. - For environments requiring strong isolation against kernel escape vulnerabilities, GKE Sandbox combines Kubernetes, containerd, and gVisor through Shim v2. - While Docker and Kubernetes can share an underlying containerd daemon, their namespaces and visibility remain separated.