Achieving Zero-Downtime Deployment with Azure Kubernetes Service: A Step-by-Step Guide

This blog post provides a solution for achieving zero-downtime deployment in Azure Kubernetes Service (AKS). We'll explore different deployment strategies and choose the one that best fits our requirements. We'll then outline the necessary Kubernetes objects in AKS and present an Azure DevOps deployment pipeline for achieving zero-downtime deployment.

There are several deployment strategies available for deploying applications to production or other environments. Each strategy has its own use cases, benefits, and drawbacks.

Let's explore some of these strategies:

1. Recreate: This strategy involves removing instances with the old version and rolling out instances with the new version. It is commonly used during development and downtime does not matter. Kubernetes services natively support this strategy.

2. Ramped: The ramped strategy replaces instances of the old version with the new version one by one. This strategy ensures zero downtime, but it can be time-consuming and may not have full control over traffic. Kubernetes services support this strategy.

3. Blue/Green: In the blue/green strategy, new version instances are deployed while traffic is routed to the old instances. Once the new version is verified, the traffic is switched to the new instances, and the old instances are removed. This strategy offers zero downtime, fast rollout/rollback, and control over traffic, but it requires additional resources. It is not supported by Kubernetes services out of the box.

4. Canary: The canary strategy involves routing weighted traffic to the new instances gradually until all traffic is directed to the new version. This allows for fast rollback, measurable performance, and more control over traffic. However, it has a slow rollout and can be expensive. It is not supported by Kubernetes services out of the box but can be implemented using an ingress controller like NGINX.

5. A/B testing: Similar to the canary strategy, A/B testing allows for routing a subset of users to the new instances using canary cookies or headers. This strategy provides complete control over traffic but has a slow rollout and requires a Layer-7 load balancer like NGINX. It is not supported by Kubernetes services out of the box.

6. Shadow: The shadow strategy involves deploying new instances alongside the old instances and mirroring traffic to both versions. This allows for quick performance tests without impacting users but requires doubling the required resources.

For more information on these deployment strategies, check out this link: https://thenewstack.io/deployment-strategies/.

Choosing the Right Deployment Strategy

To achieve our requirements of fast rollout and rollback, the ability to check the new version while users are still routed to the old version, zero-downtime switch, and suitability for a production environment, we combined the Blue/Green and A/B testing strategies.

We’ll follow this with an overview of the components involved in achieving zero-downtime deployment using Kubernetes services. Let’s briefly discuss deployment objects, service objects, ingress objects, and the Ingress controller.

Deployment Objects: To implement the Blue/Green strategy, we utilized Kubernetes Deployment objects, which represent slots for blue and green versions of the component. Each deployment object is responsible for managing pods that contain a specific version of the component. Helm charts are used to define the deployment objects in code.

Service Objects: For A/B testing, we needed to operate two different versions of a component simultaneously. To accomplish this, we employed Kubernetes Service objects. These service objects exposed a set of pods as a network service. We had a service pointing to pods running a current version and a canary service pointing to pods running the next version of the component.

Ingress Objects: To route traffic from outside the cluster to the services within, we utilized Kubernetes Ingress objects. Ingress objects define HTTP and HTTPS routes and control the traffic routing based on defined rules. We created separate Ingress objects for both the service and canary service.

Ingress Controller: An Ingress controller is essential for handling Ingress objects. In our solution, we used the NGINX Ingress Controller, which allowed us to route traffic to the appropriate services based on the defined rules.

Deployment Pipeline with Azure DevOps: To automate the rollout of our component to Azure Kubernetes Service (AKS), we set up a deployment pipeline using Azure DevOps.

The pipeline consisted of several jobs:

1. Deploy Job: This job pulls the necessary helm charts from Azure Container Registry (ACR) and deploys the component to the desired slot using helm. It also updates the ingress release to have the canary service selectors pointing to the proper set of pods.

2. User Check Job: This job pauses the deployment process and allows the user to check if the new component version works properly. The user can decide to proceed or initiate a rollback.

3. Clean Up Deployment Job: In case of a failed deployment, this job removes the new version of the component and its slot.

4. Swap Deployment Slots and Cleanup Job: This job completes the deployment process by swapping the service and canary service to the new version of pods and removing the previous version's deployment.

The deployment process was visualized through a diagram, showcasing the various steps involved in achieving zero-downtime deployment.

Conclusion

Zero-downtime deployment is achievable in the Azure cloud using Kubernetes services. By understanding your requirements and employing different deployment strategies, you can ensure uninterrupted application availability.

All the presented source codes are available for download from the following link.

Read the whole article HERE!