CONCEPT Cited by 1 source

Micro-VM as Pod

Micro-VM as Pod is the architectural stance of making the Kubernetes Pod a thin compatibility layer over a micro-VM (typically Firecracker) rather than over a Linux container on a shared kernel. Containers inside the Pod share the micro-VM's kernel; different Pods get different kernels.

Definition

In the reference Kubernetes deployment model, a Pod is one-or-more containers that share a Linux network + IPC + UTS namespace on a worker Node. The container runtime (containerd, CRI-O) uses runc or similar to carve a shared-kernel sandbox.

In the micro-VM-as-Pod model:

• Each Pod is a discrete micro-VM, with its own kernel.
• The Pod boundary is a hardware-virtualisation isolation boundary (VT-x, EPT), not a namespace boundary.
• Multi-container Pods collapse to single-container Pods until the platform chooses to implement a multi-container VM shape.
• Kubelet-typical responsibilities (image pull, rootfs assembly, probes, lifecycle) are handled by the host's micro-VM orchestrator rather than by kubelet + containerd + runc.

Why you'd do it

• Stronger isolation — a bug in a container runtime or in the Linux kernel can't cross a hypervisor boundary as easily. Same argument AWS Lambda used to move from single-tenant EC2 to Firecracker (sources/2024-11-15-allthingsdistributed-aws-lambda-prfaq-after-10-years).
• Dense multi-tenant packing — micro-VMs are light enough that providers can densely pack them onto bare metal while preserving hardware-level isolation. See concepts/micro-vm-isolation.
• Unified compute substrate — a provider with an existing micro-VM primitive (Fly Machines, Firecracker-on-Fargate, AWS Lambda) can expose K8s semantics on top of it without building a second runtime path.

Canonical production instances

• Fly Kubernetes (FKS) — Pods are Fly Machines: Firecracker micro-VMs under Fly's in-house scheduler (flyd), with a Virtual Kubelet provider translating K8s API calls into Machines API calls.
• AWS Fargate on EKS — Pods are Firecracker micro-VMs on the Fargate fabric.
• Figma's Lambda sandbox (adjacent, not K8s) — Firecracker as the per-workload isolation boundary for stateless fetch workloads; see sources/2026-04-21-figma-server-side-sandboxing-virtual-machines.

Trade-offs

• ❌ Cold-start latency is non-trivial (Firecracker is fast, but boot + rootfs + userland init together can still outweigh a per- request budget — Figma calls this out explicitly at the Lambda level).
• ❌ Multi-container Pods don't map cleanly; most implementations ship without sidecars / init-containers at first (FKS is explicit about this at beta).
• ❌ Some Kubelet APIs (kubectl exec, kubectl port-forward) require the VK provider to implement stdio / port-forwarding proxies; often missing at launch.
• ✅ Isolation + density + tenant-boundary story is stronger than a shared-kernel Node.

Seen in

• sources/2024-03-07-flyio-fly-kubernetes-does-more-now — FKS makes Pods into Fly Machines (Firecracker micro-VMs). Canonical wiki instance of micro-VM-as-Pod at the K8s API level.
• sources/2024-11-15-allthingsdistributed-aws-lambda-prfaq-after-10-years — Lambda's Firecracker migration is the adjacent framing at the serverless function level (not K8s, but same primitive below).