Adding More Walls Between Tenants
Sandboxed runtimes replace runc as the low-level runtime. They are OCI-compliant (so containerd can call them the same way it calls runc) but provide dramatically stronger isolation guarantees. The two most important are gVisor and Firecracker.
gVisor: The Userspace Kernel
Created by Google and open-sourced in 2018, gVisor introduces a component called the Sentry — a userspace kernel written in Go. The Sentry implements a large subset of the Linux kernel's system call interface entirely in userspace.
How it works: When a container process makes a system call (e.g., read()), the call is intercepted before it reaches the real host kernel. The Sentry handles the call itself, using only a small, restricted set of host kernel calls to do so. Untrusted container code never directly invokes the host kernel. The attack surface is reduced from the entire Linux kernel to the small set of syscalls the Sentry itself uses.
Trade-offs:
- Security: Excellent. Untrusted code is isolated from the host kernel by the Sentry.
- Performance: Worse than runc. Every syscall goes through an extra layer of interception and handling. Syscall-heavy workloads (databases, certain I/O patterns) can see significant slowdowns.
- Compatibility: Not every Linux syscall is implemented in the Sentry. Some applications that use obscure or very new kernel features may not run correctly.
gVisor is used in production at Google (Google Cloud Run uses it) and is available in GKE via the RuntimeClass gvisor.
Firecracker: MicroVMs
Created by AWS and open-sourced in 2018, Firecracker takes a fundamentally different approach. Rather than intercepting syscalls, it uses hardware virtualization to give each workload its own dedicated kernel.
How it works: Firecracker uses the Linux KVM (Kernel-based Virtual Machine) hypervisor to create ultra-lightweight Virtual Machines called MicroVMs. Each MicroVM has its own Linux kernel (a minimal one, ~5MB) and boots in under 125 milliseconds. The container process runs inside the MicroVM, isolated from the host by hardware virtualization boundaries — the same isolation model as a full VM, but with startup times approaching those of containers.
Trade-offs:
- Security: Strongest available. VM-level isolation backed by hardware.
- Performance: Startup is fast for a VM but slightly slower than runc. Memory overhead is higher because each MicroVM needs its own kernel in memory.
- Compatibility: Excellent. The container sees a real Linux kernel, so application compatibility issues are rare.
Firecracker powers AWS Lambda and AWS Fargate in production, running millions of MicroVMs simultaneously.
Choosing Between Them:
| Concern | runc | gVisor | Firecracker |
|---|---|---|---|
| Trusted workloads | ✅ Best performance | Overkill | Overkill |
| Untrusted code, high syscall volume | ❌ Risk | ⚠️ Perf overhead | ✅ Strong isolation |
| FaaS / multi-tenant | ❌ Risk | ✅ Good fit | ✅ Best fit |
| Startup speed | Fastest | Fast | Fast (for a VM) |
| Memory overhead | Lowest | Low | Higher (per-kernel) |
A common senior-level interview question is: "What's the difference between gVisor and Firecracker, and when would you choose one over the other?" The key distinction is mechanism: gVisor intercepts syscalls in userspace (lower overhead, some compatibility gaps), while Firecracker uses hardware virtualization to give each workload its own kernel (stronger isolation, higher memory cost). Choose gVisor when you need good isolation with lower overhead and can tolerate compatibility limitations. Choose Firecracker when you need the strongest possible isolation and your workload is latency-sensitive at startup (FaaS).