Back

07_Specialized_Virtualization

Loading views...
← PreviousNext →

Specialized Virtualization Technologies

Unikernels, MicroVMs, and Hybrid Approaches

Table of Contents

  1. Unikernels
  2. Kata Containers
  3. gVisor
  4. Firecracker MicroVMs
  5. Complete Comparison

Unikernels

Concept

Unikernels are specialized, single-purpose machine images that compile an application together with only the OS components it needs.

Traditional Stack:        Unikernel:
┌──────────────┐         ┌──────────────┐
│ Application  │         │ Application  │
├──────────────┤         │      +       │
│   Runtime    │         │  Minimal OS  │
├──────────────┤         │  (library)   │
│  Guest OS    │         │              │
├──────────────┤         ├──────────────┤
│  Hypervisor  │         │  Hypervisor  │
├──────────────┤         ├──────────────┤
│   Hardware   │         │   Hardware   │
└──────────────┘         └──────────────┘

Characteristics

  • Single-purpose kernel built for one application
  • No user/kernel separation - single address space
  • Extremely small - kilobytes to few megabytes
  • Fast boot - sub-millisecond possible
  • Minimal attack surface - no shell, no extra services

Examples

Unikernel Language Focus Use Case
MirageOS OCaml Type-safe network services
IncludeOS C++ High-performance applications
OSv Java/JVM Cloud-native Java apps
Rumprun POSIX apps Legacy application porting

Trade-offs

  • Pros: Security, speed, efficiency
  • Cons: Debugging difficulty, single application per VM, specialized build process

Kata Containers

Architecture

Kata Containers combine container speed with VM security by running each container in a lightweight VM.

┌────────────────────────────────────────┐
│  Kubernetes Pod                        │
│  ┌──────────────────────────────────┐  │
│  │  Container 1  │  Container 2     │  │
│  └──────────────────────────────────┘  │
├────────────────────────────────────────┤
│  Kata Agent (inside VM)                │
├────────────────────────────────────────┤
│  Minimal Guest Kernel                  │
├────────────────────────────────────────┤
│  Hypervisor (QEMU/Firecracker/         │
│   Cloud Hypervisor)                    │
├────────────────────────────────────────┤
│  Host Kernel                           │
└────────────────────────────────────────┘

Components

  • Kata Runtime: OCI-compliant container runtime
  • Kata Agent: Runs inside VM, manages containers
  • Kata Proxy: Communication bridge
  • Hypervisor: QEMU, Firecracker, or Cloud Hypervisor

Characteristics

  • Each pod/container runs in dedicated lightweight VM
  • Hardware-enforced isolation (VT-x/AMD-V)
  • Compatible with Kubernetes via CRI
  • Overhead: ~120MB RAM, ~100ms startup

Use Cases

  • Multi-tenant container platforms
  • Running untrusted workloads
  • Compliance requirements needing VM-level isolation

gVisor

Architecture

gVisor implements a user-space kernel that intercepts and handles container syscalls.

┌────────────────────────────────────┐
│  Container Application             │
├────────────────────────────────────┤
│  Sentry (User-space Kernel)        │
│  ┌──────────────────────────────┐  │
│  │ Syscall Table                │  │
│  │ Virtual Filesystem           │  │
│  │ Network Stack                │  │
│  │ (All implemented in Go)      │  │
│  └──────────────────────────────┘  │
├────────────────────────────────────┤
│  Gofer (File access proxy)         │
├────────────────────────────────────┤
│  Host Kernel (limited syscalls)    │
└────────────────────────────────────┘

How It Works

  1. Intercepts ALL syscalls from container
  2. Re-implements Linux syscalls in user-space (Go)
  3. Limited host kernel interaction via ~50 syscalls
  4. Better isolation than standard containers

Platform Options

  • ptrace: Uses ptrace for syscall interception
  • KVM: Uses KVM for hardware-assisted isolation

Characteristics

  • Better isolation than namespaces
  • Written in Go (memory-safe)
  • Overhead: ~10-30% performance penalty
  • Used by Google Cloud Run

Firecracker MicroVMs

Architecture

Firecracker is a minimalist Virtual Machine Monitor (VMM) designed for serverless.

┌──────────────────────────────────┐
│  Guest OS (minimal Linux)        │
│  ┌────────────────────────────┐  │
│  │ Container workload         │  │
│  └────────────────────────────┘  │
├──────────────────────────────────┤
│  Firecracker VMM (Rust)          │
│  ┌────────────────────────────┐  │
│  │ Minimal device model       │  │
│  │  - virtio-net              │  │
│  │  - virtio-block            │  │
│  │  - Serial console          │  │
│  │  (Nothing else!)           │  │
│  └────────────────────────────┘  │
├──────────────────────────────────┤
│  KVM                             │
├──────────────────────────────────┤
│  Host Linux Kernel               │
└──────────────────────────────────┘

Characteristics

  • Boot time: <125ms
  • Memory overhead: <5MB per microVM
  • Written entirely in Rust (memory-safe)
  • Minimal attack surface

What's NOT Included

  • No BIOS/UEFI (uses Linux boot protocol)
  • No PCI bus emulation
  • No USB, GPU, sound, or complex devices
  • Just the essentials: compute, network, block storage

Use Cases

  • AWS Lambda - Powers serverless functions
  • AWS Fargate - Container execution
  • Multi-tenant platforms requiring strong isolation

Complete Comparison Matrix

Technology Isolation Performance Startup Memory Use Case
Standard Containers Moderate (namespace) 99%+ Seconds MB Microservices
Kata Containers Strong (HW) 90-95% ~100ms ~120MB Secure multi-tenant
gVisor Good (user-kernel) 70-90% <1s ~50MB Untrusted code
Firecracker Strong (HW) 95%+ <125ms ~5MB Serverless/FaaS
Unikernels Strong (HW) 99%+ <1ms <10MB Specialized apps
Traditional VMs Strong (HW) 95%+ Minutes GB Legacy/full OS

When to Use What?

Requirement Best Choice
Maximum performance, trust workload Standard containers
Untrusted code, defense in depth gVisor or Kata
Serverless, fast startup Firecracker
Complete OS isolation Traditional VMs
Single-purpose appliance Unikernels
Multi-tenant public cloud Firecracker or Kata

Summary: Complete Virtualization Stack

Application Level
├── JVM, .NET CLR, Wine
│
Container Level  
├── Docker, Podman (runc)
├── gVisor (Sentry)
├── Kata Containers (lightweight VMs)
│
MicroVM Level
├── Firecracker
├── Cloud Hypervisor
│
Traditional VM Level
├── QEMU/KVM
├── VMware ESXi
├── Xen
├── Hyper-V
│
Hardware Level
└── Intel VT-x, AMD-V, ARM VE

This complete picture demonstrates how different virtualization technologies serve different needs—from ultra-lightweight serverless to full hardware-isolated VMs—all building upon the foundation of hardware virtualization extensions.

Key Takeaways

  1. Containers share kernel, fast but less isolated
  2. VMs have separate kernels, strong isolation but slower
  3. MicroVMs (Firecracker) bridge the gap for serverless
  4. gVisor provides user-space kernel for defense in depth
  5. Kata gives VM security with container experience
  6. Unikernels are ultra-specialized for single applications
  7. Linux cgroups + namespaces underpin all container technologies
  8. Hardware extensions (VT-x/AMD-V/EPT/NPT) enable efficient virtualization
  9. Cloud providers customize KVM/Xen for scale and security
  10. Choice depends on performance, security, and operational needs

Previous: 06KVMinCloudProviders.md

← PreviousNext →