Kubernetes advanced resources

When we create an application with the kubectl run command, it takes care of several things. Let's create an httpd pod by running this command one more time and take a deeper look at what actually happens behind the scenes:

$ kubectl run httpd1 --image=httpd

We can take a look at the series of events that took place during this process by running the kubectl get events command. It shows you what Kubernetes did behind the scenes to launch this application. You will see quite a long list, which may seem confusing at first glance, but we can narrow it down by using the following command: 

$ kubectl get events --sort-by=.metadata.creationTimestamp | tail -n 8
4s 4s ... kubelet, minikube pulling image "httpd"
4s 4s ... replicaset-controller Created pod: httpd1-6d8bb9cdf9-thlkg
4s 4s ... default-scheduler Successfully assigned httpd1-6d8bb9cdf9-thlkg to minikube
4s 4s ... deployment-controller Scaled up replica set httpd1-6d8bb9cdf9 to 1
4s 4s ... kubelet, minikube MountVolume.SetUp succeeded for volume "default-token-dpzmw"
2s 2s ... kubelet, minikube Created container
2s 2s ... kubelet, minikube Successfully pulled image "httpd"
2s 2s ... kubelet, minikube Started container

We are mostly interested in the last two fields on every line. They are SOURCE and MESSAGE respectively. If we read from top to bottom in the series of events, we will see that one Kubernetes component tells the other component to create a pod with the name httpd1-6d8bb9cdf9-thlkg on Minikube VM, which finally happens. Let's describe some of those components:

• replicaset-controller: Sometimes we need more than one httpd pod up and running to handle all the load for the application. ReplicaSet makes sure that a certain number of pods are up and available. ReplicaSet is controlled by the Deployment controller. 
• default-scheduler: Decides which node to run a specific pod on. In our case it is Minikube VM. 
• deployment-controller: Defines the desired state for a Kubernetes resource. In our case, it is a state of httpd pod. The Deployment controller also instructs ReplicaSet to make sure that certain pods are running.  

As already mentioned, the kubectl run command creates other Kubernetes resources including ReplicaSet and Deployment. We can verify that by running kubectl get replicaset and kubectl get deployment respectively:

$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
httpd1 1 1 1 1 38m

$ kubectl get rs
NAME DESIRED CURRENT READY AGE
httpd1-6d8bb9cdf9 1 1 1 38m

We mentioned that Deployment controller defines how many instances of httpd pods run. By default, this number is 1. We can easily change this behavior and edit Deployment config with the kubectl edit deploy httpd1 command:

$ kubectl edit deploy httpd1
...
<output omitted>
...
spec:
 replicas: 1 # change this value to 3
...
<output omitted>
...

Once you have changed the replica value to 3, save the changes and exit edit mode. The Deployment controller will detect the changes in the config and instruct ReplicaSet to bring up two more httpd pods. Let's verify that:

$ kubectl get pods
NAME                    READY STATUS   RESTARTS      AGE
httpd1-6d8bb9cdf9-hqks6  1/1   Running   0           5s
httpd1-6d8bb9cdf9-thlkg  1/1   Running   0           48m
httpd1-6d8bb9cdf9-xwmmz  1/1   Running   0           5s

If we try to delete all the pods, ReplicaSet will run a new set of pods automatically. Let's see how it works one more time:

$ kubectl delete pods --all
pod "httpd1-6d8bb9cdf9-hqks6" deleted
pod "httpd1-6d8bb9cdf9-thlkg" deleted
pod "httpd1-6d8bb9cdf9-xwmmz" deleted

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
httpd1-6d8bb9cdf9-7nx7k 1/1 Running 0 16s
httpd1-6d8bb9cdf9-gsxzp 1/1 Running 0 16s
httpd1-6d8bb9cdf9-skdn9 1/1 Running 0 16s

Delete all Kubernetes resources before we move on to the next section:

$ kubectl delete all --all