📚 课程目录第3章 Deployment工作负载基础

3. Deployment 工作负载基础：ReplicaSet、Pod 生命周期、滚动更新策略与资源请求/限制配置

在 Kubernetes 生态中，Deployment 是最常用的无状态工作负载控制器。它通过管理 ReplicaSet 来间接管理 Pod，并提供声明式的更新与回滚能力。理解 Deployment 的底层组件与行为，是后续进行资源画像与成本优化的前提。

3.1 核心组件：ReplicaSet 与 Pod 的关系

Deployment 并不直接管理 Pod，而是通过 ReplicaSet 实现 Pod 副本的期望数量控制。每个 Deployment 版本对应一个 ReplicaSet，形成“Deployment → ReplicaSet → Pod”的三层结构。

  关键设计原则：Deployment 只负责版本控制与策略编排，ReplicaSet 负责副本数保证，Pod 是实际运行容器的最小单元。

3.2 Pod 生命周期与状态机

Pod 是 Kubernetes 中最小的调度单元，其生命周期包含多个阶段。理解这些状态有助于诊断资源瓶颈与异常行为。

阶段	状态值	说明
Pending	Pod 已被接受，但容器未全部启动	调度等待、镜像拉取、存储卷挂载
Running	至少一个容器正在运行	正常服务状态，资源消耗持续
Succeeded	所有容器正常退出	Job/CronJob 场景，Deployment 通常不进入此状态
Failed	至少一个容器非零退出	应用崩溃、OOMKilled、健康检查失败
Unknown	节点失联或 kubelet 无响应	网络分区、节点宕机

成本优化提示：大量 Pod 长时间处于 Pending 状态，通常意味着集群资源不足或调度策略不合理，应优先排查节点资源水位与 Pod 资源请求配置。

3.3 滚动更新策略

Deployment 默认使用 RollingUpdate 策略，通过控制 maxSurge 和 maxUnavailable 两个参数，实现平滑版本升级。这两个参数直接影响更新期间的资源消耗与可用性。

参数	默认值	含义	对成本的影响
`maxSurge`	25%	更新期间允许超出期望副本数的最大 Pod 数	值越大，临时资源占用越高
`maxUnavailable`	25%	更新期间允许不可用 Pod 的最大比例	值越小，资源冗余要求越高

滚动更新流程可概括为以下步骤：

用户更新 Deployment 的 Pod 模板（如镜像版本）
Deployment 创建新 ReplicaSet，并逐步增加新 Pod
同时逐步缩减旧 ReplicaSet 的 Pod 副本数
直到所有 Pod 都运行在新版本上，旧 ReplicaSet 保留为 0 副本

3.4 资源请求与限制配置

资源请求（requests）与限制（limits）是 Pod 定义中最关键的字段，直接影响调度决策、QoS 等级与成本核算。

字段	作用	调度依据	超卖风险
`requests.cpu`	保证的最小 CPU 资源	节点可分配 CPU 总量	低（CFS 配额保证）
`requests.memory`	保证的最小内存资源	节点可分配内存总量	低（不可压缩资源）
`limits.cpu`	CPU 使用上限（CFS 配额）	不参与调度	中（CPU 可压缩）
`limits.memory`	内存使用硬上限	不参与调度	高（OOMKilled 风险）

常见配置陷阱：将 limits.memory 设置过高而 requests.memory 设置过低，会导致节点内存超卖严重，触发 OOM Killer 频繁回收 Pod，影响服务稳定性并增加不必要的 Pod 重建成本。

3.5 资源配置示例

以下是一个标准的 Deployment YAML 配置片段，展示了资源请求与限制的声明方式：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        resources:
          requests:
            cpu: "500m"        # 0.5 核
            memory: "256Mi"    # 256 MiB
          limits:
            cpu: "1000m"       # 1 核
            memory: "512Mi"    # 512 MiB
        ports:
        - containerPort: 80

3.6 资源画像视角下的关键指标

从成本优化角度，需要关注以下与资源配置直接相关的指标：

资源利用率：实际使用量 / requests，理想范围 60%–80%
资源浪费率：(requests − 实际使用量) / requests，过高表示过度配置
OOM 频率：limits.memory 设置过低导致的容器重启次数
CPU 节流率：CPU 使用接近 limits 时触发的 CFS 节流比例

  成本优化基线：建议将 requests 设置为 P99 实际使用量的 1.2 倍，limits 设置为 requests 的 1.5–2 倍，在稳定性和资源效率之间取得平衡。