灰度发布-方案

要在 Kubernetes 上对一个 **7×24 在线**系统做**灰度发布**，核心是把“新版本流量占比、发布节奏、回滚手段”全部自动化并可观测化；但你当前问题缺少可引用的上下文细节（例如是否使用 Service Mesh/Ingress、是否允许多版本并存、是否有统一网关、SLO/指标体系等），因此以下给出业内通用做法，具体落地仍需结合你的基础设施（**information is missing on：现有流量入口与网关形态、是否使用 Istio/Linkerd、发布工具链（Argo Rollouts/Flagger/自研）、可观测体系与告警阈值、状态组件与数据库发布策略**）。 ## 1) 前置条件（不满足很难做到“在线灰度”） - **无状态优先**：业务 Pod 尽量无状态；会话用外置存储（Redis/DB），或采用粘性会话策略（若必须）。 - **就绪/存活探针**：必须配置 `readinessProbe` / `livenessProbe`，保证流量只打到“真的可用”的新版本。 - **滚动发布参数**：Deployment 设置 `maxUnavailable=0`（保证不减容量）与合理的 `maxSurge`（增加新副本）。 - **回滚要快**：镜像不可变（tag+digest）、发布记录可追溯，一键回退到上一 ReplicaSet/Revision。 - **可观测与自动判定**：至少有错误率、延迟、QPS、饱和度、业务关键指标（如下单成功率）以及告警阈值。 ## 2) 灰度发布的两种主流流量切分方式 ### A. 基于“比例”的灰度（最常见） 适用：大多数 HTTP/gRPC 服务，目标是逐步扩大新版本流量占比。 - **实现路径** 1) 同时运行 v1 与 v2（两套 ReplicaSet/Service 选择器或同 Service 不同版本标签）。 2) 在流量入口做权重： - 有 **Service Mesh（如 Istio）**：用 VirtualService/DestinationRule 做权重 1%→5%→20%→50%→100%。 - 无 Mesh：用 **Ingress Controller（如 NGINX）** 的 canary/weight 能力，或使用 **Argo Rollouts + NGINX/Istio** 做流量管理。 3) 每个阶段“观察窗口”持续 N 分钟（按业务峰值调整），若指标异常自动暂停/回滚。 ### B. 基于“人群/条件”的灰度（更可控） 适用：需要先给内部用户、特定租户、特定地域试用，或需要严格避免影响大盘。 - **实现路径** - 在网关/Ingress/Mesh 按 **Header、Cookie、UserID 哈希、租户ID、地域** 等条件路由到 v2。 - 先让“白名单用户/员工账号/某租户”走新版本，再逐步扩大人群范围。 - 优点：即使 v2 有问题，影响范围天然可控；缺点：规则复杂度更高。 ## 3) 发布策略建议（7×24 常用节奏） 一个可复制的节奏是： 1. **预发布检查**：镜像扫描、单测/集成测试、配置校验、数据库变更检查。 2. **暗发布 / Shadow（可选）**：复制线上请求到 v2 但不返回给用户，仅用于验证兼容与性能（需要网关或 Mesh 支持）。 3. **金丝雀 1%**：只放极少量流量，重点观察错误率、P95/P99、资源、依赖调用失败率。 4. **逐级放量**：1%→5%→20%→50%→100%，每级都设置**自动分析**与**自动回滚**条件。 5. **稳定期**：全量后继续观察一段时间再清理旧版本。 ## 4) Kubernetes 资源层面怎么配合 ### 仅用 Deployment 做“无流量切分”的灰度（不推荐做严格灰度） - Deployment 的 RollingUpdate 只是在“副本替换”层面渐进，不保证“精确流量比例”，更像“滚动升级”。 - 适合：对版本风险低、且只要保证不掉容量即可的场景。 - 要点：`maxUnavailable=0`、合理 `maxSurge`、探针到位、HPA 配合。 ### 使用 Argo Rollouts（推荐） - Rollouts 提供 **canary/blue-green**、按步骤放量、自动分析（AnalysisTemplate）、自动回滚。 - 还能和 Istio/NGINX/ALB 等集成实现真正的权重流量切分。 ## 5) 数据库/缓存等“有状态变更”的灰度要点（决定是否真能 7×24） - **向前/向后兼容**：发布期间 v1 与 v2 要能同时工作（读写同一份数据时尤其关键）。 - 常用手法： - 数据库变更采用 **expand-and-contract**（先加字段/表兼容旧版，再切流量，再清理旧字段）。 - 重要变更用 **双写/回填**、特性开关控制启用时机。 - 如果做不到兼容，多数情况下无法实现严格意义的在线灰度，只能停写窗口或分批迁移。 ## 6) 你可以按这三种“落地组合”选型 1) **最省事（风险中等）**：Deployment RollingUpdate + maxUnavailable=0 + 监控告警 + 手动回滚。 2) **标准生产（推荐）**：Argo Rollouts（Canary）+ Istio/NGINX 权重分流 + 自动分析/自动回滚。 3) **强管控（大厂常见）**：条件路由（按租户/用户）+ 特性开关 + 金丝雀权重 + Shadow + 自动化分析。 --- 如果你补充以下信息，我可以把方案细化到可执行的 YAML/步骤清单（含回滚与指标阈值建议）： 1) 入口：Ingress(NGINX)/Gateway API/云 LB/Service Mesh？ 2) 服务协议：HTTP/gRPC/WebSocket？是否有长连接？ 3) 是否允许同一时刻 v1/v2 同时对外？ 4) 发布工具：Argo CD/Flux/Jenkins？ 5) 数据库变更是否频繁、是否能保证兼容？