Loading post…
BoxcomputeboxyExplainer
Why we chose KubeVirt for our VM sandboxes
Summary
BoxCompute chose KubeVirt for its VM sandboxes because workloads need a real Linux machine with a guest kernel, systemd, and machine-level workflows that process-oriented environments do not fully provide. KubeVirt adds VM resource types and controllers to Kubernetes, while launcher Pods run QEMU/KVM and the guest on a worker. The arrangement keeps placement, lifecycle, permissions, storage, and cleanup within the Kubernetes model, avoiding a separate VM management platform, although resource accounting and readiness still require sandbox-specific work. The post stresses that full virtualization does not automatically provide security: the platform still needs deliberate controls for host access, guest traffic, credentials, persistence, and cleanup after failures.
Context
The decision is framed around agent workspaces that may need background services, service managers, normal Linux boot behavior, and other machine-level workflows. Kubernetes was already the foundation for workload management, so the team wanted VM lifecycle management to remain within that ecosystem rather than coordinate a separate platform.
Approach / What changed
KubeVirt supplies Kubernetes VM resource types, controllers, and lifecycle reconciliation. A VirtualMachine describes the desired machine and lifecycle, a VirtualMachineInstance represents an instance, and a launcher Pod runs QEMU/KVM on a worker. Kubernetes handles placement and surrounding management, while the guest Linux system runs the workload; sandbox-specific code still defines readiness, security, persistence, and cleanup.
Takeaways
KubeVirt provides a real guest kernel and systemd environment, which supports machine-level workflows such as starting services, inspecting logs, and changing configuration.
KubeVirt keeps VM placement and lifecycle connected to Kubernetes resources, controllers, scheduling, policy, networking, and storage interfaces instead of adding a separate VM management API.
The Kubernetes and guest boundaries do not complete the sandbox design: resource overhead, elevated host access, credential protection, guest traffic restrictions, persistence, and failure cleanup remain operational responsibilities.
FAQ
Why use full VMs instead of ordinary Linux containers for these sandboxes?
Containers isolate processes but share the host kernel, while a VM supplies its own guest kernel and can boot a complete Linux environment with systemd. The choice targets workloads that need machine-level behavior, not only individual commands.
What does KubeVirt contribute beyond QEMU/KVM?
QEMU/KVM runs the virtual machine, while KubeVirt connects it to Kubernetes through VM resource types, controllers, launcher Pods, scheduling, and lifecycle reconciliation. This keeps placement and VM management in the Kubernetes model.
Does KubeVirt provide a complete security model for the sandbox?
No. KubeVirt adds controllers and node-level components, some requiring elevated host access, and the sandbox still needs controls for credentials, guest traffic, persistence, authentication, and cleanup after failures.
Source and freshness
- Source
- boxcompute.ai
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.