Two Approaches to Stronger Isolation
The core problem is that containers share the host kernel. The solution is to insert an additional isolation layer between the application and the real kernel. Two production-grade approaches exist, each using a fundamentally different technique.
gVisor (Google): gVisor introduces a userspace kernel — a software layer written in Go that intercepts every system call (syscall) made by the application. Instead of the application's syscall going directly to the Linux kernel, it goes to gVisor's runsc (run sandbox container) process, which implements a large subset of the Linux kernel API in userspace. Only a small, carefully audited set of syscalls ever reach the real host kernel.
Think of gVisor as a thick rubber glove between the application and the kernel. The application thinks it's talking to Linux. It's actually talking to a Go program that validates and translates its requests before passing a minimal, sanitized version to the real kernel.
- Strengths: Low memory overhead, fast startup, strong syscall filtering.
- Weaknesses: Not all syscalls are implemented (some applications break), and heavy I/O workloads pay a performance penalty because every syscall is intercepted and re-processed.
Kata Containers: Kata takes a different approach — it runs each Pod inside a genuine lightweight Virtual Machine (VM) using hardware virtualization (KVM or similar). The container's kernel is a real, separate Linux kernel running inside the VM. The host kernel never sees the container's syscalls directly.
Think of Kata as giving each tenant their own separate apartment in a building, with their own plumbing and electrical panel, rather than just a cubicle.
- Strengths: Near-perfect isolation (hardware VM boundary), compatible with any Linux application since it runs a full kernel.
- Weaknesses: Higher memory overhead (each Pod carries a kernel), slightly slower startup than standard containers, requires hardware virtualization support on the node (nested virtualization in cloud VMs can be tricky).
Choosing Between Them
| Dimension | gVisor | Kata Containers |
|---|---|---|
| Isolation mechanism | Syscall interception (software) | Hardware VM boundary |
| Startup time | Fast (~same as runc) | Slightly slower (VM boot) |
| Memory overhead | Low | Higher (full guest kernel) |
| Application compatibility | Some apps break (missing syscalls) | Very high (full Linux kernel) |
| I/O performance | Reduced (syscall overhead) | Near-native |
| Best for | Untrusted code, serverless, FaaS | Regulated workloads, multi-tenant PaaS |
Key architectural insight: gVisor and Kata are not mutually exclusive with each other or with standard runc. In a real cluster, you might run all three simultaneously — runc for trusted internal services, gVisor for customer-submitted workloads, and Kata for workloads with strict compliance requirements. This is exactly what RuntimeClass enables.