Kubernetes 1.28 gives sidecars an explicit startup lifecycle

A helper process can need to start before an application and remain alive for the application's lifetime. An ordinary init container expresses the first requirement by running to completion before later containers start. A long-running helper cannot satisfy that completion rule. Putting the helper beside the application instead leaves its early startup requirement outside the init sequence.

Kubernetes 1.28, released on August 15, introduces an alpha representation for that combination. An init container can declare restartPolicy: Always. The kubelet starts it in the init sequence, waits for startup instead of completion, and keeps it running as a sidecar. This makes a familiar deployment arrangement part of the pod lifecycle that Kubernetes understands.

I value the way Kubernetes makes operating assumptions explicit in its API. A process that prepares an environment and exits has a different role from one that must continue helping the application. Giving those roles distinct lifecycle behaviour reduces the amount of coordination that otherwise has to live in application entrypoints or injected scripts.

An init container can now continue running

The versioned 1.28 API definition restricts the new container-level restart policy to init containers. Its only supported value is Always. Omitting it retains the ordinary init behaviour, which waits for the container to complete before moving forward. The location and value of the field jointly identify the new sidecar behaviour.

For a restartable init container, the kubelet advances after the container has started instead of waiting for it to exit. The release announcement explains startup in terms of the Started container status. A configured startup probe must succeed, and the post-start handler must complete. Without a startup probe, completion of the post-start handler is enough to establish startup.

This means an ordered init list can contain different kinds of dependency. A normal init container must finish its work before the sequence advances. A sidecar init container must start successfully before later init containers or application containers proceed. The helper can then continue running while the rest of the pod starts.

That distinction is useful for a proxy or another long-lived helper. Its work is not complete when the application starts, so waiting for exit would express the wrong condition. The relevant precondition is that the helper has reached the startup state required by the application. A startup probe lets its definition make that condition more specific than merely launching a process.

The new field belongs on the helper

The following fragment shows the distinguishing fields inside a pod's spec. It illustrates the shape of a restartable init container, rather than a complete installation for a particular proxy.

initContainers:
  - name: helper
    image: example.invalid/helper:1
    restartPolicy: Always
containers:
  - name: application
    image: example.invalid/application:1

The example uses placeholder images because lifecycle structure is the point being illustrated. A real helper needs its own command and, when appropriate, a startup probe that represents its startup requirement. Adding the field to a regular application container is not the API introduced by this release.

The distinction from the pod-level restart policy is also deliberate. According to the announcement, a started sidecar restarts after failure even when the overall pod policy is Never or OnFailure. It also restarts after normal exit. The helper's continuous operation is part of its own role, so the pod's application restart behaviour does not completely describe it.

This gives the API enough information to distinguish a batch application's completion from its helper's lifetime. A helper that should continue running during application execution should not force the application itself to use a different restart policy. Those are separate requirements, and the new per-container declaration expresses the helper's requirement directly.

A completed application need not wait for its sidecar

The release announcement states that sidecars do not block pod completion. Once all regular containers have completed, Kubernetes terminates the sidecar containers in that pod. A continuously running helper therefore does not require its own application-specific signal to exit before Kubernetes can consider the pod finished.

That is particularly relevant to bounded work. A regular container can complete its task while its proxy or other helper remains healthy and running. If the helper's continued execution were treated as unfinished application work, the pod could remain active despite completion of the task that justified it. Native sidecar lifecycle gives Kubernetes a basis for ending that helper's lifetime.

Startup and completion now have related but different dependencies. The application can depend on the helper having started. The helper's ongoing lifetime can depend on the regular containers still having work to do. Kubernetes does not have to infer either relationship from a process name or from conventions inside a shell command.

The announcement also says sidecars can restart during pod termination. That detail prevents an overly broad interpretation of completion handling. Native lifecycle support does not mean that the first termination event simply disables all helper behaviour. The stated rules cover operation during the pod lifecycle, including the period when the pod is terminating.

I find the completion rule as consequential as the startup rule. Startup coordination receives attention because it can fail immediately, while a helper that prevents completed work from finishing creates a different kind of operational ambiguity. The API now tells Kubernetes which running process is supporting the work and which containers define its completion.

Alpha behaviour needs a consistent interpretation

Sidecar containers enter 1.28 as alpha. That status is part of the event, and the new declaration should be understood as an experimental lifecycle capability. It is not evidence that every proxy injector, controller, or workload definition already uses the new representation. A helper deployed as an ordinary container still has the lifecycle associated with that definition.

The source makes a narrower claim than a general promise that every application dependency is solved. Kubernetes recognises a restartable init container and applies its startup and completion rules. The workload author still defines what startup means for that helper. A probe that succeeds before the helper is useful would declare a weaker dependency than the application actually requires.

This gives operators and tool authors a concrete integration task. A component that generates pod specifications can express its helper in the init sequence when it wants these semantics. The resulting pod definition then records that choice where Kubernetes can enforce it, instead of requiring a reader to reconstruct the intended ordering from implementation details outside the lifecycle API.

Wider version skew addresses a different source of disruption

Kubernetes 1.28 also expands supported skew between node and control-plane components from two minor versions to three. The announcement names kubelet and kube-proxy on the node side. That change addresses upgrade scheduling rather than container startup, but it has a related operational purpose of reducing unnecessary workload interruption.

The release explanation says minor kubelet upgrades include draining nodes. Operators with long-running workloads can therefore care about how often a supported upgrade sequence requires touching those nodes. Under the previous skew allowance, an operator following an annual catch-up sequence might have to upgrade nodes twice, even close together, to remain within the supported relationship.

The new allowance makes a single annual node minor-version upgrade possible within the scenario the announcement describes. It does not eliminate patch maintenance or make every combination of component versions supported. The article still describes sequential control-plane minor upgrades and current patch versions as part of the annual pattern.

These two changes operate at different levels. Native sidecars let the kubelet manage a helper's lifetime within a pod. Wider supported skew gives an administrator more flexibility over when to change that kubelet. In both cases, the release adds a specific supported relationship to replace an operational assumption that previously needed more coordination outside the declared model.

Failed nodes need lifecycle handling too

Recovery from non-graceful node shutdown becomes stable in this release. The announcement describes StatefulSet pods remaining in Terminating when a stopped node's kubelet cannot delete them. Their existing names can prevent replacement pods from being created. Existing volume attachments can also prevent the associated storage from moving to another node.

That problem concerns work whose original execution environment is unavailable. Waiting for the original kubelet is insufficient when it cannot return. The stable recovery capability supplies a cleanup path so stateful work can restart elsewhere after the original node has shut down or become unrecoverable.

The relationship to sidecars is limited but useful. Lifecycle management must represent both processes that remain alive after their useful work ends and processes whose host cannot report their end. The release addresses those cases through different mechanisms, each with an explicit condition for allowing the workload to progress.