Skip to content

Kubernetes Blue/Green Deployment with Service Selector Switching

Kubernetes Blue/Green Deployment with Service Selector Switching is an implementation of the blue/green deployment strategy that uses label selectors on a Kubernetes [[Service]] to control traffic routing between two identical environments.^[400-devops__06-Kubernetes__k8s-ithelp__Day14__README.md]

Core Concept

This strategy achieves zero-downtime deployment by maintaining two separate production environments: "Blue" (the current version) and "Green" (the new version).^[400-devops__06-Kubernetes__k8s-ithelp__Day14__README.md] The critical characteristic of this method is that the switch between versions is effectively instantaneous, occurring at the moment the traffic routing configuration changes, rather than during a gradual rollout of instances.^[400-devops__06-Kubernetes__k8s-ithelp__Day14__README.md]

A significant operational consideration is that the system must have enough resources to run both the old and new versions simultaneously for a short period, effectively doubling the resource load during the update window.^[400-devops__06-Kubernetes__k8s-ithelp__Day14__README.md]

Implementation Workflow

In Kubernetes, this pattern is typically implemented using a single Service resource that dynamically updates its selector field to point to different sets of Pods.^[400-devops__06-Kubernetes__k8s-ithelp__Day14__README.md] The general process involves four steps^[400-devops__06-Kubernetes__k8s-ithelp__Day14__README.md]:

  1. Deploy Version 1 (Blue): A [[Deployment]] creates Pods with specific labels (e.g., version: v1). The Service's selector targets these labels, directing all live traffic to Version 1.
  2. Deploy Version 2 (Green): A separate Deployment creates Pods for the new version (e.g., version: v2). These are fully started and verified while the Service still points to Version 1. At this stage, both versions exist simultaneously in the cluster.
  3. Switch Traffic: The Service's configuration is updated so its selector points to the labels associated with Version 2. This immediately shifts all external traffic to the new environment.
  4. Cleanup: After verifying the stability of Version 2, the resources for Version 1 are decommissioned.

Example Configuration

The defining characteristic of this method in Kubernetes is the manipulation of the Service definition:

apiVersion: v1
kind: Service
metadata:
  name: blue-green-service
spec:
  selector:
    app: my-app
    version: v1  # Initially points to V1
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

To trigger the deployment, the version value in the selector block is updated to v2, effectively routing traffic to the pods labeled with the new version^[400-devops__06-Kubernetes__k8s-ithelp__Day14__README.md].

Sources

  • 400-devops__06-Kubernetes__k8s-ithelp__Day14__README.md