滚动更新 (Rolling Update):
滚动更新是 Kubernetes 内置的更新策略。它通过逐步替换旧版本的 Pod 为新版本的 Pod，确保在任何时刻都有一定数量的 Pod 在服务，以避免服务中断。
可以通过 kubectl set image 或在 Deployment 中设置 strategy 为 RollingUpdate 来实现。
1
2
3
4
5
| strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
|
金丝雀发布 (Canary Release):
金丝雀发布是一种将新版本发布到一小部分用户以进行测试的方法。可以通过创建一个新的 Deployment 或 ReplicaSet，并使用服务路由将部分流量导向新版本的 Pod。
常与服务网格 (如 Istio) 或反向代理 (如 NGINX) 结合使用，以实现更精细的流量控制。
创建两个 Deployment
一个用于旧版本，一个用于新版本。
用同一个services
用Istio设置权重
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-service
spec:
hosts:
- "my-service"
http:
- route:
- destination:
host: my-service
subset: v1
weight: 80
- destination:
host: my-service
subset: v2
weight: 20
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: my-service
spec:
host: my-service
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
|
蓝绿部署
蓝绿部署是通过保持两个独立的环境（蓝环境和绿环境），将新版本部署到其中一个环境（如绿环境），然后通过切换流量来实现新版本的发布。
这种方法可以快速切换版本，并在必要时回滚到旧版本（如蓝环境）。
创建两个 Deployment
一个用于蓝环境（旧版本），一个用于绿环境（新版本）。
用service的selector切换流量
1
2
3
4
5
6
7
8
9
10
11
| apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-deployment-green
ports:
- protocol: TCP
port: 80
targetPort: 8080
|
A/B 测试
A/B 测试与金丝雀发布类似，但更关注于用户行为和数据分析。通过将用户分为不同组，分别体验不同版本，从而比较新旧版本的效果。
通常结合 Istio 或其他服务网格来实现流量分配和数据收集。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-service
spec:
hosts:
- "my-service"
http:
- match:
- headers:
end-user:
exact: "user1"
route:
- destination:
host: my-service
subset: v2
- route:
- destination:
host: my-service
subset: v1
|