零停机滚动发布

环境与前置条件

只有当平台在实例停止服务前将其从负载均衡中摘除，且应用能排空进行中的请求时，滚动发布才是零停机的。修改发布策略前先验证这两点。

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1
readinessProbe:
  httpGet:
    path: /readyz
    port: 3000
  periodSeconds: 5

步骤

1. 部署新镜像并用 kubectl rollout status deployment/app 观察进度。
2. 监控首批实例的错误率、p95 延迟与就绪状态。
3. 如果发布预算被突破，立即暂停或回滚。
4. 继续分批发布，并让新版本经过一段观察期。
5. 观察期通过后，删除旧 ReplicaSet 与临时特性开关。

验证

每个副本的版本端点都应报告新构建。发布期间持续压测，确认没有连接重置，也没有由就绪状态导致的 5xx 尖峰。将仪表盘与发布前基线比较，确认错误率和延迟在预算内。

回滚

kubectl rollout undo deployment/app 会恢复上一个 ReplicaSet。回滚还必须撤销不向后兼容的配置与 schema 变更，因此数据库迁移应采用扩展-收缩流程。

决策点

首批可以是小流量金丝雀，也可以是标准滚动更新。关键路径或依赖变更优先金丝雀；低风险且测试充分的变更可用滚动更新。持续 SLO 违约应触发自动回滚；就绪失败应暂停发布，而不是无限重试。