Blue-green deployments in Kubernetes - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a blue-green deployment?

A blue-green deployment is a method to release software by running two identical environments called 'blue' and 'green'. One serves live traffic while the other is updated. After testing, traffic switches to the updated environment, reducing downtime and risk.

beginner

Why use blue-green deployments in Kubernetes?

Blue-green deployments help avoid downtime and reduce errors by switching traffic between two environments. Kubernetes can manage these environments using services and labels to route traffic smoothly.

intermediate

How does Kubernetes route traffic in a blue-green deployment?

Kubernetes uses Services with selectors that match labels on Pods. By changing the Service's selector from blue to green Pods, traffic shifts instantly without downtime.

intermediate

What is a common risk if blue-green deployments are not done properly?

If traffic is switched before the new environment is fully tested, users may face errors or downtime. Also, keeping both environments can double resource use temporarily.

intermediate

Give a simple example of switching traffic in Kubernetes for blue-green deployment.

You can update the Service selector from 'app: blue' to 'app: green'. For example: kubectl patch service my-service -p '{"spec":{"selector":{"app":"green"}}}'. This moves traffic to green Pods.

What is the main goal of blue-green deployments?

A To delete old versions immediately

B To increase server CPU usage

C To reduce downtime during software updates

D To run two different apps simultaneously

Blue-green deployments aim to reduce downtime by switching traffic between two identical environments.

In Kubernetes, how do you switch traffic from blue to green environment?

A Change the Service selector labels

B Restart all Pods manually

C Delete the blue Pods immediately

D Change the Deployment image only

Changing the Service selector labels routes traffic to the new environment without downtime.

Which Kubernetes object is primarily used to route traffic in blue-green deployments?

A PersistentVolume

B ConfigMap

C Secret

D Service

Services route traffic to Pods based on labels, enabling blue-green deployment traffic switching.

What is a downside of blue-green deployments?

A Temporary increased resource usage

B Permanent downtime

C No way to test new version

D Requires manual code changes

Running two environments at once uses more resources temporarily.

What should you do before switching traffic to the green environment?

A Delete the blue environment

B Test the green environment fully

C Restart the Kubernetes cluster

D Change the Service type to NodePort

Testing ensures the new environment works well before users access it.

Explain how blue-green deployments reduce downtime in Kubernetes.

Think about how traffic moves between two sets of pods.

Describe the steps to perform a blue-green deployment in Kubernetes.

Consider the lifecycle from deployment to cleanup.

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