3、资源分配核心概念：CPU与内存资源模型、资源请求与限制、服务质量QoS等级

在 Serverless 事件驱动场景下，集群升级的核心挑战在于：如何在保证存量函数稳定运行的同时，为升级组件（如 kubelet、CNI 插件、Sidecar 注入器）预留足够的计算资源。理解 Kubernetes 的资源模型是制定分配策略的基础。

3.1 CPU 与内存资源模型

Kubernetes 将物理节点资源抽象为可调度的“资源池”。CPU 和内存是两种最核心的可压缩与不可压缩资源，其模型差异直接影响升级时的资源预留策略。

资源类型 单位 可压缩性 回收机制 升级影响
CPU m（毫核，1 核 = 1000m） 可压缩 通过 CFS 配额限流，不杀死 Pod 升级时 CPU 争抢导致函数延迟增加
内存 Mi / Gi（字节） 不可压缩 超出 Limit 触发 OOM Kill 升级时内存不足导致函数 Pod 被驱逐
关键认知： CPU 是可压缩资源，过载时只会变慢，不会崩溃；内存是不可压缩资源，过载时直接杀死进程。在集群升级期间，内存资源的预留比 CPU 更敏感，必须设置严格的 Buffer。
CPU 与内存资源模型对比 CPU 与内存资源模型对比 CPU（可压缩） 单位：m（毫核） CFS 配额限流 过载时：延迟增加 不杀死 Pod 升级策略：预留 10%-20% CPU Buffer 内存（不可压缩） 单位：Mi / Gi OOM Killer 机制 过载时：Pod 被杀死 业务中断风险高 升级策略：预留 20%-30% 内存 Buffer

3.2 资源请求（Requests）与限制（Limits）

Requests 和 Limits 是 Kubernetes 调度与执行阶段的两种约束。Requests 用于调度决策，Limits 用于运行时压制。理解两者的差异是避免升级期间资源碎片的关键。

3.2.1 核心定义

  • Requests（请求）： Pod 启动时向集群“声明”的最小资源保证。调度器依据节点剩余可分配资源（Allocatable）是否满足所有 Pod 的 Requests 之和来决定调度位置。
  • Limits（限制）： Pod 在运行时允许使用的资源上限。对于 CPU，超过 Limits 会被限流；对于内存，超过 Limits 会触发 OOM Kill。

3.2.2 典型配置模式

模式 Requests Limits 适用场景 升级风险
Guaranteed 等于 Limits 等于 Requests 延迟敏感型函数 资源预留充足，升级安全
Burstable 小于 Limits 大于 Requests 允许突发流量函数 升级时可能超卖，需预留 Buffer
BestEffort 不设置 不设置 批处理/非关键任务 升级时极易被驱逐
升级避坑： 在 Serverless 场景下，函数 Pod 通常使用 Burstable 模式（Requests 较低，Limits 较高）。集群升级时，如果节点上所有 Pod 的 Requests 之和已经接近节点容量，升级组件（如 DaemonSet 类型的 Sidecar）将无法获得调度资源，导致升级阻塞。建议在升级前将关键函数的 Requests 临时提升至 Limits 的 80%，转为 Guaranteed 模式。

3.3 服务质量 QoS 等级

Kubernetes 根据 Pod 的 Requests 和 Limits 配置，自动将 Pod 划分为三个 QoS 等级。当节点资源紧张时，kubelet 按照 QoS 等级从低到高驱逐 Pod。

QoS 等级与驱逐优先级 QoS 等级与驱逐优先级 BestEffort 无 Requests 无 Limits 驱逐优先级：最高 升级时最先被驱逐 Burstable Requests < Limits 部分资源保证 驱逐优先级：中等 升级时可能被驱逐 Guaranteed Requests = Limits 完全资源保证 驱逐优先级：最低 升级时最安全 驱逐优先级：BestEffort > Burstable > Guaranteed

3.3.1 驱逐顺序与升级策略

  1. BestEffort Pod： 节点内存压力达到阈值时，kubelet 首先驱逐 BestEffort Pod。在升级前，应确保所有非关键 BestEffort Pod 已迁移或删除。
  2. Burstable Pod： 当 BestEffort Pod 全部驱逐后仍无法缓解压力，kubelet 开始驱逐 Burstable Pod。Serverless 函数 Pod 多属此类，升级时需通过 PDB（PodDisruptionBudget）保护核心函数。
  3. Guaranteed Pod： 只有系统级组件（如 kube-system 命名空间下的 Pod）才应设置为 Guaranteed。升级期间，Guaranteed Pod 几乎不会被驱逐。
升级资源分配最佳实践：
  • 将集群升级相关的 DaemonSet（如节点代理、监控采集器）设置为 Guaranteed QoS，确保升级过程中这些组件不被驱逐。
  • 对核心 Serverless 函数设置 PDB，允许最多 10% 的 Pod 同时不可用，避免升级时大规模驱逐。
  • 在升级窗口前，通过 Vertical Pod Autoscaler 临时提升函数 Pod 的 Requests，使其进入 Burstable 高优先级区间。

3.4 资源分配与升级的关联模型

综合以上概念，集群升级时的资源分配可以抽象为以下公式：

节点可分配资源 = 节点容量 - 系统预留 - kubelet 预留
升级可用资源 = 节点可分配资源 - 所有 Pod Requests 之和
升级组件所需资源 = 升级 DaemonSet Requests + 临时 Buffer

只有当 升级可用资源 >= 升级组件所需资源 时，升级才能顺利进行。否则，需要执行以下操作之一：

  • 驱逐部分低 QoS Pod（BestEffort 优先）
  • 临时提升节点容量（如弹性节点池）
  • 分批升级，每次只升级少量节点
← 上一章 📖 返回目录 下一章 →