kubectl flags you have probably never heard of

Analysis of logs

--all-containers

With kubectl logs we are able to view the current log output of a Pod. If a Pod consists of multiple containers, a "default" container is choosen by the kubectl logs POD_NAME command. If instead we want to see the logs of all containers within the Pod, we can use the --all-containers flag: kubectl logs --all-containers POD_NAME.

--container, -c

By default, acccessing the logs of a Pod with multiple containers leads to the first container defined in the spec.containers list. If you need to access the logs of another container, you can add the --container flag to specifiy the container to use: kubectl logs POD_NAME --container CONTAINER_NAME.

--prefix

Using the --prefix flag enables you to display the source of the log entry in front of the actual entry. This is very handy when debugging a multi-container Pod to see where the entry came from. Here is the output of the Prometheus Pod containing the two containers prometheus and config-reloader:

kubectl logs --prefix prometheus-prometheus-kube-prometheus-prometheus-0

[pod/prometheus-prometheus-kube-prometheus-prometheus-0/prometheus] ts=2022-11-30T09:00:03.802Z caller=db.go:1526 level=info component=tsdb msg="Deleting obsolete block" block=01GJAB4182JVKC74R9TTXPEFV1
[pod/prometheus-prometheus-kube-prometheus-prometheus-0/prometheus] ts=2022-11-30T09:00:04.615Z caller=checkpoint.go:100 level=info component=tsdb msg="Creating checkpoint" from_segment=181 to_segment=182 mint=1669795200000
[pod/prometheus-prometheus-kube-prometheus-prometheus-0/prometheus] ts=2022-11-30T09:00:06.417Z caller=head.go:1164 level=info component=tsdb msg="WAL checkpoint complete" first=181 last=182 duration=1.802365591s
[pod/prometheus-prometheus-kube-prometheus-prometheus-0/prometheus] ts=2022-11-30T09:00:04.604Z caller=head.go:1192 level=info component=tsdb msg="Head GC completed" caller=truncateMemory duration=300.052358ms
[pod/prometheus-prometheus-kube-prometheus-prometheus-0/config-reloader] ts=2022-11-30T10:12:37.197Z caller=reloader.go:362 level=error msg="Failed to trigger reload"

--previous, -p

When a container inside a Pod fails and is restarted, you can access the logs of that old container with the --previous flag: kubectl logs POD_NAME --previous. Of course, you can also add the --container flag to specify the container to use.

--since

If we want to see only the logs of a certain period, we can use the --since flag: kubectl logs --since=1h POD_NAME. The units you can use are s (seconds), m (minutes) and h (hours). You cannot use --since together with --since-time, which is shown below.

--since-time

To see logs created after a certain time, you can use the --since-time flag. The specified time must be in compliance with RFC3339. For example, to see all logs after the November second, 2022 at 1am, we would define --since-time=2022-11-02T01:00:00.000Z. See this link for more examples, or use tools like this to convert your timestamp to RFC3339.

Deletion of resources

--cascade=orphan

Deleting resources in Kubernets deletes the dependant child resources by default. For example, if you delete a Deployment, all ReplicaSets and Pods created by that Deployment are also deleted. You can change this behaviour by using the --cascade flag and setting the value to orphan. Now, if you delete the Deployment using kubectl delete --cascade=orphan deployment DEPLOYMENT_NAME, the orphan ReplicaSets and Pods are not deleted.

Working with labels and annotations

--overwrite

Labeling and annotating resources in Kubernetes is quite simple with kubectl annotate|label RESOURCE_TYPE RESOURCE_NAME some-key=some-value. But if you use a key that already exists on this resource, you get an error message saying that 'some-key' already has a value (another-value). However, with the --overwrite flag you are able to replace this existing value: kubectl annotate|label RESOURCE_TYPE RESOURCE_NAME --overwrite some-key=some-value.

--show-labels

To see the labels added to the resources, you can simply add the --show-labels flag to the kubectl get command: kubectl get pods --show-labels.

Adjusting and filtering the output

--selector, -l

You can use the --selector or -l flag to select only resources that match certain criteria based on their defined labels. For example, to display only Pods and Services with the label app.kubernetes.io/instance=myapp, you can run kubectl get pods,services --selector app.kubernetes.io/instance=myapp. Of course, you can also combine multiple labels into a more complex selector. See the Kubernetes documentation for more examples.

--field-selector

If you want to select resources not by their assigned labels, but by the values of their attributes, such as name, status, etc., you can use the --field-selector flag. It works with the get and delete subcommand of kubectl. The fields supported vary between resource types, but each type supports the metadata.name and metadata.namespace fields. You can use the =, == and != operators to create your filter, where = and == are equivalent. To display all Pods that are not Running, you can use kubectl get pods -A --field-selector="status.phase!=Running".

--output=jsonpath

Of course, you have probably used the --output flag with values like json or yaml, but have you ever used the jsonpath value? It is a very powerful feature to customize the output of the kubectl command to your individual needs. For example, if you just want to display the value of the key password in a secret called my-secret, you can simply use kubectl get secret my-secret -o=jsonpath='{.data.password}'.

For a complete list of the different expressions you can use, see the Kubernetes documentation.

Working with different environments

--kubeconfig

Whenever you run a kubectl command, a file called config is used by default , which is located in $HOME/.kube. However, you can use the --kubeconfig flag to define a different file to use. This can also be accomplished by setting the environment variable KUBECONFIG in your terminal.

--cluster, --context and --user

A kubectl command is always executed against the current-context defined in the kubeconfig file. With kubectl config set-context --current CONTEXT_NAME you can switch between different contexts. However, if you just want to run single commands against a different context oder cluster, the --cluster and --context flags make your life much easier. You can also use a different user defined in your kubeconfig with the --user flag.