Master Kubernetes Deployment Strategies: Blue‑Green, Canary, and Rolling Updates

Introduction

The article introduces three common Kubernetes release strategies—blue‑green deployment, canary (gray) release, and rolling update—explaining their purpose, workflow, and when to use each method.

Deployment Overview

Canary release starts with a small fraction of traffic (e.g., 1 pod or 2% of servers) to validate the new version before a full rollout. If monitoring shows the canary is healthy, the rest of the pods are upgraded; otherwise the canary is rolled back.

Rolling update improves on canary by automating the process in multiple batches. Each batch size can be configured (e.g., 1 pod, 10%, 50%, 100%). After each batch, the system waits for health checks before proceeding, resulting in a smooth, low‑risk upgrade.

Blue‑green deployment runs a new version (green) alongside the current version (blue) and switches the service routing to the green version once testing is complete, achieving zero‑downtime upgrades.

Deployment Definition and kubectl Explain

Deployments use ReplicaSet to manage pod updates. Key fields can be inspected with: kubectl explain deploy Relevant sections of the output include apiVersion, kind, metadata, spec, and status. The spec.strategy field defines the update strategy, supporting Recreate and RollingUpdate types. kubectl explain deploy.spec.strategy For RollingUpdate, the maxSurge and maxUnavailable parameters control how many extra pods may be created and how many pods may be unavailable during the rollout.

Creating a Deployment

Example YAML ( deploy-demo.yaml) creates a Deployment with three replicas:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
  namespace: test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      release: canary
  template:
    metadata:
      labels:
        app: myapp
        release: canary
    spec:
      containers:
      - name: myapp
        image: myapp:v1
        ports:
        - name: http
          containerPort: 80

Apply the manifest: kubectl apply -f deploy-demo.yaml Verify the resources:

kubectl get deploy -n test
kubectl get rs -n test
kubectl get pods -n test

Images show the created Deployment, its ReplicaSet (hash‑named), and the running Pods.

Canary Release Example

Monitor pods: kubectl get pods -l app=myapp -n test -w Update the image and pause the rollout:

kubectl set image deployment myapp-deploy myapp=myapp:v2 -n test && \
kubectl rollout pause deployment myapp-deploy -n test

After a successful observation period, resume the rollout:

kubectl rollout resume deployment myapp-deploy -n test

Rollback can be performed with:

kubectl rollout undo deployment myapp-deploy -n test

Command output demonstrates pod replacement and ReplicaSet history.

Rolling Update Example

Change the image version in deploy-demo.yaml (e.g., myapp:v3) and re‑apply: kubectl apply -f deploy-demo.yaml Observe the rolling process: new pods appear in Pending → ContainerCreating → Running states while old pods transition to Terminating. The ReplicaSet count shows both old and new sets during the upgrade.

Scale the Deployment to five replicas by editing replicas: 5 and applying again. Verify the increased pod count.

Adjust the rolling‑update strategy to limit disruption:

kubectl patch deployment myapp-deploy -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}' -n test

Describe the Deployment to see the updated RollingUpdateStrategy: 0 max unavailable, 1 max surge, confirming that with five replicas the system will never drop below five running pods and will never exceed six.

Blue‑Green Deployment Example

Two Deployment manifests are prepared: lan.yaml (v1, blue) and lv.yaml (v2, green). Each defines the same app label but different version labels.

# lan.yaml (v1)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v1
  namespace: blue-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: v1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v1
        ports:
        - containerPort: 80

# lv.yaml (v2)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v2
  namespace: blue-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: v2
  template:
    metadata:
      labels:
        app: myapp
        version: v2
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v2
        ports:
        - containerPort: 80

Apply both Deployments and a Service that initially selects the blue version:

kubectl apply -f lan.yaml
kubectl apply -f lv.yaml
kubectl apply -f service_lanlv.yaml

Both sets of Pods run simultaneously. Switching traffic to the green version is done by updating the Service selector to version: v2 (via service_lv.yaml) and re‑applying.

# service_lv.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp-lan
  namespace: blue-green
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30062
    name: http
  selector:
    app: myapp
    version: v2

After applying the new Service, the external endpoint serves the green deployment without downtime.

Conclusion

The article provides a practical, hands‑on overview of Kubernetes release strategies, showing how to inspect Deployment specifications, create and modify manifests, control rollout behavior with maxSurge and maxUnavailable, and perform canary, rolling, and blue‑green upgrades using standard kubectl commands.