Deployments
A Deployment provides declarative updates for Pods and ReplicaSets.
You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate.
It seems similar to Replica Sets but with advanced functions.
Deployment is the recommended way to deploy a pod or RS
By default, Kubernetes performs deployments in a rolling update strategy.
Below are some of the key features of deployment:
✓ Easily deploy a RS
✓ Rolling updates pods
✓ Rollback to previous deployment versions
✓ Scale deployment
✓ Pause and resume deployment
Deployment Strategy
Whenever we create a new deployment, K8s triggers a Rollout.
Rollout is the process of gradually deploying or upgrading your application containers.
For every rollout/upgrade, a version history will be created, which helps in rolling back to the working version in case of an update failure.
In Kubernetes, there are a few different ways to release updates to an application.
Recreate: terminate the old version and release the new one. Application experiences downtime.
Rolling Update: release a new version in a rolling update fashion, one after the other. It’s the default strategy in K8s. No application downtime is required.
Blue/green: release a new version alongside the old version then switch traffic.
Rolling Update Strategy
By default, deployment ensures that only 25% of your pods are unavailable during an update and does not update more that 25% of the pods at a given time
It does not kill old pods until/unless enough new pods come up
It does not create new pods until a sufficient number of old pods are killed
There are two settings you can tweak to control the process: maxUnavailable and maxSurge. Both have the default values set — 25%
The maxUnavailable setting specifies the maximum number of pods that can be unavailable during the rollout process. You can set it to an actual number(integer) or a percentage of desired pods
Let’s say maxUnavailable is set to 40%. When the update starts, the old ReplicaSet is scaled down to 60%. As soon as new pods are started and ready, the old ReplicaSet is scaled down again and the new ReplicaSet is scaled up. This happens in such a way that the total number of available pods (old and new, since we are scaling up and down) is always at least 60%
The maxSurge setting specifies the maximum number of pods that can be created over the desired number of pods
If we use the same percentage as before (40%), the new ReplicaSet is scaled up right away when the rollout starts. The new ReplicaSet will be scaled up in such a way that it does not exceed 140% of desired pods. As old pods get killed, the new ReplicaSet scales up again, making sure it never goes over the 140% of desired pods
Deployments
Create a file “deployment.yml”
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 10
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx
ports:
- containerPort: 80
Run this command:
kubectl create -f deployment.yml
To see all deployments:
kubectl get deployments
You can see the output like this:
If you want to see more details about your deployment then you can run this :
kubectl describe deployment <your-deployment-name>
You can see the o/p like this :
If you want to edit the deployment then:
kubectl edit deployment <deployment -name> #perform live edit of deployment
If you want to scale the deployment then:
kubectl scale --replicas=20 -f deployment.yml
Then you can see the Replicas count has been changed:
Whenever you’re changing the replica count in background it will change, if you want to see that process after changing the replica count, then the below command you have to run (Make this very quick because it will not take so much time to scale the replicas):
kubectl rollout status deployment <deployment-name>
You can see o/p like this:
There are multiple commands you can check and test:
kubectl rollout undo deployment <deployment -name> --to-revision=1
kubectl rollout pause deployment <deployment -name>
kubectl rollout resume deployment <deployment -name>
kubectl delete -f <deployment-yaml-file> #deletes deployment and related dependencies
kubectl delete all --all #deletes pods, replicasets, deployments and services in current namespace
ReplicaSets
ReplicaSets are a higher-level API that gives the ability to easily run multiple instances of a given pod.
ReplicaSets ensures that the exact number of pods(replicas) are always running in the cluster by replacing any failed pods with new ones.
The replica count is controlled by the replicas field in the resource definition file.
ReplicaSets uses set-based selectors whereas replication controller uses equality-based selectors.
To create Replica-Set, create file “replica -set.yml”
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: nginx-replicaset
labels:
app: webapp
type: front
spec:
replicas: 3
selector:
matchLabels:
app: webapp
template:
metadata:
name: nginx-pod
labels:
app: webapp
spec:
containers:
- name: nginx-container
image: nginx
ports:
- containerPort: 80
To create replica set, apply this command:
kubectl create –f replica -set.yml
Run this command to check replica sets:
kubectl get rs –o wide
Below are the commands which is helpful in Replica sets object, you can check and test:
kubectl edit replicaset <replicaset-name> #edit a replicaset; like image, replicas
kubectl delete replicaset <replicaset-name> #delete a replicaset; like image, replicas
kubectl delete -f replica-set.yml
kubectl get all #Toget pods, replicasets, deployments, services all in one shot
kubectl replace -f <file_name> #replaces the pods with updated definition file
kubectl scale -–replicas=6 –f <file_name> #scale using definition file
kubectl scale -–replicas=6 replicaset <replicaset-name> #using name of replicaset
“In the dynamic world of Kubernetes, Deployment and Replica Sets are the unsung heroes of scalability and resilience. 🦸♂️
As we conclude this journey, remember: Kubernetes is more than just a tool; it’s a superpower for modern application management. Deployments shape the future, seamlessly rolling out updates, while Replica Sets stand as an unyielding fortress.
Embrace this dynamic duo, experiment, and watch your containers soar. With Kubernetes as your ship and Deployment and Replica Sets as your compass, the possibilities are endless. Happy orchestrating! 🚀”