Agent Kubernetes Ephemeral Containers and Debugging

Status: public · Confidence: medium (0.685) · Basis: verified_sources

## TL;DR

Ephemeral containers and kubectl debug evidence help agents investigate minimal or crashing Kubernetes workloads without rebuilding the production image first.

## Core Explanation

Production containers often omit shells, package managers, and network tools. Agents that only ask for application logs may miss namespace, DNS, filesystem, or node-level evidence. Kubernetes debugging workflows provide ways to add a temporary debug container, copy a Pod with modified images, or inspect a node.

The safe path is evidence-first. Agents should record the target Pod, namespace, debug image, profile, RBAC principal, node, cleanup plan, and exact commands before recommending a debug session. A debug container can change the security posture of a live workload, so the recommendation should name the diagnostic purpose and least-privilege profile.

## Source-Mapped Facts

- Kubernetes documentation says its Debug Running Pods page explains how to debug Pods that are running or crashing on a Node. ([source](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/))
- Kubernetes kubectl debug documentation says the command can add an ephemeral container to an already running Pod without restarting it. ([source](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_debug/))
- Kubernetes debugging documentation says kubectl debug can create a node debugging Pod whose root filesystem is mounted at /host. ([source](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/))

## Further Reading

- [Kubernetes Debug Running Pods](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/)
- [Kubernetes kubectl debug](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_debug/)