#Azure #kubernetes

Modern Software delivery moves at a relentless pace and often requires enabling new features with minimal impact to end users. The simplest approach to follow for microservices deployed to Kubernetes is Blue Green Deployment leveraging the Kubernetes Service and Selectors.

1. The Core Blue/Green Concept

Blue/Green deployment mitigates deployment risk by running two identical, production-ready environments:

Blue Environment: The current, stable, live version serving user traffic.
Green Environment: The new version of the application, deployed alongside the Blue environment.
The fundamental principle is to deploy the new Green version and fully validate it before it receives any user traffic. This approach minimizes user impact and provides an instant rollback path.

In Kubernetes, this pattern is achieved by strategically managing Deployments and a single Service.

2. The initial State

Let’s look at a simplified YAML for our Production Service, demonstrating how the selector field dictates which pods receive traffic.

production-service.yaml ( pointing to blue deployment)

1
2
3
4
5
6
7
8
9
10
11
12
13
# production-service.yaml (Initial State: Directing traffic to 'blue' pods)
apiVersion: v1
kind: Service
metadata:
  name: my-app-production-service
spec:
  selector:
    app: blue # Initially points to the blue deployment
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

Here all traffic is always directed to the deployment with app: blue selector.

3. The Traffic Switch:

The switch is a single, atomic operation i.e. updating the Production Service’s selector from app: blue to app: green.

This instantaneous change redirects all incoming traffic to the new Green pods, achieving a seamless zero-downtime transition. The old Blue environment is retained as a hot standby for immediate rollback if necessary.

Become a member
​Here’s how the production-service.yaml would look after the switch:

production-service.yaml ( switch to green deployment)

1
2
3
4
5
6
7
8
9
10
11
12
13
# production-service.yaml (Initial State: Directing traffic to 'blue' pods)
apiVersion: v1
kind: Service
metadata:
  name: my-app-production-service
spec:
  selector:
    app: green # Switch to green deployment
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

A simple kubectl apply -f production-service.yaml (or equivalent Helm upgrade) is all it takes to perform the traffic cutover.

4. Scaling for Enterprise: The Role of HPA
For enterprise-scale applications, simple replication is insufficient. We must ensure the Green environment is ready to handle full production load immediately upon the switch. This is achieved by linking both environments to a Horizontal Pod Autoscaler (HPA) configured with identical scaling rules.

Enhancement: Ensure both the Blue and Green Deployments are linked to their own identical Horizontal Pod Autoscaler (HPA) resource.
Benefit: The Green environment will automatically scale out to the required production replica count, matching the Blue environment’s capacity, before the traffic switch, preventing sudden capacity bottlenecks.

5. Streamlining Automation with Helm Charts
Managing these multiple, yet identical, components (Deployment, HPA, PodDisruptionBudget, etc.) for both Blue and Green environments can become complex. Helm provides the necessary structure to manage this complexity efficiently.

A robust Helm structure for enterprise Blue/Green automation can utilize three primary subcharts:

Recommended Helm Subchart Structure

common Subchart

Purpose: Houses shared, stable resources that do not change during the switch.
Resources Managed: Production Service, Test Service, Ingress resources.

blue Subchart

Purpose: Manages the current live environment’s application stack.
Resources Managed: Blue Deployment, Blue HPA.

green Subchart

Purpose: Manages the new candidate environment’s application stack.
Resources Managed: Green Deployment, Green HPA.

This structure allows the automation pipeline to deploy the Green subchart, test it via the Test Service, and then update the selector in the common Service template, completing the deployment cycle.

By isolating the new version from live traffic until the final, atomic service switch, we virtually eliminate the risk of failure, ensuring that every feature reaches our end-users with the highest level of confidence. Embracing this automation is the clearest path to achieving true operational excellence in a containerized world.

#Azure #kubernetes