kubectl exec is a command-line tool for executing Kubernetes cluster commands. This article covers the kubectl exec syntax, the command actions, and frequent examples.
Table of Contents
when to use kubectl exec command
Kubernetes is a container orchestrator that lets us automate deployments across multiple physical machines. Starting a shell session to a container in a Kubernetes cluster isn’t the same as using Secure Shell (SSH) on a physical server. Although containers should be stateless and capable of running without intervention, sometimes we may need a shell to debug issues or extract data.
The kubectl exec command lets us start a shell session inside containers running in our Kubernetes cluster. This command lets us inspect the container’s file system, check the state of the environment, and perform advanced debugging tools when logs alone don’t provide enough information.
kubectl exec Syntax
Unlike a simple ssh user@server command, kubectl exec requires a few extra arguments to set up an interactive shell session. Let’s break down the command shown above:
kubectl exec -it demo-pod — /bin/sh
This specifies that we want to run the /bin/sh command in the first container within our demo-pod pod. The — separates the command to run from the kubectl arguments. Anything after the — will be passed to the container, as opposed to kubectl.
The -it is equivalent to using the –stdin (-i) and –tty (-t) flags. These instruct kubectl to route our terminal’s stdin input stream to the container (-i) and treat it as a TTY (-t). This sets up an interactive session where we can supply input to the process inside the container. Without these flags, we’d see a read-only output stream.
Whereas SSH automatically starts a shell process and binds our terminal’s input and output streams, kubectl makes each of these aspects customizable. we don’t have to start a shell in the container.
kubectl exec mypod — date
Get output from running ‘date’ command from pod mypod, using the first container by default
kubectl exec mypod -c ruby-container — date
Get output from running ‘date’ command in ruby-container from pod mypod
kubectl exec mypod -c ruby-container -i -t — bash -il
Switch to raw terminal mode, sends stdin to ‘bash’ in ruby-container from pod mypod and sends stdout/stderr from ‘bash’ back to the client
kubectl exec mypod -i -t — ls -t /usr
List contents of /usr from the first container of pod mypod and sort by modification time. If the command we want to execute in the pod has any flags in common (e.g. -i),
we must use two dashes (–) to separate our command’s flags/arguments. Also note, do not surround our command and its flags/arguments with quotes. unless that is how we would execute it normally (i.e., do ls -t /usr, not “ls -t /usr”).
kubectl exec deploy/mydeployment — date
Get output from running ‘date’ command from the first pod of the deployment mydeployment, using the first container by default
kubectl exec svc/myservice — date
Get output from running ‘date’ command from the first pod of the service myservice, using the first container by default
kubectl exec my-pod — ls /
List the content of the container’s root filesystem.
kubectl exec my-pod — rm /tmp/some.file
Delete a file on the container’s root filesystem:
kubectl exec my-pod -t — curl -s localhost:9876/info
verify that the primary webservice process is responding using curl
kubectl exec my-pod — ps aux
check the process running on the first container on my-pod pod
kubectl exec Options
- -c, –container string Container name. If omitted, the first container in the pod will be chosen
- -p, –pod string Pod name
- -i, –stdin Pass stdin to the container
- -t, –tty Stdin is a TTY
kubectl exec Options inherited from parent commands
- –alsologtostderr log to standard error as well as files
- –as string Username to impersonate for the operation
- –certificate-authority string Path to a cert. file for the certificate authority
- –client-certificate string Path to a client certificate file for TLS
- –client-key string Path to a client key file for TLS
- –cluster string The name of the kubeconfig cluster to use
- –context string The name of the kubeconfig context to use
- –insecure-skip-tls-verify If true, the server’s certificate will not be checked for validity. This will make our HTTPS connections insecure
- –kubeconfig string Path to the kubeconfig file to use for CLI requests.
- –log-backtrace-at traceLocation when logging hits line file:N, emit a stack trace (default :0)
- –log-dir string If non-empty, write log files in this directory
- –logtostderr log to standard error instead of files
- –match-server-version Require server version to match client version
- -n, –namespace string If present, the namespace scope for this CLI request
- –password string Password for basic authentication to the API server
- –request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A
- value of zero means don’t timeout requests. (default “0”)
- -s, –server string The address and port of the Kubernetes API server
- –stderrthreshold severity logs at or above this threshold go to stderr (default 2)
- –token string Bearer token for authentication to the API server
- –user string The name of the kubeconfig user to use
- –username string Username for basic authentication to the API server
- -v, –v Level log level for V logs
- –vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging