Getting Started with Kubernetes: A kubectl Cheat Sheet

• To use kubectl, you’ll need a Kubernetes cluster available to you. To learn how to create a Kubernetes cluster from scratch, you can consult How To Create a Kubernetes Cluster Using Kubeadm on Ubuntu 18.04. Alternatively, you can provision a managed Kubernetes cluster in minutes using DigitalOcean Kubernetes. To get started creating a DigitalOcean Kubernetes cluster, consult How to Create Kubernetes Clusters Using the Control Panel.
• You’ll also need a remote machine on which you’ll install and run kubectl. kubectl can run on many different operating systems.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

First, update your local package index and install required dependencies:

sudo apt-get update && sudo apt-get install -y apt-transport-https

Then add the Google Cloud GPG key to APT and make the kubectl package available to your system:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update

Finally, install kubectl:

sudo apt-get install -y kubectl

Test that the installation succeeded using version:

kubectl version

kubectl includes a shell autocompletion script that you can make available to your system’s existing shell autocompletion software.

type _init_completion

echo 'source <(kubectl completion bash)' >>~/.bashrc
. ~/.bashrc

kubectl completion bash >/etc/bash_completion.d/kubectl

kubectl TAB TAB

Output
annotate       apply          autoscale      completion     cordon         delete         drain          explain        kustomize      options        port-forward   rollout        set            uncordon
api-resources  attach         certificate    config         cp             describe
. . .

kubectl d TAB

Output
delete    describe  diff      drain

A Namespace in Kubernetes is an abstraction that allows you to subdivide your cluster into multiple virtual clusters. By using Namespaces you can divide cluster resources among multiple teams and scope objects appropriately. For example, you can have a prod Namespace for production workloads, and a dev Namespace for development and test workloads.

To fetch and print a list of all the Namespaces in your cluster, use get namespace:

kubectl get namespace

Output
NAME              STATUS   AGE
default           Active   2d21h
kube-node-lease   Active   2d21h
kube-public       Active   2d21h
kube-system       Active   2d21h

To set a Namespace for your current context, use set-context --current:

kubectl config set-context --current --namespace=namespace_name

To create a Namespace, use create namespace:

kubectl create namespace namespace_name

Output
namespace/sammy created

Similarly, to delete a Namespace, use delete namespace:

kubectl delete namespace namespace_name

To fetch all Pods in a given Namespace or to perform other operations on resources in a given Namespace, make sure to include the --namespace flag:

kubectl get pods --namespace=namespace_name

The recommended approach to managing workloads on Kubernetes is to rely on the cluster’s declarative design as much as possible. This means that instead of running a series of commands to create, update, delete, and restart running Pods, you should define the workloads, services, and systems you’d like to run in YAML manifest files, and provide these files to Kubernetes, which will handle the rest.

In practice, this means using the kubectl apply command, which applies a particular configuration to a given resource. If the target resource doesn’t exist, then Kubernetes will create the resource. If the resource already exists, then Kubernetes will save the current revision, and update the resource according to the new configuration. This declarative approach exists in contrast to the imperative approach of running the kubectl create , kubectl edit, and the kubectl scale set of commands to manage resources. To learn more about the different ways of managing Kubernetes resources, consult Kubernetes Object Management from the Kubernetes docs.

Rolling out a Deployment

For example, to deploy the sample Nginx Deployment to your cluster, use apply and provide the path to the nginx-deployment.yaml manifest file:

kubectl apply -f nginx-deployment.yaml

Output
deployment.apps/nginx-deployment created

The -f flag is used to specify a filename or URL containing a valid configuration. If you’d like to apply all manifests from a directory, you can use the -k flag:

kubectl apply -k manifests_dir

You can track the rollout status using rollout status:

kubectl rollout status deployment/nginx-deployment

Output
Waiting for deployment "nginx-deployment" rollout to finish: 1 of 2 updated replicas are available...
deployment "nginx-deployment" successfully rolled out

An alternative to rollout status is the kubectl get command, along with the -w (watch) flag:

kubectl get deployment -w

Output
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/2     2            0           3s
nginx-deployment   1/2     2            1           3s
nginx-deployment   2/2     2            2           3s

Using rollout pause and rollout resume, you can pause and resume the rollout of a Deployment:

kubectl rollout pause deployment/nginx-deployment

Output
deployment.extensions/nginx-deployment paused

kubectl rollout resume deployment/nginx-deployment

Output
deployment.extensions/nginx-deployment resumed

