containerd
summary
containerd exposes clear component boundaries and extensible plugins so teams can add custom snapshotters and integrate alternate runtimes. CRI support and simple flag-based migration let clusters replace dockerd with containerd; GKE already trials containerd on masters and plans broader rollout. Runtime sandboxing works via a new shim v2 abstraction that lets gVisor and Kata implement their own lifecycle and metrics handling. Microbenchmarks show better resource use — notably a 105-pod startup benchmark where containerd outperforms dockerd — and the integration path and APIs are production-ready.
AI-written summary · about
chapters (19)
- 0:00Start
- 2:20containerd matures
- 4:34Client-Server Design
- 6:49Summary
- 8:11Pull Image
- 10:31Plugin Registration
- 11:18Recompiled with 3th party plugins
- 12:34Support Proxy
- 13:10Remote snapshotter service
- 13:49Why external runtime plugins?
- 15:25Runtime v2 API
- 17:19CRI Runtimes
- 20:08Architecture
- 20:43Performance
- 24:03Containerd in GKE
- 25:13Container Escape
- 29:26Shim V2 is Now a Standard
- 31:38GKE Sandbox Status
- 31:56Recap
related talks
01h 17mIntro + Deep Dive: containerd
39mMore Than Secure: Containerd + KataContainers as Kubernetes Runtime
34mLet's Try Every CRI Runtime Available for Kubernetes. No, Really!
37mProject Update and Deep Dive: Containerd
32mFive things you need to know about your container runtime
35mWhat Container Runtime Do I Need?
27mKeep Calm and Containerd On!
37mLet's Try All the CRI Runtimes: Part 2: Answering the Why Question!
