With the proliferation of cloud computing environments, new software development and deployment methods are developing rapidly. In the development side, CI/CD, DevOps, SecOps and so on, make the software development, deployment cycle fully automatic: From planning, coding, building, testing to deployment using IaC ( Infrastructure as Code), SaaS(Software as a Service) for containerized cloud functions’ operation, monitoring, auto scaling, auto recovering under Kubernetes orchestrator.
As SaaS are containerized applications deployed to cloud with Kubernetes as orchestrator, together with other cloud technologies such as ingress, load balancer, service mesh, those introduce new software release upgrade and update methods: Rolling update, Recreate upgrade, Blue/Green deployment, Rainbow deployment, A/B testing, to name a few.
In this article, all those technologies will be briefly reviewed and focus on when and which mechanism to use in order to achieve zero-downtime software release goal with consideration of deployment cost, scenarios and required support technologies.
Build High Quality Application Container Image
Use ways such as build-in unit testing and multi stage build docker file to make sure the created application docker image is unit tested with least possible size. Use tools such as Skaffold, Telepresence to locally deploy, test your new application container image.
Use Rolling Update for Release Update
Kubernetes has built-in support for rolling update when you use commands: kubectl apply or Helm upgrade with new version of container image. This is normally used when bugs are found and fixed within a minor release after the major release was deployed. maxSurge and maxUnavailable parameters can be used to control the portion of new and old application images running within the cloud cluster. You only need one cloud cluster to carry out rolling updates. If you do not need this kind of gradually updating way and want to update all container images to the new version quicker, the Recreate update mechanism can be used instead.
Utilize Blue/Green/Rainbow Update
If you can afford multiple clusters’ cost, the blue/green update method can be used, which means you have a new release running on the side of the old release on different cluster. Then the application users’ traffic can be directed to either of the clusters with cloud technologies such as pod labeling, ingress or traffic manager. The application traffic can be easily switched back and forth between new or old software releases. If there are more than two versions of applications that need to be tested simultaneously, rainbow update can be used with multiple clusters being used.
Canary Release
If the cost of maintaining multiple clusters used in the blue, green deployment mechanism is too expensive and unrealistic, Canary release can be used with the help of service mesh to route a small portion of traffic to new version of software release and keep most of application routed to tested, older release. If the new software release worked as expected, 100% of application traffic can be routed to new software release. On the other hand, if the test is failed, the small portion of traffic routed to new release can be re-routed back.
After this kind of canary testing, 100% of application traffic can be switched to the new release and being switched back to the previous release on the fly. This kind of release is so called A/B release.
Service meshes, like Istio, Linkerd, Nginx should be used for best result for such kind of deployment, although pod labels can also be used to achieve similar results.
Thanks for the reading. keyuan Zhang.
Knowledge, Experience and Learning 