Cracking the Kubernetes Code: A Closer Look at Deployment and Replica Sets

Cracking the Kubernetes Code: A Closer Look at Deployment and Replica Sets

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! 🚀”