Skip to content

KodeCloud Kubernetes Deployments

Links: 111 KodeCloud Index

Deployments/Rollouts

  • Deployment vs Replica Set

    • attachments/Pasted image 20220919193045.jpg

  • Components of the deployment definition file are exactly same as the Replica Set definition file except for the kind.

What are the additional features provided by Deployment over ReplicaSet considering they have the same definition file.
  • You don't want to upgrade all the instances instantly. You would want rolling updates.
  • Roll back the changes.
  • Make multiple changes to your environment. You wouldn't want to apply it immediately. You would like to pause the environment make the changes and resume so that all the changes are rolled out together.
  • The deployment automatically creates a ReplicaSet.
  • Pod naming convention when created by deployment: <deployment-name>-<replica-set-hash>-<random-hash>.
    • In case of replica set the name of the pods was just <replica-set-name>-<random-hash>.
    • We don't need to provide a pod name since it is automatically assigned by the deployment.
  • Replica set naming convention:
    • In case of replica set the name of the replica set was whatever specified in the name of the definition file.
    • In case of deployment the name of the replica set is <deployment-name>-<replica-set-hash>
  • We can see the status of roll out using:
    • k rollout status deployment/<deployment-name>
  • Get the history and revisions of the rollout:
    • k rollout history deployment/<deployment-name>
  • Get the rollout history of a particular revision:
    • k rollout history deployment/<deployment-name> --revision=3
  • Rolling update is the default deployment strategy.

  • Another deployment strategy is Recreate in which all the pods are first destroyed and then the new revision is added.

  • Difference between Recreate & Rolling Update: ^02046b

    • attachments/Pasted image 20220919202752.jpg
    • See how the ReplicaSet replicas change in Recreate (reduced to 0) and Rolling Update (few units at a time)
    • Notice that Recreate has only 1 replica set where as rolling has 2 different replica sets.
  • When we apply a deployment definition a new rollout is triggered and a new revision is created.
How do upgrades happen in rolling Deployments?
  • When we upgrade our application a new ReplicaSet is created under the hood and starts deploying the containers there.
  • At the same time pods are being taken down in the old ReplicaSet in a rolling update strategy. attachments/Pasted image 20220920000658.jpg
  • This can be verified when we list the ReplicaSets. We will see one ReplicaSet with 0 pods and other one with x pods.
  • Another way verifying it is looking carefully at this image.
  • See how for recreate the name of the replica set remains the same (this means only one replica set) since we are deleting all the pods in a replica set and recreating all of them in the same one.
  • For rolling we see that there are 2 different replica sets.
  • We can easily rollback using k rollout undo deployment/<deployment-name>
    • This will destroy the pods in the new ReplicaSet and bring the older ones up in the old ReplicaSet.
    • attachments/Pasted image 20220920000907.jpg
    • We can notice the difference in ReplicaSets before and after the rollback.

  • Rollback to a particular revision:

    • k rollout undo deployment/<deployment-name> --to-revision=1

  • Whenever we apply a deployment file we can record the cause of rollout using the --record flag.

    • k apply -f deployment.yaml --record
    • Using this would mean that the cause of change is tracked in the revision history.

  • Scenario:

    • Suppose in a deployment you change the image to a non existent image
    • When you apply this configuration you will have some working pods (from the older ReplicaSet) and some non working pods (from the new ReplicaSet)
    • attachments/Pasted image 20220920233119.jpg
    • In the above example image we see that only one pod was terminated (from the older ReplicaSet) and it failed to create 3 new pods since it couldn't pull the image.
    • You can notice the different ReplicaSet by comparing the hash.
    • Even though we have specified the wrong image, the application is not impacted since we have 5 working pods.
    • This is because of the default deployment strategy of rolling deployment.
    • Kubernetes will only delete the older pods once all the new pods are up and running.

Last updated: 2023-05-03