Deployment：声明式应用管理的核心

Deployment 是 Kubernetes 中最常用的工作负载控制器，也是无状态应用部署的标准方式。你声明"我要 3 个副本运行 v2 版镜像"，Deployment 控制器就会确保这个状态始终成立——副本不够就补，版本不对就更新，更新出问题还能回退。理解 Deployment，是理解 K8s 控制器范式的起点。

Deployment / ReplicaSet / Pod：三层嵌套关系#

K8s 的控制器采用嵌套设计，Deployment 并不直接管理 Pod，而是通过 ReplicaSet 间接管理。三层关系如下：

text
Deployment（用户声明期望状态）
  └── ReplicaSet（维护副本数量 + 版本锁定）
        └── Pod × N（实际运行的容器实例）

各层职责：

层级	职责	关键字段
Deployment	声明副本数、更新策略、版本滚动升级	`replicas`, `strategy`, `template`
ReplicaSet	维护指定数量的 Pod，Pod 模板决定版本	`replicas`, `selector`, `template`
Pod	运行容器，拥有独立 IP 和生命周期	`containers`, `volumes`

为什么需要 ReplicaSet 这一层？因为 Deployment 的滚动更新是通过创建新 ReplicaSet、缩容旧 ReplicaSet 实现的。一次更新会产生两个 ReplicaSet 共存：新 RS 逐步扩容，旧 RS 逐步缩容，直到新 RS 独占所有副本。如果 Deployment 直接管 Pod，版本切换就没有"中间过渡态"，无法做到零中断。

实操中你几乎不会直接操作 ReplicaSet，所有管理都通过 Deployment 完成。但理解这层嵌套，是理解滚动更新和回滚机制的前提。

滚动更新：maxSurge 与 maxUnavailable#

当你修改 Deployment 的 Pod 模板（比如更新镜像版本），K8s 会自动触发滚动更新。更新策略由 spec.strategy.rollingUpdate 控制，核心是两个参数：

yaml
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%       # 更新过程中，允许超出期望副本数的最大增量
    maxUnavailable: 25% # 更新过程中，允许不可用副本的最大数量

参数含义：

参数	含义	默认值	值类型
`maxSurge`	滚动更新时，可以多创建多少个 Pod（超出 replicas 数）	25%	整数或百分比
`maxUnavailable`	滚动更新时，最多允许多少个 Pod 不可用	25%	整数或百分比

更新过程（以 replicas=4, maxSurge=1, maxUnavailable=0 为例）：

新 ReplicaSet 创建 1 个 Pod（总数 4+1=5，超出 1 个，满足 maxSurge=1）
新 Pod 就绪后，旧 ReplicaSet 缩掉 1 个 Pod（总数 4，不可用 0 个，满足 maxUnavailable=0）
重复步骤 1-2，直到所有 4 个 Pod 都属于新 ReplicaSet
旧 ReplicaSet 保留 replica=0（用于回滚），但不删 Pod 模板

maxUnavailable=0 配合 maxSurge≥1 是最稳妥的策略——更新期间始终有 4 个可用 Pod，但会短暂占用 5 个 Pod 的资源。如果集群资源紧张，适当放宽 maxUnavailable 可以减少资源峰值。

触发更新的条件：只有修改 Pod 模板（spec.template）才会触发滚动更新，包括镜像版本、环境变量、端口等。仅修改 replicas 只会扩缩容，不触发更新。

回滚实操#

滚动更新不一定总是顺利——镜像有 bug、配置写错、新版本性能退化都需要回退。K8s 为 Deployment 保留了更新历史，让你可以一键回退。

关键命令#

bash
# 查看更新状态（是否完成、是否卡住）
kubectl rollout status deployment/nginx-app

# 查看更新历史（每个 revision 对应一次 Pod 模板变更）
kubectl rollout history deployment/nginx-app

# 回滚到上一个版本
kubectl rollout undo deployment/nginx-app

# 回滚到指定版本（revision 号来自 rollout history）
kubectl rollout undo deployment/nginx-app --to-revision=2

实操示例#

假设你把 nginx 从 1.24 更新到 1.25，更新后发现新版本有兼容问题：

