# Use Kubernetes restartable sidecars with an explicit shutdown plan

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

- Canonical URL: https://update.dsesecurity.com/updates/use-kubernetes-restartable-sidecars-with-an-explicit-shutdown-plan/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:14:40+00:00
- Modified: 2026-10-20T18:34:31+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://kubernetes.io/docs/concepts/workloads/pods/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](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/). Reviewed October 20, 2026.

## Primary reference

- Name: Kubernetes documentation — Sidecar Containers
- Authority: kubernetes.io
- URL: https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Use Kubernetes restartable sidecars with an explicit shutdown plan,” DSE Security, https://update.dsesecurity.com/updates/use-kubernetes-restartable-sidecars-with-an-explicit-shutdown-plan/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.