Linux 知识库

Appearance

Kubernetes-QoS资源分配策略 ​

Kubernetes 的 Quality of Service (QoS) 是集群资源管理的核心机制，它通过精细化的资源分配策略，确保不同优先级的 Pod 在资源竞争环境下获得适当的处理。本文将全面解析 Kubernetes QoS 的分类标准、实现原理、应用场景以及最佳实践，帮助您深入理解并有效运用这一关键特性。

QoS 分类与判定标准 ​

Kubernetes 根据 Pod 中容器的资源请求(Requests)和限制(Limits)配置，自动将 Pod 划分为三个 QoS 等级，每个等级对应不同的资源保障强度和驱逐优先级。

1. Guaranteed (最高保障) ​

核心特征：

  • Pod 中所有容器都必须设置 CPU 和内存的 Requests 和 Limits，且两者的值必须完全相同
  • 如果容器只指定了 Limits 而未设置 Requests，Kubernetes 会自动将 Requests 设置为与 Limits 相同的值
  • 适用于数据库、支付系统等关键核心服务，需要严格资源保障的场景

配置示例：

yaml
apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: app-container
    image: nginx
    resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "500m"

说明：所有容器的 Requests 和 Limits 完全一致，确保资源独占性

2. Burstable (可突增资源) ​

核心特征：

  • Pod 不满足 Guaranteed 的条件，但至少有一个容器设置了内存或 CPU 的 Requests
  • 允许容器在节点资源充足时临时超出 Requests 的限制，但在资源不足时可能被限制或终止
  • 适用于普通应用如 Web 服务，需要在资源保障和利用率之间取得平衡的场景

配置示例：

yaml
apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: app-container
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "200m"
      limits:
        memory: "1Gi"
        cpu: "2"

说明：Requests 和 Limits 不一致，容器可获得最低保障但也能在资源充足时突发使用更多资源

3. BestEffort (尽力而为) ​

核心特征：

  • Pod 中所有容器均未设置任何内存或 CPU 的 Requests 和 Limits
  • 没有任何资源保障，在节点资源紧张时会被优先终止
  • 适用于临时测试任务等非关键业务，对资源可用性要求不高的场景

配置示例：

yaml
apiVersion: v1
kind: Pod
metadata:
  name: besteffort-pod
spec:
  containers:
  - name: app-container
    image: nginx
    resources: {}  # 未设置任何requests和limits

QoS 的影响与实现原理 ​

资源调度与驱逐优先级 ​

Kubernetes 根据 QoS 等级实施差异化的资源管理策略：

  1. 调度优先级：

    • Guaranteed Pod 在调度时获得最高优先级，更容易分配到资源充足的节点
    • BestEffort Pod 可能因节点资源不足而处于 Pending 状态

  2. 驱逐顺序： 当节点资源(CPU、内存)不足时，Kubernetes 按以下顺序驱逐 Pod：

    BestEffort → Burstable → Guaranteed
    • 内存耗尽时，BestEffort Pod 会最先被终止，其次是 Burstable，最后才是 Guaranteed
    • 对于 Burstable Pod，系统会优先终止超过 Requests 最多的容器

OOM 评分机制 ​

Kubernetes 通过 Linux 内核的 OOM(Out Of Memory) Killer 机制实现 QoS 优先级控制：

  1. OOM 评分调整(oom_score_adj)：

    • 每个进程都有 oom_score 值(0-2000)，数值越高被终止概率越大
    • Kubernetes 通过设置 oom_score_adj(-1000到+1000)影响 oom_score 计算

  2. 各类 QoS 的默认值：

    • Guaranteed: -997 (几乎不会被 OOM Killer 选中)
    • BestEffort: 1000 (最高值，最先被终止)
    • Burstable: 动态计算，公式为 min(max(2, 1000 - (1000 * memoryRequestBytes)/machineMemoryCapacityBytes), 999)
      • 确保所有 Burstable 容器在使用完 Requested 内存时具有相同的规范化 oom_score
      • 超过 Requests 内存使用的容器会有更高 oom_score，被优先终止

  3. 系统关键组件保护：

    • kubelet 和 docker 的 oom_score_adj 设置为 -999，永远不会因 OOM 被终止

资源类型差异处理 ​

Kubernetes 对可压缩资源(如 CPU)和不可压缩资源(如内存)采用不同的管理策略：

  1. CPU 资源(可压缩)：

    • 当 Pod 使用超过 Limits 时，进程不会被终止，但会被限制 CPU 使用
    • 如果没有设置 Limits，Pod 可以使用全部空闲 CPU 资源

  2. 内存资源(不可压缩)：

    • 当 Pod 使用超过 Limits 时，容器进程会被内核因 OOM 立即终止
    • 系统倾向于在原节点上重启该容器或创建新 Pod

生产环境配置建议 ​

  1. 应用分类策略：

    • 核心应用(如数据库)：设置为 Guaranteed，确保资源独占性
    • 常规应用(如 Web 服务)：设置为 Burstable，平衡保障与利用率
    • 辅助应用(如日志收集)：设置为 BestEffort，充分利用闲置资源

  2. 节点分区部署：

    • 将集群节点分为核心节点、常规节点和辅助节点
    • 通过 nodeAffinity 实现定向调度：
      yaml
      affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:  # 核心应用用prefer策略
      - weight: 100
        preference:
          matchExpressions:
          - key: node-type
            operator: In
            values: ["core"]

  3. Java 应用特别配置：

    • 设置 JVM 堆大小(-Xmx)低于容器内存 Limits，预留空间给非堆内存
    • 考虑使用 EmptyDir 作为内存文件系统，避免磁盘 IO 瓶颈

常见问题与故障排查 ​

QoS 不生效场景分析 ​

  1. 节点资源完全耗尽：

    • 即使 Guaranteed Pod 也可能被终止
    • 解决方案：设置合理的集群资源超配比例，监控节点资源水位

  2. cgroup 配置错误：

    • 检查 /sys/fs/cgroup/memory/kubepods/ 下子目录是否正确
    • 确保 kubelet 的 --cgroups-per-qos=true 参数启用

  3. OOM 事件诊断：

    • 查看内核日志获取详细 OOM 信息：
      bash
      dmesg | grep -i oom
    • 检查被终止容器的 Exit Code 是否为 137(OOMKilled)

特殊资源类型支持 ​

  1. 大内存页(HugePage)：

    yaml
    resources:
  limits:
    hugepages-2Mi: 1Gi
    memory: 1Gi
  requests:
    memory: 1Gi

    效果：提高内存密集型应用的性能，减少内存碎片

  2. 临时存储(Ephemeral Storage)：

    • Kubernetes 1.31+ 默认驱逐策略：
      • nodefs.available < 10%
      • nodefs.inodesFree < 5%
      • imagefs.available < 15%