Problem

You want to list Kubernetes resources of a certain kind.

Solution

Use the get verb of kubectl along with the resource type. To list all pods:

$ kubectl get pods

To list all services and deployments:

$ kubectl get services,deployments

To list a specific deployment:

$ kubectl get deployment myfirstk8sapp

To list all resources:

$ kubectl get all

Note that kubectl get is a very basic but extremely useful command to get a quick overview what is going on in the cluster—it’s essentially the equivalent to ps on Unix.

Problem

You no longer need resources and want to get rid of them.

Solution

Use the delete verb of kubectl along with the type and name of the resource you wish to delete.

To delete all resources in the namespace my-app, do:

$ kubectl get ns
NAME          STATUS    AGE
default       Active    2d
kube-public   Active    2d
kube-system   Active    2d
my-app        Active    20m

$ kubectl delete ns my-app
namespace "my-app" deleted

If you’re wondering how to create a namespace, see Recipe 6.3.

You can also delete specific resources and/or influence the process by which they are destroyed. To delete services and deployments labeled with app=niceone, do:

$ kubectl delete svc,deploy -l app=niceone

To force deletion of a pod, do:

$ kubectl delete pod hangingpod --grace-period=0 --force

To delete all pods in the namespace test, do:

$ kubectl delete pods --all --namespace test

Discussion

Do not delete supervised objects such as pods controlled by a deployment directly. Rather, kill their supervisors or use dedicated operations to get rid of the managed resources. For example, if you scale a deployment to zero replicas (see Recipe 9.1), then you effectively delete all the pods it looks after.

Another aspect to take into account is cascading versus direct deletion—for example, when you delete a custom resource definition (CRD) as shown in Recipe 13.4, all its dependent objects are deleted too. To learn more about how to influence the cascading deletion policy, read Garbage Collection in the Kubernetes docs.

Problem

You want to watch the changes to Kubernetes objects in an interactive manner in the terminal.

Solution

The kubectl command has a --watch option that gives you this behavior. For example, to watch pods:

$ kubectl get pods --watch

Note that this is a blocking and autoupdating command, akin to top.

Discussion

The --watch option is useful, but sometimes not very reliable, in terms of refreshing the screen correctly. Alternatively, you can use the watch command, as in:

$ watch kubectl get pods

Problem

You want to update the property of a Kubernetes resource.

Solution

Use the edit verb of kubectl along with the resource type:

$ kubectl run nginx --image=nginx
$ kubectl edit deploy/nginx

Now edit the nginx deployment in your editor—for example, change replicas to 2. Once you save, you’ll see something like:

deployment "nginx" edited

Discussion

If you have editor issues, use EDITOR=vi. Also be aware that not all changes trigger a deployment.

Some triggers have shortcuts, for example, if you want to change the image version a deployment uses, simply use kubectl set image, which updates the existing container images of resources (valid for deployments, replica sets/replication controllers, daemon sets, jobs, and simple pods).

Problem

You want to gain a deeper understanding of a certain resource—for example, service—and/or understand what exactly a certain field in a Kubernetes manifest means, including default values and if it’s required or optional.

Discussion

The kubectl explain command¹ pulls the descriptions of resources and fields from the Swagger/OpenAPI definitions,² exposed by the API server.

See Also

• Ross Kukulinski’s blog post, “kubectl explain — #HeptioProTip”