LoginSign Up
← Back to all sparks
K

Kata Containers

INFRA · APIS
Velocity2.5

Secure container runtime using lightweight virtual machines

katacontainers.io ↗

With the Rust runtime shipped, Kata turns to GPUs and slimmer packaging.

confidential-computingcontainer-runtimesgpupackagingkubernetes
◆Current state
Kata Containers ships monthly, and 4.1.0 is the first release after the Rust runtime became the default. It is consolidation work: the static release tarball is split by runtime, the GPU extension is built without depending on the monolithic image, NVIDIA libraries are chiselled down from a filelist, and kata-deploy stops shipping virtiofsd when shared_fs is disabled. Dragonball merged its three network device managers into one, EROFS backing mode became configurable, and the CI matrix churned across s390x, arm64 and ppc64le.
◆Where it's heading
The rewrite arc has closed and an accelerator arc is opening in its place. Four separate changes in this release touch NVIDIA support — library chiselling, Fabric Manager topology, local CUDA repository support, and decoupling the GPU extension from the monolithic image — which is the shape of a project preparing for confidential GPU workloads rather than incidental hardware support. The packaging work points the same way: splitting tarballs by runtime and dropping unused components matters when the image is being pulled onto every node of a GPU cluster.
◆Prediction
Expect the next releases to continue narrowing the shipped artifact and to deepen NVIDIA support toward attested GPU workloads, rather than to revisit the runtime itself.

◆Recent moves

  1. 26d ago

    4.1.0 splits release tarballs and slims the NVIDIA GPU extension

    The first release after the Rust runtime default, spent on packaging and accelerators: the static tarball splits by runtime, the GPU extension builds without the monolithic image, NVIDIA libraries are chiselled from a filelist, and Dragonball's three network device managers merge into one. Consolidation rather than direction.

    View source ↗
  2. 1mo ago

    4.0.0 makes the Rust runtime-rs the default runtime

    ⚡ SPARK

    4.0.0 made the Rust runtime-rs the default across every supported architecture and hypervisor, completing a handover the 3.2x series had been staging release by release. Everything since has been built on top of that decision.

    View source ↗
  3. 2mo ago

    3.32.0 adds TDX ACPI boot, guest memfd and QEMU NUMA support

    3.32.0 added TDX ACPI boot, guest memfd and QEMU NUMA support — confidential-computing plumbing landing alongside the runtime-rs commits that were quietly staging the 4.0.0 handover.

    View source ↗
  4. 3mo ago

    3.31.0 brings coldplug GPU support and deployment health probes

    3.31.0 brought coldplug GPU support and deployment health probes. The GPU work here is the earliest visible thread of what 4.1.0 has since expanded into a sustained accelerator effort.

    View source ↗
  5. 4mo ago

    3.30.0 sets QEMU as the runtime-rs default and adds vCPU pinning

    3.30.0 set QEMU as the runtime-rs default and added vCPU pinning — a staging step that made the Rust runtime viable as a default before 4.0.0 declared it one.

    View source ↗
  6. 4mo ago

    3.29.0 tightens genpolicy validation and adds an eBPF debug kernel

    3.29.0 tightened genpolicy validation and added an eBPF debug kernel. Policy validation is part of the same isolation argument the confidential-computing work serves.

    View source ↗