Blue-green deployments in Kubernetes - Step-by-Step Execution

Process Flow - Blue-green deployments

Deploy Blue Version

↓

Test Blue Version

↓

Switch Traffic to Blue

↓

Deploy Green Version

↓

Test Green Version

↓

Switch Traffic to Green

↓

Retire Blue Version

Blue-green deployment switches traffic between two identical environments to reduce downtime and risk.

Execution Sample

Kubernetes

kubectl apply -f blue-deployment.yaml
kubectl apply -f green-deployment.yaml
kubectl patch service myapp -p '{"spec":{"selector":{"version":"green"}}}'

Deploy blue and green versions, then switch service traffic from blue to green.

Process Table

Step	Action	Kubernetes Resource	State Change	Result
1	Apply blue deployment	Deployment blue	Pods created with label version=blue	Blue version running
2	Apply green deployment	Deployment green	Pods created with label version=green	Green version running alongside blue
3	Service selector points to blue	Service myapp	Selector set to version=blue	Traffic routed to blue pods
4	Patch service to green	Service myapp	Selector changed to version=green	Traffic switched to green pods
5	Monitor green deployment	Pods green	Check pod health and logs	Green version stable
6	Delete blue deployment	Deployment blue	Pods terminated	Blue version retired

💡 Blue version retired after traffic successfully switched to green

Status Tracker

Resource	Initial State	After Step 1	After Step 2	After Step 4	Final
Deployment blue	Not present	Running pods with version=blue	Running pods with version=blue	Running pods with version=blue	Deleted
Deployment green	Not present	Not present	Running pods with version=green	Running pods with version=green	Running pods with version=green
Service myapp selector	None	version=blue	version=blue	version=green	version=green

Key Moments - 3 Insights

Why do we keep both blue and green deployments running at the same time?

Both versions run simultaneously to allow testing the new version (green) without affecting live traffic, as shown in steps 2 and 3 in the execution table.

What happens if the green deployment has issues after switching traffic?

You can quickly switch back the service selector to blue version to restore traffic, because blue pods are still running until step 6.

Why do we patch the service selector instead of redeploying the service?

Patching the selector changes traffic routing instantly without downtime, as seen in step 4, making the switch smooth and fast.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the service start routing traffic to the green deployment?

A Step 4

B Step 2

C Step 3

D Step 6

💡 Hint

Check the 'Service myapp' resource state changes in the execution table rows.

According to the variable tracker, what is the state of the blue deployment after step 4?

A Not present

B Running pods with version=blue

C Deleted

D Pods terminating

💡 Hint

Look at the 'Deployment blue' row under 'After Step 4' in the variable tracker.

If the service selector was patched back to version=blue after step 4, what would happen to traffic routing?

A Traffic would stop completely

B Traffic would route to both blue and green pods

C Traffic would route to blue pods again

D Traffic would route to green pods only

💡 Hint

Refer to how the service selector controls traffic routing in the execution table and variable tracker.

Concept Snapshot

Blue-green deployments use two identical environments: blue (current) and green (new).
Deploy new version to green while blue serves live traffic.
Switch service selector to green to route traffic instantly.
Keep blue running until green is stable, then retire blue.
This reduces downtime and risk during updates.

Full Transcript

Blue-green deployment is a method to update applications with minimal downtime. First, the blue version is deployed and serves live traffic. Then, the green version is deployed alongside blue. The service selector initially routes traffic to blue pods. When green is ready and tested, the service selector is patched to route traffic to green pods instantly. Blue pods remain running until green is stable, allowing quick rollback if needed. Finally, blue pods are deleted to complete the switch. This process ensures smooth updates by switching traffic between two identical environments.

Practice

1. What is the main purpose of a blue-green deployment in Kubernetes?

easy

A. To update applications without downtime by switching traffic between two versions

B. To create multiple replicas of a pod for load balancing

C. To automatically scale pods based on CPU usage

D. To backup data from one cluster to another

Solution

1. Step 1: Understand blue-green deployment concept

   Blue-green deployment runs two versions of an app side by side to avoid downtime.

