How Kubernetes Container Runtime Works

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.

👀 Remote Jobs

• Ozone is hiring a DevOps Engineer

  Remote Location: Worldwide

• Ashby is hiring a Principal Site Reliability Engineer

  Remote Location: EMEA

📚️ Resources

• How SSH Secures Your Connection

• Moving secure GitOps forward with Flux

• CI/CD Security: Using Checkov to enforce security with terraform

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

🧠 DEEP DIVE USE CASE

How Kubernetes Container Runtime Works

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 containerd or CRI-O to run them inside Kubernetes.

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

1. Kubernetes Containerd Runtime Flow

2. Kubernetes CRI-O Runtime Flow

1. Kubernetes Containerd Runtime Flow

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 archieve of 170+ 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