Modifying a Running Deployment

If you’d like to modify a running Deployment, you can make changes to its manifest file and then run kubectl apply again to apply the update. For example, we’ll modify the nginx-deployment.yaml file to change the number of replicas from 2 to 3:

. . .
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
. . .

The kubectl diff command allows you to see a diff between currently running resources, and the changes proposed in the supplied configuration file:

kubectl diff -f nginx-deployment.yaml

Now allow Kubernetes to perform the update using apply:

kubectl apply -f nginx-deployment.yaml

Running another get deployment should confirm the addition of a third replica.

If you run apply again without modifying the manifest file, Kubernetes will detect that no changes were made and won’t perform any action.

Using rollout history you can see a list of the Deployment’s previous revisions:

kubectl rollout history deployment/nginx-deployment

Output
deployment.extensions/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>

With rollout undo, you can revert a Deployment to any of its previous revisions:

kubectl rollout undo deployment/nginx-deployment --to-revision=1

Deleting a Deployment

To delete a running Deployment, use kubectl delete:

kubectl delete -f nginx-deployment.yaml

Output
deployment.apps "nginx-deployment" deleted

You can also use a set of imperative commands to directly manipulate and manage Kubernetes resources.

Creating a Deployment

Use create to create an object from a file, URL, or STDIN. Note that unlike apply, if an object with the same name already exists, the operation will fail. The --dry-run flag allows you to preview the result of the operation without actually performing it:

kubectl create -f nginx-deployment.yaml --dry-run

Output
deployment.apps/nginx-deployment created (dry-run)

We can now create the object:

kubectl create -f nginx-deployment.yaml

Output
deployment.apps/nginx-deployment created

Modifying a Running Deployment

Use scale to scale the number of replicas for the Deployment from 2 to 4:

kubectl scale --replicas=4 deployment/nginx-deployment

Output
deployment.extensions/nginx-deployment scaled

You can edit any object in-place using kubectl edit. This will open up the object’s manifest in your default editor:

kubectl edit deployment/nginx-deployment

You should see the following manifest file in your editor:

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: extensions/v1beta1
kind: Deployment
. . . 
spec:
  progressDeadlineSeconds: 600
  replicas: 4
  revisionHistoryLimit: 10
  selector:
    matchLabels:
. . .

Change the replicas value from 4 to 2, then save and close the file.

Now run a get to inspect the changes:

kubectl get deployment/nginx-deployment

Output
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   2/2     2            2           6m40s

We’ve successfully scaled the Deployment back down to 2 replicas on-the-fly. You can update most of a Kubernetes’ object’s fields in a similar manner.

Another useful command for modifying objects in-place is kubectl patch. Using patch, you can update an object’s fields on-the-fly without having to open up your editor. patch also allows for more complex updates with various merging and patching strategies. To learn more about these, consult Update API Objects in Place Using kubectl patch.

The following command will patch the nginx-deployment object to update the replicas field from 2 to 4; deploy is shorthand for the deployment object.

kubectl patch deploy nginx-deployment -p '{"spec": {"replicas": 4}}'

Output
deployment.extensions/nginx-deployment patched

We can now inspect the changes:

kubectl get deployment/nginx-deployment

Output
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   4/4     4            4           18m

You can also create a Deployment imperatively using the run command. run will create a Deployment using an image provided as a parameter:

kubectl run nginx-deployment --image=nginx --port=80 --replicas=2

The expose command lets you quickly expose a running Deployment with a Kubernetes Service, allowing connections from outside your Kubernetes cluster:

kubectl expose deploy nginx-deployment --type=LoadBalancer --port=80 --name=nginx-svc

Output
service/nginx-svc exposed

Here we’ve exposed the nginx-deployment Deployment as a LoadBalancer Service, opening up port 80 to external traffic and directing it to container port 80. We name the service nginx-svc. Using the LoadBalancer Service type, a cloud load balancer is automatically provisioned and configured by Kubernetes. To get the Service’s external IP address, use get:

kubectl get svc nginx-svc

Output
NAME        TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
nginx-svc   LoadBalancer   10.245.26.242   203.0.113.0   80:30153/TCP   22m

You can access the running Nginx containers by navigating to EXTERNAL-IP in your web browser.

There are several commands you can use to get more information about workloads running in your cluster.

Inspecting Kubernetes Resources

kubectl get fetches a given Kubernetes resource and displays some basic information associated with it:

kubectl get deployment -o wide

