Skip to content

Commit 0b60fe1

Browse files
anveshmuppedaanveshmuppeda
authored
Merge pull request #154 from anveshmuppeda/main
Syn feature
2 parents 1889c73 + da4f504 commit 0b60fe1

17 files changed

+702
-170
lines changed

‎docs/deployment-strategies/blue-green.md‎

Lines changed: 245 additions & 58 deletions
Original file line numberDiff line numberDiff line change
@@ -5,62 +5,249 @@ sidebar_id: "blue-green"
55
sidebar_position: 1
66
---
77

8-
# Blue-Green Deployment Strategy
8+
# ⎈ Blue-Green Deployment in Kubernetes 🟦🟩
9+
10+
#### *⇢ A Hands-On Example with Deployment and Service Manifests*
11+
12+
<img src="./img/blue-green-deployment.png.webp">
13+
14+
15+
#### Introduction:
16+
In the fast-paced world of software development, deploying updates and new features while maintaining uptime and minimizing risks is crucial. Blue-Green Deployment is a strategy that helps achieve this by reducing downtime and risk during deployments. In this guide, we’ll explore what Blue-Green Deployment is, its benefits, how it works, and a practical example using Kubernetes.
17+
#### What is Blue-Green Deployment?
18+
Blue-Green Deployment is a technique used to release software updates with minimal downtime and risk. In this approach, two identical environments, typically referred to as “blue” and “green,” are set up: one represents the currently live production environment (blue), while the other is a clone where the new version is deployed (green). Once the new version in the green environment is tested and ready, traffic is switched from blue to green, making the green environment the new production environment.
19+
20+
<img src="./img/blue-green-deployment-flowchart.png.webp">
21+
22+
### Benefits of Blue-Green Deployment:
23+
**Zero Downtime:** By having two identical environments, you can switch traffic seamlessly from one environment to another without any downtime.
24+
**Risk Mitigation:** Since the new version is deployed in an isolated environment, any issues can be identified and resolved before directing traffic to it.
25+
**Rollback Capability:** If any issues arise after switching traffic to the green environment, you can quickly rollback by redirecting traffic back to the blue environment.
26+
27+
### How Blue-Green Deployment Works:
28+
**1. Set Up Environments:** Create two identical environments, typically labeled blue and green, using Kubernetes clusters.
29+
**2. Deploy New Version:** Deploy the new version of your application to the green environment.
30+
**3. Testing:** Conduct thorough testing in the green environment to ensure the new version functions as expected and meets quality standards.
31+
**4. Switch Traffic:** Once testing is successful, reroute traffic from the blue environment to the green environment using load balancers or DNS changes.
32+
**5. Monitoring:** Monitor the green environment closely to detect any issues that may arise after the switch.
33+
**6. Rollback (if necessary):** If any issues occur post-deployment, quickly rollback by switching traffic back to the blue environment.
34+
<img src="./img/blue-green-deployment-animated-flowchart.png.gif">
35+
36+
### Real-Time Example:
37+
Let’s demonstrate Blue-Green Deployment with a practical example using Kubernetes. Consider a simple web application which display the pod name(so that it easy to test the traffic from where it is getting the response) with version 1.0. We’ll update it to version 2.0 using Blue-Green Deployment.
38+
39+
### 1. Setup Environments
40+
***1.1 Deploy Blue Application (Version 1.0)***
41+
Use the below manifest file as Blue Deployment and save it as **blue-deployment.yaml:**
42+
```yaml
43+
apiVersion: apps/v1
44+
kind: Deployment
45+
metadata:
46+
name: blue-deploy
47+
labels:
48+
app: echo-application
49+
env: blue
50+
version: v1.0.0
51+
spec:
52+
replicas: 3
53+
selector:
54+
matchLabels:
55+
app: echo-application
56+
env: blue
57+
template:
58+
metadata:
59+
labels:
60+
app: echo-application
61+
env: blue
62+
version: v1.0.0
63+
spec:
64+
containers:
65+
- name: echoapp
66+
image: anvesh35/echo-pod-name:v1.0.0
67+
ports:
68+
- containerPort: 80
69+
```
70+
***Apply the above blue-deployment.yaml (deployment) manifest to deploy version 1.0.0 of the echo application using the below command:***
71+
```yaml
72+
kubectl apply -f blue-deployment.yaml
73+
```
74+
75+
#### 1.2 Deploy Green Application (Version 1.0)
76+
Use the below manifest file as Green Deployment and save it as **green-deployment.yaml:**
77+
78+
```yaml
79+
80+
apiVersion: apps/v1
81+
kind: Deployment
82+
metadata:
83+
name: green-deploy
84+
labels:
85+
app: echo-application
86+
env: green
87+
version: v1.0.0
88+
spec:
89+
replicas: 3
90+
selector:
91+
matchLabels:
92+
app: echo-application
93+
env: green
94+
template:
95+
metadata:
96+
labels:
97+
app: echo-application
98+
env: green
99+
version: v1.0.0
100+
spec:
101+
containers:
102+
- name: echoapp
103+
image: anvesh35/echo-pod-name:v1.0.0
104+
ports:
105+
- containerPort: 80
106+
```
107+
108+
***Apply the above green-deployment.yaml (deployment) manifest to deploy version 1.0.0 of the echo application using the below command:***
109+
```yaml
110+
kubectl apply -f green-deployment.yaml
111+
```
112+
#### 1.3 Deploy Service
113+
Use the below manifest file for service t route traffic between blue and green deployments and save it as ***svc-manifest.yaml:***
114+
```yaml
115+
116+
apiVersion: v1
117+
kind: Service
118+
metadata:
119+
name: echoapp-svc
120+
spec:
121+
selector:
122+
app: echo-application
123+
env: blue
124+
ports:
125+
- name: http
126+
port: 80
127+
targetPort: 80
128+
type: NodePort
129+
```
130+
The above service manifest will route the traffic to blue application since we are using selector as env: blue. Apply the above svc-manifest.yaml (service) manifest to deploy service for above echo application using the below command:
131+
```yaml
132+
kubectl apply -f svc-manifest.yaml
133+
```
134+
Using the above steps we have deployed identical applications (blue and green deployments) and created a service which routes the traffic to the Blue deployment.
135+
136+
```yaml
137+
$ kubectl get all
138+
NAME READY STATUS RESTARTS AGE
139+
pod/blue-deploy-6764f5b964-lzkwj 1/1 Running 0 15m
140+
pod/blue-deploy-6764f5b964-wn5bt 1/1 Running 0 15m
141+
pod/blue-deploy-6764f5b964-xmk4d 1/1 Running 0 15m
142+
pod/green-deploy-6c976bd585-5wzfs 1/1 Running 0 15m
143+
pod/green-deploy-6c976bd585-7k7p6 1/1 Running 0 15m
144+
pod/green-deploy-6c976bd585-ztlkw 1/1 Running 0 15m
145+
146+
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
147+
service/echoapp-svc NodePort 10.225.214.77 <none> 80:32266/TCP 15m
148+
149+
NAME READY UP-TO-DATE AVAILABLE AGE
150+
deployment.apps/blue-deploy 3/3 3 3 15m
151+
deployment.apps/green-deploy 3/3 3 3 15m
152+
153+
NAME DESIRED CURRENT READY AGE
154+
replicaset.apps/blue-deploy-6764f5b964 3 3 3 15m
155+
replicaset.apps/green-deploy-6c976bd585 3 3 3 15m
156+
```
157+
Let’s try to access the application to verify the traffic and functionality.
158+
#### Testing-blue-application
159+
<img src="./img/testing-blue-applications.webp">
160+
161+
Or we can use the below curl command to test the traffic:
162+
```yaml
163+
$ for i in $(seq 1 10); do curl <app-url>; done | grep -o '<span id='\'podName\''>[^<]*' | sed 's/<[^>]*>//g'
164+
```
165+
```yaml
166+
$ for i in $(seq 1 10); do curl 146.190.533.230:32266; done | grep -o '<span id='\'podName\''>[^<]*' | sed 's/<[^>]*>//g'
167+
blue-deploy-6764f5b964-wn5bt
168+
blue-deploy-6764f5b964-xmk4d
169+
blue-deploy-6764f5b964-lzkwj
170+
blue-deploy-6764f5b964-lzkwj
171+
blue-deploy-6764f5b964-wn5bt
172+
blue-deploy-6764f5b964-lzkwj
173+
blue-deploy-6764f5b964-wn5bt
174+
blue-deploy-6764f5b964-wn5bt
175+
blue-deploy-6764f5b964-wn5bt
176+
blue-deploy-6764f5b964-lzkwj
177+
```
178+
Using the above steps we have successfully configured the two identical environments(**Blue** & **Green**).
179+
180+
### 2. Deploy New Version
181+
***2.1 Update the Green deployment version***
182+
To deploy the new version (v2.0.0) of your application to the green environment, update the image for the green deployment to anvesh35/echo-pod-name:v2.0.0 (in green-deployment.yaml). This change will upgrade the version of the application running in the green environment.
183+
Apply the changes by executing the following command:
184+
185+
```yaml
186+
kubectl apply -f green-deployment.yaml
187+
```
188+
### 3. Switch Traffic:
189+
***3.1 Update the Service to Point Green deployment***
190+
Update the service to route traffic to the green deployment by changing the selector field to env: green. This ensures that traffic is directed to the green deployment, which now hosts the newer version.
191+
After updating the selector field to env: green in svc-manifest.yaml apply the manifest file using the following command:
192+
193+
```yaml
194+
kubectl apply -f svc-manifest.yaml
195+
```
196+
These changes will upgrade the green environment to the newer version (**v2.0.0**) compared to the blue environment (**v1.0.0**) and update the service to route traffic to the **Green environment** from the **Blue environment**.
197+
198+
### 4. Test & Monitor the New Version
199+
With the newer version successfully deployed in the green environment and traffic routed from the blue environment, it’s time to test and monitor the new version.
200+
Access the service endpoint to observe the behavior of the green deployment. In our scenario, the service endpoint prints the pod name of the environment, so it should now display the pod name of the green deployment.
201+
#### Testing-green-application
202+
<img src="./img/testing-green-application.png.webp">
203+
204+
Or using curl command:
205+
206+
```yaml
207+
$ for i in $(seq 1 10); do curl 146.190.55.220:32266; done | grep -o '<span id='\'podName\''>[^<]*' | sed 's/<[^>]*>//g'
208+
green-deploy-6c976bd585-7k7p6
209+
green-deploy-6c976bd585-7k7p6
210+
green-deploy-6c976bd585-5wzfs
211+
green-deploy-6c976bd585-7k7p6
212+
green-deploy-6c976bd585-5wzfs
213+
green-deploy-6c976bd585-7k7p6
214+
green-deploy-6c976bd585-7k7p6
215+
green-deploy-6c976bd585-ztlkw
216+
green-deploy-6c976bd585-ztlkw
217+
green-deploy-6c976bd585-5wzfs
218+
```
219+
Now, the traffic is being routed to the new version (v2.0.0) from the Green Environment.
220+
221+
### 5. Rollback
222+
By following the above steps, we have successfully upgraded the application in the green environment and redirected the traffic from the blue environment to the green environment. In case we encounter any issues, bugs, or unexpected behavior with the new version, we can quickly rollback to the older version (v1.0.0) which is still available in the blue environment. To do this, simply update the selectors in the service manifest file to app: blue and apply the changes. This will effectively route the traffic from the newer version(v2.0.0 from Green environment) to the older version (v1.0.0 from Blue environment).
223+
Once the svc-manifest.yaml files is updated with app: blue then apply the new changes using the below command:
224+
225+
```yaml
226+
kubectl apply -f svc-manifest.yaml
227+
```
228+
229+
Once the service is routed to older version(v1.0.0 from Blue environment) then verify the traffic status:
230+
231+
#### Rollout-older-version
232+
<img src="./img/rollout-older-version.png.webp">
233+
234+
235+
236+
curl command output:
237+
238+
```yaml
239+
$ for i in $(seq 1 10); do curl 146.190.55.220:32266; done | grep -o '<span id='\'podName\''>[^<]*' | sed 's/<[^>]*>//g'
240+
blue-deploy-6764f5b964-xmk4d
241+
blue-deploy-6764f5b964-wn5bt
242+
blue-deploy-6764f5b964-wn5bt
243+
blue-deploy-6764f5b964-xmk4d
244+
blue-deploy-6764f5b964-xmk4d
245+
blue-deploy-6764f5b964-lzkwj
246+
blue-deploy-6764f5b964-xmk4d
247+
blue-deploy-6764f5b964-lzkwj
248+
blue-deploy-6764f5b964-lzkwj
249+
blue-deploy-6764f5b964-wn5bt
250+
```
251+
### Conclusion:
252+
**Blue-Green** Deployment is a powerful strategy for deploying software updates with minimal downtime and risk. By setting up identical environments and switching traffic seamlessly, teams can release updates confidently while maintaining high availability. In Kubernetes, Blue-Green Deployment can be achieved effectively using namespaces and service routing. Incorporating Blue-Green Deployment into your deployment strategy can significantly improve your release process.
9253

