Welcome to Part 4 of Day 02 of the #5DaysOfKubernetes challenge! Today, we’ll delve into the fascinating world of Kubernetes Deployment Objects. These versatile tools are the key to managing application updates, and rollbacks, and keeping your Kubernetes applications running smoothly. So, let’s get started on our journey to master the Deployment Object in Kubernetes! 🚀🐱‍🏍 #Kubernetes #K8sLearning #DeploymentObject

Replication Controller and Replica Set don’t provide the updates and rollback for the application in the cabinets cluster. But in a deployment, the object does.
The deployment object works as a supervisor for the pods which gives granular control over the pods. Deployment objects can decide how and when the pods should be deployed, rollback or updated.
In Deployment, we define the desired state and the deployment controller will help to achieve the desired state from the current state.
You can achieve this by declarative(manifest) method only.
A Deployment provides declarative updates for Pods and ReplicaSets.
The deployment object supports updates which means if there is any update in the applications that needs to be deployed in the new version then, the deployment object helps to achieve it.
Deployment object supports rollback which means if the app is crashing in a new update then you can easily switch to the previous version by rollback.
The deployment object doesn’t work directly with the pods. Under the deployment object, there will be a replica set or replica controller that manages the pods and helps to manage the desired state.

Use Cases for the Deployment Object

With the help of deployment, the replica set will be rolled out, which will deploy the pods and check the status in the background whether the rollout has succeeded or not.
If the pod template spec is modified then, the new replica set will be created with the new desired state and the old replica set will still exist and you can roll back according to the situation.
You can roll back to the previous deployment if the current state of the deployment is not stable.
You can scale up the deployment to manage the loads.
You can pause the deployment if you are fixing something in between the deployment and then resume it after fixing it.
You can clean up those replica sets which are older and no longer needed.

HandsOn

YML file

apiVersion: apps/v1
kind: Deployment
metadata:
   name: thedeployment
spec:
   replicas: 3
   selector:     
    matchLabels:
     name: deploy-pods
   template:
     metadata:
       name: ubuntu-pods
       labels:
         name: deploy-pods
     spec:
      containers:
        - name: container1
          image: ubuntu
          command: ["/bin/bash", "-c", "while true; do echo This is Day09 of 30DaysOfKubernetes; sleep 5; done"]

Creating the deployment by running the command ‘kubectl apply -f da-deployment.yml’.

If you observe that the replica set has 3 desired states and same as the current state.

Also, all three pods are in ready and running status.

Now, if you try to delete any pod, because of a replica set, the new pod will be created quickly.

Here, we have increased the number of replicas set from 3 to 5 by the command

‘kubectl scale — replicas=5 deployment <deployment_name>’.

Here, we are checking the logs for the particular pod.

Here, I made some changes in the previous YML file as you can see in the file. I have updated the image and command for the needed YML file.

apiVersion: apps/v1
kind: Deployment
metadata:
   name: thedeployment
spec:
   replicas: 3
   selector:
    matchLabels:
     name: deploy-pods
   template:
     metadata:
       name: ubuntu-pods
       labels:
         name: deploy-pods
     spec:
      containers:
        - name: container1
          image: centos
          command: ["/bin/bash", "-c", "while true; do echo DevOps is a Culture; sleep 5; done"]

After updating the file, I have applied the updated file and as you can see, ‘thedeployment’ has 3 replicas which were previously 5. This happened because, in the YML file the replicas are 3.

Also, if you observe that the previous rs is still present with 0 desired and current state.

Now, if you will check the logs of the new pods. You will see the updated command running that we have written in the YML file.

Also, We have updated the image for the OS and you can see that we are getting the expected result for the image.

Here, we have increased the number of replicas set from 3 to 5 by the command ‘kubectl scale — replicas=5 deployment <deployment_name>’.

Now, if you want to switch to the previous deployment you can do it by the given command.

kubectl rollout undo deployment <deployment_name>

If you compare the first kubectl get rs command with the second kubectl get rs, then the desired state shifts to the other deployment.

Now, if you see the logs of the running pods. You will see that the previous command is running because we have switched to the previous deployment.

If you see the OS Image, you will understand that in our previous deployment, we used an Ubuntu image which is expected.

If you want to delete all those running pods and replica sets, then use the given command.

kubectl delete -f <deployment_file>

Conclusion

The Deployment object in Kubernetes is your trusted companion for managing application updates, rollbacks, and more. Its declarative approach, support for rollbacks, and seamless updates make it an indispensable tool for Kubernetes enthusiasts.

So, the next time you need to roll out a new version of your application or swiftly revert to a stable state, think of Deployment objects. They’re here to make your Kubernetes journey smoother and more efficient.

Happy Deploying!

Part 4 of Day 02 Deployment Object in Kubernetes

HandsOn

Conclusion