bash
# 1. 触发更新
kubectl set image deployment/nginx-app nginx=nginx:1.25

# 2. 观察更新状态
kubectl rollout status deployment/nginx-app
# 输出：Waiting for rollout to finish: 2 out of 4 new replicas have been updated...

# 3. 发现问题，暂停更新（可选，用于冻结当前状态）
kubectl rollout pause deployment/nginx-app

# 4. 决定回滚
kubectl rollout undo deployment/nginx-app
# 输出：deployment.apps/nginx-app rolled back

# 5. 验证回滚结果
kubectl rollout status deployment/nginx-app
kubectl get pods -l app=nginx-app -o jsonpath='{.items[*].spec.containers[0].image}'
# 输出：nginx:1.24

revision 保留数量：默认保留 10 个历史版本（revisionHistoryLimit: 10）。超过后旧 ReplicaSet 被删除，对应版本不可回滚。如果你经常回滚到很早的版本，可以调大这个值。

暂停更新（rollout pause）适合在更新过程中发现问题、想先排查再决策的场景。暂停后可以继续更新（rollout resume），也可以直接 undo。

扩缩容：手动与自动#

手动扩缩容#

最简单的方式是修改 replicas 数：

bash
# 扩容到 6 个副本
kubectl scale deployment/nginx-app --replicas=6

# 缩容到 2 个副本
kubectl scale deployment/nginx-app --replicas=2

也可以直接编辑 Deployment YAML 中的 spec.replicas 字段。kubectl scale 是命令式操作，适合临时调整；正式环境建议通过 YAML 声明副本数，由 GitOps 流程管控。

HPA：基于指标自动伸缩#

手动扩缩容依赖人工判断，面对突发流量往往反应滞后。Horizontal Pod Autoscaler（HPA）根据指标自动调整副本数，是生产环境应对流量波动的基本配置。

HPA 基本概念：

HPA 监控 Pod 的 CPU/内存利用率（或自定义指标），动态调整 Deployment 的 replicas
当 CPU 利用率超过目标值，HPA 增加副本；低于目标值则减少副本
扩容是立即执行的，缩容有 5 分钟冷却期（防止震荡）

最小示例：

yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-app
  minReplicas: 2        # 最少保持 2 个副本
  maxReplicas: 10       # 最多不超过 10 个副本
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # 目标 CPU 利用率 70%

HPA 工作流程：

Metrics Server 收集 Pod 的 CPU/内存指标（集群必须安装 Metrics Server，HPA 才能工作）
HPA 控制器每 15 秒计算当前平均利用率
期望副本数 = ceil(当前副本数 × 当前利用率 / 目标利用率)
将计算结果写入 Deployment 的 replicas 字段

HPA 要求 Pod 必须设置 resources.requests.cpu，否则无法计算利用率。requests.cpu 为 0 的 Pod，HPA 会报错跳过。

扩缩容对比：

方式	适用场景	优势	局限
`kubectl scale`	手动调整、测试环境	简单直接	需人工判断、无法自动响应流量
HPA	生产环境流量波动	自动响应、无需人工介入	依赖指标准确性、冷却期可能不够快

实战要点#

更新前先验证镜像：在测试环境跑一遍，避免滚动更新到有 bug 的版本
设置合理的更新参数：生产环境推荐 maxUnavailable=0 + maxSurge=1（资源充足时），确保更新过程零中断
配合 readinessProbe：只有新 Pod 通过就绪检查才会被纳入 Service 端点，防止未就绪的 Pod 接收流量
HPA + PDB 组合：HPA 自动扩缩，PDB（Pod Disruption Budget）防止缩容过猛导致服务不可用

小结#

Deployment 是 K8s 无状态应用的基石。三层嵌套（Deployment → ReplicaSet → Pod）是理解滚动更新和回滚的底层逻辑。滚动更新通过新旧 ReplicaSet 共存实现零中断过渡，maxSurge/maxUnavailable 控制过渡节奏。回滚通过保留历史 ReplicaSet 实现一键退回。扩缩容从手动 kubectl scale 到 HPA 自动伸缩，是从测试到生产的必经之路。掌握 Deployment，你就掌握了 K8s 控制器的核心范式——声明期望状态，控制器负责达成。