Solutions
Audit & Optimization Platform Design Automation Team Structure
Documentation Blog
Get Started
Kubernetes Runtime 2016

CRI & CRI-O: Opening Kubernetes to New Container Runtimes

K8s Guru
2 min read
#cri #cri-o #runtime #containers
CRI & CRI-O: Opening Kubernetes to New Container Runtimes

Table of Contents

Introduction

For most of Kubernetes’ early life, Docker was the one-and-only runtime. As container standards solidified around the Open Container Initiative (OCI), Kubernetes SIG Node designed the Container Runtime Interface (CRI), a pluggable gRPC API between kubelet and runtimes. In parallel, Red Hat launched CRI-O, a lightweight implementation mapping CRI calls to OCI-compliant runtimes.

Why CRI Matters

  • Pluggability: kubelet speaks CRI, allowing runtimes like Docker, rkt, and CRI-O to implement the same API.
  • Decoupled Release Cadence: New runtime features ship without waiting for Kubernetes core merges.
  • Security & Footprint: Operators can swap Docker for minimal runtimes purpose-built for Kubernetes.
  • Standards Alignment: CRI builds on OCI image and runtime specs, fostering ecosystem interoperability.

CRI-O Architecture

  • CRI gRPC Server: Listens for RunPodSandbox, CreateContainer, StartContainer, and related calls from kubelet.
  • runc Backend: Uses runc (OCI runtime) to spawn containers, pulling images via containers/image.
  • Storage Layer: Leverages overlayfs, devicemapper, or other graph drivers through containers/storage.
  • Networking: Integrates with CNI plugins identical to kubelet’s expectations.
  • Instrumentation: Exposes metrics and logging hooks for debugging runtime operations.

2016 Status

  • Alpha: CRI APIs landed behind feature gates in Kubernetes 1.5—the Docker shim remained default but CRI paths compiled in.
  • CRI-O Milestones: Early GitHub releases demonstrated running Pods with ocid (the original daemon name) plus runc.
  • rktnetes: CoreOS continued work on rkt CRI integration, showing the diversity CRI enabled.
  • RuntimeClass Discussions: Conversations began about surfacing runtime choices per workload, eventually leading to the RuntimeClass API.

Operational Considerations

  • Feature Parity: Docker-specific features (log drivers, stats) weren’t fully mirrored; plan validation before switching.
  • Debugging Tooling: crictl and ocic were introduced for runtime troubleshooting, replacing docker ps habits.
  • SELinux/AppArmor: CRI-O aligned tightly with SELinux defaults, giving Red Hat distributions a more secure baseline.
  • Upgrades: Rolling out CRI required restarting kubelets with the --container-runtime=remote flag and pointing to the CRI socket.

Future Outlook

  • Remove the in-tree Docker shim and converge on CRI-only runtimes.
  • Integrate Kata Containers and gVisor-style sandboxes via CRI implementations.
  • Extend the API for image filesystem stats, checkpoint/restore, and richer logging.

Conclusion

2016’s CRI and CRI-O work signaled Kubernetes’ transition from “Docker orchestrator” to a runtime-agnostic platform. The abstraction unlocked innovation across secure, minimal, and specialized runtimes that would flourish in subsequent releases.