• TechOps Examples
  • Posts
  • CRI-O vs Containerd: Undersanding Kubernetes Container Runtimes

CRI-O vs Containerd: Undersanding Kubernetes Container Runtimes

TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

👋 👋 A big thank you to today's sponsor MINDSTREAM

Turn AI Into Your Income Stream

The AI economy is booming, and smart entrepreneurs are already profiting. Subscribe to Mindstream and get instant access to 200+ proven strategies to monetize AI tools like ChatGPT, Midjourney, and more. From content creation to automation services, discover actionable ways to build your AI-powered income. No coding required, just practical strategies that work.

👀 Remote Jobs

📚️ Resources

Looking to promote your company, product, service, or event to 57,000+ Cloud Native Professionals? Let's work together. Advertise With Us

🧠 DEEP DIVE USE CASE

CRI-O vs Containerd: Undersanding Kubernetes Container Runtimes

When your Pod starts in Kubernetes, the container runtime is one of the first components to take action.

What Is a Container Runtime?

A container runtime is the system level component responsible for:

  • Pulling container images from a registry

  • Unpacking and mounting the image layers

  • Creating isolated environments using Linux namespaces and cgroups

  • Executing the container process using a low level runtime like runc

  • Reporting back container state to the kubelet for health and lifecycle tracking

It sits underneath your Kubernetes worker node, abstracted behind the Container Runtime Interface (CRI), and acts as the bridge between kubelet and the host operating system.

Popular Container Runtime Types

Kubernetes supports several CRI compatible runtimes. Each has specific use cases and trade offs:

  • containerd (Default in GKE, EKS, k3s. Handles image pulls, snapshots, and lifecycle. Lightweight and production ready)

  • CRI-O (Kubernetes focused, minimal runtime. Used in OpenShift and upstream clusters for strict CRI compliance)

  • Docker Engine (Deprecated since v1.24. Still used for image builds but not for running containers in Kubernetes)

  • gVisor (Sandbox runtime offering user space isolation. Ideal for multi tenant or untrusted workloads)

  • Kata Containers (Uses lightweight VMs for stronger isolation. Suitable for high security environments)

  • Mirantis CR (Enterprise grade fork of Docker Engine with commercial support)

Note: Kubernetes did not “drop Docker,” it dropped the Docker Engine as a container runtime.

You can still use Docker to build images, but use CRI-O or containerd to run them inside Kubernetes.

Let’s explore the two most popular runtimes used across managed Kubernetes environments and self hosted clusters.

  1. CRI-O Runtime Flow

  2. Containerd Runtime Flow

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)

Upgrade to Paid to read the rest.

Become a paying subscriber to get access to this post and other subscriber-only content.

Already a paying subscriber? Sign In.

Paid subscriptions get you:

  • • Access to archive of 250+ use cases
  • • Deep Dive use case editions (Thursdays and Saturdays)
  • • Access to Private Discord Community
  • • Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
  • • Quarterly 1:1 'Ask Me Anything' power session