In the previous post, we used Kubectl to create a Kubernetes Pod using YAML file. In this post, we will understand the Kubernetes Pod YAML parameters in detail.

Basically, we will look at every line in our YAML file and describe what it does in the overall scheme of things.

So let’s start.

1 – Revisiting the Kubernetes Pod YAML file

Below is the YAML file that we used to deploy our Docker image on a Kubernetes Pod.

apiVersion: v1
kind: Pod
metadata:
  name: docker-react-pod
  labels: 
    component: web
spec:
  containers:
    - name: docker-react-app
      image: dashsaurabh/progressive-coder
      ports: 
      - containerPort: 3000

Basically, this file describes how a Pod should be created. When we apply this file using Kubectl, the Pod starts up on the Kubernetes cluster. It pulls the image from Docker Hub and deploys it in a container running inside a Pod.

However, there are various parameters in this file. Knowledge of these parameters is essential in order to create your own Kubernetes Pod YAML files in the future.

2 – Understanding the Parameters

In Kubernetes, every config file we write creates an object. Objects can serve different purposes such as running a container, setting up some networking, monitoring etc. In other words, an object is a thing that we create in our Kubernetes cluster.

With this understanding, let’s look at each parameter.

2.1 – API Version

The API version property essentially limits the type of objects we can create using our config files.

For example, by using API version v1, we get access to a certain set of objects. In other words, we get access to object types such as Pod, Namespace, Service etc.

Similarly, if we use a different API version (such as apps/v1), we get access to different type of objects.

2.2 – Kind

The Kind parameter describes the Kubernetes object we want to create. Basically, every single config file has a kind parameter that tells Kubernetes what type of object it should create.

kind: Pod

In the above example, the kind of object is a Pod. To make things clear, a Pod is used to run an application within our Kubernetes cluster.

2.3 – Meta Data

The Meta Data section has a couple of important properties.

metadata:
  name: docker-react-pod
  labels: 
    component: web

The name property specifies the name of the Pod. This property helps us reference the Pod in our Kubectl commands and other logging related concerns.

The other property i.e. labels and component helps us build a reference to this particular Pod. Using this reference, we can address the Pod in other Kubernetes config files such as Service.

2.4 – Spec & Containers

Pod is the lowest entity that can be deployed in a Kubernetes cluster. However, one Pod can have one or more containers.

The decision to put more than one container in a Pod largely depends on whether those containers are tightly coupled.

The Spec & Containers section in the YAML file describes the containers within a given Pod.

spec:
  containers:
    - name: docker-react-app
      image: dashsaurabh/progressive-coder
      ports: 
      - containerPort: 3000

Basically, in the above snippet, we are telling Kubernetes what all containers should be part of our Pod. In the above case, we have only one container.

  • The name property specifies the name of the container. Mostly, this property is used for logging and monitoring. However, in the case of multi-container pod, this can also be for some networking purpose.
  • Next, the image property points to the Docker image that will run on the container.
  • The ports property and more specifically, the containerPort property specifies the port on the container that should be exposed.

Conclusion

With this, we have successfully looked at important properties in the Kubernetes Pod YAML file.

The YAML file shown here is available on Github.


Saurabh Dashora

Saurabh is a Software Architect with over 12 years of experience. He has worked on large-scale distributed systems across various domains and organizations. He is also a passionate Technical Writer and loves sharing knowledge in the community.

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *