kubectl-exec

Open Bash in a pod, using the first container by default

$ kubectl exec [pod_name] [[-it|--stdin --tty]] -- bash

kubectl exec POD [-c CONTAINER] [--] COMMAND [ARGS...]
kubectl exec [-i] [-t] POD [-c CONTAINER] [--] COMMAND [ARGS...]

POD
    The name of the pod where the command will be executed.

-c, --container NAME
    Name of the container to execute the command in. If omitted, the first container in the pod is used.

-i, --stdin
    Pass stdin to the container, enabling interactive input. Essential for interactive shell sessions.

-t, --tty
    Allocate a pseudo-TTY (terminal). Required for an interactive shell experience with proper line editing and cursor control.

--
    A separator. Any arguments after -- are treated as the command and its arguments, useful when the command itself starts with a hyphen.

COMMAND
    The command to execute inside the container.

[ARGS...]
    Optional arguments for the command being executed.

kubectl exec is a fundamental command in Kubernetes that allows users to execute arbitrary commands inside a running container within a pod. It provides a secure way to interact directly with your containerized applications for debugging, troubleshooting, and administrative tasks, without needing to SSH into the host node. This command can capture output, and optionally pass input, simulating a shell-like experience.

Unlike kubectl attach, which connects to the main process of a container, kubectl exec spins up a new process for the specified command. It's widely used to inspect file systems, check network configurations, run diagnostic tools, or perform one-off scripts directly within the container's isolated environment. When combined with the -i (interactive) and -t (TTY) flags, it enables a powerful, interactive shell session inside the target container.

No Default Shell: Containers often do not have common shells like bash or sh installed at standard paths, or they might not be in the container's PATH. You may need to specify the full path (e.g., /bin/sh) or ensure the shell is available.

Security Implications: Granting exec permissions (specifically create on pods/exec) allows users to run arbitrary code inside your containers, which can be a significant security risk. Use Role-Based Access Control (RBAC) to restrict access carefully.

Ephemeral Nature: Commands run via exec are temporary. Any changes made to the container's filesystem are lost when the container is restarted or recreated, unless they are within mounted volumes.

Command Availability: The command you intend to execute must be present and executable within the container's environment.

When you run kubectl exec, the Kubernetes API server receives the request and proxies it to the Kubelet agent running on the node hosting the target pod. The Kubelet then instructs the container runtime (e.g., containerd, Docker) to execute the specified command within the container's namespace. The output and input are streamed back through this proxy connection, providing a seamless user experience.

The most common and powerful usage pattern for kubectl exec is to obtain an interactive shell inside a container. This is typically achieved using the command: kubectl exec -it <pod-name> -- /bin/sh (or /bin/bash). This allows for a rich debugging experience directly within the container's runtime context.

kubectl exec has been a core and indispensable part of the kubectl command-line tool since the early days of Kubernetes. Its introduction provided a crucial mechanism for direct interaction with containerized applications, complementing logging and port-forwarding functionalities. It quickly became the go-to tool for developers and operators for in-depth debugging, allowing them to step into the container's environment to diagnose issues that weren't apparent from logs alone. Its development focused on providing a robust, secure, and reliable way to execute commands remotely, leveraging Kubernetes' internal communication channels.

kubectl logs(1), kubectl cp(1), kubectl attach(1), kubectl debug(1)