项目三：云原生高可用服务平台
把前面的应用搬进 Kubernetes 后，练习重点转向运行过程：发布时是否中断，实例失效后怎样恢复，数据库和外部依赖是否成为瓶颈。高可用不是部署多个副本就结束，还需要实际验证。
把前两个项目部署到 Kubernetes，加入渐进发布、OpenTelemetry、SLO、安全供应链和故障演练，形成生产级交付证据。
1. 本文覆盖范围
- Kubernetes 与资源治理
- CI/CD 与迁移
- 可观测/SLO/值班
- 安全与灾难恢复
2. 核心知识详解
1. 平台部署
使用不可变签名镜像、Deployment/Stateful 依赖、Service/Gateway、Secret、NetworkPolicy 和 autoscaling。
- 多可用区分布。
- requests/limits 和连接预算。
- 探针与优雅停机。
这里容易混淆的是： 副本数增加不等于高可用，下游、控制面和故障域仍需设计。
2. 发布和数据
流水线 build once，自动测试扫描，canary 按 SLI 晋级；数据库使用 expand/contract，事件 schema 兼容。
- 制品可追溯。
- 发布有回滚/前向修复。
- 迁移可暂停和重入。
这里容易混淆的是： 镜像回滚不能撤销 schema 和外部副作用。
3. SRE 闭环
OTel 收集日志、指标和 trace，SLO/error budget 驱动告警与发布；runbook、演练和复盘改进系统。
- 业务与技术 SLI。
- 多窗口 burn-rate。
- 事故角色和时间线。
这里容易混淆的是： 仪表盘多不代表可运营，关键是用户导向目标和可行动告警。
4. 安全与恢复
OIDC、最小权限、secret rotation、SBOM/签名、备份恢复和跨区域策略构成纵深防护。
- 定期恢复演练验证 RPO/RTO。
- 审计不可由业务管理员篡改。
- 依赖漏洞和密钥泄露有流程。
这里容易混淆的是： 有备份文件不等于可恢复，必须执行恢复和数据一致性验证。
3. 工程链路
4. 操作练习：验证一个副本退出时会发生什么
先在隔离的练习集群部署至少两个副本，配置真实的 readiness 检查，并持续请求一个可校验返回值的只读接口。不要只以“Pod 显示 Running”判断业务健康；一个进程可以活着，却还没有加载配置或连上必要资源。
| 故障操作 | 要观察的行为 | 不能据此宣称什么 |
|---|---|---|
| 让一个副本 readiness 失败 | 经过探针与端点传播后，正常 Service 流量不再路由到它 | 不能保证瞬间摘除，也不能保证已有连接全部迁走 |
| 优雅停止一个副本 | 新请求停止进入，在途请求按宽限期完成或明确失败 | 不能承诺任意长请求都完成 |
| 发布一个启动失败的新版本 | 新副本不接流量，旧健康副本按滚动策略保留 | 不合理的可用副本配置仍可能导致不可用 |
| 恢复备份到新环境 | 数据、约束和关键查询可用，记录真实恢复时间 | 有备份文件并不证明可以恢复 |
每一步记录时间线、成功率、错误率和请求重试次数。如果客户端不断重试把故障藏起来，用户延迟仍可能大幅上升，因此要同时观察延迟分位数。具体探针和滚动配置放在对应 Kubernetes 章节；这一阶段验收的是它们一起工作时的实际行为。
5. 实践与验证
- 用 IaC/manifest 从空环境部署。
- 执行 canary 自动回滚和兼容迁移。
- 演练节点故障、密钥轮换和数据库恢复并记录 RTO/RPO。
6. 掌握检查
- 环境可重建。
- 发布可渐进和停止。
- SLO 可行动。
- 恢复经过实际验证。