实现灰度发布与蓝绿发布

2025-06-04 14:09:19

实现灰度发布与蓝绿发布

文章目录

实现灰度发布与蓝绿发布@[toc]一、什么是灰度发布二、什么是蓝绿发布三、Kubernetes的灰度发布和蓝绿发布解决方案四、nginx Ingress的灰度发布和蓝绿发布五、使用nginx Ingress实现灰度发布1.部署两个版本的应用程序2.创建稳定版本Ingress3.创建金丝雀版本Ingress实现灰度发布4.将所有流量从旧版本迁移至新版本

六、使用nginx Ingress实现蓝绿发布

一、什么是灰度发布

灰度发布（又称金丝雀发布或渐进式发布）是一种在软件发布过程中逐步引入新功能或版本的策略，旨在通过分阶段控制流量来降低风险并保障用户体验。其核心原理是：将新版本先部署给一小部分用户（如1%-10%），通过监控性能、收集反馈验证稳定性，若未发现问题则逐步扩大范围，最终完成全量替换。

具体来说，灰度发布的特点包括：

分阶段发布：新版本并非一次性推送给所有用户，而是按地域、用户ID、设备类型等维度逐步扩大覆盖范围。风险控制：若新版本出现严重问题（如BUG），可快速回滚至旧版本，仅影响少量用户，避免大规模故障。实时优化：通过灰度期间的用户反馈和性能数据，持续优化新版本功能，提升产品质量。平滑过渡：新旧版本通常并行运行，支持A/B测试，确保用户无感知切换至新版本。

例如，若需将登录接口从V1升级到V2，灰度发布可能先分配5%的流量到V2，验证无异常后再逐步提升比例，直至完全替代V1。这种策略广泛应用于互联网产品迭代，尤其在高并发或复杂系统中，能有效平衡创新与稳定性需求。

以前矿工在下矿洞前，会先放一只金丝雀进去探一探，通过金丝雀能否活下来来判断是否有有毒气体，金丝雀发布由此得名。

灰度发布，就像“试吃新品” 假设你开了一家奶茶店，想推出一款新口味，但不确定顾客是否喜欢。于是你这么做：

先给10%的顾客免费试喝（比如老顾客或随机选的人）。观察反馈：如果大家说好喝，再慢慢推广给所有人；如果有人说拉肚子，立马停用，换回原来的配方。没问题的话，最后所有顾客都能喝到新口味，而且全程没人因为“试错”而大规模闹肚子。

总结：灰度发布就是“先小范围试试，没问题再铺开”，避免一更新就翻车，让用户不知不觉中过渡到新版本。

二、什么是蓝绿发布

蓝绿发布是一种零停机部署策略，通过同时维护两个独立的生产环境（蓝色和绿色）实现版本更新与快速回滚，确保服务稳定性和连续性。以下是其核心特点：

双环境并行

蓝色环境：当前运行的生产环境，承载实时用户流量。绿色环境：与蓝色环境配置完全相同的备用环境，用于部署新版本。例如，若需升级登录功能，新版本会先在绿色环境中部署并测试，而蓝色环境继续服务用户。流量切换与验证新版本在绿色环境完成测试后，通过负载均衡或路由配置（如Kubernetes的Ingress策略、Istio的VirtualService）将流量从蓝色全量切换至绿色。若新版本异常，可立即切回蓝色环境，实现秒级回滚。优势与适用场景

零停机：用户无感知完成升级。低风险：新版本仅影响绿色环境，问题可控。简化回滚：旧版本保留完整，无需重新部署。适用于金融、电商等对稳定性要求极高的场景。局限性

资源消耗：需双倍硬件资源支持双环境运行。数据一致性：切换时需确保数据库等状态服务同步，可能增加复杂度。

示例：某电商平台使用蓝绿发布升级支付系统。旧版本在蓝色环境运行，新版本部署至绿色环境并通过内部测试后，将用户流量切换至绿色。若支付失败率上升，立即切回蓝色，避免大规模交易故障。

