QoS 优先级

在 Pod 的调度过程中，不是仅依靠 Pod 的 requests 中指定的资源申请量来衡量的，因为还存在一些没有指定申请量和限制量的 Pod，这些 Pod 可能会占满整个宿主机的资源，这是非常可怕的，因此 Kubernetes 提出了优先级的概念，为 Pod 提供优先级标识，低优先级的 Pod 可以被高优先级的 Pod 剥夺资源。

🐳 这里主要是指内存资源，因为 Pod 会因内存资源不足而被杀死，而不会因为 CPU 资源不足而被杀死

☃️ Pod 的 QoS 优先级包含三种，由 Kubernetes 根据 Pod 中容器的 requests 和 limits 划分，而不是由用户手动指定：

• BestEffort（优先级最低）

• Burstable

• Guarranteed（优先级最高）

可以通过 kubectl describe pods 以及通过 Pod 的 YAML 描述文件中的 status.qosClass 查看该 Pod 的 QoS 优先级。

QoS 优先级定义

上面提到，Kubernetes 中共有三种等级划分，并且是根据 Pod 中容器的 requests 和 limits 划分，下面根据不同的优先级说明定义规则。

BestEffort

BestEffort 优先级最低。当 Pod 中没有任何容器指定了 requests 或 limits 时，该 Pod 的优先级为 BestEffort。

在需要为其他 Pod 释放内存资源时，这些 Pod 会被第一批杀死。但是在不被杀死时，由于其没有设置 limits，因此这类容器可以使用尽可能多的资源。

Guarranteed

Guarranteed 优先级最高。该优先级的 Pod 需要满足下面三个条件：

• CPU 和 内存都要设置 requests 和 limits；

• Pod 中每个容器都要设置；

• 每种资源的 requests 和 limits 的值必须相等；

因此该优先级的 Pod 可以使用它所申请的等额资源，但是无法消耗更多的资源（因为它们的资源申请量和限制量相等）。

Burstable

Burstable 优先级居中。只需要记住上面两种优先级的 Pod 的特点，除了上述两种优先级的 Pod，其他任意一种 Pod 都是 Burstable 优先级。

内存不足时进程的杀死顺序

Pod 的 QoS 等级决定了内存资源不足时被杀死的顺序。下面分两种情况讨论：

1. 处理具有不同 QoS 优先级的 Pod；

2. 处理具有相同 QoS 优先级的 Pod；

处理不同 QoS 优先级 Pod

这种情况就比较简单，直接将低优先级的 Pod 杀死，将其资源提供给高优先级的 Pod 使用。

BestEffort 优先级的 Pod 首先被杀死，其次是 Burstable 优先级的 Pod，最后是 Guarranteed 优先级的 Pod。Guarranteed 优先级的 Pod 只有在系统进程需要内存时才会被杀掉。

处理相同 QoS 优先级 Pod

🐙 相同 QoS 优先级 Pod 之间的处理是依赖 Linux 的 oom_score 机制，在 Linux 系统中，每个进程都有一个 OOM 分值，可以通过 /proc/$PID/oom_score 查看指定进程的分值，当需要释放内存时，该分值越高的进程将被杀死。

OOM 分值主要由两个参数计算得到：

1. 进程已消耗内存占宿主机总的可分配内存的百分比；

2. /proc/$PID/oom_score_adj OOM 分值调节因子，该因子范围是从 -1000 到 1000，值越小，OOM 分值越低，则进程越不容易被杀死；