QA
Senior LevelDocker & Deployment

Compare Container Runtime Interface (CRI) implementations: containerd vs CRI-O.

❓ Interview Prompt: Explain the Kubernetes CRI specification, containerd vs CRI-O architectures, and when to choose each for production Kubernetes deployments.

Container Runtime Interface (CRI) is a Kubernetes plugin API that allows kubelet to communicate with different container runtimes. It replaced direct Docker integration (removed in Kubernetes 1.24).

Why CRI Was Created:

Originally, kubelet had hardcoded Docker support (dockershim). As Kubernetes matured, the community wanted to support alternative runtimes (rkt, containerd, CRI-O) without touching kubelet code. CRI standardizes this interface.

containerd:

•
Origin: Split from Docker Engine in 2016; donated to CNCF in 2017.
•
Architecture: Full-featured daemon managing the complete container lifecycle: image pull, storage snapshots, container execution.
•
CRI Plugin: Built-in cri plugin exposes gRPC CRI endpoint (/run/containerd/containerd.sock).
•
Additional Users: Docker Engine (uses containerd as its backend), Kubernetes, AWS Fargate.
•
Strengths: Mature, battle-tested, excellent OCI ecosystem support, plugin architecture (Snapshotter, Runtime Handler).

CRI-O:

•
Origin: Red Hat project; CNCF incubating project.
•
Philosophy: Minimal, Kubernetes-specific container runtime. Implements only what Kubernetes needs via CRI.
•
Architecture: Lightweight daemon using libpod under the hood; delegates execution to runc or Kata.
•
No Docker support: Cannot run containers outside of Kubernetes (no crio CLI for standalone containers).
•
Strengths: Smaller footprint, Kubernetes-specific optimizations, preferred in OpenShift.

Code Implementation Example

bash
# Check which CRI is running on a node
kubectl get node node-1 -o jsonpath='{.status.nodeInfo.containerRuntimeVersion}'
# containerd://1.7.11   OR   crio://1.29.0

# --- containerd configuration ---
# /etc/containerd/config.toml
# [plugins."io.containerd.grpc.v1.cri"]
#   [plugins."io.containerd.grpc.v1.cri".containerd]
#     default_runtime_name = "runc"
#     [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
#       [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
#         runtime_type = "io.containerd.kata.v2"

# Interact with containerd directly (bypassing Docker)
ctr -n k8s.io containers list    # list Kubernetes containers
crictl --runtime-endpoint unix:///run/containerd/containerd.sock ps
crictl logs <container-id>

# --- CRI-O configuration ---
# /etc/crio/crio.conf
# [crio.runtime]
# default_runtime = "runc"
# [crio.runtime.runtimes.kata-containers]
#   runtime_path = "/usr/bin/containerd-shim-kata-v2"

# Interact with CRI-O
crictl --runtime-endpoint unix:///var/run/crio/crio.sock ps
💡containerd: full-featured CRI with Docker support. CRI-O: lightweight K8s-only CRI. Both work with crictl for debugging.
🎯 Interview Key Takeaway

containerd = Docker-derived, full-featured, supports both Docker and K8s. CRI-O = lightweight, K8s-only, minimal footprint. Both support runc and sandboxed runtimes. containerd is more widely deployed.

#CRI#containerd#CRI-O#Container Runtime#Kubernetes#Senior
Back to all Docker & Deployment Questions→

More Docker & Deployment Interview Questions

Beginner LevelDocker & Deployment

How do Docker Multi-Stage Builds minimize image size and improve security?

Beginner LevelDocker & Deployment

What is the difference between a Docker Container and a Virtual Machine (VM)?

Beginner LevelDocker & Deployment

What is the difference between a Docker Image and a Docker Container?