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 inPodSpec.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 inPodSpec.runtimeClassName
.handler
: Must match theruntimeHandler
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:
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: kata-qemu-handler
handler: kata-qemu
---
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
runtimeClassName: kata-qemu-handler
containers:
- name: app
image: nginx:latest
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

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
- Kubernetes Official Docs: RuntimeClass Feature State, Spec fields.
- Kubernetes Official Docs: Pod Scheduling with RuntimeClass.
- OPA Gatekeeper Docs: Admission Control for RuntimeClass.
- containerd Handlers Guide.
- CRI-O Runtime Handlers.
- gVisor runsc.
- Kata Containers.
- Kubernetes Taints and Tolerations.
Suggested Reading
PostHashID: 0206fbfcbf932e793b90cd81266ac8ed4423326f7fb323780474e373e2dc5a67