滚动部署

分批替换实例

滚动部署维持一个实例池，按受控批次替换。编排器先用新镜像创建实例，等待就绪检查通过，再终止同样数量的旧实例，如此循环直到全部收敛。节奏由两个参数决定：允许多出多少实例（surge）以及允许多少实例不可用（unavailable）。发布过程可以暂停，便于运维在批次之间查看指标。

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

何时使用

适用于具备健康检查和水平扩容能力的无状态服务，尤其是成本敏感的场景。与蓝绿部署相比，它不需要复制整套环境；与停机重建相比，它保持可用性。它只是部署机制，不是发布策略：若需要按用户控制暴露范围，应配合功能开关。

权衡

主要代价是版本混跑。发布期间请求可能同时命中新旧代码，因此 API、缓存和数据库 schema 必须双向兼容。发布时长随实例规模增长，大集群需要仔细调优探针，否则容易卡住。可观测性必须能区分版本，否则回归看起来只是随机噪声。

示例与常见误解

某团队运行 12 个 Pod，设置 maxSurge 为 1、maxUnavailable 为 0。Kubernetes 先增加一个就绪的新 Pod，再删除一个旧 Pod，如此往复，整个发布约经历十二个探针周期，容量始终不下降。常见误解是滚动部署天然零停机：没有就绪探针和富余容量就会丢请求；另一个误解是回滚能恢复数据，实际上它只恢复代码。相关概念包括蓝绿部署与渐进式交付。