Plugging Runtimes into Kubernetes
Kubernetes supports multiple runtimes on the same cluster through a resource called RuntimeClass. This allows you to run most workloads on runc for performance while routing specific high-risk workloads to gVisor or Firecracker — all within the same cluster.
A RuntimeClass object maps a name to a handler, which containerd uses to select the correct low-level runtime binary.
Defining one is just a name mapped to a handler — for gVisor, the handler is runsc, the name of gVisor's runtime binary. A Pod then opts into that runtime by naming the RuntimeClass in its spec instead of leaving it to the cluster default. When the kubelet schedules this Pod, it tells containerd to use the runsc handler instead of the default runc. The container starts inside a gVisor sandbox. The application code is completely unaware of this — it sees a normal Linux environment.
This is the production pattern for multi-tenant platforms: define RuntimeClass objects for each security tier, and enforce which workloads use which class via admission controllers or OPA policies.