Author：rab

---

---

前言

前面提到了 Kubernetes 的准入控制策略，那你有没有想过一个问题：如果 Pod 运行的当前 Node 节点的资源不足了，那该 Pod 如何被逐出呢？因此，这里就提到了服务质量类（Quality of Service class，QoS class），Kubernetes 在 Node 资源不足时使用 QoS 类策略来就驱逐 Pod。

Kubernetes 创建 Pod 时，会将如下 QoS 类之一设置到 Pod 上：

• Guaranteed
• Burstable
• BestEffort

至于 Pod 会被设置为哪一个 Qos 类，取决于 Pod 容器中 limits 的取值。

一、QoS 类为 Guaranteed 的 Pod

1.1 概述

当为 Pod 的 Qos 为 Guaranteed 时，要求在创建 Pod 前，应配置 Pod 的资源限制（Resource Limits）和资源请求（Resource Requests）相等。这意味着 Pod 请求了特定数量的资源，并且该数量是 Pod 所能获得的最小资源量。因此，Guaranteed 级别通常用于关键应用，确保它们始终获得它们所需的资源。

1.2 案例

下面是包含一个 Container 的 Pod 清单。该 Container 设置了内存请求和内存限制，值都是 200 MiB。 该 Container 设置了 CPU 请求和 CPU 限制，值都是 700 milliCPU。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"
      requests:
        memory: "200Mi"
        cpu: "700m"

**说明：**如果某 Container 指定了自己的内存限制，但没有指定内存请求，Kubernetes 会自动为它指定与内存限制相等的内存请求。同样，如果容器指定了自己的 CPU 限制， 但没有指定 CPU 请求，Kubernetes 会自动为它指定与 CPU 限制相等的 CPU 请求。也就是说，QoS 类为 Guaranteed 的 Pod 除了能想以上案例这样写之外，还可以这样写：

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "700m"

此时，Kubernetes 会自动为它指定与 CPU 限制相等的 CPU 请求，以及与内存限制相等的内存请求。

查看 Pod 详情：

kubectl get pod qos-demo --namespace=qos-example --output=yaml

spec:
  containers:
    ...
    resources:
      limits:
        cpu: 700m
        memory: 200Mi
      requests:
        cpu: 700m
        memory: 200Mi
    ...
status:
  qosClass: Guaranteed

可见 Pod 的 status 为 Guaranteed。

二、QoS 类为 Burstable 的 Pod

2.1 概述

当为 Pod 的 Qos 为 Burstable 时，要求在创建 Pod 前，应配置 Pod 的资源请求小于资源限制。Pod 可以使用比其请求的资源更多的资源，但在高负载情况下可能会受到竞争，资源可能不足。因此，Burstable 级别通常用于需要灵活性的应用，但不需要保证资源的固定数量的应用。

2.2 案例

下面是包含一个 Container 的 Pod 清单。该 Container 设置的内存限制为 200 MiB， 内存请求为 100 MiB。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-2
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-2-ctr
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

查看 Pod 详情：

kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml

spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: qos-demo-2-ctr
    resources:
      limits:
        memory: 200Mi
      requests:
        memory: 100Mi
  ...
status:
  qosClass: Burstable

可见 Pod 的 status 为 Burstable。

三、QoS 类为 BestEffort 的 Pod

3.1 概述

当为 Pod 的 Qos 为 Guaranteed 时，要求创建 Pod 时无需设置资源请求及资源限制。于是 Pod 可以使用节点上的所有可用资源，但无法保证获取足够的资源，可能会受到节点上其他 Pod 的影响。因此，BestEffort 级别通常用于非关键应用，如测试应用或不太重要的工作负载。

3.2 案例

下面是包含一个 Container 的 Pod 清单。该 Container 没有设置内存和 CPU 限制或请求。

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo-3
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-3-ctr
    image: nginx

查看 Pod 详情：

kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml

spec:
  containers:
    ...
    resources: {}
  ...
status:
  qosClass: BestEffort

可见 Pod 的 status 为 BestEffort。

那问题来了：当节点资源不足时，哪些 Pod 应该首先被删除以释放资源呢？

• BestEffort 级别的 Pod 通常是首先被删除的，因为它们没有设置资源请求，它们的删除优先级最低。在节点资源不足时，Kubernetes 会首先回收 BestEffort 级别的 Pod，以腾出更多的资源。
• Burstable 级别的 Pod 相对于 Guaranteed 级别的 Pod 有较低的删除优先级。当节点资源不足时，Burstable 级别的 Pod 会在回收Guaranteed 级别的 Pod 之前被删除。
• Guaranteed 级别的 Pod 通常是最后被删除的。它们的资源请求和资源限制相等，因此它们被认为是高优先级的Pod。在节点资源不足时，Kubernetes 通常首先回收 BestEffort 级别的 Pod，然后回收 Burstable 级别的 Pod，最后才回收 Guaranteed 级别的 Pod。

总结

Kubernetes（K8s）中的 QoS（Quality of Service）是一个用于分类和管理 Pod 的资源要求和限制的机制。QoS分类有三个级别：Guaranteed、Burstable 和 BestEffort，这些级别反映了 Pod 对 CPU 和内存资源的使用要求。QoS 级别用于帮助 Kubernetes 调度器和资源管理器更好地管理和分配资源，以确保各个 Pod 在共享的节点上能够得到合理的资源分配。

当 Node 节点资源不足时，先删除服务质量为 BestEffort 的 Pod，然后在删除 Burstable 的 Pod，最后再删除 Guaranteed 的 Pod。

—END