3. 运行基线模型:Pod生命周期、资源模型(CPU/Memory/Ephemeral Storage)与QoS等级

在云原生架构中,Pod 是最小调度单元,其生命周期、资源声明与服务质量(QoS)等级共同构成了运行基线的核心模型。本章从架构视角出发,深入解析这三个维度的设计原理与核验要点。

3.1 Pod 生命周期:从 Pending 到 Running 再到 Terminating

Pod 的生命周期由一系列状态组成,每个状态都对应着调度、拉取、运行或终止的关键阶段。理解这些状态是进行运行基线核验的前提。

状态 阶段描述 核验关注点
Pending Pod 已被 API Server 接受,但尚未调度到节点,或正在拉取镜像。 调度器是否因资源不足、污点/容忍度不匹配而阻塞。
Running Pod 已绑定到节点,所有容器已创建,至少有一个容器正在运行或正在启动。 容器是否持续 CrashLoopBackOff;就绪探针是否通过。
Succeeded Pod 中所有容器成功终止,且不会再重启(Job 场景)。 退出码是否为 0;日志是否完整。
Failed Pod 中所有容器终止,且至少一个容器以非零退出码终止。 错误日志、OOMKilled 事件、资源限制是否过小。
Unknown API Server 无法获取 Pod 状态,通常由节点失联导致。 节点心跳、网络分区、kubelet 是否异常。
架构建议: 在核验基线时,应重点监控 Pending 和 Unknown 状态的 Pod 数量。若 Pending 超过 30 秒,需排查调度策略或资源碎片;若 Unknown 出现,应立即触发节点自愈流程。

3.2 资源模型:CPU、Memory 与 Ephemeral Storage

资源模型定义了 Pod 对计算、内存和临时存储的请求(requests)与限制(limits)。这是调度决策和运行时 QoS 分类的基础。

3.2.1 资源单位与语义

资源类型 单位 requests 语义 limits 语义
CPU cores(如 100m = 0.1 core) 调度保证的最小 CPU 时间 CPU 时间硬上限(CFS quota)
Memory bytes(如 256Mi, 1Gi) 调度保证的最小内存 内存硬上限(OOM Killer 触发)
Ephemeral Storage bytes(如 10Gi) 节点上临时存储的最小保证 临时存储硬上限(Pod 驱逐)
常见陷阱: 许多团队只设置 limits 而不设置 requests,这会导致调度器无法准确计算节点资源占用,造成节点过载和 Pod 驱逐。基线核验要求:requests 必须等于 limits(Guaranteed QoS)或至少设置 requests。

3.2.2 资源模型配置示例

apiVersion: v1
kind: Pod
metadata:
  name: baseline-pod
spec:
  containers:
  - name: app
    image: nginx:1.25
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"
        ephemeral-storage: "1Gi"
      limits:
        cpu: "500m"
        memory: "512Mi"
        ephemeral-storage: "2Gi"

3.3 QoS 等级:Guaranteed、Burstable 与 BestEffort

Kubernetes 根据 Pod 中所有容器的资源 requests 和 limits 设置,自动将 Pod 划分为三个 QoS 等级。该等级决定了节点资源竞争时的驱逐优先级。

3.3.1 等级判定规则

QoS 等级 判定条件 驱逐优先级(越低越优先保留)
Guaranteed 所有容器均设置了 requests 和 limits,且每个资源的 requests == limits 最低(最优先保留)
Burstable 至少一个容器设置了 requests 或 limits,且不满足 Guaranteed 条件 中等
BestEffort 没有任何容器设置任何 requests 或 limits 最高(最先被驱逐)

3.3.2 QoS 等级与资源竞争行为

  • CPU 竞争: Guaranteed Pod 获得完整的 CPU 时间片;Burstable Pod 在节点空闲时可使用超出 requests 的 CPU;BestEffort Pod 只能使用剩余 CPU。
  • 内存竞争: 当节点内存不足时,kubelet 按 QoS 等级从低到高驱逐 Pod。BestEffort 最先被驱逐,Guaranteed 最后。
  • Ephemeral Storage 竞争: 当节点临时存储使用率超过阈值(默认 85%)时,同样按 QoS 等级驱逐。
基线核验策略: 生产环境核心服务必须配置为 Guaranteed 等级;非关键批处理任务可配置为 Burstable;禁止在正式环境中使用 BestEffort,除非是明确的低优先级日志采集或监控 sidecar。

3.4 运行基线模型总览图

下图展示了 Pod 生命周期状态、资源模型与 QoS 等级之间的关联关系,以及它们在节点资源竞争时的交互逻辑。

运行基线模型:Pod生命周期、资源模型与QoS等级 运行基线模型总览 Pod 生命周期 Pending → Running Running → Succeeded/Failed Terminating → Unknown 核验点:状态转换耗时 资源模型 CPU: requests / limits Memory: requests / limits Ephemeral Storage 核验点:requests == limits QoS 等级 Guaranteed(最低驱逐) Burstable(中等驱逐) BestEffort(最高驱逐) 核验点:核心服务 Guaranteed 运行基线核验核心逻辑 Pod 生命周期状态 → 资源模型(requests/limits)→ QoS 等级 → 驱逐优先级 核验目标:确保核心服务处于 Guaranteed 等级,生命周期状态稳定,资源声明合理

3.5 核验清单与架构决策

在架构设计阶段,建议将以下核验点纳入运行基线检查清单:

  1. 生命周期核验: 确认所有 Pod 的 restartPolicy 符合业务场景;就绪探针和存活探针配置合理,避免因探针失败导致 Pod 频繁重启。
  2. 资源模型核验: 使用 kubectl describe node 检查节点资源分配率;确保 requests 不超过节点可分配资源的 80%,预留系统守护进程和 kubelet 开销。
  3. QoS 等级核验: 通过 kubectl get pod -o jsonpath='{.status.qosClass}' 批量检查所有 Pod 的 QoS 等级;对非 Guaranteed 的 Pod 进行逐一定位和整改。
  4. 驱逐策略核验: 确认 kubelet 的 --eviction-hard 和 --eviction-soft 参数配置,确保与 QoS 等级驱逐优先级一致。
架构决策建议: 在集群初始化阶段,通过准入控制器(如 OPA/Gatekeeper)强制要求所有生产命名空间的 Pod 必须设置资源 requests 和 limits,且 CPU 和 Memory 的 requests 必须等于 limits,从而从源头保证 Guaranteed QoS 等级。