[markdown]
kubectl Cheat Sheet
This page contains a list of commonly used `kubectl` commands and flags.
### Kubectl autocomplete
#### BASH
“` bash
source <(kubectl completion bash) # setup autocomplete in bash into the current shell, bash-completion package should be installed first.
echo “source <(kubectl completion bash)” >> ~/.bashrc # add autocomplete permanently to your bash shell.
“`
You can also use a shorthand alias for `kubectl` that also works with
completion:
“` bash
alias k=kubectl
complete -F start_kubectl k
“`
#### ZSH
“` zsh
source <(kubectl completion zsh) # setup autocomplete in zsh into the current shell
echo “[[ $commands[kubectl] ]] && source <(kubectl completion zsh)” >> ~/.zshrc # add autocomplete permanently to your zsh shell
“`
### Kubectl context and configuration
Set which Kubernetes cluster `kubectl` communicates with and modifies
configuration information. See [Authenticating Across Clusters with
kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
documentation for detailed config file information.
“`bash
kubectl config view # Show Merged kubeconfig settings.
# use multiple kubeconfig files at the same time and view merged config
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2
kubectl config view
# get the password for the e2e user
kubectl config view -o jsonpath='{.users[?(@.name == “e2e”)].user.password}’
kubectl config view -o jsonpath='{.users[].name}’ # display the first user
kubectl config view -o jsonpath='{.users[*].name}’ # get a list of users
kubectl config get-contexts # display list of contexts
kubectl config current-context # display the current-context
kubectl config use-context my-cluster-name # set the default context to my-cluster-name
# add a new user to your kubeconf that supports basic auth
kubectl config set-credentials kubeuser/foo.kubernetes.com –username=kubeuser –password=kubepassword
# permanently save the namespace for all subsequent kubectl commands in that context.
kubectl config set-context –current –namespace=ggckad-s2
# set a context utilizing a specific username and namespace.
kubectl config set-context gce –user=cluster-admin –namespace=foo \
&& kubectl config use-context gce
kubectl config unset users.foo # delete user foo
“`
### Kubectl apply
`apply` manages applications through files defining Kubernetes
resources. It creates and updates resources in a cluster through running
`kubectl apply`. This is the recommended way of managing Kubernetes
applications on production. See [Kubectl
Book](https://kubectl.docs.kubernetes.io).
Creating objects
—————-
Kubernetes manifests can be defined in YAML or JSON. The file extension
`.yaml`, `.yml`, and `.json` can be used.
“`bash
kubectl apply -f ./my-manifest.yaml # create resource(s)
kubectl apply -f ./my1.yaml -f ./my2.yaml # create from multiple files
kubectl apply -f ./dir # create resource(s) in all manifest files in dir
kubectl apply -f https://git.io/vPieo # create resource(s) from url
kubectl create deployment nginx –image=nginx # start a single instance of nginx
# create a Job which prints “Hello World”
kubectl create job hello –image=busybox — echo “Hello World”
# create a CronJob that prints “Hello World” every minute
kubectl create cronjob hello –image=busybox –schedule=”*/1 * * * *” — echo “Hello World”
kubectl explain pods # get the documentation for pod manifests
“`
### Create multiple YAML objects from stdin
“`bash
cat < apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep
spec:
containers:
– name: busybox
image: busybox
args:
– sleep
– “1000000”
—
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep-less
spec:
containers:
– name: busybox
image: busybox
args:
– sleep
– “1000”
EOF
“`
### Create a secret with several keys
“`bash
cat < pod.yaml
kubectl attach my-pod -i # Attach to Running Container
kubectl port-forward my-pod 5000:6000 # Listen on port 5000 on the local machine and forward to port 6000 on my-pod
kubectl exec my-pod — ls / # Run command in existing pod (1 container case)
kubectl exec –stdin –tty my-pod — /bin/sh # Interactive shell access to a running pod (1 container case)
kubectl exec my-pod -c my-container — ls / # Run command in existing pod (multi-container case)
kubectl top pod POD_NAME –containers # Show metrics for a given pod and its containers
kubectl top pod POD_NAME –sort-by=cpu # Show metrics for a given pod and sort it by ‘cpu’ or ‘memory’
“`
### Interacting with Deployments and Services
“`bash
kubectl logs deploy/my-deployment # dump Pod logs for a Deployment (single-container case)
kubectl logs deploy/my-deployment -c my-container # dump Pod logs for a Deployment (multi-container case)
kubectl port-forward svc/my-service 5000 # listen on local port 5000 and forward to port 5000 on Service backend
kubectl port-forward svc/my-service 5000:my-service-port # listen on local port 5000 and forward to Service target port with name
kubectl port-forward deploy/my-deployment 5000:6000 # listen on local port 5000 and forward to port 6000 on a Pod created by
kubectl exec deploy/my-deployment — ls # run command in first Pod and first container in Deployment (single- or multi-container cases)
“`
### Interacting with Nodes and cluster
“`bash
kubectl cordon my-node # Mark my-node as unschedulable
kubectl drain my-node # Drain my-node in preparation for maintenance
kubectl uncordon my-node # Mark my-node as schedulable
kubectl top node my-node # Show metrics for a given node
kubectl cluster-info # Display addresses of the master and services
kubectl cluster-info dump # Dump current cluster state to stdout
kubectl cluster-info dump –output-directory=/path/to/cluster-state # Dump current cluster state to /path/to/cluster-state
# If a taint with that key and effect already exists, its value is replaced as specified.
kubectl taint nodes foo dedicated=special-user:NoSchedule
“`
### Resource types
List all supported resource types along with their shortnames, [API
group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning),
whether they are
[namespaced](/docs/concepts/overview/working-with-objects/namespaces),
and
[Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects):
“`bash
kubectl api-resources
“`
Other operations for exploring API resources:
“`bash
kubectl api-resources –namespaced=true # All namespaced resources
kubectl api-resources –namespaced=false # All non-namespaced resources
kubectl api-resources -o name # All resources with simple output (only the resource name)
kubectl api-resources -o wide # All resources with expanded (aka “wide”) output
kubectl api-resources –verbs=list,get # All resources that support the “list” and “get” request verbs
kubectl api-resources –api-group=extensions # All resources in the “extensions” API group
“`
### Formatting output
To output details to your terminal window in a specific format, add the
`-o` (or `–output`) flag to a supported `kubectl` command.
-o=custom-columns= |
Print a table using a comma separated list of custom columns |
-o=custom-columns-file= |
Print a table using the custom columns template in the file |
-o=json |
Output a JSON formatted API object |
-o=jsonpath= |
Print the fields defined in a jsonpath expression |
-o=jsonpath-file= |
Print the fields defined by the jsonpath expression in the file |
-o=name |
Print only the resource name and nothing else |
-o=wide |
Output in the plain-text format with any additional information, and for pods, the node name is included |
-o=yaml |
Output a YAML formatted API object |
Examples using `-o=custom-columns`:
#### All images running in a cluster
“`bash
kubectl get pods -A -o=custom-columns=’DATA:spec.containers[*].image’
“`
#### All images running in namespace: default, grouped by Pod
“`bash
kubectl get pods –namespace default –output=custom-columns=”NAME:.metadata.name,IMAGE:.spec.containers[*].image”
“`
##### All images excluding
“`bash
“k8s.gcr.io/coredns:1.6.2″
kubectl get pods -A -o=custom-columns=’DATA:spec.containers[?(@.image!=”k8s.gcr.io/coredns:1.6.2”)].image’
“`
##### All fields under metadata regardless of name
“`bash
kubectl get pods -A -o=custom-columns=’DATA:metadata.*’
“`
More examples in the kubectl [reference
documentation](/docs/reference/kubectl/overview/#custom-columns).
##### Kubectl output verbosity and debugging
Kubectl verbosity is controlled with the `-v` or `–v` flags followed by
an integer representing the log level. General Kubernetes logging
conventions and the associated log levels are described
[here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
--v=0 |
Generally useful for this to always be visible to a cluster operator. |
--v=1 |
A reasonable default log level if you don’t want verbosity. |
--v=2 |
Useful steady state information about the service and important log messages that may correlate to significant changes in the system. This is the recommended default log level for most systems. |
--v=3 |
Extended information about changes. |
--v=4 |
Debug level verbosity. |
--v=5 |
Trace level verbosity. |
--v=6 |
Display requested resources. |
--v=7 |
Display HTTP request headers. |
--v=8 |
Display HTTP request contents. |
--v=9 |
Display HTTP request contents without truncation of contents. |
[/markdown]