Blue/Green Deployments on AKS: Zero-Downtime Execution

To maintain maximum availability and continuous value delivery, enterprise applications must support zero-downtime deployments. A Blue/Green Deployment model accomplishes this by running two identical physical production environments—only one of which is active at any given time.

This guide outlines the architectural design, ingress-level traffic routing configurations, and database synchronization strategies required to run blue/green deployments successfully on Azure Kubernetes Service (AKS).

---

1. Architectural Traffic Switch

In a Kubernetes environment, the swap is executed at the Ingress controller or Service routing layer rather than by rebuilding or updating pods inside an active namespace.

---

2. Ingress Traffic Routing Switch

To perform the switch, we update the selectors in the Service manifests or modify the target service in our Ingress resource. Below is the configuration standard using an Nginx Ingress Controller.

2.1 Service Definitions

We maintain separate deployments and services for both Blue and Green pods.

apiVersion: v1
kind: Service
metadata:
  name: qe-app-blue
  namespace: qe-prod
spec:
  ports:
    - port: 80
      targetPort: 3000
  selector:
    app: qe-app
    version: v1 # Points to Blue deployment
---
apiVersion: v1
kind: Service
metadata:
  name: qe-app-green
  namespace: qe-prod
spec:
  ports:
    - port: 80
      targetPort: 3000
  selector:
    app: qe-app
    version: v2 # Points to Green deployment

2.2 Ingress Swap Manifest

When promoting Green to active production, the Ingress resource is modified to repoint the backend service target.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: qe-app-ingress
  namespace: qe-prod
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
    - host: portal.qestrategy.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: qe-app-green # Swap from qe-app-blue to qe-app-green
                port:
                  number: 80

---

3. The Data Tier: Expand-Contract Pattern

A primary challenge of Blue/Green deployment is database schema compatibility. If the database schema is updated, the active "Blue" (v1) and standby "Green" (v2) environments must both be able to read and write to the database simultaneously during the transition phase.

We solve this using the Expand-Contract Pattern:

1. Expand (Phase 1): Apply database schema changes that are additive only (e.g., adding a new column that is nullable, or creating a new table). Do not remove or rename old columns.
2. Deploy (Phase 2): Deploy the Green (v2) pods. Since the database schema changes were additive, both Blue (v1) and Green (v2) run smoothly.
3. Swap (Phase 3): Shift the Ingress traffic routing to Green (v2).
4. Contract (Phase 4): Once Green has run stably in production and the rollback window is closed, execute a final database script to clean up old, unused tables and columns.

---

4. Gated Validation & Rollback

4.1 Gated Automation Checks

Before switching the Ingress backend:

• Execute E2E Playwright verification tests against the standby Service endpoint (e.g., http://qe-app-green.qe-prod.svc.cluster.local) to ensure the build is fully operational in the production cluster environment.
• Once E2E checks pass, trigger the traffic swap.

4.2 Instantaneous Rollback

If metrics degrade immediately after the switch:

1. Repoint the Ingress backend service target back to qe-app-blue.
2. Apply the Ingress manifest.
3. All traffic is redirected back to the stable Blue pods in milliseconds without requiring pod recreation or code redeployments.