Kubernetes 1.33 gives sidecars a stable lifecycle

A Job that finishes its work should be able to complete even when its network proxy is designed to run forever. Treating both processes as ordinary application containers makes that difficult. The proxy has no independent reason to exit, while Kubernetes needs all the relevant work to finish before it can regard the Pod as complete. Applications then acquire shutdown coordination that exists only to compensate for the container model.

The Kubernetes 1.33 release announcement makes native sidecars stable. The mechanism places a long-running auxiliary container in the init container sequence and marks it with a container-level restart policy of Always. This gives Kubernetes enough information to treat that container differently during both initialization and completion.

I value the controller and API machinery in Kubernetes more than any individual workload type. This change is interesting because the API now describes a relationship that applications previously had to implement themselves. A helper can remain available to the main workload without becoming part of the definition of when that workload has finished.

The problem includes the beginning of a Pod

The earlier design recorded in KEP-753 documents several motivations. A log collector may need to capture the application's startup output. A network proxy may need to accept connections before initialization code attempts to use the network. Both can also be required during shutdown, after the main application has begun releasing its resources.

An ordinary init container runs before application containers, but its successful completion is the condition for moving on. A long-running proxy cannot fit that contract. An ordinary application container can keep running, but that placement does not express its required order relative to initialization. The native sidecar combines continuing execution with ordered startup.

Its location in initContainers is therefore functional. Kubelet processes that sequence in order. When it encounters an init container with restartPolicy set to Always, it waits for startup instead of waiting for the process to exit successfully. It can then proceed to the next init container while the sidecar continues running.

This supports an initialization step that needs an already running helper. A later init container can perform its finite task after the helper has started. Application containers begin after the init sequence has advanced through its required steps, with the sidecar still present.

The shape of the declaration also limits the feature. This is not a general dependency graph between arbitrary application containers. It uses the existing init sequence to express the ordering Kubernetes needs. Keeping the model constrained makes it easier to understand what startup ordering does and does not promise.

A process starting is not the same as a dependency being usable

The KEP explains startup completion through container status and startup probes. A startup probe provides a way to establish that a helper has reached the point required by subsequent initialization. Without such a probe, starting the process cannot prove that its listener or external dependencies are already usable.

The following fragment shows the declaration that distinguishes the sidecar from an ordinary init container. It belongs inside a Pod specification and is not a complete workload manifest. The helper image and its startup checks remain specific to the application being deployed.

initContainers:
  - name: helper
    image: example.invalid/helper:1.0
    restartPolicy: Always

The image reference is an illustrative placeholder. The relevant stable API behavior is the combination of initContainers and restartPolicy. Moving a real container into that position still requires deciding what observation establishes successful startup for that particular helper.

Readiness probes answer a different question. The KEP says a sidecar's readiness contributes to the readiness of the Pod. That can keep a Pod out of ready service while the helper is unable to perform its role. It does not make readiness a substitute for the startup condition that controls progression through the init sequence.

Liveness concerns another state transition, restarting a process that no longer performs correctly. The release announcement calls out support for startup, readiness and liveness probes. Their availability allows the helper to participate in the same operational controls that an application container needs while retaining its distinct lifecycle relationship.

Completion no longer requires a helper to finish its own work

KEP-753 explicitly says that sidecars do not block Pod completion. Once the regular containers complete, Kubernetes terminates the sidecars. That resolves the Job case without requiring the batch application to send an application-specific shutdown message to a proxy or collector.

The distinction is between the work whose completion defines the Pod's outcome and the services that support that work. A continuously running helper can be healthy at the moment the batch process finishes. Its health is compatible with stopping it because the work it supports has ended.

This is especially useful when a helper is injected by separate tooling. Without a lifecycle contract, the application and injector need to agree on extra shutdown behavior. Native sidecars let the Pod model express why the injected process should continue running and when it should stop.

The design also considers restart behavior. A sidecar must be kept available while the application runs, including for Pods whose main containers use a non-restarting policy. Reusing the word Always at container scope does not mean the Pod itself should run forever. The helper's restart behavior and the main workload's completion behavior have different responsibilities.

I prefer that separation to making every batch program understand the proxy injected beside it. The application still owns its protocol-level behavior, but it should not need a special agreement merely to tell Kubernetes that an auxiliary process is no longer required.

Shutdown ordering still shares a deadline

The design discusses keeping sidecars running until the main containers terminate, then stopping sidecars in reverse order. That is useful when a helper depends on another helper. Reversing the startup order allows the dependency that started first to remain available while a later helper exits.

There is still a Pod termination grace period. Sidecars do not receive unlimited time after application shutdown. The design explicitly considers environments with a fixed external deadline, and it describes termination within that shared time budget. A main container that consumes most of the budget leaves less time for auxiliary cleanup.

The KEP also discusses PreStop hooks and their interaction with termination. Hook behavior needs to fit within the same grace period. Ordering the normal termination signals cannot guarantee arbitrary cleanup after the deadline has expired. This is a bounded lifecycle mechanism, so application cleanup still needs a realistic duration.

Logging illustrates the practical meaning. Keeping a collector alive until application containers stop removes one source of lost shutdown output. It does not establish that a remote logging service has acknowledged every record. The container relationship and the collector's delivery semantics remain separate parts of the system.

The release distinguishes stability from defaults

Kubernetes 1.33 also graduates the nftables kube-proxy backend to stable. The announcement explicitly retains iptables as the default on Linux for compatibility. That provides a useful comparison with native sidecars. Stability identifies the maturity of an available mechanism, while an existing manifest continues to determine which mechanism a workload uses.

A container already declared under containers does not acquire native sidecar behavior merely because the cluster now supports the stable feature. The manifest must express that role through the init container declaration. Likewise, a node does not switch its Service backend simply because nftables has graduated.

Other changes in the same release are at different maturity stages. In-place Pod resource resizing reaches beta after its alpha introduction in 1.27. The release describes changing resource allocation on existing Pods, avoiding replacement for supported updates. That changes another assumption about the Pod lifecycle, but it is a distinct capability with its own conditions.

User namespace support also becomes enabled by default at beta. The announcement states that existing Pods are unaffected unless their specifications opt in through hostUsers. Enabling the feature gate makes the capability available. It does not silently change the user namespace of every running workload.

These distinctions matter when reading the release as an operator. Several improvements concern how a Pod runs over time, but each has a separate activation point. Native sidecars require an explicit auxiliary-container declaration, resource resizing concerns a supported update, and user namespaces require a Pod-level choice. The release expands the available contracts without making those choices interchangeable.

For sidecars, the substantive stable contract is now clear enough to put into workload design. A helper can start during initialization, continue alongside the application, and stop when the application has completed. Startup probes can define the dependency's usable state, while the shared termination budget bounds how long the Pod can spend shutting down its containers.