与灰度发布（逐步放量）不同，蓝绿发布是“全有或全无”的切换，适合需要一次性替换全流量的场景。

蓝绿发布，就像“桥梁维修的双车道切换” 假设一座桥有两个完全相同的车道（蓝色车道和绿色车道）：

平时只用蓝色车道：所有车辆都走这里，绿色车道空着备用。维修升级：工程师趁车辆还在蓝色车道通行时，偷偷把绿色车道铺上新路面（部署新版本）。瞬间切换：新路面通过测试后，指挥所有车辆突然改道到绿色车道（流量全切到新版本）。

如果新车道有坑（出BUG），立刻让车辆掉头回蓝色车道（秒级回滚），没人会掉坑里。如果一切正常，蓝色车道暂时闲置，等下次升级时再重复这个过程。

总结：蓝绿发布是“备胎秒换”策略，新旧版本像双胞胎一样随时待命，用户无感知切换，适合要求100%稳定的系统（比如银行转账）。

对比灰度发布：

灰度是“先让10%的人走新路，没问题再慢慢全切”（渐进式）。蓝绿是“所有人突然一起换到新路，不行就集体回头”（全量切换）。

三、Kubernetes的灰度发布和蓝绿发布解决方案

维度灰度发布蓝绿发布核心目标逐步验证新版本稳定性，降低全量风险零停机全量切换，快速回滚流量切换方式渐进式（如5% → 20% → 100%流量逐步迁移）全量切换（0% → 100%流量一次性切换）资源消耗较低（新旧版本共存，但新版本初始副本少）较高（需同时运行两套完整环境，资源翻倍）回滚速度较慢（需逐步减少新版本副本或调整流量规则）秒级回滚（直接切换Service或Ingress指向旧环境）适用场景- 复杂功能验证 - A/B测试 - 长期观察性能指标- 高风险全量替换 - 零停机需求（如支付系统） - 简单版本升级典型工具/实现- 原生Kubernetes（调整Deployment副本） - Istio（流量权重） - Argo Rollouts- Kubernetes Service切换 - Ingress路由调整 - Istio Gateway全量切换优势- 风险分散 - 支持精细化测试（按用户/请求头分流） - 资源利用率高- 回滚极快 - 用户无感知 - 操作简单（切换即完成）劣势- 回滚周期长 - 流量分配逻辑复杂（需工具支持）- 资源占用高 - 无法部分验证（全量切换风险集中） - 数据一致性处理复杂数据兼容性要求高（新旧版本需同时兼容同一数据库/API）中（切换期间需短暂兼容，切换后旧版本可下线）自动化推荐工具- Flagger（自动渐进式发布） - Istio + Prometheus（指标监控回滚）- Spinnaker（蓝绿管道） - Kubernetes原生脚本（快速切换）

四、nginx Ingress的灰度发布和蓝绿发布

以下是Nginx Ingress实现灰度发布和蓝绿发布的核心对比：

灰度发布（Canary）

方法：通过Ingress的Canary注解逐步分流流量。策略：

按权重分流

annotations:

nginx.ingress.kubernetes.io/canary: "true"

nginx.ingress.kubernetes.io/canary-weight: "10" # 10%流量到新版本

按Header/Cookie分流

annotations:

nginx.ingress.kubernetes.io/canary-by-header: "env"

nginx.ingress.kubernetes.io/canary-by-header-value: "test"

蓝绿发布

方法：维护新旧两套环境，全量切换Service或Ingress指向。步骤：

部署新旧版本Service（如blue-svc和green-svc）。

切换流量：

kubectl patch ingress my-ingress -p '{"spec":{"rules":[{"http":{"paths":[{"backend":{"serviceName":"green-svc"}}]}}]}}'

对比表格

