What is Kubectl?

The world does not revolve around kubernetes, but within the SRE/DevOps/Infra community, kubernetes is a pretty big deal, and if you know kubernetes, you must, MUST, know kubectl.

Kubernetes is a container orchestration platform. It has a control plane and a worker plane, the control plane consists of the kube API server.

The API server is the brain of the entire cluster, and is essential in coordinating the other components of the cluster, like the controllers, the scheduler, etcd, etc.

You should be able to make requests to the API Server, in order to manage your cluster.

If you want to create a new pod for example, you can't say,

You must create a Pod Manifest(a bunch of information that will be required by kubernetes to run your container, in YAML Format) , and submit that to the API Server, using curl or wget.

The API Server validates this request and creates your pod (and within the pod, your container).

So, in order to make all this simple, a bunch of smart people came together and created kubectl, which is a CLI-based tool, that will help you interact with the API Server, without breaking your head over simple actions.

Disclaimer: The aforementioned description of kubernetes can barely be passed of as a bird's eye view of the platform. In order to understand kubectl, you must have a basic understanding of the various components of kubernetes.

Prerequisites

• minikube

• kubectl

The ~/.kube/config file should point to the minikube cluster. The file has information on where the kube API Server is located, and some information that is used to authorise requests sent by you. This file is very sensitive, since it can allow someone to control the entire cluster (if the compromised used was an admin)

The kube config file, is usually generated my minikube itself, when you install it. It can also be generated though.

The location of the kube config file is specified using the KUBECONFIG environment variable, if you change this variable, you can get kubectl to access a different kube config file, the default location is: $HOME/.kube/config.

We can keep going on and on about kube config, so I'll stop here, read this article to know more.

Lets start by listing the current namespaces,

The output has given us the list of namespace is the minikube cluster, and the period for which they have been active.

Lets create a new namespace jungle. We have to create a yaml file (ns.yaml), with the following contents.

and then run,

As you can see, this is a pretty tedious way to do it. Kubectl offers an alternative.

If you want to see the yaml file that is going to be submitted to the API server, you can run,

Time to run a Pod!

Now that we have created a namespace on kubernetes, its time to create a pod, lets run a simple nginx pod. Lets list all pods in our namespace,

There are no pods here, we'll create a pod in the jungle namespace, lets call it "lion".

We have now successfully created a pod, with the help of the kubectl run command, lets check if its running!

Yay! The pod is finally running. Note that I always specify the namespace using the -n flag. This is essential, in order to schedule the pod in the right namespace.

A mice infested jungle!

Let's create a lot of mouse pods in our jungle namespace, pause for a second here and think how we can do this?

A beginner would run a bunch of kubectl run commands put together, but using a deployment is a much cleaner way to do so.

This time we have used a deployment to create the pods, the difference is that all the pods are mapped to the same owner, which is a the mouse deployment.

The deployment can be scaled to increase or decrease the number of pods that are owned by it. This can be extremely advantageous in case of stateless apps, which can be scaled horizontally.

Here's a video that clearly explains the difference between Stateless and Stateful Architectures. If you are a developer, who is writing code for systems that are going to be running on a kubernetes cluster. You must watch this, if not, watch it nonetheless - its a basic software architecture concept.

Let's see if our mouse are running,

The mouse population has increased, lets represent that by scaling up the mouse deployment.

With that we have scaled up the number of replicas to 15. The lion king is angry and eats a bunch of mice and this causes the population to decline. The scale down command is similar,

The mice got together and made a plan to kill the lion, and unfortunately they succeeded.

The delete command for pod is as follows,

We have successfully deleted the lion pod, and remaining are the six mouse pods.

Without the lion, which was keeping the population of the other predators in check, the mouse population slowly declined and became extinct. You see where I am going with this, lets delete the deployment,

We are back to no animals in the jungle.

Without bio-diversity, the jungle too eventually rotted away.

Debugging with kubectl

How do we read logs that are being written by our pods? Kubectl helps us with that as well,

The pod writes logs to console, and we want to be able to see the logs, how?

This way kubectl also allows us to read the logs in a pod, you can also view the logs for all pods in a deployment at once, by specifying the deployment name like this

-f tells kubernetes not to close the connection and keep streaming logs live.

You can also use stern, a production grade log monitoring tool. Once you start using stern, you will never look at kubectl logs again 😅. I'll cover stern in another article.

I want to view the file that is writing the logs, can i view it? Lets see,

Woah, look at that, I have created a terminal, inside the pod! I ran the command , which has allowed me to spawn a shell inside the container. This is extremely useful when you need to debug a live container.

This is what I found inside.

You can also view other important information associated with the pod,

The output contains the pod, name, namespace, current status, Node that the pod was scheduled on. It shows the image name, environment variables, mounted volumes, etc. This is a treasure trove of information which can prove to be extremely useful while debugging.

You can also see how much resources a pod is consuming, if you have the metrics api enabled,

You can use this information to autoscale and manage your cluster in a cost-optimised manner.

Mastering is the first step toward becoming truly effective with Kubernetes. It's more than just a CLI tool — it’s your gateway to understanding, managing, and debugging the entire cluster ecosystem. Whether you're scaling deployments, inspecting logs, or diagnosing issues, puts the power of Kubernetes right at your fingertips. Get comfortable with it, and you'll unlock a new level of confidence in working with cloud-native infrastructure.