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.