维度灰度发布蓝绿发布流量策略渐进式（权重/Header分流）全量切换（一次性替换）资源占用低（新旧版本共存）高（双环境并行运行）回滚速度较慢（需逐步调整）秒级（切回旧Service）适用场景A/B测试、功能验证高风险全量更新、零停机需求

注意事项

数据兼容：确保新旧版本接口/数据库兼容。监控：实时跟踪错误率和延迟。优雅终止：配置preStop保证旧Pod处理完请求。

五、使用nginx Ingress实现灰度发布

这里在前面部署的nginx Ingress控制器的基础上实现灰度发布，以发布nginx服务器为例，采用经典的权重策略，按比例分配流量。

1.部署两个版本的应用程序

在Kubernetes集群中部署两个版本的nginx服务器。

（1）定义旧版本的Deployment和Service

[root@master ~]# vim nginx-deploy-service-v1.yaml

[root@master ~]# cat nginx-deploy-service-v1.yaml

# 定义ConfigMap，使用ConfigMap更改Nginx首页文件

apiVersion: v1

kind: ConfigMap # 类型为ConfigMap

metadata:

data:

index.html: |

This is V1

---

# 定义Deployment

apiVersion: apps/v1

kind: Deployment # 类型为Deployment

metadata:

spec:

replicas: 2 # 副本数量

selector:

matchLabels:

app: nginx-v1

template:

metadata:

labels:

app: nginx-v1 # Pod的标签

spec:

containers:

- name: nginx # 容器的名称

image: nginx:1.14.2 # 容器所用的镜像

ports:

- name: nginx-port

containerPort: 80 # 容器需要暴露的端口

volumeMounts: # 卷挂载点

- mountPath: /usr/share/nginx/html

volumes: # 定义卷

- name: nginx-index

configMap:

---

# 定义Service

apiVersion: v1

kind: Service

metadata:

spec:

selector:

app: nginx-v1

ports:

- targetPort: 80

port: 8080

type: NodePort

这里使用ConfigMap定制nginx服务器的首页，便于测试

（2）定义新版本的Deployment和Service

[root@master ~]# vim nginx-deploy-service-v2.yaml

[root@master ~]# cat nginx-deploy-service-v2.yaml

apiVersion: v1

kind: ConfigMap

metadata:

data:

index.html: |

This is V2

---

apiVersion: apps/v1 # 版本号

kind: Deployment # 类型为Deployment

metadata: # 元数据

spec: # 详细信息

replicas: 2 # 副本数量

selector: # 选择器，指定该控制器管理哪些Pod

matchLabels: # 匹配规则

app: nginx-v2

metadata:

labels:

app: nginx-v2 # Pod的标签

spec:

containers: # 容器列表（本例仅定义一个容器）

- name: nginx # 容器的名称

image: nginx:1.17.2 # 容器所用的镜像

ports:

- name: nginx-port

containerPort: 80 # 容器需要暴露的端口

volumeMounts:

- mountPath: /usr/share/nginx/html

volumes:

- name: nginx-index

configMap:

---

apiVersion: v1

kind: Service

metadata:

spec:

selector:

app: nginx-v2

ports:

- targetPort: 80

port: 8080

type: NodePort

（3）基于以上两个配置文件创建相应的Deployment和Service及ConfigMap

[root@master ~]# kubectl apply -f nginx-deploy-service-v1.yaml

configmap/nginx-index-html-configmap1 created

deployment.apps/nginx-v1 created

service/nginx-v1 created

[root@master ~]# kubectl apply -f nginx-deploy-service-v2.yaml

configmap/nginx-index-html-configmap2 created

deployment.apps/nginx-v2 created

service/nginx-v2 created

（4）查看Service列表，发现两个新创建的两个版本的Service都能正常运行

[root@master ~]# kubectl get svc

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes ClusterIP 10.96.0.1 443/TCP 27d

nginx-v1 NodePort 10.99.7.175 8080:31834/TCP 46s

