Kubernetes β€’ Debug & Inspection

How to Exec into a Kubernetes Pod with an Interactive Bash Shell

`kubectl exec -it` attaches your standard input (stdin) and allocates a pseudo-TTY to a running container. This enables live inspection of container files, environment variables, DNS resolution, and internal processes.

Exec Interactive Bash in Pod Command
Caution β€’ Restarts Pods or Executes Shell
kubectl exec -it my-app -n default -- /bin/bash
Customize:
Namespace:
Resource Name:

Flags & Parameter Breakdown

-iKeep standard input open (interactive)
-tAllocate a pseudo-terminal (TTY)
-c <container-name>Required if the pod has multiple containers
-- /bin/shFallback shell if /bin/bash is not installed (e.g. Alpine Linux)

Step-by-Step Execution Workflow

1Verify the pod is running

Check that the pod is in Running state before attempting to exec:

kubectl get pods -n default
2Exec with bash

Run interactive exec into the primary container:

kubectl exec -it my-pod -n default -- /bin/bash
3Alpine fallback if bash is not found

If the container returns "OCI runtime exec failed: /bin/bash: not found", use /bin/sh:

kubectl exec -it my-pod -n default -- /bin/sh

Common Pitfalls & Troubleshooting Advice

  • In multi-container pods, specify `-c <container-name>` or kubectl will default to the first container defined in the spec.
  • Production distroless or scratch images do not include shells. For those, use ephemeral debug containers: `kubectl debug -it <pod> --image=busybox`.

Prerequisites & Cluster Access

  • Pod status must be Running (not Pending or CrashLoopBackOff).
  • Container must have a shell installed (/bin/bash or /bin/sh).

Frequently Asked Questions About Exec Interactive Bash in Pod

Frequently Asked Questions

Frequently Asked Questions

Everything you need to know regarding specifications, syntax, and security best practices.

Many lightweight container images (like Alpine Linux or slim Debian) do not install bash by default. Replace `/bin/bash` with `/bin/sh`.