As we discussed in the << Purposed Model of continuous integration & deployment >> post about the process that how a developer performs code change/fix,
how it gets propagated to the pipeline, how this become part of delivery
& deployment.
In continuation to that there arises a point of how an update is rolled out, what are the possible ways to do that & how that can be benefited?
Note: At most in this deployment we will have 4 pods at a time & at least 3 pods.
In continuation to that there arises a point of how an update is rolled out, what are the possible ways to do that & how that can be benefited?
Let's start the journey with a possible deployment architecture explaining that how an update is rolled out:
Note: Here in this deployment example we will consider a replica set of 3 identical pods having same image i.e. "hello1".- An update of new image is available from the container registry, this needs to be rolled out in the deployment.
- Now we have a new updated image say "hello2". In this case we will tell our kubernetes master to create a second replica set that will have containers with image "hello2".
- You will notice that with creation of 2nd replica set the service pointing to replica set (1) will gradually start pointing to replica set (2) pods.
- First replica set pods will start decreasing & second replica set pods will increase.
Note: At most in this deployment we will have 4 pods at a time & at least 3 pods.
- Finally you will observe all 3 pods of replica set (2) are created & you are left with last POD of replica set (1) that too will be vanished soon.
- Finally the new image version is rolled out
