企业灰度发布 14：从零设计一套 Kubernetes + Istio 发布平台
前十三篇建立了完整前提：容器提供不可变版本，Kubernetes 管理副本，DDD 和契约保证业务边界可独立演进，Service Mesh 执行统一网络策略，Istio 精确控制流量，Rollout Controller 运行发布状态机，Prometheus 提供自动判定证据。企业平台要做的不是再实现一遍这些控制器，而是把它们变成有权限、有策略、有证据、有审计的内部产品。
推荐默认技术栈是 Argo CD + Argo Rollouts + Istio + Prometheus。Flagger 和 Kruise Rollouts 通过 adapter 作为可选执行器接入；平台领域模型保持稳定，同时保留底层特有能力。
总体架构：上层编排，底层各司其职
Argo CD 负责把版本化声明同步到集群；Argo Rollouts 负责单个工作负载的 stable/canary ReplicaSet、步骤和 AnalysisRun；Istio 负责真实请求路由；Prometheus 与业务数据提供判断。Release Orchestrator 负责跨组件和跨集群流程，例如先迁移 schema、再集群 A 灰度、审批后集群 B、最后关闭回滚窗口。
平台永远不要位于业务数据面。平台 API 或数据库故障时，已有服务与代理应继续运行，底层 Rollout 依据已提交状态继续或安全暂停。紧急回滚还应保留受审计的 Kubernetes/Argo CLI 路径，避免“平台挂了就无法救平台管理的应用”。
领域模型要高于 Kubernetes 资源
核心对象可以设计为：Application、Environment、Release、Artifact、Strategy、Stage、Evidence、Approval、PolicyDecision 和 IncidentLink。Application 关联限界上下文、团队、依赖、SLO 与数据风险；Artifact 记录镜像 digest、配置 revision、SBOM 和 schema 兼容；Release 是一次不可变发布意图；Stage 保存实际状态和证据。
不要把 Rollout CRD 原样暴露成平台 API。用户提交的是“checkout 生产环境发布 digest X，核心交易策略”，平台再根据模板生成底层对象。高级用户可以查看和下载生成 YAML，但不能绕开字段所有权和准入策略。
一次 Release 的端到端状态机
Validating 检查镜像、签名、配置、容量、探针、schema、依赖和观测；Preparing 创建 canary 资源并预热；每个集群内部由底层 Rollout 执行 1%/5%/20%/50% 等步骤。平台不应跨两个集群同时起步，先隔离故障域，确认一个集群健康后再扩大。
策略模板要按风险而不是团队喜好
平台根据业务等级、变更类型、时间窗、数据迁移和依赖扇出计算策略。低风险内部服务可直接 RollingUpdate；普通在线服务走 5→20→50→100；核心交易先内部 Header cohort，再 1% 快速安全指标，之后小步扩大并人工批准；不可逆数据变更先执行独立迁移 Release。
策略即代码应版本化。OPA/Kyverno 或自研规则可做准入，但判定结果要保存输入、规则版本和原因。审批不是万能安全：平台先用确定性检查过滤，人工只判断业务风险和证据冲突。紧急发布可以走 break-glass，但需要更强身份、双人确认、限时权限和事后复盘。
| 风险信号 | 策略动作 |
|---|---|
| 核心域或资金副作用 | 小初始流量、人工批准、业务补偿 |
| 数据库破坏性变更 | 禁止标准自动灰度，拆迁移 Release |
| 高扇出同步依赖 | 更长观察、依赖指标、全链路验证 |
| 无可靠业务指标 | 不允许自动 100%，要求人工门 |
| 回滚目标不可用 | 发布前直接拒绝 |
API 与前端应该围绕“证据”设计
关键 API 可以包括：创建 Release、执行预检、启动、暂停、继续、abort、retry、查询 timeline、获取 live topology、提交 approval、下载 evidence bundle。所有 mutation 使用幂等 key 和 optimistic concurrency，避免双击或网络重试推进两次。
前端首页不应只显示绿色进度条。一个 Release 页面需要同时展示：stable/canary digest、期望与实际副本、期望与观测流量、当前 step、剩余观察时间、指标原始值、阈值、Istio 配置同步、合成测试、审批、数据迁移、最近操作和一键回滚范围。
最有价值的视图是时间线：11:02 canary ready；11:03 目标代理 ACK；11:04 observed traffic 达到 4.8%；11:09 错误率通过；11:10 业务转化样本不足，自动延长；11:18 审批进入 20%。这让人能理解状态机，而不是猜控制器在做什么。
权限、安全与供应链
业务团队只能发布自己拥有的 Application；平台服务账号按 namespace/资源和字段最小授权；修改 Istio 全局资源、AnalysisTemplate 和策略模板属于平台管理员权限。Secret 不进入 Release 数据库，平台保存引用并使用短期凭证访问集群。
镜像必须按 digest 部署并验证签名/SBOM；Webhook、Analysis provider 和自定义 Lua/插件同样属于控制面代码，需要签名、版本锁定和漏洞治理。审计日志采用 append-only 事件，证据 bundle 可写入对象存储并设置保留策略。
四类故障路径必须演练
第一类是版本失败：快速指标越界，流量归零，保留 canary 供诊断或按策略缩容。第二类是平台依赖失败：Prometheus、GitOps 或 Istio 控制面不可用，Release 进入 paused/unknown，不能默认 promotion。第三类是控制器冲突：字段被 GitOps 或人工覆盖，立刻冻结并显示 owner diff。第四类是业务不可逆失败：停止扩大流量，触发领域补偿或向前修复，不声称镜像回滚已经恢复业务。
每季度至少演练：控制器重启、Prometheus 空数据、配置 NACK、集群断联、回滚镜像拉取失败、审批超时、数据库迁移卡住和多集群只完成一半。平台的可靠性来自这些失败路径被反复证明，而不是架构图完整。
分四阶段建设，不要一次造完
阶段一建立标准工作负载和人工 Canary：应用目录、不可变 Artifact、Argo Rollouts、Istio 权重、基础 timeline，先让发布可见可控。阶段二引入 Prometheus Analysis、合成测试、策略模板和自动 abort。阶段三加入 Header cohort、全链路泳道、数据库迁移门控与多集群串行发布。阶段四再做自助化、变更风险评分、历史回放和策略优化。
每阶段都有退出指标：发布成功率、平均回滚时间、误回滚率、无证据人工操作数、配置漂移数和业务事故率。平台目标不是让发布按钮更漂亮，而是把爆炸半径变小、判断时间变短、恢复行为变得可重复。
最终技术选择
新系统默认采用 Argo CD + Argo Rollouts + Istio + Prometheus：Argo CD 管声明收敛，Rollouts 管工作负载发布状态机，Istio 管流量，Prometheus 管可执行质量证据。平台通过 Kubernetes API 和标准 CRD 编排，在上层补齐企业所需的目录、权限、策略、审批、审计、多集群和数据迁移。
这条路线的关键不是工具名字，而是职责分离：不让 Istio 冒充发布系统，不让 Rollout Controller 承担业务审批，不让平台重写数据面，不让自动回滚假装能逆转业务事实。 各层边界清楚，灰度发布才会从几段 YAML 变成企业可依赖的工程系统。