Treat Kubernetes ephemeral containers as temporary diagnostic access

An attached debug container is an investigation tool, not a durable application fix.

Source facts

Kubernetes ephemeral containers lack the resource and execution guarantees of ordinary containers and are never automatically restarted. Fields including ports and health probes are disallowed, and resource allocation cannot be set through this diagnostic container. They are unsuitable for constructing an application. The API uses a dedicated ephemeralcontainers subresource rather than an ordinary Pod-spec update.

Source: Kubernetes documentation — Ephemeral Containers.

Applicability

Review ephemeral-container troubleshooting access and its documented API and execution limitations.

DSE recommendation

DSE recommends choosing a trusted debug image and documenting the reason for access, affected Pod UID, operator, and expected commands before attaching it. Keep credentials and customer data out of copied diagnostic output. Use findings to update the managed application image or workload configuration through the normal deployment process. Do not leave a repair dependent on a debug process that has no restart guarantee. Define how the diagnostic session and any files it created will be accounted for when the workload is replaced.

Verification

On a disposable workload, inspect the ephemeral-container status and confirm the expected diagnostic access. Compare the managed Pod template afterward to ensure no lasting application dependency was introduced. Review the authorization and audit record for the session. Set an explicit end condition for the investigation. Ask the workload owner to demonstrate the proposed permanent fix from its managed deployment artifact, without depending on commands typed in the diagnostic session.

Official reference

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