Pod 的服务质量等级

本页面介绍了 Kubernetes 中的服务质量 (QoS) 类，并解释了 Kubernetes 如何根据您为 Pod 中的容器指定的资源约束，为每个 Pod 分配 QoS 类。Kubernetes 依赖此分类来决定在节点上资源不足时要驱逐哪些 Pod。

服务质量类

Kubernetes 对您运行的 Pod 进行分类，并将每个 Pod 分配到特定的服务质量 (QoS) 类。 Kubernetes 使用该分类来影响如何处理不同的 Pod。Kubernetes 基于 Pod 中资源请求以及这些请求与资源限制的关系进行分类。容器这就是所谓的服务质量 (QoS) 类。Kubernetes 根据其组件容器的资源请求和限制为每个 Pod 分配一个 QoS 类。Kubernetes 使用 QoS 类来决定从经历节点压力的节点中驱逐哪些 Pod。可能的 QoS 类为 Guaranteed、Burstable 和 BestEffort。当节点资源耗尽时，Kubernetes 将首先驱逐该节点上运行的 BestEffort Pod，然后是 Burstable Pod，最后是 Guaranteed Pod。当此驱逐是由于资源压力时，只有超出资源请求的 Pod 才会成为驱逐的候选者。

Guaranteed

Guaranteed Pod 具有最严格的资源限制，并且最不可能面临驱逐。 保证在它们超出其限制或没有可以从节点抢占的优先级较低的 Pod 之前不会被杀死。它们可能不会获取超出其指定限制的资源。这些 Pod 还可以使用 static CPU 管理策略来使用独占 CPU。

标准

要使 Pod 被赋予 Guaranteed 的 QoS 类

  • Pod 中的每个容器都必须具有内存限制和内存请求。
  • 对于 Pod 中的每个容器，内存限制必须等于内存请求。
  • Pod 中的每个容器都必须具有 CPU 限制和 CPU 请求。
  • 对于 Pod 中的每个容器，CPU 限制必须等于 CPU 请求。

Burstable

Burstable Pod 基于请求具有一些下限资源保证，但不要求特定的限制。如果未指定限制，则默认设置为与节点容量等效的限制，这允许 Pod 在资源可用时灵活地增加其资源。如果由于节点资源压力而导致 Pod 被驱逐，则仅在所有 BestEffort Pod 被驱逐后才驱逐这些 Pod。由于 Burstable Pod 可以包含没有资源限制或请求的容器，因此 Burstable Pod 可以尝试使用任意数量的节点资源。

标准

如果满足以下条件，则 Pod 将被赋予 Burstable 的 QoS 类

  • Pod 不满足 QoS 类 Guaranteed 的条件。
  • Pod 中至少有一个容器具有内存或 CPU 请求或限制。

BestEffort

BestEffort QoS 类中的 Pod 可以使用未明确分配给其他 QoS 类中的 Pod 的节点资源。例如，如果您的节点有 16 个可供 kubelet 使用的 CPU 核心，并且您将 4 个 CPU 核心分配给 Guaranteed Pod，那么 BestEffort QoS 类中的 Pod 可以尝试使用剩余 12 个 CPU 核心中的任意数量。

如果节点受到资源压力，kubelet 更倾向于驱逐 BestEffort Pod。

标准

如果 Pod 不满足 Guaranteed 或 Burstable 的条件，则该 Pod 的 QoS 类为 BestEffort。换句话说，仅当 Pod 中的容器都没有内存限制或内存请求，并且 Pod 中的容器都没有 CPU 限制或 CPU 请求时，Pod 才为 BestEffort。Pod 中的容器可以请求其他资源（非 CPU 或内存），并且仍然被归类为 BestEffort。

使用 cgroup v2 的内存 QoS

特性状态： Kubernetes v1.22 [alpha]（默认禁用：false）

内存 QoS 使用 cgroup v2 的内存控制器来保证 Kubernetes 中的内存资源。Pod 中容器的内存请求和限制用于设置内存控制器提供的特定接口 memory.min 和 memory.high。当 memory.min 设置为内存请求时，内存资源将被保留，并且永远不会被内核回收；这就是内存 QoS 确保 Kubernetes Pod 内存可用性的方式。如果在容器中设置了内存限制，则表示系统需要限制容器内存使用量；内存 QoS 使用 memory.high 来限制接近其内存限制的工作负载，从而确保系统不会被瞬时内存分配淹没。

内存 QoS 依赖于 QoS 类来确定要应用哪些设置；但是，这些是不同的机制，它们都提供了对服务质量的控制。

某些行为独立于 QoS 类

某些行为独立于 Kubernetes 分配的 QoS 类。例如

  • 任何超出资源限制的容器都将被 kubelet 杀死并重新启动，而不会影响该 Pod 中的其他容器。

  • 如果容器超出其资源请求并且其运行所在的节点面临资源压力，则该容器所在的 Pod 将成为驱逐的候选对象。如果发生这种情况，则 Pod 中的所有容器都将被终止。Kubernetes 可能会创建一个替换 Pod，通常是在不同的节点上。

  • Pod 的资源请求等于其组件容器的资源请求之和，Pod 的资源限制等于其组件容器的资源限制之和。

  • kube-scheduler 在选择要抢占哪些 Pod 时，不考虑 QoS 类。当集群没有足够的资源来运行您定义的所有 Pod 时，可能会发生抢占。

下一步是什么

上次修改时间：太平洋标准时间 2024 年 4 月 20 日 凌晨 12:16：修复 pod-qos.md 中的特性状态 (aeb36c0c72)