Kubernetes 1.29 makes sidecar shutdown ordering explicit

A helper that starts before an application may also need to remain available while that application shuts down. Starting a proxy early solves only the first half of that lifecycle. If termination stops the proxy before the process using it has finished, the application loses the dependency during its final operations. Kubernetes 1.29 adds an explicit ordering rule for native sidecar termination.

The December 13 release announcement marks the year's final Kubernetes minor release. Its versioned release notes say SidecarContainers is now beta and enabled by default. They also specify serialised termination. Each sidecar receives SIGTERM after all main containers and later-starting sidecars have terminated.

I value API changes that make lifecycle dependencies inspectable. The original sidecar alpha gave Kubernetes a representation for a helper that starts early and keeps running. Ordered shutdown now describes how that helper remains available while the processes started after it finish.

Reverse ordering follows the declared dependency

Native sidecars use restartable init containers, introduced in the Kubernetes 1.28 announcement. An init container with restartPolicy: Always participates in the ordered init sequence but allows the sequence to advance once it has started. It continues running beside the regular containers instead of needing to exit first.

The 1.29 termination rule makes startup order relevant to shutdown. A sidecar started earlier waits for a later-starting sidecar to terminate. All sidecars wait for the main containers before receiving their ordered termination signal. This gives a chain of helpers a defined relationship instead of treating every container's shutdown as independent.

Suppose one helper depends on another and both support the application. Declaring their startup order records which helper must be available first. Reversing that order at termination preserves the earlier dependency until the later helper has ended. The release note describes this ordering directly, without requiring the application containers to coordinate every helper's exit themselves.

This is still lifecycle management, not proof that an application completes every final request. The declaration describes which containers Kubernetes waits for before signalling a sidecar. Application-specific completion remains part of each process's behaviour. The new rule removes an otherwise separate source of ordering ambiguity from that behaviour.

Beta enablement does not rewrite existing pods

The 1.29 feature-gate definition records SidecarContainers with a true default and beta maturity. That enables the capability by default. It does not change an ordinary container into a restartable init container simply because its name or purpose resembles a sidecar.

The pod definition still selects the lifecycle. A helper must be represented through the native sidecar fields to obtain their semantics. Existing charts or injectors that place a proxy in the ordinary container list need their own integration change if they want native lifecycle handling. Capability availability and consumption by a workload are distinct events.

This matters when describing an upgrade's practical result. Moving to 1.29 makes native sidecar support ordinarily available, but the running pod's specification remains the evidence for how its helper is defined. Inferring native ordering solely from the cluster version would skip the configuration that activates the behaviour for a particular workload.

The same distinction applies to batch completion. The 1.28 announcement says sidecars do not block completion once regular containers finish. That property belongs to the native representation. It cannot be assumed for an arbitrary long-running process in a regular application container merely because the process supports another container.

Resource accounting recognises the continuing helper

The 1.29 release notes include corrections for resources allocated to restartable init containers. CPU sets, device resources, and memory allocated to an init container with restart policy Always had been erroneously reused by a regular container. These fixes follow from the central difference between an ordinary init container and a sidecar.

An ordinary init stage completes before application execution proceeds. A native sidecar continues using its allocation during application execution. Reusing its resources as though the init stage had finished would ignore an active consumer. Lifecycle classification therefore affects resource management as well as startup and shutdown order.

The notes also list a fix for restarting init containers in the correct order relative to regular containers with the feature enabled. Together, these changes show the scope of integrating a continuing init container. Kubernetes needs to preserve its dependency ordering and account for its continued presence after the sequence advances.

I find those resource corrections useful context for the beta. They connect the API representation to the node's actual obligations. A helper is still consuming resources while the application runs, even though its declaration sits in the init list.

Stable KMS v2 changes the encryption choice

KMS v2 encryption at rest becomes stable in 1.29. The release announcement describes an interface to an external key service for encrypting persisted API data. It identifies improvements to key rotation, status and health checking, and observability, alongside performance work.

The release also disables the KMS v1 feature gate by default. Continued use of v1 requires an explicit opt-in. This makes the encryption provider configuration relevant to an upgrade even when the application manifests do not change. A dependency used by the API server's persistence path is part of the control-plane operating configuration.

The claim should remain specific to encryption at rest. An interface for protecting persisted API data does not by itself describe workload traffic encryption or authorisation. Those are different controls. KMS v2's graduation provides a stable mechanism for the storage encryption role named in the announcement.

Its default transition also differs from sidecar enablement. Sidecar beta makes a capability available for pod definitions that request it. Disabling KMS v1 changes the default availability of a legacy control-plane integration. Both are release defaults, but their effects depend on different maintained configurations.

API flow control reaches a stable version

API Priority and Fairness also becomes stable. The release announcement lists the graduation and removes the deprecated flowcontrol.apiserver.k8s.io/v1beta2 API version for FlowSchema and PriorityLevelConfiguration. Manifests or clients using that served version need to change before upgrading to 1.29.

This is a useful distinction between retaining a capability and retaining every API version used to configure it. A feature can become stable while a deprecated beta representation stops being served. An upgrade process needs to consider both maturity and the concrete version strings in its maintained definitions.

The result is an API maintenance task with a definite target. Finding a flow-control resource in configuration is insufficient. The version through which the client reads or writes it determines whether that request remains supported. The announcement explicitly points users toward migration before the upgrade.

Single-pod storage access becomes stable

ReadWriteOncePod reaches general availability for CSI volumes. The announcement contrasts it with ReadWriteOnce, which restricts read-write mounting to a single node. Several pods on that node can still use the volume under the older mode, so that mode does not express a cluster-wide single-pod requirement.

The newer mode restricts use to one pod across the cluster. That is a more precise way to express a workload's storage-access requirement when concurrent access by another pod would be unacceptable. The distinction between a node and a pod is part of the safety property, even though both mode names begin with similar words.

This follows the same preference for explicit relationships seen in native sidecars. A pod lifecycle should identify which containers support the main work, and a volume mode should identify the intended unit of exclusive access. Kubernetes 1.29 stabilises some of these declarations and advances others to beta, with concrete rules that operators can connect to the maintained workload and control-plane configuration.

Legacy service account token cleanup also reaches beta. The release notes limit its invalidation rules to auto-generated secret-based credentials that have not been used for the configured period, are referenced by a ServiceAccount's secrets list, and are not referenced by pods. The default period is one year. A further unused period permits deletion after invalidation.

Those qualifications matter when interpreting the feature. It is not a blanket deletion rule for every Secret or every service account credential. The configuration and usage conditions identify a particular legacy credential lifecycle. As with the release's other changes, the resource's actual role determines which new behaviour applies to it.