Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

If kubectl exec -it POD -- sh fails because the application image has no sh, use kubectl debug to add a separate ephemeral container with its own shell and diagnostic tools. That gives you a way to investigate the running Pod; it does not install a shell in the application container. Whether the debug container can see the application’s processes depends on Pod namespace configuration and container-runtime support.

Why kubectl exec -- sh fails

Distroless images contain an application and its runtime dependencies, but omit shells and the utilities normally found in a general-purpose distribution image. If the image does not contain sh, kubectl exec -it POD -- sh has no executable to launch. This is a limitation of the image contents, not a special restriction imposed by kubectl exec. The Distroless project describes these images as containing only the application and runtime dependencies.

Kubernetes documents ephemeral containers as useful for interactive troubleshooting when kubectl exec is insufficient because an image lacks debugging utilities. The feature has been Stable since Kubernetes v1.25; check the documentation for your cluster and kubectl release when applying the commands below.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Add a debug container to the running Pod

An ephemeral container is a separate container added to an existing Pod for user-initiated troubleshooting. It supplies its own image, shell, and utilities; it does not change the application image. Kubernetes documents this BusyBox pattern:

kubectl debug -it POD --image=busybox --target=APP_CONTAINER
  1. Replace POD with the Pod name and APP_CONTAINER with the name of the application container you want to target.
  2. Choose an image that actually contains the shell and diagnostic tools your investigation needs. The --image option selects that image.
  3. Use --target to request targeting the named container’s namespaces. If the command starts an interactive session, run the tools available in the debug image there.

The Distroless project also publishes :debug image variants that include a BusyBox shell. These can help when building or testing a debug variant, but they are distinct from adding an ephemeral container to an already-running Pod.

What the debug container can—and cannot—see

Application processes: possible, not guaranteed

--target=APP_CONTAINER requests namespace targeting; it does not guarantee that the application process will appear in ps. Kubernetes says the container runtime must support the target parameter. Without that support, the debug container may fail to start or may start with an isolated process namespace, leaving the target’s processes invisible. Check the Pod’s process-namespace setup and runtime behavior before treating an empty process listing as evidence that the application is not running.

Application files and internal state: not automatically shared

The ephemeral container has its own filesystem and toolset. Kubernetes describes it as a way to inspect a service and troubleshoot, not as a promise that the application container’s complete filesystem or all of its internal state is available. Process visibility and other access also depend on namespace configuration, capabilities, and permissions.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Security settings still apply

A selected debug profile does not automatically bypass the Pod’s security configuration. Kubernetes notes that some profile capabilities may not work when the entire target Pod is configured to run as a non-root user. The image, profile, and applicable permissions determine what the session can do.

Choose the right kubectl debug mode

Method Where it runs What it is for
Ephemeral container Added to the existing Pod Interactive troubleshooting of that Pod; process visibility when targeting another container remains dependent on namespace setup and runtime support.
Pod copy A separate copied Pod Troubleshooting with selected changes, such as a different image or command. It is not the same running application instance.
Node debugging A debugging Pod in the node’s host namespaces, with the host filesystem mounted at /host Node-level investigation rather than inspection of the application container as if it had gained a shell.

These modes address different questions: whether you need to inspect the existing Pod, reproduce an issue in a modified copy, or investigate the node beneath the workload.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Know the limits before adding an ephemeral container

  • Ephemeral containers are intended for troubleshooting, not application workloads, and do not have automatic restart guarantees.
  • Once added, an ephemeral container cannot be changed or removed.
  • Its specification cannot include fields such as ports, liveness or readiness probes, or resource requests. Pod resource allocations are immutable.
  • Ephemeral containers are unsupported for static Pods.

For the exact syntax and current behavior of targeting, profiles, Pod copies, and node debugging, consult the Kubernetes documentation on debugging a running Pod and the Kubernetes overview of ephemeral containers.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.