Skip to main content

Understand Kubernetes Objects – Pod and Deployment

Background

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.

Pods

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.

web-deployment

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

deployments status

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

kubectl describe deployment

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
get pods

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
describe pod

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

pod details

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

deployment details

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

delete 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.

Comments

Popular Posts

Unit Test Application Configuration Settings

BackgroundAll the post I had written this month so far were related to the Entity Framework learning series. This time I thought of taking a diversion and share a quick method of unit testing setting which might be stored in the Application Configuration file (App.config) of a DotNet application. Unit Test Application Configuration SettingsLets fire up Visual Studio and create a simple console application. You can name it whatever you want. I have named the project as AppConfigTest. Once the project is created right click on Add and select Add New Item option in the solution explorer window. Select Application Configuration File option and click Add. This will automatically name the new file as App.config.Since this file used to configure settings at application level there is a possibility of someone changing these setting unknowingly. It can lead to severe problems later. It might also happen that the settings are different in different environments like development machines, test s…

Build custom SQL Server 2017 Linux Docker image

BackgroundIn the earlier series of posts on continuous deployment of multi-container apps, I had used two containers for ASP.Net Core MVC web site and ASP.Net Core Web API. This post is a sort of continuation. In the earlier version we were using in memory database to store the data. This approach is useful in a proof of concept or a quick demo application. In an enterprise scenario we would use some sort  of persistent data store to store the data. It is very easy to containerize the stateless services and web front ends. When we move towards stateful processing, things start to get interesting.Containers by their very nature are supposed to be ephemeral. This means that containers can be stopped and destroyed and a new one built and put in place with minimum setup and configuration. If we destroy the container and replace it with a new one what happens to the data stored inside the container? Can we use containers to run database related processes? How can the stateless containers c…

Integrate SQL Server 2017 Linux with ASP.NET Core using Docker

In the previous post, we saw how to initialize a SQL Server 2017 on Linux database running inside Docker container. This post is continuation of my exploration about Docker containers for stateful applications. In this post we will explore how to integrate the SQ Server 2017 on Linux container with ASP.Net Core Web API also running inside a Docker container. We will perform following activitiesUpdate Docker compose file to build the SQL server imageUpdate Web API project to use SQL Server Database instead of In memory databaseBuild and run the application containers using Docker compose commandsQuery Data from SQL container using the MVC web front endUpdate Docker compose file to build the SQL server imageDocker provides Docker Compose as a tool for defining and running multi-container Docker applications. I already have an existing docker compose file which I have been using for my series of post on implementing continuous deployment of multi container apps. In a compose file we defi…