2. Step 2: Identify the main goal

   The main goal is to switch user traffic smoothly from the old version (blue) to the new version (green).

3. Final Answer:

   To update applications without downtime by switching traffic between two versions -> Option A

4. Quick Check:

   Blue-green deployment = zero downtime updates [OK]

Hint: Blue-green means two versions, switch traffic smoothly [OK]

Common Mistakes:

• Confusing blue-green with scaling pods
• Thinking it is for backups
• Mixing it with auto-scaling

2. Which Kubernetes resource is typically used to switch traffic between blue and green deployments?

easy

A. ConfigMap

B. PersistentVolume

C. Service

D. Ingress Controller

Solution

1. Step 1: Identify traffic routing resource

   In Kubernetes, a Service routes traffic to pods based on labels.

2. Step 2: Understand blue-green switching

   Switching traffic between blue and green versions is done by changing the Service selector to point to the desired pods.

3. Final Answer:

   Service -> Option C

4. Quick Check:

   Service routes traffic in blue-green deployments [OK]

Hint: Service controls traffic routing between versions [OK]

Common Mistakes:

• Choosing ConfigMap which stores config data
• Selecting PersistentVolume which manages storage
• Picking Ingress Controller which manages external access

3. Given the following Kubernetes Service selector for blue deployment:

selector:
  app: myapp
  version: blue

What happens if you change the selector to version: green?

medium

A. Traffic will be split evenly between blue and green pods

B. Traffic will be routed to pods labeled with version green

C. Traffic will stop because selector is invalid

D. Pods with version blue will receive traffic

Solution

1. Step 1: Understand Service selector role

   The Service selector chooses pods matching the labels to send traffic to.

2. Step 2: Effect of changing selector

   Changing selector to version: green directs traffic only to pods labeled green, ignoring blue pods.

3. Final Answer:

   Traffic will be routed to pods labeled with version green -> Option B

4. Quick Check:

   Selector change = traffic to matching pods [OK]

Hint: Service selector controls which pods get traffic [OK]

Common Mistakes:

• Assuming traffic splits automatically
• Thinking selector change breaks traffic
• Believing old pods still get traffic

4. You deployed a green version but users still see the blue version. What is the most likely cause?

medium

A. The Service selector was not updated to point to green pods

B. The green pods failed to start due to image pull error

C. The Deployment was deleted accidentally

D. The cluster is out of CPU resources

Solution

1. Step 1: Check traffic routing setup

   If users still see blue, traffic is likely still routed to blue pods.

2. Step 2: Identify cause of routing

   This happens if the Service selector was not updated to green pods after deploying green version.

3. Final Answer:

   The Service selector was not updated to point to green pods -> Option A

4. Quick Check:

   Service selector update needed to switch traffic [OK]

Hint: Update Service selector to switch traffic [OK]

Common Mistakes:

• Assuming pods failed without checking
• Thinking Deployment deletion causes this
• Blaming cluster resource issues first

5. You want to perform a blue-green deployment with zero downtime. You have:

• Blue pods running version 1
• Green pods running version 2

Which sequence of steps ensures a safe switch?

hard

A. Update Deployment to green version, wait for rollout, then update Service selector

B. Delete blue pods first, then update Service selector to green pods

C. Scale down blue pods to zero, then create green pods and update Service selector

D. Update Service selector to green pods, then delete blue pods after confirming green is healthy

Solution

1. Step 1: Switch traffic safely

   First, update the Service selector to point to green pods so new traffic goes to version 2.

2. Step 2: Confirm green pods are healthy

   Check green pods are running well before removing blue pods to avoid downtime.

3. Step 3: Remove old version

   After confirmation, delete blue pods to free resources.

4. Final Answer:

   Update Service selector to green pods, then delete blue pods after confirming green is healthy -> Option D

5. Quick Check:

   Switch traffic first, confirm health, then remove old [OK]

Hint: Switch traffic first, confirm green healthy, then remove blue [OK]

Common Mistakes:

• Deleting blue pods before switching traffic
• Not confirming green pods health
• Updating Deployment without switching Service selector