CRI-O vs containerd: Kubernetes Container Runtime Guide

What Changed: Docker → containerd/CRI-O

Kubernetes removed Docker (dockershim) in v1.24. Now you choose between:

• containerd — Docker’s runtime extracted as standalone (CNCF graduated)
• CRI-O — Purpose-built for Kubernetes CRI (CNCF graduated)

Both implement the Container Runtime Interface (CRI) — Kubernetes doesn’t care which you use.

Architecture

Kubernetes (kubelet)
       │
       │ CRI gRPC
       ▼
┌─────────────────────┐    ┌─────────────────────┐
│     containerd      │    │       CRI-O         │
│  ┌───────────────┐  │    │  ┌───────────────┐  │
│  │   CRI Plugin  │  │    │  │  CRI Server   │  │
│  └───────┬───────┘  │    │  └───────┬───────┘  │
│          │          │    │          │          │
│  ┌───────▼───────┐  │    │  ┌───────▼───────┐  │
│  │   Snapshotter │  │    │  │   Storage     │  │
│  └───────┬───────┘  │    │  └───────┬───────┘  │
│          │          │    │          │          │
│  ┌───────▼───────┐  │    │  ┌───────▼───────┐  │
│  │     runc      │  │    │  │     runc      │  │
│  └───────────────┘  │    │  └───────────────┘  │
└─────────────────────┘    └─────────────────────┘

Feature Comparison

Performance Benchmarks

Tested on bare-metal (64 cores, 256GB RAM), 1000 pod deployment:

CRI-O is slightly more efficient because it does less — no plugin system, no non-CRI features.

Installation

containerd on Ubuntu

# Install from Docker repository
sudo apt-get update
sudo apt-get install -y containerd.io

# Generate default config
sudo containerd config default | sudo tee /etc/containerd/config.toml

# Enable SystemdCgroup (required for K8s)
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

sudo systemctl restart containerd

CRI-O on RHEL/Rocky

# Set K8s version to match
export KUBERNETES_VERSION=v1.31
export CRIO_VERSION=v1.31

# Add repos
curl -fsSL https://pkgs.k8s.io/addons:/cri-o:/stable:/$CRIO_VERSION/rpm/repodata/repomd.xml.key |   sudo gpg --dearmor -o /etc/pki/rpm-gpg/RPM-GPG-KEY-cri-o

# Install
sudo dnf install -y cri-o
sudo systemctl enable --now crio

Verify

# containerd
sudo crictl --runtime-endpoint unix:///run/containerd/containerd.sock info

# CRI-O
sudo crictl --runtime-endpoint unix:///var/run/crio/crio.sock info

Kubernetes Configuration

kubelet for containerd

# /var/lib/kubelet/config.yaml
containerRuntimeEndpoint: unix:///run/containerd/containerd.sock

kubelet for CRI-O

containerRuntimeEndpoint: unix:///var/run/crio/crio.sock

Security Considerations

containerd

• Supports multiple OCI runtimes (runc, kata, gVisor, youki)
• Namespace isolation for multi-tenant
• Image verification via content trust
• AppArmor and SELinux profiles

CRI-O

• Smaller attack surface — fewer features = fewer vulnerabilities
• Integrated with OpenShift’s security model
• SELinux-first design (Red Hat heritage)
• Automatic seccomp profile application
• Read-only container filesystem by default (configurable)

When to Choose

Choose containerd when:

• Using managed Kubernetes (GKE, EKS, AKS default to it)
• Need nerdctl for local development (Docker CLI compatible)
• Want runtime flexibility (kata, gVisor, WASM)
• Running non-Kubernetes container workloads alongside K8s
• k3s or Rancher ecosystem

Choose CRI-O when:

• Running OpenShift (it’s the default and only option)
• Want minimal attack surface
• Red Hat / Fedora CoreOS nodes
• Prefer K8s-version-locked runtime releases
• Security-first environments (government, finance)

Both are excellent — the choice often comes down to ecosystem:

• Cloud-managed K8s → containerd (pre-installed)
• OpenShift / Red Hat → CRI-O (pre-installed)
• Self-managed vanilla K8s → either works, pick based on team familiarity

Related Articles

• Podman vs Docker: Rootless Containers
• Buildah vs Kaniko: Container Image Building
• EKS vs GKE vs AKS 2026