nginx-v2 NodePort 10.109.71.190 8080:32640/TCP 3s

（5）测试两个版本的nginx服务器的访问，结果都是正常的

[root@master ~]# curl 10.99.7.175:8080

This is V1

[root@master ~]# curl 10.109.71.190:8080

This is V2

由于Service是NodePort类型的，可以通过“节点地址：节点端口”地址访问来进行测试。

2.创建稳定版本Ingress

针对旧版本的Service创建一个稳定版本的Ingress，对外发布nginx。

（1）编写Ingress配置文件

[root@master ~]# vim stable-ingress.yaml

[root@master ~]# cat stable-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

kubernetes.io/ingress.class: nginx # 通过注解指定Ingress类

spec:

rules:

- host: nginx.abc.com # 对外发布服务的域名

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

前面关于Ingress定义的例子中使用.spec.ingressClassName字段指定Ingress类，这里通过注解指定该Ingress类。

（2）基于配置文件创建Ingress

[root@master ~]# kubectl apply -f stable-ingress.yaml

Warning: annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead

ingress.networking.k8s.io/stable-ingress created

（3）查看Ingress列表

[root@master ~]# kubectl get ing

NAME CLASS HOSTS ADDRESS PORTS AGE

stable-ingress nginx.abc.com 80 39s

（4）测试通过该Ingress访问nginx服务器

[root@master ~]# curl nginx.abc.com

This is V1

3.创建金丝雀版本Ingress实现灰度发布

针对新版本的Service创建一个金丝雀版本的Ingress对外发布服务，采用权重策略分配流量，仅允许20%的流量转发到此版本的服务中，以实现灰度发布。

（1）定义Ingress配置文件

[root@master ~]# vim canary-ingress.yaml

[root@master ~]# cat canary-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

kubernetes.io/ingress.class: nginx # 通过注解指定Ingress类

nginx.ingress.kubernetes.io/canary: "true" # 启用Canary

# 将20%的流量转发到Canary Ingress

nginx.ingress.kubernetes.io/canary-weight: "20"

spec:

rules:

- host: nginx.abc.com # 对外发布服务的域名

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

（2）基于配置文件创建Ingress

[root@master ~]# kubectl apply -f canary-ingress.yaml

Warning: annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead

ingress.networking.k8s.io/canary-ingress created

（3）查看Ingress列表

[root@master ~]# kubectl get ing

NAME CLASS HOSTS ADDRESS PORTS AGE

canary-ingress nginx.abc.com 80 30s

stable-ingress nginx.abc.com 80 8m47s

（4）访问使用Ingress发布的nginx服务器来测试灰度发布

[root@master ~]# for i in {1..10}; do curl http://nginx.abc.com; done;

This is V2

This is V1

This is V2

This is V1

可以发现，由新版本响应的大约占20%，符合20%权重的设置，实际的流量分配比例可能会有所浮动，这属于正常现象。理论上讲，访问次数越多就越接近权重比例的设置。

4.将所有流量从旧版本迁移至新版本

两个版本运行一段时间后，如果新版本一直正常运行并且符合预期，则可以结束灰度发布，将所有流量迁移到新版本，下线旧版本，仅保留新版本在线，从而完成版本的升级。

（1）修改稳定版本的Ingress配置，将stable-ingress.yaml文件中的后端服务器指向新版本

[root@master ~]# vim stable-ingress.yaml

[root@master ~]# cat stable-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

kubernetes.io/ingress.class: nginx # 通过注解指定Ingress类

spec:

rules:

- host: nginx.abc.com # 对外发布服务的域名

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

（2）应用配置文件

[root@master ~]# kubectl apply -f stable-ingress.yaml

ingress.networking.k8s.io/stable-ingress configured

（3）访问nginx服务器进行测试，可以发现所有流量都迁移到新版本

