kubectl-attach

Get output from a pod

$ kubectl attach [pod_name]

$ kubectl attach [pod_name] [[-c|--container]] [container_name]

$ kubectl attach [[rs|replicaset]]/[replicaset_name]

$ kubectl attach [pod_name] [[-it|--stdin --tty]]

$ kubectl attach [pod_name] [[-c|--container]] [container_name] [[-it|--stdin --tty]]

kubectl attach POD [-c CONTAINER] [options]

POD
    The required name of the pod to attach to.

-c, --container=NAME
    Name of the container to attach to. If omitted and the pod has only one container, that container will be used.

--stdin
    Pass standard input (stdin) to the container. Necessary for interactive sessions.

--tty
    Allocate a TTY for the container. Often used with --stdin for interactive shells.

--namespace=NAME
    If present, the namespace scope for this CLI request.

--pod-running-timeout=DURATION
    The time to wait (e.g., 5s, 2m) until at least one pod is running. Use 0 for no timeout.

--quiet
    Do not print header information (pod/container names) before attaching.

The kubectl attach command allows users to connect to a specific running container within a Kubernetes pod, effectively redirecting its standard output (stdout), standard error (stderr), and optionally standard input (stdin) to the local terminal. This capability is crucial for real-time observation of containerized application logs, particularly for the primary process (PID 1). Unlike kubectl logs, which retrieves past logs, attach provides a live stream of the process's I/O and can enable interactive communication if the container's process is designed to accept input (e.g., a simple shell or an interactive application). It's invaluable for debugging, monitoring, and direct interaction with the main application process. The command will block until the attached process exits or the user explicitly detaches using the appropriate escape sequence.

• kubectl attach connects to the primary process (PID 1) of the container. If that process doesn't handle standard I/O or signals gracefully, interaction may be limited.
• It does not create a new process; it connects to an already running one. If the connected process exits, kubectl attach will also terminate.
• For interactive shells, the container image must include a shell and the primary process must be configured to accept stdin.
• Attaching to containers can expose sensitive information or allow unintended interaction, depending on container contents and permissions.

While both commands allow interaction with containers, kubectl attach connects to the already running primary process (PID 1) of a container, redirecting its standard I/O streams. It's ideal for monitoring the main application logs in real-time or interacting with an application designed to handle standard I/O directly. In contrast, kubectl exec runs a new command within an existing container. This is typically used to spawn a shell (e.g., bash or sh) for debugging, inspecting files, or running utilities, without affecting the container's primary application process. For most interactive debugging tasks where a shell is needed, kubectl exec is often preferred.

To detach from a container attached via kubectl attach without terminating the process within the container, use the escape sequence Ctrl+P followed by Ctrl+Q. Simply closing the terminal or pressing Ctrl+C will send a signal (like SIGINT or SIGHUP) to the attached process, which might cause the process to terminate, depending on its signal handling configuration.

kubectl attach has been a fundamental command in Kubernetes since its early days, providing a direct, real-time window into the standard I/O of containerized applications. It emerged as a core debugging and monitoring tool, distinct from kubectl logs by offering live streaming and interactive capabilities. While kubectl exec later provided more flexibility by allowing the execution of new commands within containers (like spawning a shell), attach maintained its specific role for connecting to the primary process (PID 1), which is crucial for applications that manage their own I/O or where direct interaction with the main process is needed. Its design has remained consistent, focusing on robust I/O redirection for live container interaction.

kubectl exec(1), kubectl logs(1), kubectl run(1)