Learn through the super-clean Baeldung Pro experience:
>> Membership and Baeldung Pro.
No ads, dark-mode and 6 months free of IntelliJ Idea Ultimate to start with.
Last updated: March 18, 2024
kubectl attach and kubectl exec grant us access to the command line of a container in a pod as if we were logged into the container. Both commands are useful when debugging containerized applications in a Kubernetes cluster. But while their uses are similar, kubectl attach and kubectl exec serve different purposes.
In this tutorial, we’ll compare kubectl attach and kubectl exec and highlight their differences.
At its simplest, kubectl attach attaches to the main process of the default container in a pod and returns the output of said process:
$ kubectl attach test-pod
Defaulted container "app" out of: app, nginx, busybox
If you don't see a command prompt, try pressing enter.
.
Illuminate\Database\QueryException
SQLSTATE[HY000] [2002] No such file or directory (SQL: select * from information_schema.tables where table_schema =
and table_name = migrations and table_type = 'BASE TABLE')
...truncated...
In the command above, we attached to a pod named test-pod. However, the main process of the default container in said pod throws a MySQL general error. So, when we attached to that pod, our output was that error.
But if we switch to another container using -c, we should get a different result:
$ kubectl attach test-pod -c nginx
If you don't see a command prompt, try pressing enter.
The container nginx in the command has no output. This is why we only see the prompt to press enter.
If we configure the container with stdin set to true, we can pass standard input to the container using -i:
$ kubectl attach -i test-pod -c busybox
If the container also has tty set to true, we can switch to raw terminal mode by adding –t:
$ kubectl attach -it test-pod -c busybox
kubectl exec executes a command in the container of a specified pod and returns the output.
Let’s run whoami in the default container of test-pod:
$ kubectl exec test-pod -- whoami
Defaulted container "nginx" out of: nginx, busybox
root
We can run the same command in the busybox container using -c:
$ kubectl exec test-pod -c busybox -- whoami
root
To get into interactive mode, we’ll use -i:
$ kubectl exec test-pod -c busybox -i -- sh
ls -t /usr
bin
sbin
Then to go into raw terminal mode, we’ll add -t:
$ kubectl exec test-pod -c busybox -it -- sh
kubectl attach and kubectl exec are similar in that they allow interactions with containers without logging into the containers’ terminals. Both commands return outputs from their interactions with containers, and their syntaxes share some similarities. However, the way they interact with containers differ.
The primary role of kubectl attach is to gain access to the input/output stream of a container. On the other hand, kubectl exec is primarily for executing commands in a container – typically short-lived diagnostic commands.
kubectl attach always attaches to the main process of the target container. Contrarily, kubectl exec does not need the main process to run commands; it runs its own processes.
kubectl attach connects to the output stream of the target container by default. Then it stays connected until we terminate the session.
On the contrary, kubectl exec does not connect to the I/O stream of the container by default. It just runs a command and returns the output. To connect to the I/O stream, we must use the -it flags with kubectl exec.
When we terminate a kubectl attach session, we also terminate the container. But when we terminate a kubectl exec session, the container remains unterminated.
By default, kubectl attach returns output in the terminal of the container to which it is attached. Contrarily, kubectl exec displays output in our local terminal (the terminal from which we run it). But in interactive mode, kubectl exec will return output in the target container.
In this tutorial, we saw an overview of kubectl attach and kubectl exec commands. Then we discussed the differences between them.
Most distinctions between kubectl attach and kubectl exec are reflective of their dependence on their target container’s main process. kubectl attach, which is dependent on its target container’s main process, becomes interconnected with the container in many ways. kubectl exec, which is independent of the target container’s main process, barely intersects with the target container’s main process.