Pod 服务质量等级

本页面介绍 Kubernetes 中的**服务质量 (QoS) 等级**，并解释 Kubernetes 如何根据为 Pod 中的容器所指定的资源约束为每个 Pod 分配一个 QoS 等级。Kubernetes 依赖于这种分类，以便在节点上没有足够的可用资源时决定驱逐哪些 Pod。

服务质量等级

Kubernetes 对你运行的 Pod 进行分类，并将每个 Pod 分配到特定的**服务质量 (QoS) 等级**。Kubernetes 使用该分类来影响不同 Pod 的处理方式。Kubernetes 根据 Pod 中容器的资源请求以及这些请求与资源限制的关系来进行这种分类。这被称为服务质量 (QoS) 等级。Kubernetes 根据 Pod 的组成容器的资源请求和限制为每个 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 驱逐的情况下，这些 Pod 只会在所有 BestEffort Pod 被驱逐后才会被驱逐。由于 Burstable Pod 可以包含没有资源限制或请求的容器，因此 Burstable Pod 可以尝试使用任何量的节点资源。

标准

如果满足以下条件，Pod 会被赋予 Burstable QoS 等级：

  • Pod 不满足 Guaranteed QoS 等级的标准。
  • Pod 中至少有一个容器设置了内存或 CPU 请求或限制。

BestEffort

BestEffort QoS 等级中的 Pod 可以使用未专门分配给其他 QoS 等级 Pod 的节点资源。例如，如果你有一个节点，kubelet 有 16 个 CPU 核可用，而你为一个 Guaranteed Pod 分配了 4 个 CPU 核，那么 BestEffort QoS 等级中的 Pod 可以尝试使用剩余的 12 个 CPU 核中的任意数量。

如果节点面临资源压力，kubelet 倾向于驱逐 BestEffort Pod。

标准

如果 Pod 不满足 Guaranteed 或 Burstable 的标准，则其 QoS 等级为 BestEffort。换句话说，只有当 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 AM PST：修复了 pod-qos.md 中的特性状态 (aeb36c0c72)