Output
NAME               READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES   SELECTOR
nginx-deployment   4/4     4            4           29m   nginx        nginx    app=nginx

Since we did not provide a Deployment name or Namespace, kubectl fetches all Deployments in the current Namespace. The -o flag provides additional information like CONTAINERS and IMAGES.

In addition to get, you can use describe to fetch a detailed description of the resource and associated resources:

kubectl describe deploy nginx-deployment

Output
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Wed, 11 Sep 2019 12:53:42 -0400
Labels:                 run=nginx-deployment
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               run=nginx-deployment
. . . 

The set of information presented will vary depending on the resource type. You can also use this command without specifying a resource name, in which case information will be provided for all resources of that type in the current Namespace.

explain allows you to quickly pull configurable fields for a given resource type:

kubectl explain deployment.spec

By appending additional fields you can dive deeper into the field hierarchy:

kubectl explain deployment.spec.template.spec

Gaining Shell Access to a Container

To gain shell access into a running container, use exec. First, find the Pod that contains the running container you’d like access to:

kubectl get pod

Output
nginx-deployment-8859878f8-7gfw9   1/1     Running   0          109m
nginx-deployment-8859878f8-z7f9q   1/1     Running   0          109m

Let’s exec into the first Pod. Since this Pod has only one container, we don’t need to use the -c flag to specify which container we’d like to exec into.

kubectl exec -i -t nginx-deployment-8859878f8-7gfw9 -- /bin/bash

Output
root@nginx-deployment-8859878f8-7gfw9:/#

You now have shell access to the Nginx container. The -i flag passes STDIN to the container, and -t gives you an interactive TTY. The -- double-dash acts as a separator for the kubectl command and the command you’d like to run inside the container. In this case, we are running /bin/bash.

To run commands inside the container without opening a full shell, omit the -i and -t flags, and substitute the command you’d like to run instead of /bin/bash:

kubectl exec nginx-deployment-8859878f8-7gfw9 ls

Output
bin
boot
dev
etc
home
lib
lib64
media
. . .

Fetching Logs

Another useful command is logs, which prints logs for Pods and containers, including terminated containers.

To stream logs to your terminal output, you can use the -f flag:

kubectl logs -f nginx-deployment-8859878f8-7gfw9

Output
10.244.2.1 - - [12/Sep/2019:17:21:33 +0000] "GET / HTTP/1.1" 200 612 "-" "203.0.113.0" "-"
2019/09/16 17:21:34 [error] 6#6: *1 open() "/usr/share/nginx/html/favicon.ico" failed (2: No such file or directory), client: 10.244.2.1, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "203.0.113.0", referrer: "http://203.0.113.0"
. . .

This command will keep running in your terminal until interrupted with a CTRL+C. You can omit the -f flag if you’d like to print log output and exit immediately.

You can also use the -p flag to fetch logs for a terminated container. When this option is used within a Pod that had a prior running container instance, logs will print output from the terminated container:

kubectl logs -p nginx-deployment-8859878f8-7gfw9

The -c flag allows you to specify the container you’d like to fetch logs from, if the Pod has multiple containers. You can use the --all-containers=true flag to fetch logs from all containers in the Pod.

Port Forwarding and Proxying

To gain network access to a Pod, you can use port-forward:

sudo kubectl port-forward pod/nginx-deployment-8859878f8-7gfw9 80:80

Output
Forwarding from 127.0.0.1:80 -> 80
Forwarding from [::1]:80 -> 80

In this case we use sudo because local port 80 is a protected port. For most other ports you can omit sudo and run the kubectl command as your system user.

Here we forward local port 80 (preceding the colon) to the Pod’s container port 80 (after the colon).

You can also use deploy/nginx-deployment as the resource type and name to forward to. If you do this, the local port will be forwarded to the Pod selected by the Deployment.

The proxy command can be used to access the Kubernetes API server locally:

kubectl proxy --port=8080

Output
Starting to serve on 127.0.0.1:8080

In another shell, use curl to explore the API:

curl http://localhost:8080/api/

Output
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "203.0.113.0:443"
    }
  ]

Close the proxy by hitting CTRL-C.

This guide covers some of the more common kubectl commands you may use when managing a Kubernetes cluster and workloads you’ve deployed to it.

You can learn more about kubectl by consulting the official Kubernetes reference documentation.

There are many more commands and variations that you may find useful as part of your work with kubectl. To learn more about all of your available options, you can run:

kubectl --help