Use Kubernetes restartable sidecars with an explicit shutdown plan

A helper’s location in the Pod specification affects completion and termination behavior.

Source facts

Kubernetes supports restartable sidecars through init containers configured with restartPolicy set to Always. They can run alongside the application. During Pod termination, the kubelet waits for main application containers to stop before terminating these sidecars in reverse declaration order. A sidecar implemented this way does not prevent a Job from completing after its main container finishes.

Source: Kubernetes documentation — Sidecar Containers.

Applicability

Review restartable init sidecars, their shutdown sequence and their effect on Job completion.

DSE recommendation

DSE recommends documenting which helpers must remain available during application shutdown. Put log shipping, proxy shutdown, and buffered output requirements into the application’s termination design rather than relying on an assumed simultaneous stop. Distinguish the helper’s health from the main process’s completion criterion. Keep enough termination time for the intended sequence and consider what happens when the application consumes that time. Do not use the presence of a sidecar as evidence that its final output was delivered.

Verification

In an approved test Job, record main-container completion and sidecar termination order. Repeat with a deliberately slow application shutdown and inspect whether the required final records arrive. Retain the observations before changing the production Pod template. Have the helper owner define the final message or buffered item that should arrive. Compare that application result with the termination timeline, rather than accepting an exited container as the only success criterion.

Official reference

Kubernetes documentation — Sidecar Containers. Reviewed October 20, 2026.