OCI, CRI, ??: Making Sense of the Container Runtime Landscape in Kubernetes - Phil Estes, IBM
summary
OCI forms the interoperability layer born in 2015 with the runtime spec and runc implementation (2017), and Kubernetes uses the CRI abstraction so any CRI-compliant runtime can plug in. Major implementations include containerd 18% adoption and cri-o 4% in surveys, containerd is now default in some managed services and Fargate, OpenShift defaults to cri-o, sandboxes like gVisor/Kata/Firecracker are usable via runtimeClass, and operators use crictl talking to the CRI socket for runtime-agnostic ops.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:27It all began with Docker
- 1:35Container Runtimes
- 3:04The OCI is Born
- 4:40A Common Substrate
- 6:09Ongoing OCI Focus
- 8:03Kubernetes...
- 8:32Kubernetes: Runtime
- 9:19Kubernetes: CRI
- 10:24Who implements the CRI?
- 13:05Current State of Runtimes
- 14:42Why Different Runtimes?
- 15:44Sandboxes
- 16:42Common Interface
- 18:00Summary
related talks
24mOCI, CRI, ??: Making Sense of the Container Runtime Landscape in Kubernetes
46mCRI-O: All the Runtime Kubernetes need
38mIntroduction to CRI-O
29mCRI-O: All the Runtime Kubernetes Needs, and Nothing More
34mContainer Runtime Evolving in Kubernetes
34mContainer Runtime Evolving in Kubernetes
31mCRI-O: The Runtime Control Room
42mCRI Runtimes Deep Dive: Who's Running My Kubernetes Pod!?
