Kubernetes 文档 / 概念 / 工作负载 / Pod / Pod QoS 类

Kubernetes 文档 / 概念 / 工作负载 / Pod / Pod QoS 类

此文档从 Kubernetes 官网摘录
中文地址
英文地址
本页介绍 Kubernetes 中的 服务质量（Quality of Service，QoS） 类， 阐述 Kubernetes 如何根据为 Pod 中的容器指定的资源约束为每个 Pod 设置 QoS 类。 Kubernetes 依赖这种分类来决定当 Node 上没有足够可用资源时要驱逐哪些 Pod。

QoS 类

Kubernetes 基于每个 Pod 中容器的资源请求和限制为 Pod 设置 QoS 类。Kubernetes 使用 QoS 类来决定从遇到节点压力的 Node 中驱逐哪些 Pod。可选的 QoS 类有 Guaranteed、Burstable 和 BestEffort。 当一个 Node 耗尽资源时，Kubernetes 将首先驱逐在该 Node 上运行的 BestEffort Pod， 然后是 Burstable Pod，最后是 Guaranteed Pod。

Guaranteed

Guaranteed Pod 具有最严格的资源限制，并且最不可能面临驱逐。这些 Pod 不可以获得超出其指定 limit 的资源。这些 Pod 也可以使用 static CPU 管理策略来使用独占的 CPU.

Pod 被赋予 Guaranteed QoS 类的几个判据：

• Pod 中的每个容器必须有内存 limit 和内存 request。
• 对于 Pod 中的每个容器，内存 limit 必须等于内存 request。
• Pod 中的每个容器必须有 CPU limit 和 CPU request。
• 对于 Pod 中的每个容器，CPU limit 必须等于 CPU request。

Burstable

因为 Burstable Pod 可以包括没有资源 limit 或资源 request 的容器， 所以 Burstable Pod 可以尝试使用任意数量的节点资源。

Pod 被赋予 Burstable QoS 类的几个判据：

• Pod 不满足针对 QoS 类 Guaranteed 的判据。
• Pod 中至少一个容器有内存或 CPU 的 request 或 limit。

BestEffort

如果 Pod 不满足 Guaranteed 或 Burstable 的判据，则它的 QoS 类为 BestEffort。 换言之，只有当 Pod 中的所有容器没有内存 limit 或内存 request，也没有 CPU limit 或 CPU request 时，Pod 才是 BestEffort。

使用 cgroup v2 的内存 QoS

内存 QoS 使用 cgroup v2 的内存控制器来保证 Kubernetes 中的内存资源。 Pod 中容器的内存请求和限制用于设置由内存控制器所提供的特定接口 memory.min 和 memory.high。 当 memory.min 被设置为内存请求时，内存资源被保留并且永远不会被内核回收；

内存 QoS 使用 memory.high 来限制接近其内存限制的工作负载， 确保系统不会因瞬时内存分配而不堪重负。

某些行为独立于 QoS 类

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

• 所有超过资源 limit 的容器都将被 kubelet 杀死并重启，而不会影响该 Pod 中的其他容器。
• 如果一个容器超出了自身的资源 request，且该容器运行的节点面临资源压力，则该容器所在的 Pod 就会成为被驱逐的候选对象。 如果出现这种情况，Pod 中的所有容器都将被终止。Kubernetes 通常会在不同的节点上创建一个替代的 Pod。
• Pod 的资源 request 等于其成员容器的资源 request 之和，Pod 的资源 limit 等于其成员容器的资源 limit 之和。
• kube-scheduler 在选择要抢占的 Pod 时不考虑 QoS 类。当集群没有足够的资源来运行你所定义的所有 Pod 时，就会发生抢占。