Skip to main content

Deployments

For this study, let's follow this sequence:

  1. Labels
  2. Rolling Updates & Rollbacks

Blue Green vs Canary

In a few words, Blue-Green is the act of creating a second deployment, with a new name, new image, new labels, and it's recommended to maintain a version label, but not necessary. Once the second deployment is ready, only the service selector should be changed to stop pointing to the first deployment and point to the second, redirecting all traffic immediately.

On the other hand, Canary deployment is the act of migrating gradually. A percentage of the service requests should go to the first deployment and another percentage to the second. These percentages should be adjusted gradually so that over a period all traffic moves to the second deployment.

In Canary deployment, both deployments need to have at least one label in common, for example app=my-app-name. In the Service, we'll filter by this common label so that all pods from both deployments can respond to requests, even being from different versions.

To control traffic, it's only necessary to control the number of pods of both versions. In version 1, we can have 3 replicas and in version 2, we can have 7 replicas. This gives us 30% traffic to version 1 and 70% to version 2, since the service has the round-robin algorithm by default.

There are better tools to do this, such as Istio, but we won't study it in CKAD.