[root@master ~]# for i in {1..10}; do curl http://nginx.abc.com; done;

This is V2

（4）删除用于灰度发布的金丝雀版本的Ingress

[root@master ~]# kubectl delete -f canary-ingress.yaml

ingress.networking.k8s.io "canary-ingress" deleted

（5）删除旧版本的Deployment和Service，使相应的nginx服务器下线

[root@master ~]# kubectl delete -f nginx-deploy-service-v1.yaml

configmap "nginx-index-html-configmap1" deleted

deployment.apps "nginx-v1" deleted

service "nginx-v1" deleted

（6）查看Service列表，可以发现目前仅有新版本的Service在运行，这样就完成了版本的升级

[root@master ~]# kubectl get svc

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes ClusterIP 10.96.0.1 443/TCP 27d

nginx-v2 NodePort 10.109.71.190 8080:32640/TCP 13m

（7）删除稳定版本的ingress，以及新版本的Deployment和Service

[root@master ~]# kubectl delete -f stable-ingress.yaml

ingress.networking.k8s.io "stable-ingress" deleted

[root@master ~]# kubectl delete -f nginx-deploy-service-v2.yaml

configmap "nginx-index-html-configmap2" deleted

deployment.apps "nginx-v2" deleted

service "nginx-v2" deleted

六、使用nginx Ingress实现蓝绿发布

前面提到，nginx Ingress的Canary Ingress基于权重的流量切分策略的典型场景是蓝绿发布。实际应用只有一个生产环境，绿色版本表示当前的生产环境，即旧版本；蓝色环境表示测试环境（金丝雀），即新版本。我们可以通过调整权重的方式（非0%即100%）实现蓝绿版本的上线或下线，新版本如果有问题可以快速地回滚到旧版本。

（1）创建相应地Deployment和Service

[root@master ~]# kubectl apply -f nginx-deploy-service-v1.yaml

configmap/nginx-index-html-configmap1 created

deployment.apps/nginx-v1 created

service/nginx-v1 created

[root@master ~]# kubectl apply -f nginx-deploy-service-v2.yaml

configmap/nginx-index-html-configmap2 created

deployment.apps/nginx-v2 created

service/nginx-v2 created

（2）创建绿色版本地Ingress

[root@master ~]# vim green-ingress.yaml

[root@master ~]# cat green-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

kubernetes.io/ingress.class: nginx # 通过注解指定Ingress类

spec:

rules:

- host: nginx.abc.com # 对外发布服务的域名

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

（3）访问使用Ingress发布地nginx服务器进行测试，可以发现所有流量都分配到绿色版本

[root@master ~]# for i in {1..10}; do curl http://nginx.abc.com; done;

This is V1

（4）创建蓝色版本Ingress

[root@master ~]# vim blue-ingress.yaml

[root@master ~]# cat blue-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

kubernetes.io/ingress.class: nginx # 通过注解指定Ingress类

nginx.ingress.kubernetes.io/canary: "true" # 启用Canary

# 将100%的流量转发到Blue Ingress

nginx.ingress.kubernetes.io/canary-weight: "100"

spec:

rules:

- host: nginx.abc.com # 对外发布服务的域名

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

[root@master ~]# kubectl create -f blue-ingress.yaml

Warning: annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead

ingress.networking.k8s.io/blue-ingress created

（5）访问使用Ingress发布地nginx服务器进行测试，可以发现所有流量都分配到蓝色版本

[root@master ~]# for i in {1..10}; do curl http://nginx.abc.com; done;

This is V2

（6）蓝色版本运行过程中如果出现问题，修改blue-ingress.yaml配置文件，将流量权重值改为0，使用kubectl apply更新Ingress，然后通过访问应用程序进行测试，可以发现所有流量都切回到绿色版本

[root@master ~]# vim blue-ingress.yaml

[root@master ~]# cat blue-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

kubernetes.io/ingress.class: nginx # 通过注解指定Ingress类

