Firecracker Lab on Kubernetes¶

This is a self-contained set of experiment documents for evaluating how Firecracker runs on Linux and Kubernetes. It does not depend on the build, runtime, configuration, or other documentation of the repository it lives in, and can be copied in its entirety to other sites.

Verification Status¶

The Launcher approach is intentionally positioned as a proof of concept. It lets Kubernetes manage the Firecracker VMM process, but it does not automatically turn ordinary Pods into Pods backed by microVMs. If that isolation boundary is the actual goal, Kata Containers or a sandbox control plane should be used instead.

Document Directory¶

• Host Deployment and Native Smoke Tests
• Kubernetes Launcher Tests
• Kata + Firecracker RuntimeClass Tests
• Firecracker Experiment Results and Operations Manual
• Agent Workloads: OpenClaw, DSH, Hermes, and Codex
• Observability and Resource Accounting
• Jailer and Security Baseline
• Firecracker, Kata, KubeVirt, and CubeSandbox Selection
• Redacted Test Report

Reusable examples are located in configs/ and manifests/, with specific links provided in the relevant guides. Replace the example node names and image addresses before use.

Accessing the Retained Experiment Environment¶

The tested node is still retained as a dedicated, tainted Kata/Firecracker worker. The long-running Workbench can be accessed with the following command:

kubectl get pod -n firecracker-lab kata-fc-workbench -o wide
kubectl logs -n firecracker-lab kata-fc-workbench
kubectl exec -n firecracker-lab -it kata-fc-workbench -- /bin/sh

Before modifying the thin pool or containerd configuration, read the RuntimeClass guide; when proceeding to the next phase of testing, refer to the experiment operations manual.

Verified Data Flows¶

Kubernetes scheduler
        |
        v
Privileged Launcher Pod -- /dev/kvm --> Firecracker VMM --> Linux microVM
        |
        +-- Kubernetes CPU, memory, and lifecycle cgroup

Kubernetes 调度器
        |
        v
特权 Launcher Pod -- /dev/kvm --> Firecracker VMM --> Linux microVM
        |
        +-- Kubernetes CPU、内存与生命周期 cgroup

This differs from the runtime-hosted path:

Pod runtimeClassName --> RuntimeClass --> containerd --> Kata shim
                                                     --> Firecracker --> microVM

Both paths were tested on the same isolated worker. When ordinary Pods need a microVM isolation boundary, the RuntimeClass path is the more appropriate starting point; the Launcher is better suited for directly observing and debugging the VMM.

The Agent experiments combined two systems:

Agent Pod -> Kata + Firecracker isolation boundary -> CubeSandbox Adapter -> Agent sandbox

Agent Pod -> Kata + Firecracker 隔离边界 -> CubeSandbox Adapter -> Agent 沙箱

This two-layer approach is valuable when both the Agent runtime and the temporary tool execution environments it creates need independent isolation, but it also adds memory, network, storage, and operational overhead. Ordinary CubeSandbox usage scenarios do not require two-layer isolation.

Security Boundary¶

The Launcher Pod runs in privileged mode, with access to /dev/kvm and a writable host directory. It should be treated as code with node administrator privileges. Do not expose this mode to untrusted tenants, do not mount arbitrary host paths, and do not treat it as a production-grade multi-tenant runtime. In production, Firecracker should use a version-matched jailer, with explicitly designed image, network, storage, cgroup, and cleanup policies.

Primary References¶

• Firecracker Getting Started Guide
• Firecracker jailer
• Kubernetes RuntimeClass
• Kata Containers Installation Guide
• containerd devmapper snapshotter
• Kata runtime-rs Firecracker issue #13484
• Kata hypervisor
• CubeSandbox Architecture