Kubernetes deployment YAML Walkthrough

MrDevSecOps

4 min readFeb 19, 2022

A Deployment is a resource object in Kubernetes that defines the desired state for our program.
Kubernetes Deployment is the process of providing declarative updates to Pods and ReplicaSets.
It allows users to declare the desired state in the manifest (YAML) file.

This definition file always contains four top-level fields, the API version, kind, metadata, and spec.

apiVersion

This refers to the version of Kubernetes.
API version consists of two things group name and Version.
There are several versions, and several objects are introduced with each version.
Some common ones are v1, apps/v1, and extensions/v1beta1.
On the right-hand side, you can see the different types of values
You can check out the below command for the list of versions.

$ kubectl api-versions

Kind:

This is the type of Kubernetes object. In this case (the example above), we’re creating a deployment.
You can see the other types of objects that we create commonly on the right side here.
You can check out the below command for the list of kinds.

$ kubectl api-resources | awk '{print $5}'

Metadata:

The metadata houses information that describes the object briefly.
The information in the metadata usually contains the name you want to give the object (deployment in our case), the labels, and the annotation.
name the object is the only mandatory field and the remaining are optional.
You can check out the official Kubernetes documentation for the metadata field.

Spec:

In the spec section,

First, the replicas that define the number pod of instances that deploy and should keep alive.
Next, we use a label selector to tell the deployment which pods are part of the deployment.
This essentially says all the pods matching these labels are grouped in our deployment.
After that, we have the template object. It’s essentially a pod template packed inside our deployment spec.
When the deployment creates pods, it will create them using this template!
For this example, we are deploying a replicate with four pods of the instance with an nginx docker image.
Kubernetes uses default deployment strategies called RollingUpdate to recreate pods.
Even if didn't mention any deployment strategy in the deployment YAML file, Kubernetes manage the pods and replica set with a RollingUpdate strategy.

ReplicaSet Vs Deployment YAML file

If we compare the replica set and deployment YAML file both look almost the same. there is only one field different that is kind since we are creating a deployment object.
Deployment is responsible for two things, One is scaling and another is application deployment.

Deployment Strategy YAML

Kubernetes uses two deployment strategies called Recreate and RollingUpdate to recreate pods.
We can define those strategies in .spec.strategy.type field.
The RollingUpdate strategy is the default for deployments.

Recreate will delete all the existing pods before creating the new pods.

RollingUpdate will recreate the pods in a rolling update fashion. Moreover, it will delete and recreate pods gradually without interrupting the application availability.

This strategy utilizes the maxUnavailable and maxSurge values to control the rolling update process.

maxSurge: The number of pods that can be created above the desired amount of pods during an update. This can be an absolute number or percentage of the replicas count. The default is 25%.

maxUnavailable: The number of pods that can be unavailable during the update process. This can be an absolute number or a percentage of the replicas count; the default is 25%.

To understand the maxSurge and maxUnavailable, let’s go through the above configuration.

let’s assume that we already have four instances of pods running with Nginx.

Now, when we initiate the upgrade from Nginx -1.8 to 1.9 using this YAML file, then it will first create two new pods with Nginx 1.9 and after a successful configuration, then it will delete the two pods running with Nginx 1.8.
After that, it will create two more pods with nginx1.9 and once both pods are running, it will delete old Nginx pods ie Nginx-1.8

In the end, you will have four pods instances running with nginx1.9

Also, check