10-
Blue-Green Deployment is a deployment strategy that minimizes downtime and risk by running two environments, one active (Blue) and one idle (Green). This document provides an overview of the Blue-Green Deployment strategy, its benefits, and how to implement it in Kubernetes.
11-
12-
---
13-
14-
<div style={{ backgroundColor: '#f9f9f9', borderLeft: '4px solid #0078d4', padding: '1rem', margin: '1rem 0', borderRadius: '5px' }}>
15-
<h2 style={{ marginTop: 0 }}>🚧 Work in Progress</h2>
16-
<p>This page is currently under construction. Please check back later for detailed information about Blue-Green Deployment in Kubernetes.</p>
17-
</div>
18-
19-
---
20-
21-
## Table of Contents
22-
- [Introduction](#introduction)
23-
- [How It Works](#how-it-works)
24-
- [Benefits](#benefits)
25-
- [Implementation in Kubernetes](#implementation-in-kubernetes)
26-
- [Best Practices](#best-practices)
27-
28-
---
29-
30-
## Introduction
31-
Blue-Green Deployment is a strategy that allows you to deploy new versions of an application with minimal downtime. It involves maintaining two separate environments:
32-
- **Blue Environment**: The currently active environment serving live traffic.
33-
- **Green Environment**: The new environment where the updated application is deployed.
34-
35-
Once the Green environment is verified, traffic is switched from Blue to Green.
36-
37-
---
38-
39-
## How It Works
40-
1. Deploy the new version of the application to the Green environment.
41-
2. Test the Green environment to ensure it is functioning correctly.
42-
3. Switch traffic from the Blue environment to the Green environment.
43-
4. Optionally, keep the Blue environment as a fallback in case of issues.
44-
45-
---
46-
47-
## Benefits
48-
- **Minimal Downtime**: Traffic is switched instantly, reducing downtime.
49-
- **Rollback Capability**: The Blue environment can be used as a fallback if issues arise.
50-
- **Testing in Isolation**: The Green environment can be tested without affecting live traffic.
51-
52-
---
53-
54-
## Implementation in Kubernetes
55-
> **Note:** Detailed steps for implementing Blue-Green Deployment in Kubernetes will be added soon.
56-
57-
---
58-
59-
## Best Practices
60-
- Use a **load balancer** or **Ingress controller** to manage traffic switching.
61-
- Automate the deployment and traffic switching process using CI/CD pipelines.
62-
- Monitor both environments during and after the deployment.
63-
64-
---
65-
66-
Stay tuned for updates as we continue to enhance this guide!

0 commit comments

Comments
 (0)