nginx.ingress.kubernetes.io/canary: "true" # 启用Canary

# 将100%的流量转发到Blue Ingress

nginx.ingress.kubernetes.io/canary-weight: "0"

spec:

rules:

- host: nginx.abc.com # 对外发布服务的域名

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

[root@master ~]# kubectl apply -f blue-ingress.yaml

Warning: resource ingresses/blue-ingress is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.

ingress.networking.k8s.io/blue-ingress configured

[root@master ~]# for i in {1..10}; do curl http://nginx.abc.com; done;

This is V1

（7）修正蓝色版本地问题之后，再次更新应用程序部署，完成后再修改blue-ingress.yaml文件，将流量权重值重新设置为100，更新Ingress，以便将流量全部导向蓝色版本

[root@master ~]# vim nginx-deploy-service-v2.yaml

[root@master ~]# cat nginx-deploy-service-v2.yaml

apiVersion: v1

kind: ConfigMap

metadata:

data:

index.html: |

This is new V2

---

apiVersion: apps/v1 # 版本号

kind: Deployment # 类型为Deployment

metadata: # 元数据

spec: # 详细信息

replicas: 2 # 副本数量

selector: # 选择器，指定该控制器管理哪些Pod

matchLabels: # 匹配规则

app: nginx-v2

metadata:

labels:

app: nginx-v2 # Pod的标签

spec:

containers: # 容器列表（本例仅定义一个容器）

- name: nginx # 容器的名称

image: nginx:1.17.2 # 容器所用的镜像

ports:

- name: nginx-port

containerPort: 80 # 容器需要暴露的端口

volumeMounts:

- mountPath: /usr/share/nginx/html

volumes:

- name: nginx-index

configMap:

---

apiVersion: v1

kind: Service

metadata:

spec:

selector:

app: nginx-v2

ports:

- targetPort: 80

port: 8080

type: NodePort

[root@master ~]# vim blue-ingress.yaml

[root@master ~]# cat blue-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

annotations:

kubernetes.io/ingress.class: nginx # 通过注解指定Ingress类

nginx.ingress.kubernetes.io/canary: "true" # 启用Canary

# 将100%的流量转发到Blue Ingress

nginx.ingress.kubernetes.io/canary-weight: "100"

spec:

rules:

- host: nginx.abc.com # 对外发布服务的域名

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 80

[root@master ~]# kubectl apply -f nginx-deploy-service-v2.yaml

configmap/nginx-index-html-configmap2 configured

deployment.apps/nginx-v2 unchanged

service/nginx-v2 unchanged

[root@master ~]# kubectl apply -f blue-ingress.yaml

ingress.networking.k8s.io/blue-ingress configured

[root@master ~]# for i in {1..10}; do curl http://nginx.abc.com; done;

This is new V2

[root@master ~]#

（8）蓝色版本一直正常运行并且符合预期，则可以结束蓝绿发布，让蓝色版本正式提供服务，撤销绿色版本，并下线旧版本应用程序，将资源释放出来，以便将来部署下一个测试地新版本

[root@master ~]# kubectl delete -f green-ingress.yaml

ingress.networking.k8s.io "green-ingress" deleted

[root@master ~]# kubectl delete -f nginx-deploy-service-v1.yaml

configmap "nginx-index-html-configmap1" deleted

deployment.apps "nginx-v1" deleted

service "nginx-v1" deleted

[root@master ~]#

（9）清理实验环境

[root@master ~]# kubectl delete -f nginx-deploy-service-v2.yaml

configmap "nginx-index-html-configmap2" deleted

deployment.apps "nginx-v2" deleted

service "nginx-v2" deleted

[root@master ~]# kubectl delete -f blue-ingress.yaml

ingress.networking.k8s.io "blue-ingress" deleted

幻速s6油耗多少，幻速s6实际油耗多少
港鐵路綫代號