Deployment 是什么
Deployment 是无状态工作负载的标准控制器：它管理一组副本集，副本集再管理实际的实例，因此每次修改实例模板都会产生一个新的副本集，发布与回滚就是在这两个副本集之间切换。它默认采用滚动更新策略，可以精细控制发布过程中允许的额外实例数与不可用实例数。
基本信息
| 层级关系 | Deployment 管理 ReplicaSet，ReplicaSet 管理实例，一个版本对应一个副本集 |
|---|---|
| 更新策略 | 支持滚动更新与先停后起两种；滚动更新由额外实例与不可用实例两个参数控制节奏 |
| 发布历史 | 默认保留若干历史版本，用于回滚；数量可在配置里调整 |
| 触发条件 | 只有实例模板变化才触发发布，单纯调整副本数不算发布 |
| 回滚方式 | 通过发布管理命令回到上一版或指定版本 |
| 标签选择器 | 创建后不可修改，必须与实例模板中的标签一致 |
典型使用场景
- 无状态服务发布：Web、接口服务这类可以随意替换实例的业务
- 灰度与分批：通过调整发布节奏参数控制新旧版本的重叠程度
- 快速回滚：新版本异常时一键退回上一版本
- 配合扩缩容：副本数由控制器维护，自动扩缩容同样作用于它
- 配置生效：配置更新后触发滚动重建，让新配置在实例上生效
- 多版本并存观察：发布过程中新旧副本集同时存在，便于观察指标
滚动更新参数
| 参数 | 作用 | 调优方向 |
|---|---|---|
| maxSurge | 允许超过期望副本数的实例上限 | 设大加快发布，代价是峰值资源占用 |
| maxUnavailable | 允许不可用的实例上限 | 设为 0 时先起新再停旧，容量不缩水 |
| revisionHistoryLimit | 保留的历史版本数量 | 回滚需求多时调大 |
| minReadySeconds | 实例就绪后观察多久才算可用 | 设大能拦住『起来就崩』的版本 |
| progressDeadlineSeconds | 发布无进展的判定时间 | 用于及早暴露卡住的发布 |
Deployment 示例
Deployment 示例
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
revisionHistoryLimit: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels: { app: web }
template:
metadata:
labels: { app: web }
spec:
containers:
- name: web
image: registry.example.com/team/web:1.2.3
ports:
- containerPort: 8080
readinessProbe:
httpGet: { path: /healthz, port: 8080 }
periodSeconds: 5
先起新再停旧的组合是保守策略：发布期间总容量不缩水，代价是峰值多占用资源，适合容量紧张但要求平滑的场景。
实例模板变化才触发滚动发布：只改副本数不会产生新版本，回滚历史里也不会多出一条记录。
标签选择器创建后不可修改：写错只能删除重建，重建过程中服务会有中断窗口，发布前务必核对标签。
就绪检查决定发布能否推进：没有就绪检查时新实例一启动就被当作可用，问题版本会立刻接收全部流量。
发布前的准备项
- 确认只有实例模板变化才触发发布，改副本数不会产生新版本
- 确认就绪检查的路径与端口正确，否则发布会被永久卡住
- 确认资源请求与上限合理，否则新实例可能根本调度不上去
- 确认发布历史保留数量足够，回滚时才有可用版本
- 确认容量余量能承受发布期间额外实例带来的资源占用
- 确认监控与日志已经生效，发布后能第一时间发现异常
副本数与发布策略要和容量一起评估：滚动更新期间会产生额外实例，容量紧张的集群应先扩容再发布，避免把发布变成容量事故。