Pod 服务质量等级

本页介绍了 Kubernetes 中的服务质量 (QoS) 类，并解释了 Kubernetes 如何将 QoS 类分配给每个 Pod，作为您为该 Pod 中的容器指定的资源约束的结果。Kubernetes 依赖于此分类来决定在节点上没有足够的可用资源时应该驱逐哪些 Pod。

服务质量类

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

保证型

Guaranteed的 Pod 具有最严格的资源限制，最不可能被驱逐。保证他们不会被杀死，直到他们超过其限制，或者没有可以从节点上抢占的更低优先级的 Pod。他们可能无法获取超出其指定限制的资源。这些 Pod 还可以使用static CPU 管理策略来使用专用 CPU。

标准

要使 Pod 被赋予 QoS 类Guaranteed

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

突发型

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

标准

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

  • Pod 不符合 QoS 类Guaranteed的标准。
  • Pod 中至少有一个容器具有内存或 CPU 请求或限制。

尽力型

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

如果节点遇到资源压力，kubelet 优先驱逐BestEffort Pod。

标准

如果 Pod 不符合Guaranteed或Burstable的标准，则该 Pod 具有BestEffort QoS 类。换句话说，只有当 Pod 中的任何容器都没有内存限制或内存请求，并且 Pod 中的任何容器都没有 CPU 限制或 CPU 请求时，Pod 才是BestEffort。Pod 中的容器可以请求其他资源（不是 CPU 或内存），但仍然被分类为BestEffort。

使用 cgroup v2 的内存 QoS

功能状态： Kubernetes v1.22 [alpha]

内存 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)