企业灰度发布 10：渐进式交付的本质是一台可恢复的发布状态机
把流量从 5% 手工改到 20%，不是企业级灰度发布。真正困难的是：什么时候允许进入下一阶段，观察窗口从何时开始，指标缺失算通过还是失败，人工暂停期间配置变化怎么办，控制器重启后如何继续，以及 abort 到底恢复了哪些状态。
Progressive Delivery 的核心是一台持久化状态机。Kubernetes 管副本，Istio 管流量，Prometheus 提供证据，发布控制器把它们串成一条可重试、可暂停、可回滚、可审计的执行链。
一次发布至少包含三种状态
期望状态来自发布策略，例如 canary 权重 10%、副本 3、观察 10 分钟。观测状态来自 Kubernetes、Istio 和指标系统，例如 ready 副本 2、实际 canary 流量 7%、部分代理尚未同步。判定状态则由控制器根据规则形成：等待、通过、失败、暂停、终止或人工复核。
步骤的完成条件必须读取 observed state，不能在写入权重后立即开始计时。先等待 canary Pod ready，再等待目标代理接受配置，再验证 observed traffic，之后才进入分析窗口。否则启动错误和传播延迟会污染质量判断。
Canary、Blue/Green、A/B 和 Shadow 解决不同问题
Canary 按小比例真实流量逐步扩大爆炸半径，适合统计比较和连续验证。Blue/Green 同时维护两个完整环境，通过切换 active Service 快速上线或回退，适合需要完整预热和快速切换的系统，但资源成本更高，数据库兼容问题仍然存在。
A/B 测试按用户属性稳定分组，目标可能是比较产品转化而不是只证明技术健康；它需要实验统计、样本随机化和持续时间，不能把“指标更高”直接等同于发布更安全。Shadow/Mirroring 不返回新版本响应，最安全地验证流量兼容，却无法证明用户侧结果。
平台不应只提供一个“灰度百分比”表单，而要让发布目的选择策略：技术风险控制、内部验收、产品实验、容量预热或协议兼容。策略目的决定路由、指标和停止条件。
自动回滚必须定义范围
最小回滚是把 canary 正式流量降为 0；随后可缩容 canary、恢复 stable Service selector，并把 Release 标为 aborted。是否自动回滚镜像声明，要与 GitOps 协调：直接改 Git、提交 revert，还是让运行时状态短期偏离 Git，都要有唯一协议。
数据库、事件和外部副作用通常不能由发布控制器回滚。平台应把 traffic rollback、workload rollback 与 business compensation 分开展示。若发布包含不可逆迁移，自动 abort 可能选择“停止继续扩大 + 保留新版本用于向前修复”，而不是盲目切回旧代码。
GitOps 与运行时控制器会争夺哪些字段
Git 中的 VirtualService 若固定写 100/0，Argo CD 可能不断把 Rollout Controller 写入的 90/10 改回去。反过来，忽略整个 VirtualService diff 又会放过非权重配置漂移。更合理的是明确字段所有权：GitOps 管资源结构与基线，发布控制器仅管理 route weight、临时 header/mirror route 和 stable/canary selector，平台持续审计其差异。
Server-Side Apply 的 managed fields 可以帮助识别字段管理者，但不能替代组织约定。不同控制器使用 merge patch、update 或自定义恢复注解时，仍需按实际实现验证冲突行为。
幂等与恢复是状态机能否生产化的分水岭
控制器可能在任意一步重启，API 写入可能成功但响应超时，指标查询可能暂时失败。每个动作都必须幂等：重复设置 10% 不应产生第二条路由；重复创建 AnalysisRun 要能根据 owner/release id 识别已有实例；重复 abort 不能覆盖原始失败证据。
状态需要持久化 desired step、observed generation、开始时间、最后证据、尝试次数和恢复快照。人工暂停可能持续数小时，其间 stable 发生扩容、证书轮换或依赖故障；恢复时应重新跑前置条件，而不是从暂停点无条件继续。
Release CRD 与平台领域模型不应完全相同
底层控制器 CRD 描述 Kubernetes 执行细节，企业平台还需要应用、环境、风险、审批、变更单、合规证据和业务指标。平台 Release 可以引用一个或多个底层 Rollout，把多集群、数据库迁移、合成测试和人工节点编排在更高层。
这也避免把平台锁死在一个控制器。应用可以默认使用 Argo Rollouts，已有 Flux 团队使用 Flagger，低侵入工作负载使用 Kruise；平台把它们映射到统一的状态与证据接口，而不假装三者 CRD 完全一致。
一台合格状态机的检查项
| 能力 | 验收问题 |
|---|---|
| 前置检查 | 容量、兼容、监控和回滚目标是否就绪 |
| 阶段推进 | desired 与 observed 一致后才计时 |
| 证据判定 | 指标缺失、延迟和小样本如何处理 |
| 暂停审批 | 超时、状态变化和恢复时是否重检 |
| Abort | 流量、工作负载、数据各恢复到哪里 |
| 重入恢复 | 控制器重启和 API 超时后能否安全继续 |
| 审计 | 每个状态转换能否还原原因和证据 |
下一篇比较 Argo Rollouts、Flagger 与 Kruise Rollouts。选型不会只看功能打勾，而会看 workload 所有权、GitOps 生态、指标模型、Istio 接入方式和平台二开边界。