Because the OCI runtime specification is a written contract, runc can be replaced with alternative runtimes such as crun, gVisor's runsc, or Kata Containers. What does that swap actually change, and what stays identical?

## What the contract actually is The OCI runtime-spec pins down two things: the **bundle** — a directory with `config.json` and an unpacked `rootfs/` — and the **lifecycle operations** a runtime must expose: `create`, `start`, `state`, `kill`, `delete`. That is the entire surface a container manager depends on. Everything else about a runtime is an implementation choice, and that is precisely what makes runtimes swappable. ## The runtimes people actually name **runc** — the reference implementation, written in Go, donated by Docker. It creates Linux namespaces, writes cgroup limits, applies seccomp filters, capabilities, and LSM labels, pivots into the rootfs and execs the entrypoint. The container's processes are ordinary host processes sharing the host kernel. **crun** — a C implementation from the Podman ecosystem. Same isolation model and the same kernel primitives, but a smaller binary, noticeably lower memory per container and faster start; it also tracked cgroup v2 and OCI features earlier. It is a genuine drop-in: the behaviour a workload sees is the same. **runsc (gVisor)** — implements the same OCI verbs but *not* the same isolation model. A user-space process called the Sentry implements a large subset of the Linux syscall surface itself; the container's syscalls are intercepted (via ptrace or KVM) and handled by the Sentry, which makes only a small, tightly-restricted set of real calls to the host kernel. The host kernel attack surface drops dramatically, which is the point: kernel LPE bugs that would break out of a runc container often cannot be reached. Costs: syscall-heavy and network/file-I/O-heavy workloads see meaningful slowdowns, and unimplemented or subtly different syscalls break some software (certain databases, anything using exotic ioctls or direct hardware access). **Kata Containers** — runs each container (or Kubernetes pod) inside a lightweight virtual machine with its own guest kernel, using a hardware virtualization boundary. Isolation approaches VM strength. Costs: hundreds of milliseconds of extra start latency, a per-VM memory floor, nested virtualization required if you are already on VMs, and awkwardness with host device access and some volume types. There are others in the same family — Firecracker-based sandboxes, `youki` (Rust), Windows and WASM runtimes fronted by shims. ## What is genuinely unchanged - **The image.** Runtimes do not consume images; the manager unpacks them. The same OCI image runs under all of these. - **The registry and the build.** Nothing changes. - **The manager.** containerd or CRI-O still handles pull, snapshotting, the shim and lifecycle bookkeeping. - **`config.json`.** The same declarative document is passed down; every runtime is expected to honour the process, mounts, resources and security fields it can. ## What is not identical, despite the spec This is where senior candidates separate themselves. Compliance guarantees the *interface*, not equivalent *behaviour*: - **Kernel fidelity.** Under gVisor the guest kernel is a reimplementation; `/proc` contents, unusual syscalls, and kernel-version-specific behaviour differ. Under Kata the guest kernel is a real but *different* kernel from the host's, so host module or sysctl assumptions break. - **Performance profile.** Start latency, syscall cost, network throughput and memory floor all shift, sometimes by an order of magnitude for the wrong workload. - **Feature support.** Privileged containers, host networking, host PID namespace, device passthrough, and some volume drivers are limited or unavailable in sandboxed runtimes — exactly the features that leak host access, so the limitation is often intentional. - **Observability.** Host-level tools (perf, eBPF probes, ps on the host) see sandboxed containers differently or not at all. ## How you select one Docker: `dockerd` is configured with named runtimes in `/etc/docker/daemon.json`, then `docker run --runtime=runsc …`. containerd exposes **runtime handlers**; Kubernetes surfaces them as `RuntimeClass` objects that a pod selects by name — the details of scheduling that belong to the orchestration side, but the mechanism is the same OCI swap underneath. ## The judgment answer Use the sandboxed runtime where the threat model demands it and the workload tolerates it: untrusted or multi-tenant user code, CI runners executing arbitrary builds, third-party plugins, functions-as-a-service. Keep runc or crun for trusted first-party services where a kernel-shared boundary plus a tight seccomp profile, dropped capabilities, read-only rootfs and a user namespace is proportionate. Mixing runtimes in one cluster is normal and is the usual answer — you pay the isolation tax only where it buys something. Always benchmark the specific workload before committing; the overhead is workload-shaped, not a single number.