Table of contents

In this article I will post kubectl commands and Kubernetes tricks I use as part of my daily routine. I don't remember things by heart, but I am also sick and tired of googling each time. So here is the list of absolute must-know CLI commands that is used to operate a cluster on daily basis.

# Aliases

The kubectl CLI command name is objectively challenging to spell. The letter combination is not handy and can't be easily typed in. So, I define an alias:

# Contexts

The next thing I may want to do is to see the list of contexts. Each context represents a separate cluster. To see the list of contexts:

To switch to a specific context:

To delete a context no longer needed:

If find it useful to add some aliasing for the first two commands:

# Adding contexts

The way to add new contexts depends on the kind of cloud provider used. For GCP the method is the following:

1. Install and setup gcloud cli

2. Activate your project:

   $

   gcloud config set project <PROJECT_ID>
   
   

   The code is licensed under the MIT license

3. Knowing the cluster name and the zone it operates in, add the context:

   $

   gcloud container clusters get-credentials <CLUSTER_NAME> --zone <CLUSTER_ZONE>
   
   

   The code is licensed under the MIT license

# Namespaces

To see the list of all namespaces on a cluster:

As most of the time I work with just one application, it makes sense narrow the scope to just one particular namespace:

# Seeing a list of pods

To see the list of pods, there is a command:

To see the list of pods and containers running inside each of them, here is a snippet:

To get a list of containers and images they are spinning, here is another snippet:

Note, that I select imageID, not image, because the sha digest is much more valuable than just an image name + a tag.

# Getting pod name by job name

Sometimes it is needed to read the job log to see why it failed. Every job is backed by a temporary pod. Knowing the pod name, we can get to the logs and hopefully understand the reason.

To get the pod name that backs the job, use:

# Getting info about a specific pod

There is a way to see the detailed information about a pod: labels, a list of containers, etc.

# Getting a list of containers in a pod

# Reading container's logs

To see the logs there is a command:

If you don't specify the -c parameter, it will print logs of the default container of the pod (this is probably not what you want, so get the list of containers on the pod first).

If there is a job you are running inside of the cluster, and you need real time log output, there is the "-f" option:

# Exec into a container

Exec into a container may be last resort. But, anyway, there is how it is done:

Most of the time I use it when I need to check the env vars with printenv.

# Restarting a pod

Sometimes I want a pod restarted, in case if it misbehaves. I scale it down to zero and then up again.

# Getting K8s events

If a deployment is reported to be scaled up, but nothing shows up, it's a good case for reading the event log of the K8s itself:

# Getting info about jobs

If I have a regular job, or a cron job, I may want to see how it is doing. Assuming that I have the jq tool installed, I can then type:

The -l command is a selector by label. It accepts a label name and label value to filter the list of jobs against.

# Injecting an env variable

Sometimes an environment variable must be injected into a working pod, without changing the terraform files or redeploying. For example, if there is a need to temporary increase the logging level from "warn" to "debug". This is how it's done:

This command will patch the deployment and do the rolling update.

# Connecting to a container from outside

Most of the time, there is no connectivity between a container and an outer world, because a port may not be exposed via an ingress. If debugging is needed, it is possible to do port forwarding to a local machine.

After running this command, the pod becomes available through localhost:<LOCAL_PORT>.

# Creating a temporary container and SSH into it

Sometimes, just for the sake of debugging, I may want to create a new container to check/debug something. I can then pick an image, run it and SSH into it. After the work is done, the container gets removed.

# Creating resources

If a cluster resource was deleted by mistake, and you have a yaml file describing it (most likely in the infra repository), no need to worry, as it can be easily restored using the following command:

# Applying the aliases

Don't forget to apply those:

As usual, this is a work in progress article. I will add more commands later as soon as I have them!