Understanding Blue Green Deployment

What this blue-green all about?

This is a way of switching traffic from one deployment to another one. That means say you have a new version of software to roll out, which has been successfully tested in staging environment. Now you want that to go-live, so here in kubernetes you have this magic word blue-green deployment.

Definition: "A blue green deployment uses the service label selector to switch all traffic from one deployment to another."

If above stated definition is cryptic, than lets see an image view to understand it;

Here if you notice, we have app:hello version:1.0.0 is currently deployed. Now let's say we have a new version i.e. 2.0.0 of hello app;

First test you new deployment, i.e. version 2.0.0. Once you have verified it, it's time to switch live traffic to version 2.0.0 deployment.

Now let's get back to the definition, we discussed previously. It says use service label selector to switch traffic. Awesome we are on track understanding traffic switch.

Here we have successfully switched to new version 2.0.0 with help of "selectors & labels". That means if we want to get all this done, the mantra is to understand "labels & selectors".

Got it, now you must be asking where the heck is this labels & selectors discussion. Need not to worry we will soon see a video tutorial because that needs much attention.

Very well, we have made a basic understanding of blue-green deployment.

Enjoy :-)

Understanding Updates Rollout in Continuous Deployment

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?

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

References:

• https://www.coursera.org/learn/google-kubernetes-engine/

Enjoy :-)

Details about Canary Deployment

About Canary Deployment:

• Definition: Canary deployments are a pattern for rolling out releases to a subset of users or servers. The idea is to first deploy the change to a small subset of servers, test it, and then roll the change out to the rest of the servers
• This means when i have to deploy an update in production, i can do this by canary way. This will allow me to deploy the change in production but only to a subset of servers. So by this way we subset of users can test the new update & report if any issue occurs. If all goes well than the update can be rolled out completely.

How to switch the traffic to from old version to new version?

This can be made possible with blue-green deployment. More info Understanding blue-green deployment.

References:

• https://www.coursera.org/learn/google-kubernetes-engine/

Enjoy :-)