Restoring the Promise of a Resource Limit
The opening question was whether a microVM resource limit governs the same reality that the host, Kubernetes, and the cloud bill can see. The evidence now supports a precise answer: strong guest isolation does not automatically align physical resource ownership with accounting, eviction, or billing. This final synthesis connects Kata Containers, Firecracker, host cgroups, virtio backends, Kubernetes storage accounting, and co-located workloads into one judgment. It also turns that judgment into a conditional review model: identify who creates or retains the resource, who observes it, what boundary governs it, and what failure a proposed fix could introduce.
The conclusion is not that microVMs are unsafe or that limits are meaningless. MicroVMs address a genuine isolation problem by giving workloads a guest kernel and separating them from direct host-kernel execution. Kata’s cgroup design also shows that sandbox overhead can be deliberately included in the pod boundary or deliberately separated into an overhead hierarchy. The problem appears when a platform treats that security boundary as if it were already a complete resource boundary, without checking how delegated I/O, page charging, storage paths, and billing inputs relate to it.
A resource limit is a chain of promises
A limit begins as a promise about a workload, but it is implemented through a chain of host decisions. The guest application creates demand. A guest kernel and virtual device path carry that demand across the VM boundary. A VMM or virtio service may populate memory, retain a file-backed page, allocate host blocks, or handle a queue. The host kernel assigns ownership according to a process, cgroup, filesystem, or object. Kubernetes reads selected metrics and turns them into eviction or scheduling decisions. A billing system interprets declared resources and runtime according to its own model.
For the promise to be coherent, these layers do not have to expose the same counters. They do need a reliable relationship. If the host backend is intentionally part of the pod’s resource boundary, the platform can include its cost in the pod budget and decide what happens under pressure. If the backend sits in a separate sandbox-overhead group, the infrastructure owner can govern that group separately and make the distinction visible. If a file-backed page is charged to a backend that the tenant boundary does not represent, the platform needs another attribution or containment mechanism. If a disk object is retained outside the path a scanner traverses, the platform needs object-aware monitoring or a hard quota.
Kata’s two cgroup modes make this logic concrete. When sandbox_cgroup_only is true, the design assumes the pod cgroup was sized to include the sandbox. The shim places the VMM, I/O threads, shim, and vCPU threads in a per-sandbox child under the pod hierarchy. This is the straightforward resource story: pod statistics and limits can include the host cost of the sandbox, and a noisy workload remains within the pod’s governing parent. But the assumption must be supplied by the orchestrator; the runtime does not discover a correct overhead budget by itself.
When the setting is false, the pod cgroup is treated as a budget for the workload and vCPU threads, while other sandbox processes move to a separate overhead hierarchy. That can prevent the VMM and I/O machinery from consuming the application’s expected memory budget. It can also leave host resource use outside ordinary pod enforcement if the infrastructure owner does not size or constrain the overhead group. The two modes are not a choice between accounting and no accounting. They are different contracts about where the sandbox cost belongs and who is responsible for governing it.
The memory findings expose a second distinction.