Understand Kubernetes Objects — Pod and Deployment

This is the third part of the series on building highly scalable multi-container apps using AKS. Previous posts in this series:

This post we will focus on creating another basic resource in Kubernetes named Pod.

We will be performing the following actions during this post

  • Get familiar with Pod and Deployment
  • Create a Pod using Kubernetes manifest file via Controller (Deployment)
  • Find details about the Pod and Deployment using Kubernetes CLI kubectl
  • Find Pod and deployment details using Kubernetes dashboard
  • Delete the Deployment using Kubernetes CLI kubectl
  • Delete Deployment using Kubernetes dashboard

Pod

A pod is the smallest unit of deployment in Kubernetes. Usually a pod consists of a single container and its related resources like storage/networking and the specification of how to run the container. This is illustrated in the diagram below.

Each Pod has its own IP and the container as shown in Pod1. Pod 2 is an example where a Pod has Volume attached to it. We will cover Volume later in the series. Pod 3 is an example where multiple containers are scheduled to run as part of the same pod. Finally Pod 4 is an example where we have multiple containers and multiple volumes within the same pod.

We can create pod using the kubectl create pod command. It is generally recommended to use a higher level API to create pod instead of directly creating them ourselves. We will use Controller API with the Deployment to create pod.

Deployment

Deployment is one of the higher level API provided Kubernetes. It interacts with basic objects like Namespaces and Pods. Deployment consists of the template to deploy a containerized application. We can create deployments similar to the way we created namespace in the earlier post using kubectl. Lets look at the deployment file for ASP.Net Core web application.

Here is the brief description of important attributes in the manifest file.

metadata: creates a deployment named techtalksweb in the abc2018sg namespace created in the previous post.

Deployment specification (spec): We have specified the replica as 1.

Selector : is used to select the template based on the matching label. The label is key value pair. We can also specify multiple labels to identify the deployment.

Be careful with the key value pairs used for different labels. For a newbie it is quite common to make spelling mistakes in the label names. At times I had to spend lot of time debugging different Kubernetes resources when things did not work out correctly due to mismatch in the labels

template:spec : Describes the pod details. Deployment can deploy a single container or multiple containers. This is represented using the containers collection on line 21. In this case we have only one container. Later we would be able to see use of multiple containers used within single deployment when we talk about init-containers.

The name and image on lines 22 and 23 are self explanatory. For each container we specify the properties like image name in the container registry. I am using DockerHub as the public container registry. The repository is named nileshgule and the image name is techtalksweb. As we did not specify the specific version, latest image will be pulled and deployed to the Kubernetes cluster.

env : specifies the environment variables we wish to override in the container. We also specify the port which needs to be exposed. We have also defined the policies for pulling images and restarts.

In the deployment template we can specify multiple constraints like the memory and CPU requirements. If the container exceeds the limits, Kubernetes master will kill the container and start a new instance. We specify how the termination process should be handled. In this case we are specifying that the graceful time for termination is 30 seconds using terminationGracePeriodSeconds attribute. This will be applied when the container is killed and it needs time to gracefully perform operations like closing database connections etc.

Save the contents of the file to disk with file named web-deployment.yml. We can create the deployment using kubectl by running the command

kubectl create –-filename web-deployment.yml

Find details about the Pod and Deployment using Kubernetes CLI kubectl

Lets query the Kubernetes cluster to know details about the newly created deployment object. We can start with getting all the deployments

kubectl get deployments

Initially there are no results. We get a message No resources found. But if you look at the earlier command output, it says deployment “techtalksweb’ created. What happened there? The kubectl is referring to default namespace. The object that we created is linked with the abc2018sg namespace. We need to add the namespace filter to the command as follows

kubectl get deployments –-namespace abc2018sg

Now we get the correct result with the name of the deployment as techtalksweb. We can get details of the individual deployment using the command

kubectl describe deployment techtalksweb –-namespace=abc2018sg

We can cross verify from the screen shot above that all the details specified in the deployment manifest are matching with the output. We can also find the additional details which are set to default values. Some of the examples of default properties being applied are StrategyType, MinReadySeconds, Volumes.

These details are related to the deployment. How about individual pod? We can query the Kubernetes cluster to get all pods. Note that most of the commands from here on will require us to specify the namespace to filter the details. We can first get a list of all the pods running within a namespace using the command

kubectl get pods –namespace abc2018sg

Once we know the name of the pod, we can drill down to a specific pod. Remember the command we had used in the previous post to describe the details for a namespace? Off course it is the describe command

kubectl describe pod –namespace abc2018sg techtalksweb-594576578c-kh475

Here we can see details related to the pod which are derived from the template we defined in the manifest file as well as the default values provided by Kubernetes itself.

Details of Pods and Deployments using Kubernetes dashboard

We can retrieve the same information that is available using CLI commands instead using the Kubernetes dashboard. Browse to the Kubernetes dashboard by running the following command

az aks browse --resource-group=ABC2018ResourceGroup --name=ABC2018AKSCluster

Filter the namespace on the left navigation pane. We can then list all the pods using the Pods link as shown below

Similar to the pods, we can also get details about the deployments using Deployments link.

We get the same details that were available in the CLI output in a graphical form.

Delete deployment using Kubernetes CLI Kubectl

Deleting any resources in Kubernetes is done using the delete command and passing the type of the resource. Here is the example of how we would delete the Techtalksweb deployment

kubectl delete deployment techtalksweb –namespace abc2018sg

Another option to delete the deployment is by giving the manifest file reference as follows

kubectl delete –filename techtalksweb-deployment.yml

Note that we need not specify the namespace name when uisng the manifest fielname as it is already part of the declarative markup. The approach of using filename instead of individual resource name is extremely useful if you are creating multiple objects using the same manifest file and would like to delete them all in one go. Personally I prefer to define one single Kubernetes object in one manifest file. You might come across one big yaml file containing all the object definition.

Delete Pod and Deployment using Kubernetes dashboard

Deleting Pod or deployment using dashboard is done using the context menu associated with the resource. Here is an example of deleting the pod

Conclusion

In this post we saw how to interact with Deployments using the Kubernetes CLI as well as the dashboard. The deployment controller internally creates the pod which is one of the basic object in Kubernetes. A pod has an IP, volume and container encapsulated together. Deployment defines the template for creating and managing a running instance of a pod.

Later in this series we will see how to define resource constraints for the containers as well as how to manage dependencies or pre-requisites between containers using the concept of init-containers. The complete source code for the examples used during this multipart series is available on Github.

Until next time, Code with Passion and Strive for Excellence.


Originally published at www.handsonarchitect.com.