Kubernetes - Deployment Management/Strategies

When we have an deployment it does not make the pods directly instead there is an another object that’s like in the middle its called as Replica set.

ReplicaSets

• ReplicaSets are the one which actually creates the pod

• ReplicaSet does one job and one job well, i.e. to maintain n number of copies of pod that are identical and replicas of each other

• So the deployments jus creates the ReplicaSets then configures what N number are in fly.

• deployment handles the creation/modification of ReplicaSets

• do not manually manage the ReplicaSet that are owned by a Deployment.

Deployment Strategies

Built-In

• Rolling Update

  • default if not defined

  • Our Application stays live and we go through one by one and update each instance in pod to the new version

  • New ReplicaSet is created, then scaled up as the old ReplicaSet is scaled down

  • Here for ex if you have 1 replica set with 3 pod, when new configured is updated

    • it creates a new ReplicaSet

    • then it will create new pod in it , where there are 3 + 1 new pod and traffic will go to all 4 pods because they have same selectors

    • as new pod is created an existing pod from the old replica set will be destroyed, then it continue to do same for all

    • then old replica set will be renamed because Kubernetes don’t clean it up for some time.

• Recreate

  • Removes all the existing pods in the existing ReplicaSet first then creates new Pods in the ReplicaSet

  • Same scenario , 1 replica set with 3 pods

    • Here, 1st it will scale down the current replicaSet from 3 → 0

    • then it create a new replicaSet then scale up the pods to 3 with newer version

    • There will be downtime in this strategy

Others:

• Canary Deployment

  • Deploy new container to subset of traffic

  • involves two deployment and label management between them

  • Scenario when we have 1 replica set with 3 pods

    • In this case we have 2 deployment , One with label track:stable and replicas 3 and another with track:canary replicas 1 but both have same service file where traffic are going to all 4 pods where only one pad has newer version

    • When new version is tested and ready for production they update the image version of track stable for newer version and track canary will be scaled down to 0

    • If the newer version is not stable means they take down the canary deployment so no traffic will flow to that pod.

    • In this service file won’t change and they don’t have selector track

• Blue/Green Deployment

  • Popular in cloud environments where we have ability to spin up a duplicate capacity and then flip the switch to go and transform our production to going to newer version.

  • for example:

    • This this case also we have 2 deployment files and one service file may need of another service file for testing

    • Labels in the older version of deployment have {app:blog,tire:frontend,color:blue} and newer version have {app:blog,tire:frontend,color:green} and service file selector have {app:blog,tire:frontend,color:blue} , now according to service selector the all traffic are going to older version of the deployment

    • So before moving traffic to newer version they will be tested by QA for that we need to create a another service file having selectors {app:blog,tire:frontend,color:green}

    • once everything will be tested the older service file will be changed to colour green ({app:blog,tire:frontend,color:green}) so that all the traffic will now move to newer version.

    • If there is no issues came from newer version then the older deployment(blue) replica will be scaled down to 0, if issues came up then it again rolled back or service file selector colour will be changed to blue

    • In further updated this colour will be opposite

Controlling Deployment

Pausing

• if the application is complex and if you need to pause/resume the deployment we can use command

  kubectl rollout [pause | resume ] deployment <name>

Rolling back to previous version

• Declarative (preffered)

  • modify the deployment file then reapply

    kubectl apply 0f <deployment file>

• Imperative

  • kubectl rollout undo deployment <name>

General Optional Options

progressDeadlineSeconds

• max number of sec we expect a deployment to every take

minReadySeconds

• min sec a newly created pod should be ready with out any of its containers crashing. default to 0

revisionHistorylimit

• number of old ReplicaSets to retain to allow rollback. default to 10

paused

• pause a deployment; if set to true, then changes to spec do not trigger a deployment