3. 运行基线模型

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

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

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

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

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

3.2.1 资源单位与语义

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 等级判定规则

3.3.2 QoS 等级与资源竞争行为

• CPU 竞争： Guaranteed Pod 获得完整的 CPU 时间片；Burstable Pod 在节点空闲时可使用超出 requests 的 CPU；BestEffort Pod 只能使用剩余 CPU。
• 内存竞争： 当节点内存不足时，kubelet 按 QoS 等级从低到高驱逐 Pod。BestEffort 最先被驱逐，Guaranteed 最后。
• Ephemeral Storage 竞争： 当节点临时存储使用率超过阈值（默认 85%）时，同样按 QoS 等级驱逐。

3.4 运行基线模型总览图

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

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 等级驱逐优先级一致。