官方文档：https://argo-rollouts.readthedocs.io/en/stable/
一、核心原理与生产架构
1. 核心原理
- 蓝环境（Blue）
当前承载 100% 生产流量的稳定旧版本。
- 绿环境（Green）
部署完成、验证通过的新版本，初始无流量。
- 流量开关
Service selector（标签选择器）——修改即秒级切换 Endpoints。
- 秒级回滚
切回 Service selector 即可，无需重新部署旧版。
- 资源要求
发布时需双倍 Pod 资源（发布完成可清理旧版）。
2. 生产标准架构（推荐）
用户 → Ingress/Nginx → 主 Service（prod-svc） ↓（selector 动态切换） ┌─────────────┐ ┌─────────────┐ │ app-blue │ │ app-green │ │ Deployment │ │ Deployment │ │ (v1.0 稳定) │ │ (v1.1 新版) │ └─────────────┘ └─────────────┘- Ingress
固定指向主 Service（prod-svc），永不修改。
- 主 Service
仅修改 selector，作为唯一流量入口。
- 双 Deployment
蓝、绿独立，标签区分（
version: blue/green）。
二、生产级 YAML 完整配置
1. 蓝环境（旧版）Deployment
apiVersion: apps/v1kind: Deploymentmetadata:name: app-bluenamespace: productionlabels:app: myappversion: bluespec:replicas: 3# 生产必须：Pod 反亲和（避免同节点）affinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- myapptopologyKey: kubernetes.io/hostname# 生产必须：PDB（高可用，最少2个副本）minReadySeconds: 10strategy:type: Recreate # 蓝绿用 Recreate，不滚动selector:matchLabels:app: myappversion: bluetemplate:metadata:labels:app: myappversion: bluespec:containers:- name: myappimage: myapp:v1.0.0ports:- containerPort: 8080# 生产必须：资源限制resources:requests:cpu: 200mmemory: 512Milimits:cpu: 1000mmemory: 1Gi# 生产必须：健康检查（零宕机关键）readinessProbe:httpGet:path: /actuator/healthport: 8080initialDelaySeconds: 10periodSeconds: 5failureThreshold: 2livenessProbe:httpGet:path: /actuator/healthport: 8080initialDelaySeconds: 30periodSeconds: 10# 生产必须：优雅退出lifecycle:preStop:exec:command: ["/bin/sh","-c","sleep 30 && kill -SIGTERM 1"]terminationGracePeriodSeconds: 60
2. 绿环境（新版）Deployment
仅修改name、version、image，其余与蓝完全一致：
apiVersion: apps/v1kind: Deploymentmetadata:name: app-greennamespace: productionlabels:app: myappversion: greenspec:replicas: 3# 其余与 app-blue 完全相同...template:metadata:labels:app: myappversion: greenspec:containers:- name: myappimage: myapp:v1.1.0 # 仅版本不同# 其余与蓝一致...
3. 主 Service（流量入口）
apiVersion: v1kind: Servicemetadata:name: myapp-prod-svcnamespace: productionspec:selector:app: myappversion: blue # 初始指向蓝环境ports:- port: 80targetPort: 8080type: ClusterIP
4. Ingress（固定指向主 Service）
apiVersion: networking.k8s.io/v1kind: Ingressmetadata:name: myapp-ingressnamespace: productionannotations:kubernetes.io/ingress.class: nginxnginx.ingress.kubernetes.io/proxy-connect-timeout: "30"nginx.ingress.kubernetes.io/proxy-read-timeout: "60"spec:rules:- host: api.myapp.comhttp:paths:- path: /pathType: Prefixbackend:service:name: myapp-prod-svc # 固定主Serviceport:number: 80
三、生产发布全流程（零宕机标准步骤）
步骤 1：部署绿环境（新版）
# 部署新版（不影响线上）kubectl apply -f app-green.yaml -n production# 等待绿环境全量 Ready（必须）kubectl wait --for=condition=available deployment/app-green -n production --timeout=300s# 验证绿环境（内部测试，不接流量）kubectl port-forward svc/myapp-green-svc 8081:80 -n productioncurl http://localhost:8081/actuator/health
步骤 2：流量秒级切换（核心）
# 方式1：patch 命令（推荐，秒级）kubectl patch svc myapp-prod-svc -n production \-p '{"spec":{"selector":{"version":"green"}}}'# 方式2：编辑 Servicekubectl edit svc myapp-prod-svc -n production# 将 selector.version: blue → green
步骤 3：验证与监控（发布后必做）
# 确认 Service 指向绿环境kubectl get svc myapp-prod-svc -n production -o jsonpath='{.spec.selector}'# 查看流量是否进入绿 Podkubectl get endpoints myapp-prod-svc -n productionkubectl logs -f app-green-xxx -n production# 监控指标（生产必备）# - QPS、错误率、P99延迟# - CPU/内存、连接数、业务成功率
步骤 4：秒级回滚（异常时）
回滚仅需1条命令，秒级生效：
# 切回蓝环境（旧版）kubectl patch svc myapp-prod-svc -n production \-p '{"spec":{"selector":{"version":"blue"}}}'# 回滚后验证kubectl get svc myapp-prod-svc -n production -o jsonpath='{.spec.selector}'
步骤 5：清理旧版（稳定后）
# 确认 v1.1 稳定运行 30分钟+，删除蓝环境kubectl delete deployment app-blue -n production
四、生产关键保障（零宕机/秒回滚核心）
1. 健康检查（必开）
- readinessProbe
确保 Pod完全启动才接入流量。
- livenessProbe
异常 Pod 自动重建，避免僵死实例。
- 禁止
无探针直接切流 → 直接 502 宕机。
2. 优雅退出（长连接必备）
- preStop + terminationGracePeriodSeconds切流后
等待30~60秒，处理完长连接/请求再销毁。
适配：WebSocket、gRPC、HTTP Keep-Alive 场景。
3. 数据库兼容（最易踩坑）
遵循expand → migrate → contract原则：
- expand
先加字段、不加非空约束、不删旧字段。
- migrate
蓝绿双写兼容，切流后验证。
- contract
稳定7天+，再删旧字段/旧逻辑。
4. 高可用保障
- Pod 反亲和
蓝、绿 Pod 不调度到同节点。
- PDB（PodDisruptionBudget）
保证发布时最少 N 个副本可用。
- 资源预留
集群 CPU/内存 预留 50%+，支撑双环境运行。
5. 消息/缓存隔离（生产必控）
绿环境验证阶段：关闭 MQ 消费、定时任务、写缓存。
避免：未切流就写生产数据、重复消费、脏缓存。
五、常见问题与排错
1. 切流后部分 502/超时
原因：绿 Pod 未 Ready、readinessProbe 失败。
解决：
kubectl describe pod app-green-xxx查探针日志。
2. 回滚不生效/流量仍到新版
原因：kube-proxy 未同步 Endpoints、客户端 DNS 缓存。
- 解决：
kubectl rollout restart deployment/kube-proxy -n kube-system # Ingress 层刷新 kubectl exec -n ingress-nginx nginx-ingress-xxx -- nginx -s reload
3. 长连接用户仍访问旧版
原因：WebSocket/Keep-Alive 未断开。
解决：
切流后保留旧版 30~60分钟再清理。
应用层支持连接优雅关闭通知。
4. 资源不足、双环境无法运行
解决：
先缩旧版（如 3→2），再部署新版（3）。
集群开启HPA、节点自动扩缩容。
六、进阶：自动化与工具链
1. Argo Rollouts（生产推荐）
替代原生 Deployment，支持蓝绿/金丝雀可视化、自动验证、自动回滚。
支持：暂停/手动确认、自动切流、失败自动回滚。
2. CI/CD 集成（GitLab/Jenkins）
# 发布流水线 1. 构建镜像 → 2. 部署绿环境 → 3. 自动化测试 → 4. 人工确认 → 5. 切流 → 6. 监控 → 7. 清理旧版3. 可观测（生产必备）
- 监控
Prometheus + Grafana（按 version 维度）。
- 日志
ELK/Loki（按
version=blue/green过滤）。 - 链路
SkyWalking/Jaeger（追踪版本调用）。
七、蓝绿 vs 滚动 vs 金丝雀
特性 | 蓝绿发布 | 滚动更新 | 金丝雀（灰度） |
|---|---|---|---|
| 宕机风险 | 0（双环境） | 极低 | 极低 |
| 回滚速度 | 秒级 （切标签） | 分钟级（重部署） | 秒级（切流量） |
| 资源占用 | 双倍 | 正常 | 少量额外 |
| 适用场景 | 核心应用、强稳定性 | 非核心、常规迭代 | 大版本、风险高 |
| 流量控制 | 全量切换 | 逐步替换 | 百分比放量 |
八、生产最佳实践总结
- 固定架构
Ingress → 主 Service → 双 Deployment。
- 必开配置
健康检查、优雅退出、反亲和、PDB。
- 严格流程
先部署绿环境 → 验证 → 切流 → 监控 → 清理。
- 秒级回滚
永远保留旧版至稳定，回滚仅切 Service selector。
- 数据安全
数据库兼容优先，消息/缓存严格隔离。
