In Kubernetes, a Deployment is a resource object that provides a declarative way to manage applications. It's designed to handle the deployment and scaling of pods while ensuring high availability and managing updates efficiently.

Features of Kubernetes Deployments:

1. Pod Replica Management: Deployments manage a set of identical pod replicas to ensure that a specified number of replicas are running at all times. If a pod fails or is terminated, the Deployment controller automatically replaces it.

2. Rolling Updates: Deployments support rolling updates, enabling you to change the configuration or update the image of your application without causing service downtime. Old pods are gradually replaced by new ones, ensuring a smooth transition.

3. Rollbacks: In the event of issues with a new version or update, Deployments allow you to easily roll back to the previous version, ensuring application stability.

4. Scaling: You can easily scale your application up or down by adjusting the number of pod replicas in the Deployment configuration. This scalability is essential for handling varying workloads.

5. Declarative Configuration: Deployments follow a declarative model. You specify the desired state (such as the number of replicas, the container image, and more) in a YAML file, and the Deployment controller takes care of ensuring that the current state matches the desired state.

6. Automated Management: Deployments abstract the complexities of managing pods. They handle the creation and deletion of pods, making it easier to manage applications.

7. High Availability: By ensuring that a specific number of pod replicas are always running, Deployments contribute to the high availability of your applications. Even in the presence of hardware failures or pod issues, the desired replica count is maintained.

8. Resource Efficiency: Deployments use a resource-efficient approach, only creating or updating the pods that need changes, rather than recreating the entire set.

9. Service Integration: Deployments are often used in conjunction with Kubernetes Services to expose and manage application access.

Example of Paytm :

( Current Version: v10.33.1-assume we are working to upgrade to v10.33.2)

A rollout is the process of gradually deploying or upgrading your application containers.

What happens in a deployment?

When you first create a deployment, it triggers a rollout. A new rollout creates a new Deployment revision. Let’s call it revision 1.

In the future when the application is upgraded – meaning when the container version is updated to a new one – a new rollout is triggered and a new deployment revision is created named Revision 2.

This helps us keep track of the changes made to our deployment and enables us to roll back to a previous version of the deployment if necessary.

• You can see the status of your rollout by running the command:

"kubectl rollout status" followed by the name of the deployment.

• To see the revisions and history of rollout run the command:

"kubectl rollout history" followed by the deployment name and this will show you the revisions.

When we create a deployment, a replicaset is created and automatically the replicaset creates pods.

Let's create a deployment:

Here we have just changed the kind to Deployment. Other than this, most of the things are the same as replicaset.
We have given the file name deployment.yaml.

To create the deployment we have to run the below command

"kubectl create -f deployment.yaml"

Let's check the deployment status:

It shows we have 1 deployment and 3 out of 3 ready pods. Let's check the pods

Let's check more information in the description:

Now use this command " kubectl get all" to get a few more details:

Other than the service, all of the things are related to the deployment:

Deployment strategy

1. Way 1 (Recreate strategy):

   There are two types of deployment strategies. Say for example you have 5 replicas of your web application instance deployed. One way to upgrade these to a newer version is to destroy all of these and then create newer versions of application instances.

   

   This means first, destroying the 5 running instances and then deploy 5 new instances of the new application version. The problem with this as you can imagine,
   is that during the period after the older versions are down and before any newer version is up, the application is down and inaccessible to users.

   

   This strategy is known as the Recreate strategy, and thankfully this is NOT the default deployment strategy.

   

   

Way 2 (Rolling update by default):

1. The second strategy is were we do not destroy all of them at once. Instead, we take down the older version and bring up a newer version one by one. This way the application never goes down and the upgrade is seamless.

   

   

   

Note: if you do not specify a strategy while creating the deployment, it will assume it to be Rolling Update. In other words, RollingUpdate is the default Deployment Strategy.

Let's do it practically:

Let's delete our deployment thus no pods exist and we will modify our deployment and then use rollout and others here.

Let's update our replicas to 6

Let's create the deployment, You can now check the status of deployment by watching the 6replcas (pods) getting created live :

Let's use the rollout status command to see the status:

Did you realize what happened?
I guess not. Let's delete the deployment and create it fast. Then check the rollout status.

Let's check the history of the deployment:

You can see that, we have just 1 revision. You can see the Cause change None as we did not set anything to record while deployment.

Let's delete the deployment and set this time.

Let's create the deployment with --record command to record the Cause of change this time.

kubectl create -f deployment.yaml --record

Now, check the rollout status & history too

You can see the cause of change.

As we have used the --record command, it has recorded the command "kubectl create --filename=deployment.yaml --record=true"
You can check the deployment information properly:

kubectl describe deployment myapp-deployment

Let's change the image of the replica pods:

kubectl edit deployment myapp-deployment --record

we are using --record to record whatever we are doing...

first press "i" to get into insert mode and then change the image to nginx:1.22 which is a stable version and an older one.

In the below above, you can see the image has been changed to 1.22. We have to make sure of alignment.

Now the old pods (Which had nginx image) are terminated and new pods are created using image nginx:1.22.

If you type this command within a very short time, you may see something like this as in the below snippet.

kubectl  rollout status deployment.apps/myapp-deployment

Now check the pods or replicas;

They are completely new and made of ngnix:1.22 image

If you check the description of the deployment now, you can see something like this:

You can see the image has been changed to nginx:1.22 and events. Also, it is revision 2 now.

Let's change the image to nginx:1.22-perl again. You may use

kubectl edit deployment myapp-deployment --record
OR
kubectl set image deployment myapp-deployment nginx=nginx:1.22-perl

Remember for this yaml file, we did set the container name as nginx and the image was set to nginx:1.22 which we are changing to nginx:1.22-perl.

We will use the below command:

You can now check the rollout status:

To check the status command will be:

kubectl rollout status deployment.apps/myapp-deployment

You can see the old replicas to be terminated.

Now, you may check the history of rollouts:

There are a total of 3 revisions. for the 1st time, when we created the deployment, 1 rollout happened and 1 version was created.

Then we edited the image t nginx:1.22 and thus another rollout happened and a new revision appeared. Again, when we changed the image to nginx:1.22-perl, another rollout happened and another revision was created.

Now, assume that your boss told you that revision 3 was a bad decision. You should have been in revision 2, then what should you do? You can undo changes. Use this command:

This will undo revision 3 and take you back. This will create revision 4.
Thus new pods will be created which will have image nginx:1.22

Now check out the description of the deployment and you can see the image nginx:1.22

kubectl describe deployment myapp-deployment

Wait, a second. We now have 3 revisions (revision 1,3,4). Where is revision 2, Right?

kubectl rollout history deployment.apps\myapp-deployment

Because revision 2 the revision 4.

Hey! Did you notice that we were just applying the RollingUpdate strategy by now?

kubectl edit deployment myapp-deployment --record

You will find a section under spec defining strategy

If you need to change it to Recreate or any other, you can change it to "Recreate"
For example, for the Recreate strategy, you need to edit it to:

Here, we are done with this task:

Congratulations !!!

Hope this was helpful. Thank you for your time !!

Stay Connected, many more to come !!

You can connect with me: linkedin.com/in/aman-srivastava-dev