Runtime Class in Kubernetes

Runtime Class in Kubernetes To Pick Container Runtime Per Pod

Kubernetes

Kubernetes uses Runtime Class to let you pick the container runtime per Pod. It solves use-cases where you need distinct runtimes for security or performance. You define a RuntimeClass resource, reference it in your PodSpec, and Kubernetes schedules containers with the chosen handler. This article dives deep into Runtime Class architecture, spec fields, usage, CRI integrations, and production best practices.


TL;DR

  • RuntimeClass is a stable feature since Kubernetes v1.20 for selecting container runtimes per Pod.
  • Define a RuntimeClass CRD with a handler pointing to a CRI implementation (e.g., containerd, CRI-O, Kata).
  • Reference the RuntimeClass name in PodSpec.runtimeClassName to schedule with that runtime.
  • Use taints, node labels, and feature gates to control where runtime classes run.
  • Validate in CI, monitor performance and security impact, and automate admission with PodSecurityPolicy or OPA.

Runtime Class Overview

Runtime Class decouples Pod scheduling from the underlying container runtime. You can run most pods on default Docker or containerd while routing sensitive workloads to Kata Containers for hardware isolation. Nodes advertise supported handlers via kubelet flags. The scheduler picks a node that supports the requested handler and quotes the runtimeHandler in the CRI call to run the container.


Runtime Class Spec Fields

The RuntimeClass resource lives in node.k8s.io/v1. Key fields:

  • metadata.name: Unique name, used in PodSpec.runtimeClassName.
  • handler: Must match the runtimeHandler supported by kubelet (--container-runtime-endpoint or custom CRI shim).
  • overhead: (Optional) Pod-level resource request overhead to account for runtime overhead.
  • scheduling.nodeSelector: (Beta v1.21+) Node labels required for scheduling this class.

Using Runtime Class in Pods

To use a RuntimeClass, apply the CRD then reference it in your Pod manifest:

When you create secure-pod, the kubelet uses the kata-qemu handler. If no node supports that handler, scheduling fails with an unschedulable error.


Runtime Class and CRI Providers

RuntimeClass works with any CRI-compliant runtime. Common handlers:

  • containerd (runc, kata shim)
  • CRI-O (runc, cc-oci-runtime)
  • gVisor (runsc)
  • Kata Containers (kata-qemu, kata-fc)

Install and configure your CRI shim on each Node. Kubelet must start with --feature-gates=RuntimeClass=true (default on v1.20+) and --container-runtime-endpoint pointing to the CRI socket .


Runtime Class in Production

In real clusters, combine RuntimeClass with scheduler constraints and admission controls:

  • Node labels: Label sensitive nodes (node-role.kubernetes.io-secure=true), use RuntimeClass.scheduling.nodeSelector.
  • Taints and tolerations: Taint nodes running specialized runtimes, require pods to tolerate.
  • PodSecurityPolicy or OPA Gatekeeper: Enforce which namespaces or teams may use high-isolation runtimes.

Runtime Selection Flowchart

Runtime Class in Kubernetes To Pick Container Runtime Per Pod

Best Practices for Runtime Class

Follow these guidelines to avoid pitfalls:

  • Test runtime overhead and performance impact in staging.
  • Define overhead to reserve CPU/memory for sandbox runtimes.
  • Monitor CRI errors and scheduling events: kubectl describe pod shows unschedulable reasons.
  • Use namespacing and RBAC: Only grant create permission on RuntimeClass to trusted admins.
  • Automate admission: Deny unexpected or undeclared runtime classes via admission webhooks.

References

Suggested Reading

PostHashID: 0206fbfcbf932e793b90cd81266ac8ed4423326f7fb323780474e373e2dc5a67

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.