官方文档https://argo-rollouts.readthedocs.io/en/stable/一、核心原理与生产架构1. 核心原理蓝环境Blue当前承载 100% 生产流量的稳定旧版本。绿环境Green部署完成、验证通过的新版本初始无流量。流量开关Service selector标签选择器——修改即秒级切换 Endpoints。秒级回滚切回 Service selector 即可无需重新部署旧版。资源要求发布时需双倍 Pod 资源发布完成可清理旧版。2. 生产标准架构推荐用户 → Ingress/Nginx → 主 Serviceprod-svc ↓selector 动态切换 ┌─────────────┐ ┌─────────────┐ │ app-blue │ │ app-green │ │ Deployment │ │ Deployment │ │ (v1.0 稳定) │ │ (v1.1 新版) │ └─────────────┘ └─────────────┘Ingress固定指向主 Serviceprod-svc永不修改。主 Service仅修改 selector作为唯一流量入口。双 Deployment蓝、绿独立标签区分version: blue/green。二、生产级 YAML 完整配置1. 蓝环境旧版DeploymentapiVersion: 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: 602. 绿环境新版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: ClusterIP4. Ingress固定指向主 ServiceapiVersion: networking.k8s.io/v1kind: Ingressmetadata:name: myapp-ingressnamespace: productionannotations:kubernetes.io/ingress.class: nginxnginx.ingress.kubernetes.io/proxy-connect-timeout: 30nginx.ingress.kubernetes.io/proxy-read-timeout: 60spec: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 --forconditionavailable deployment/app-green -n production --timeout300s# 验证绿环境内部测试不接流量kubectl port-forward svc/myapp-green-svc 8081:80 -n productioncurl http://localhost:8081/actuator/health步骤 2流量秒级切换核心# 方式1patch 命令推荐秒级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 不调度到同节点。PDBPodDisruptionBudget保证发布时最少 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 reload3. 长连接用户仍访问旧版原因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按versionblue/green过滤。链路SkyWalking/Jaeger追踪版本调用。七、蓝绿 vs 滚动 vs 金丝雀特性蓝绿发布滚动更新金丝雀灰度宕机风险0双环境极低极低回滚速度秒级切标签分钟级重部署秒级切流量资源占用双倍正常少量额外适用场景核心应用、强稳定性非核心、常规迭代大版本、风险高流量控制全量切换逐步替换百分比放量八、生产最佳实践总结固定架构Ingress → 主 Service → 双 Deployment。必开配置健康检查、优雅退出、反亲和、PDB。严格流程先部署绿环境 → 验证 → 切流 → 监控 → 清理。秒级回滚永远保留旧版至稳定回滚仅切 Service selector。数据安全数据库兼容优先消息/缓存严格隔离。