Free — no signup required

Assigning Pods to Runtimes

2 min read

The runtimeClassName Field

From a developer's perspective, using a sandboxed runtime requires exactly one additional line in the Pod spec — a runtimeClassName field naming the class by name (e.g. gvisor) alongside the normal container definition. The cluster administrator handles all the complexity of installation and RuntimeClass definition — the developer just references the class by name.

When this Pod is submitted, the Kubernetes API server:
1. Looks up the gvisor RuntimeClass object.
2. Merges the RuntimeClass's scheduling constraints into the Pod's scheduling requirements.
3. Passes the handler name (runsc) to the kubelet on the selected node.
4. The kubelet instructs containerd to use the runsc handler instead of the default runc.

Applying RuntimeClass at Scale with Admission Control

In a real multi-tenant platform, you typically don't want to rely on developers remembering to add runtimeClassName. You enforce it using a MutatingAdmissionWebhook or a policy engine like OPA/Gatekeeper or Kyverno.

For example, a Kyverno ClusterPolicy can automatically inject runtimeClassName: gvisor into any Pod created in namespaces labeled tenant-isolation: strict — matching on that namespace label and mutating the Pod spec to add the field. This makes the security boundary invisible to developers — they deploy normally, and the platform enforces the runtime choice transparently.

Senior-level insight: RuntimeClass interacts with resource accounting in a subtle way. Kata Containers, because they run a full VM, consume memory for the guest kernel and agent processes that are not reflected in the Pod's resource requests. This means your node capacity planning must account for the Kata overhead separately — typically 100–200 MB per Pod depending on the Kata configuration. Failing to account for this leads to nodes that appear to have capacity but OOM-kill Pods at runtime. Some teams add an overhead field to the RuntimeClass definition (supported since Kubernetes 1.18), setting a podFixed memory and CPU amount that gets automatically added to every Pod using that class's resource accounting.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free