Kubernetes series | part 3 - hands on

Previous parts of the series can be found here part-1 , part-2 .

In this post, Lets have our fingers dirty with Kubernetes. There are few ways available to have the Kubernetes setup.

  1. Cloud based K8s cluster setup like GCP, Azure or AWS
  2. Installing K8s tools like Minikube & Kubectl
  3. Using online playgrounds to have hands-on

Cloud based cluster setup is suitable for multi node cluster which is obviously not necessary to get initial hands-on. Installing Minikube & Kubectl is a good option so that we can have a single node cluster where both master & worker nodes will be placed. But it will take some time to get started. So my choice here is to go with ready-to-use setup. Here, I am gonna try Katacoda .My heartful thanks to the Katacoda team for this free tool .

Let’s start…

Go to the Katacoda home page for Kubernetes. There we can see lot of scenarios given by the team to explore the K8s. For now, Lets click Start scenario button of Launch A Single Node Cluster block. This Single Node Cluster given by Katacoda itself using Minikube . Click on the Start scenario to get into the terminal world of K8s.

We can see the empty terminal once we click the Start button, this is nothing but a ubuntu terminal. All the required tools like Minikube are already installed in the server. We can validate required tools installed properly with below commands.

Use below command to start our single node cluster using Minikube tool.

Here go, we have started out single node cluster using Minikube tool. Last line of the log says, kubectl is configured to use with Minikube means that Kubectl is a command line tool to interact with Minikube cluster. Minikube is pre-installed with Docker, even we don’t have Docker installed, it is going to work.

To get the status of the cluster:

minikube status to get the status of the cluster. It is giving status of some of the processes running in the cluster.

From the above log,
* apiserver is a entry point to the K8s cluster. To do all the

kubectl get nodes to get the nodes information of the cluster. For now there is single node running as a master.

kubectl version to see the client & server version of the Kubernetes. Here, v1.17.3 is the kubernetes verison we are currently have in katacoda tool.

we have seen two command line tools as of now. Those are Minikube and Kubectl. Minikube is just to start and stop the cluster. For all other operations with the cluster, we will use kubectl.

Basic kubectl commands:
kubectl get
command is to get status and configuration details of the components. for example,

kubectl get nodes : to get the node details of the cluster
kubectl get pods : to get the pod running in the server
kubectl get services : to get list of all services in the namespace. There is many get commands available.

Since our katacode cluster is new, we don’t have any pod running. Lets create a Pod now.

Creating Pod / Deployment:
We know that Pod is the smallest unit of the cluster. We will not usually work with Pods. We will work with the component called Deployment which is like a abstraction layer to the Pods.

we can create Deployment using kubectl create command. Once created, the Deployment ensures that the desired number of Pods are running and available at all times.

  • nginx-deployment is the deployment name, — image specify which image to use.
  • Docker is pre-installed in Minikube. So it can get the nginx docker image from the dockerhub. Using that, the deployment will be created.
  • Deployment component will have blueprint on how to create the deployment including default configurations. Here, deployment name and image name are the two required parameters. Then default patameters are used here.

Now lets see the status of the deployment. The below image says, deployment is ready.

So obviously now we should see the output for kubectl get pods command. The output below says, there is a Pod running with a name nginx-deployment-ddd976fc7–87mxq.

  • Here one concept we need to discuss is replicaset. Replicaset is managing the replicas of the Pod. This will be automatically created by the deployment command. We can see the replicaset using below command.

If you see the replicaset name and Pod name, we can understand how this works. So Replicaset is a copy of a Pod, we can use this copy to replicate the crashed/dead Pod. If I understand this correctly, the actual Pod itself created by using this Replicaset only.

For summary,

  • Deployment is managing the Replicaset
  • Replicaset manages all the replicas of the Pod
  • Pod is an abstraction of the container images
  • And finally Container contains our actual applications.

From all above 4, we will work only with Deployments most of the time. other three components will be automatically managed by the K8s.

Edit the Deployment:
kubectl edit
command is use to edit the available deployment. This command will open up the Yaml file of the Deployment. This is auto generated config file created by the kubectl create deployment command with the default values.

kubectl edit deployment nginx-deployment

How to debug the Pods:
using kubectl logs <image_name> , we can get the actual log that is being printed by the container image which is inside the pod. I didn’t get as much logs with nginx Pod. So I created new mongodb Pod to see logs command works. Below image shows the output.

Once I ran the create command for mongodb, deployment created, after some time Pod came to running state. Then I ran the logs command & it printed all the logs from the MongoDB container. This will be very usefult to debug the containers inside the Pod.

Another most useful debugging command is exec. it will open the terminal of the application running in the Pod.

As seen above, by using the exec command I entered the Mongodb terminal where I can run commands to debug the application.

Deleting the deployment:
kubectl delete
command used to delete the deployment.

Deployment creation using config file:

we are creating the deployments using the command line by giving the required parameters name and image. But in production, we may need to give lot of options for deployment creation. So writing all the options in the command line is not a feasible way. For that, we can add all the configuration options in the file and pass it to the create command.

lets create a file named nginx-deployment.yaml and add the following content.

apiVersion: apps/v1
kind: Deployment
name: nginx-deployment
app: nginx
replicas: 1
app: nginx
app: nginx
- name: nginx
image: nginx:1.16
- containerPort: 80

This is a basic content needed to create the nginx Pod using the file. Now deployment can be created using this file with apply command.

kubectl apply -f mongo.yaml command will read the deployment config file and created the deployment like below.

Now, whatever changes we want to do to the deployment, we can go and change the nginx.yaml file. Then the change will be automatically updated to the deployment. for example, I am going to change the replicas to 2 in the file.

Here we can see two Pods running as per the configuration given.


We got hands-on with the following concepts as of now,

  • CRUD deployment commands
    1. Create: kubectl create deployment <name> image
    2. Edit: kubectl edit deployment <name>
    3. Delete: kubectl delete deployment <name>
  • Status of diffetent Pods
    kubectl get nodes | pod | services | replicaset | deployment
  • Debugging Pods:
    Get logs of the Pod: kubectl logs pod_name
    More info of pod: kubectl describe pod pod_name
  • Get interactive terminal
    kubectl exec -it pod_name — /bin/bash
  • Deployment with config file
    1. create/update: kubectl apply -f config_file_name
    2. delete: kubectl delete -f config_file_name

Thats it for this post. Will come up with more posts on kubernetes in coming days. ta ta.

Gobalakrishnan Viswanathan.

Yet another Pythonic-Automation guy.