Skip to content

Kata Containers 4.3.0

4.3.0 is the third monthly snapshot after 4.0.0, and follows 4.2.0. Much of this release is about what happens after something goes wrong: a container that never starts, a shim that dies, a mount that will not go away. runtime-rs now keeps enough state to retry that work, waits for the processes that own the resources, and takes care not to remove host data through mounts left behind.

The install changes too. kata-deploy returns to job mode by default, and a plain install advertises only the RuntimeClasses whose prerequisites it can meet. Confidential, NVIDIA, Firecracker and remote deployments each have a profile that brings their settings together. Guest extensions reach Cloud Hypervisor and Dragonball, and rootless VMM device provisioning becomes a Helm option rather than a set of manual changes on every node.

Read the breaking changes before upgrading

Job mode is the default again, and specialized RuntimeClasses need their profiles. Containerd no longer forwards every Kata annotation. Cloud Hypervisor no longer supports confidential guests. The supported containerd baseline also moves to 2.2.

New features

Guest extensions reach Cloud Hypervisor and Dragonball

The composable guest images introduced for QEMU can now be used with Cloud Hypervisor and Dragonball through runtime-rs (#13931). Both backends attach the configured extension images as read-only block devices and carry their identities into the guest, where the same extension mount service assembles them. Extension names on these two backends are limited to 10 ASCII characters, leaving room for the prefix in the block-device serial. The devkit tests now exercise both VMMs as well as QEMU.

An extension that cannot be mounted also leaves its output on the guest console, in addition to the journal. That matters during early boot: the guest can power off before there is an agent to ask for the journal.

See Composable VM images for the image layout and configuration.

Rootless VMM host setup becomes a Helm option

4.2.0 made rootless QEMU useful for devices and disks. The next obstacle was getting every node's device permissions right before the unprivileged VMM tried to open them. kata-deploy now does that work when a supported shim asks for it (#13908):

values.yaml
deploymentMode: job
shims:
  qemu-runtime-rs:
    hypervisor:
      rootless: true

The install creates the device groups it needs, reconciles the live device nodes, and writes udev rules so the permissions survive device recreation. /dev/kvm keeps its conventional kvm group; /dev/sev and /dev/uv get separate kata-sev and kata-se groups. A sandbox receives only the groups for the devices its own configuration needs. /dev/vhost-vsock and /dev/vhost-net are left alone, since the privileged shim already passes their open descriptors to QEMU.

The runtime now checks that those paths are character devices with usable read-and-write access before dropping privileges, and refuses group 0 rather than adding the temporary VMM user to it (#13556). TDX quote generation through a Unix socket gets the same early check for parent traversal and socket access; provisioning the QGS socket itself remains the host's job. A failure names the resource and the access it needs instead of surfacing later as a QEMU launch error.

Supported shims and node requirements

This Helm option is opt-in, for the runtime-rs QEMU shims and clh-runtime-rs. It requires job mode, a persistent /etc, and a udev implementation reading /etc/udev/rules.d; DaemonSet mode is rejected. Cloud Hypervisor rootless support is for non-confidential guests. Only the VMM drops privileges — the shim and virtiofsd still run as root.

The rootless VMM guide covers the host contract, TEE devices, QGS and hosts whose device rules need another mechanism.

NVIDIA GPU runtime-rs on arm64

kata-deploy now ships qemu-nvidia-gpu-runtime-rs for aarch64, with GPU CI on an arm64 BF3 runner as well as the existing amd64 runners (#14020). The arm64 leg covers single-GPU workloads; it skips vLLM because the images and snapshots exceed that runner's disk budget. This is coverage for the plain GPU handler, not a claim of arm64 confidential GPU support.

The policy generator also accepts nvidia.com/gpu alongside the existing nvidia.com/pgpu resource key, following the device plugin's move to the standard name (#14011).

Large overlay mounts use the new mount API

A sufficiently long list of image layers exceeds the mount(2) option string limit, so the agent could fail to mount a valid multi-layer image even though the filesystem could represent it. It now falls back to fsopen/fsconfig/fsmount, passing each lower directory separately through lowerdir+ (#13670).

A minimum memory limit for the webhook

kata-webhook can enforce MIN_MEMORY_LIMIT on explicit memory limits for both regular and init containers (#12652). No minimum is configured by default. Limits below the configured minimum are raised to it; containers that omitted a memory limit keep it unset.

Breaking changes

Job mode is the default again

4.2.0 temporarily kept the DaemonSet as the default while the staged installer settled. That hold is removed: deploymentMode defaults to job, and the two NVIDIA profiles follow it again (#13841).

An install now uses short-lived per-node Jobs and the dispatcher rather than a long-running installer on each node. That also puts kernel-module loading and host-binary staging back on the default install path. Set deploymentMode: daemonset explicitly if that is the deployment model you need, and keep its host preparation requirements in mind.

Specialized RuntimeClasses move to profiles

The default chart no longer enables confidential, NVIDIA, Firecracker or remote shims, and no longer sets up nydus (#13672). Those classes depended on hardware, a snapshotter or an external provider a plain install did not arrange. Advertising them made a successful install look more capable than the node actually was, until the first pod stayed in ContainerCreating.

Use the profile that carries the shim and its prerequisites:

Workload Profile Additional prerequisite
Confidential guests try-kata-tee.values.yaml The matching TEE hardware and host setup
NVIDIA CPU images try-kata-nvidia-cpu.values.yaml The profile configures EROFS and dm-verity
NVIDIA GPU images try-kata-nvidia-gpu.values.yaml GPUs and the NVIDIA GPU Operator's node labels
Firecracker try-kata-fc.values.yaml A host devmapper thin-pool, which kata-deploy does not create
Remote hypervisor try-kata-remote.values.yaml A deployed remote provider, such as cloud-api-adaptor

Profiles are complete values files

Pick one as the starting point and apply your overrides to it. Combining two profiles produces a mixture neither describes. Enabling a shim by name alone no longer suffices: the chart rejects an enabled shim with no supportedArches, so use its profile or copy its complete definition and prerequisites.

An upgrade also removes this installation's nydus service and proxy plugin if nydus is no longer requested, rather than leaving a service that neither later upgrades nor uninstall would remove. If you need to keep nydus, request it explicitly. The RuntimeClass guide describes the classes, their intended workloads and their requirements.

Containerd forwards only the configured annotations

Every containerd handler used to forward io.katacontainers.*, even when the Kata configuration had not enabled the annotation. Agent, runtime and container-resource annotations could therefore reach settings that have no second allowlist at the runtime layer. kata-deploy now derives forwarding from each handler's effective configuration, including drop-ins (#13857).

Only the hypervisor annotations named in enable_annotations are forwarded by default. Use shims.<shim>.allowedHypervisorAnnotations to enable those, and the explicit extra patterns for other annotations you intend to permit:

values.yaml
containerd:
  extraPodAnnotations:
    - sgx.intel.com/epc
shims:
  qemu:
    containerd:
      extraPodAnnotations:
        - example.com/kata-*

Review workloads that depend on annotations

Agent, runtime and container-resource annotations need an explicit forwarding rule now. Setting containerd.extraPodAnnotations: ["io.katacontainers.*"] restores the old behaviour and its exposure; prefer the individual patterns you need.

Cloud Hypervisor drops confidential guest support

Cloud Hypervisor's upstream tdx build feature is rejected from v53.0, so Kata stops requesting it and rejects confidential guests in the runtime-rs backend. The Go backend rejects TDX alongside its existing SEV and SEV-SNP rejections (#13279). The packaged VMM is now v54.0 (#14054).

Use a supported QEMU confidential handler for those workloads. Keeping TDX configuration from an older Cloud Hypervisor deployment does not preserve that support.

The containerd baseline moves to 2.2

The project's minimum/latest containerd versions move from v1.7/v2.3 to v2.2/v2.4, following the end of support for 1.7 (#13869). Plan host upgrades around the new baseline. This does not upgrade the containerd daemon on your nodes, and it is separate from the Go shim's client library, which remains on the 1.7 series.

Guest-pull policies and policy state change together

Both runtimes now send empty image_guest_pull storage driver_options; the agent derives sandbox identity from the OCI container-type annotations rather than host-supplied driver metadata, and generated policies reject unexpected driver options (#13692).

Policies also bind each guest-pulled image source to its declared container image. Unpinned references must match byte for byte. Pinned references may change registry, repository or tag, but both sides must carry the same canonical SHA-256, SHA-384 or SHA-512 manifest digest; the sandbox source must be pause (#13902).

Policy state now identifies a container by its policy-array index, prevents two active containers from sharing one policy entry, and permits only one sandbox creation. RemoveContainerRequest defaults to denial when its rules do not match (#13891).

Regenerate policies with the matching release

The runtime request shape, the agent's policy state and the generated rules change together. Regenerate policies and validate guest-pull workloads before rollout. A policy state patch failure, or a patch returned for an unsynchronized request type, now shuts the guest down rather than letting it continue with inconsistent authorization state.

Bundled NFD moves to 0.20.0

The vendored Node Feature Discovery chart moves from 0.19.0 to 0.20.0. If you enable its optional topology updater, the new chart changes its NodeResourceTopology permissions from create/get/update to create/patch. Externally managed RBAC needs all four verbs during upgrades and rollbacks, while old and new updater pods coexist. The updater also rolls up to ten percent of its pods at once; set node-feature-discovery.topologyUpdater.updateStrategy.rollingUpdate.maxUnavailable: 1 to keep the previous pace of one pod.

The unused agent developer option is removed

agent.devmode is removed from the agent configuration and documentation (#14044). It had never changed the Rust agent's behaviour and did not enable core dumps as the old documentation claimed. Remove it from custom guest command lines or agent configuration, and drop the obsolete KATA_DEV_MODE contributor setup step.

Building from source

Rust moves from 1.96 to 1.97 (#13934), and Go from 1.26.7 to 1.26.9 (#13987, #14038). Contributor CI also checks Cargo.toml formatting with taplo format --check (#11131).

Notable fixes

Security

Dragonball validates complete guest-memory ranges. The vsock and balloon paths checked addresses without establishing that the entire accessed range belonged to one contiguous guest-memory mapping. A guest-controlled buffer could therefore cross into unrelated host memory in the shim. The full header, data and balloon reporting ranges are now validated before host pointer access or memory discard (#13661).

Template clones get fresh randomness and the current time. runtime-rs restored the guest RNG state and clock from the snapshot without replacing either, so clones could share random output and inherit a clock behind by the age of the template. After connecting to the agent it now reseeds the RNG from fresh host entropy and sets guest time, failing startup if either operation fails (#13912).

Recovery state stays outside the VMM user's writable directory. Non-jailed sandbox state.json is stored under the root-owned /run/kata/<sid>, so the unprivileged VMM cannot replace the state a root recovery process later reads (#13985).

SELinux labels are applied in the child. runtime-rs no longer leaves a pending exec label on a shim thread while preparing a VMM. QEMU, Cloud Hypervisor, Firecracker and its jailer, virtiofsd and nydusd apply their VM label only in the child, and label errors fail launch. This prevents an unrelated helper spawned on that thread from inheriting the VM's label (#14053).

The policy-state operations described above are synchronized so concurrent requests cannot race authorization state (#13891). NVRC artefact verification also pins the signing identity to the workflow for the selected source; testing an NVRC pull request is possible, but a required static check prevents merging a pin to anything other than a published release (#13994).

Dependency updates carrying security fixes are listed under Dependencies.

Runtime

runtime-rs teardown preserves host data and retries unfinished work. This is a series of related fixes rather than one new cleanup path:

  • Sandbox teardown detaches remaining mounts and checks none remain before recursively removing the shared tree. Previously that removal could follow a bind mount into host files, delete them, and then fail with EBUSY (#13958).
  • Deleting a container before Start releases its rootfs and volumes, and a failed container setup rolls back volumes already acquired. Both paths used to leave mounts behind for sandbox teardown to encounter (#13961, #13964).
  • Rootfs, bind mounts and shared-volume cleanup can be retried after partial success. A shared reference is released only once, so retrying cannot unmount another container's live share (#13959).
  • Container cleanup reports failures and keeps pending resources until they are released. Stopped containers and Delete retry that work, and cancellation no longer discards unfinished entries (#13960).
  • Sandbox exit, TaskExit and teardown are coordinated so containerd cannot remove paths while the VMM still owns them. Independent cleanup steps can finish even when one fails; failed steps remain available for a bounded retry. VMM fallback signaling uses process identity and a pidfd, while filesystem daemon ownership is retained until exit (#13674).

Recovery after shim death reaches the resources it must remove. The fresh Delete process registers configuration plugins before loading persisted configuration (#13968), waits for cgroup v2's populated 0 before removing a killed multithreaded VMM's cgroup (#13969), and does not try to change the read-only TimeoutStopUSec property on a restored systemd scope (#14042). It also removes the shared directory when the restored resource manager has no in-memory shared-filesystem object (#14060).

A missing OCI bundle no longer prevents that recovery, and the fresh process initializes logging early enough for validation and cleanup failures to reach the journal (#14056, #13973).

Other runtime fixes matter on the ordinary path too:

  • Containers have one exit waiter. CreateContainer and StartProcess both spawned one, publishing duplicate TaskExit events and leaving a sandbox waiter looking up a container already deleted by teardown (#13938). A container killed before Start now gets a waiter too, so Wait and deletion can finish rather than hanging in Created (#13965).
  • Cleanup respects ownership. runtime-rs unmounts a source rootfs only if the shim mounted it, preserving CRI-O's storage ownership (#13939). It removes Kata-created network namespaces, including the replaced rootless namespace, and empty per-container share directories (#13971, #13966).
  • Rootless QEMU's filesystem socket fits. A full sandbox ID and a five-digit UID could put the virtiofsd socket beyond the Unix socket path limit. QEMU now uses the short symlink approach already used for Cloud Hypervisor, with stale links and cleanup handled for both (#14056).
  • Template configuration is checked before restore. Configuration is loaded, adjusted, annotated and validated once. A saved template whose VM configuration differs from the sandbox's now falls back to a normal boot, including differences from resource sizing or annotations (#13594).
  • Cloud Hypervisor preserves sparse disks. runtime-rs no longer maps discard_unmap to the VMM's sparse option, which made ordinary sparse direct-volume images get fully allocated on attachment (#14032). Its network queue-pair count is capped at the rounded-up boot vCPU count, before TAP creation, for both cold plug and hotplug. DAN requests above 256 queue pairs are capped across VMMs too (#13809).
  • Non-QEMU backends stop inheriting QEMU firmware. Generated runtime-rs configurations for direct-kernel VMMs no longer accidentally acquire QEMU's aarch64 AAVMF path (#13734).
  • Go-runtime Firecracker guests receive volume updates. Setting the backend's shared filesystem mode to none starts the copy event loop, so rotated Secrets, ConfigMaps, projected volumes and service-account tokens reach a running guest (#14051).
  • Memory-backed emptyDir follows symlinked host paths. Both runtimes resolve mount paths before comparing them with the mount table, avoiding disk-backed treatment when /var points elsewhere. The Go parser also decodes escaped mount paths, and Rust hugepage handling shares the corrected lookup (#13755).
  • QEMU on ppc64le can fall back to XICS. The Go backend no longer forces kernel_irqchip=on on pseries, which made LPARs and nested guests without XIVE fail at QEMU startup (#13848).
  • Exec preserves no_new_privileges. The Go runtime carries the OCI flag into the agent request, so an approved exec probe no longer fails a policy that requires it (#14025).
  • VFIO accepts an IOMMU enabled by the kernel default. #14099 removes an x86 kernel-command-line check that rejected passthrough when no iommu= parameter was present, even if the kernel had enabled the IOMMU by default. runtime-rs instead relies on the existing /sys/class/iommu check, so hosts built with CONFIG_INTEL_IOMMU_DEFAULT_ON=y can use VFIO without adding a redundant boot parameter. The check for an enabled IOMMU remains in place.
  • VFIO devices in one IOMMU group share an IOMMUFD context. QEMU used to get one object per device, so the second device in a shared group failed with EPERM and QEMU exited. Both runtimes now share one context across cold-plugged devices; the Go runtime also reuses it for hotplug. This fixes configurations such as four NVSwitches in one group and avoids pinning guest RAM once per device, which could exhaust the rootless VMM's memory-lock allowance with ENOMEM (#14096).
  • Large file copies are chunked. runtime-rs no longer tries to encode files larger than 2 GiB in one protobuf message (#13569).
  • Dragonball validates the whole block transfer. Range checks accumulate all data descriptors and use checked arithmetic, rejecting a combined request beyond disk capacity even when each descriptor alone appeared to fit (#14029).

Agent and policy generation

  • Metrics cannot monopolize agent workers. Synchronous collection moves to the blocking pool, with one active collection and concurrent requests using the last successful response. A stuck filesystem query no longer ties up workers needed for health or signal handling. The Go shim bounds agent metrics requests per sandbox, propagates cancellation, and keeps shim metrics available when guest collection fails (#13491).
  • Scraping QEMU or Firecracker no longer panics runtime-rs. Their unimplemented hypervisor metrics methods now return an empty payload with a warning, leaving agent and shim metrics available (#13707). kata-monitor also mounts /run/kata so it can discover runtime-rs sandboxes (#13855).
  • PCI environment variables use guest addresses for every device. #13935 restores PCIDEVICE_* translation during container creation: the agent had updated a temporary copy of the environment and discarded the result. It also accumulates address mappings across all of a container's VFIO devices, rather than retaining only the last device's mappings, fixing translation for multi-device containers on both creation and exec. Conflicting mappings are rejected without adding any mappings from that device.
  • CPU throttling time is reported on cgroup v2. The agent reads throttled_usec and converts it to the nanoseconds expected by the metric (#13852).
  • Exec unseals secret environment variables. Sealed secrets are handled during exec as well as container creation, so kubectl exec gets the usable value rather than its sealed representation (#13859).
  • Generated policies match Kubernetes inputs more closely. Images with environment variables but no PATH get the default path containerd supplies (#13879). Rolling-update budgets accept percentages and integers, and probe ports use Kubernetes' integer-or-string type (#13892). Missing Secret and ConfigMap inputs name the resource and key and explain how to provide them (#13893).
  • Policy diagnostics reach the agent log. Rego prints for denied requests go through structured logging, including failures outside an interactive kubectl call. Policy log output uses a response field for responses, and use of AllowRequestsFailingPolicy emits a warning (#13887).

Deployment

  • Relocated confidential installations boot with their own assets. The installation-prefix drop-in relocates paths from each shim's actual configuration, including firmware and guest extensions, rather than imposing plain-QEMU paths on confidential shims. Its QEMU wrapper follows the actual binary too (#13842).
  • Side-by-side installations keep separate drop-ins. The install suffix now reaches the user drop-in and the k0s/K3s containerd drop-in, so uninstalling one release cannot remove another's handlers or fs-verity configuration (#13844).
  • Redeploy removes handlers it no longer enables. Stale containerd stanzas and platform entries no longer advertise deleted configurations. Turning debug off also removes the containerd debug level Kata wrote (#13843).
  • Scheduled reconcile can stop cleanly on uninstall. Its stop hook has the list/watch permissions needed by waited foreground deletion, so it can stop both the CronJob and outstanding per-node install Jobs before reverting nodes (#13845).
  • External NFD installations are detected by label. Helm release prefixes no longer make node selectors and NodeFeatureRules miss a running NFD (#13906).
  • An invalid DCGM install can still be removed. Enabling DCGM on a CPU shim is still rejected during installation, but no longer blocks cleanup, reset or the shared SELinux stage (#14064).
  • The installed version is visible again. VERSION is staged alongside versions.yaml after the tarball split had stopped carrying it to the host (#14067).

GPU images and builds

The NVIDIA bundle once again builds and ships the GPU and confidential guest extensions its handlers require, and checks measured-rootfs hashes against fresh image artefacts before packaging cached shim configurations (#13849, #13926). Driver sources can come from a complete tarball URL, that source participates in cache keys, and an optional dedicated userspace repository supports driver releases not yet in the CUDA repository (#13862, #13863). DCGM's whole package family is pinned, preventing an upstream package revision from breaking a build that requested the older version (#14002).

For Intel GPUs, the kernel fragment is architecture-qualified and moves to the Xe driver. runtime-rs no longer asks the agent to wait for Intel GPU CDI devices it does not generate, enabling the legacy device flow (#13593). The fragment also enables power management for Xe's GuC communication on SR-IOV VFs; it remains a custom build option, not part of the shipped kernels (#14007).

Dependencies

Component Old New PR
Guest kernel, including NVIDIA and experimental Dragonball v6.18.35 v6.18.56 #13861, #14007
Node Feature Discovery (bundled chart) 0.19.0 0.20.0 Upstream release
Cloud Hypervisor v51.1 v54.0 #13279, #14054
Firecracker v1.12.1 v1.17.0 #14016
Intel TDX OVMF edk2-stable202511 edk2-stable202608 #13717
NVIDIA driver 595.58.03 615.71.09 #14093
Go 1.26.7 1.26.9 #13987, #14038
Rust 1.96 1.97 #13934
Supported containerd minimum / latest v1.7 / v2.3 v2.2 / v2.4 #13869
containerd/containerd (Go client) 1.7.35 1.7.36 #13914
OpenTelemetry (Go) 1.44.0 1.45.0 #13871
golang.org/x/net 0.58.0 0.60.0 #14038
golang.org/x/text 0.41.0 0.42.0 #14038
h2 0.4.14 0.4.16 #13929
event-listener 5.4.1 5.4.2 #13929
quinn-proto 0.11.15 0.11.18 #14041
rustls 0.23.40 0.23.46 #13929, #14086

The Go updates include security fixes in the toolchain and in x/net and x/text across the runtime, webhook and direct-volume driver. Rust dependency updates address RUSTSEC-2026-0258 (h2), RUSTSEC-2026-0221 (event-listener), RUSTSEC-2026-0285 through the kata-ctl HTTP client update, RUSTSEC-2026-0340 and RUSTSEC-2026-0341 (quinn-proto), and RUSTSEC-2026-0346 through RUSTSEC-2026-0349 (rustls), as recorded in the linked update PRs.

Cloud Hypervisor v54.0 brings flat VMDK support needed for merged multi-layer EROFS images. Firecracker v1.17.0 supports the 6.18 guest kernel and brings vsock and logger fixes. The kernel updates retire two now-upstream filesystem patches, and the guest kernel enables CONFIG_NETFILTER_XT_MATCH_SOCKET for uses such as Cilium L7 egress inside the guest (#14049).

Known issues

NUMA and vCPU pinning remain disabled by default on the NVIDIA configurations. This release does not re-enable them. The NVIDIA guide drops the earlier GPU-locality recommendation because NUMA is not working as expected on release nodes; follow #13539 and validate explicit overrides against your hardware (#13836).

Sandbox API container DNS still needs follow-up work. runtime-rs now formats the Sandbox API's DNS fields into valid resolver directives, which fixes guest-level operations such as image pulls. Containerd does not supply /etc/resolv.conf or /etc/hostname as workload OCI mounts on this path, and the runtime still needs to expose the guest resolver and hostname files to the containers. The merged fix therefore restores guest DNS, not container DNS (#13921).

Do not first deploy EROFS or nydus onto a node that has already used them. The settings kata-deploy writes can disagree with those used to create existing layers. Both snapshotters require a node where neither has been used before; see the EROFS guide and Helm configuration (#13905).

Testing and support coverage

Change Effect PR
NVIDIA GPU runtime-rs on arm64 Adds single-GPU coverage on BF3 with EROFS; vLLM is skipped for disk capacity, and NIM nightly selection checks available CPUs #14020
NVIDIA GPU jobs restored after a temporary pause The GPU jobs run again; this does not by itself make them required merge gates #14012, #14018
Containerd stability matrix installs the selected version The minimum/latest legs now test the requested containerd rather than both using the runner's preinstalled daemon #13996
External PR updates need renewed CI approval ok-to-test is removed on updates from non-members, with an event-time guard so a stale label cannot authorize the new code #13980
TOML formatting is required taplo format --check gates changes to Cargo.toml files #11131
Hosted Ubuntu runners move to 24.04 Workflows and kcli worker images move off the retiring 22.04 image #13831
Peer-pods CI uses released CVM images It continues checking cloud-api-adaptor changes but no longer exercises the latest podvm changes in that pipeline #13821

New regression coverage includes direct-volume sparseness, rootless device provisioning, relocated confidential installations, independent drop-ins for side-by-side installs, and cleanup after an invalid DCGM setting. Guest-extension devkit coverage now includes Cloud Hypervisor and Dragonball. Policy request fixtures use shared bases and RFC 6902 patches, making individual cases easier to inspect (#13773).

Documentation

The new RuntimeClass guide explains which class to choose and what its host must provide, while Helm configuration describes profiles, annotation forwarding and rootless provisioning. The rootless guide now spells out the device access contract and TEE setup. NVIDIA instructions correct the CDI filenames, NVSwitch specification and GPU deployment prerequisites (#13836).

The release process records the target date as the first Tuesday after the 15th of each month (#13900). Security reporting guidance clarifies that CVE assignment must be explicitly requested (#13983). Kubernetes distribution detection is documented as probing the known systemd unit names; renamed units and other init systems are outside that detection (#13846).

Upgrading

  1. Review deploymentMode: job mode is the default again, including the NVIDIA profiles. Set it explicitly if your rollout depends on DaemonSet mode.
  2. Start specialized deployments from the appropriate try-kata-*.values.yaml profile. Keep its complete shim definitions and snapshotter prerequisites; a shim name with enabled: true alone is insufficient.
  3. Review the snapshotters your existing release uses. The default no longer requests nydus, and an upgrade removes this installation's nydus service if it is no longer selected. Keep it explicit if workloads still need it.
  4. Audit pod annotations. Enable the hypervisor annotations you need and add explicit forwarding patterns for agent, runtime or container-resource annotations your workloads use.
  5. Move Cloud Hypervisor confidential workloads to a supported QEMU handler.
  6. Plan for containerd 2.2 or later on the host; updating Kata does not update the daemon for you.
  7. Regenerate agent policies with this release, and validate guest-pull image references, container identity and removal against the new rules.
  8. If enabling rootless VMMs through Helm, use job mode and check that device rules survive a node reboot. Provision QGS socket permissions separately where TDX quote generation uses a Unix socket.
  9. Remove agent.devmode from custom agent configuration and command lines.
  10. Review the full breaking changes and known issues sections above.

For general guidance, see Upgrading and the installation instructions.