k8s Quality of Service

文章目录

- - [QoS 分类规则](#QoS 分类规则)
  - [QoS 类别影响](#QoS 类别影响)
  - [创建 QoS 分类的案例](#创建 QoS 分类的案例)
  - [1. Guaranteed QoS 示例](#1. Guaranteed QoS 示例)
  - - [示例 YAML 文件：](#示例 YAML 文件：)
  - [2. Burstable QoS 示例](#2. Burstable QoS 示例)
  - - [示例 YAML 文件：](#示例 YAML 文件：)
  - [3. BestEffort QoS 示例](#3. BestEffort QoS 示例)
  - - [示例 YAML 文件：](#示例 YAML 文件：)
  - [4. 混合 QoS 示例（多个容器）](#4. 混合 QoS 示例（多个容器）)
  - - [示例 YAML 文件：](#示例 YAML 文件：)
  - [5. Pod QoS 分配总结](#5. Pod QoS 分配总结)
  - [查看 QoS 类别](#查看 QoS 类别)
  - 总结

Kubernetes 提供了 Quality of Service (QoS) 的功能，以帮助管理和保障 Pod 的资源分配。QoS 分类机制根据 Pod 请求和限制的资源配置，将 Pod 分为三种类型，分别是：

Guaranteed：资源请求和限制都已明确设置，并且一致。适用于最需要严格资源保证的场景。
Burstable：只设置了资源请求，或者请求和限制不一致，适用于对资源有一定保证，但仍然能够利用节点余量的容器。
BestEffort：没有设置资源请求和限制。适用于最不重要、能够被最优先终止的容器。

QoS 分类规则

Guaranteed ：如果 Pod 中的所有容器都设置了 请求和限制 且请求和限制的值相同，那么该 Pod 会被分配到 Guaranteed 类别。
Burstable ：如果 Pod 中的容器设置了请求和限制，但是请求和限制的值不相同，或者有些容器没有设置 limit，那么该 Pod 会被分配到 Burstable 类别。
BestEffort ：如果 Pod 中的所有容器都没有设置任何 请求和限制 ，那么该 Pod 会被分配到 BestEffort 类别。

QoS 类别影响

Guaranteed：这种类型的 Pod 会得到最优的资源保障，它不会被调度到资源过载的节点上，也不会被 OOM（Out Of Memory）或系统压力杀死。
Burstable：这种类型的 Pod 可能会在资源紧张时被限制或终止，尤其是在其他 Pod 需要更多资源时。
BestEffort：这种类型的 Pod 是最容易被抢占和杀死的，尤其在节点资源不足时，Kubernetes 会优先选择终止它们。

创建 QoS 分类的案例

以下是几个示例，展示了不同类型的 QoS 分类如何在实际应用中使用。

1. Guaranteed QoS 示例

Guaranteed QoS 适用于那些希望获得最大资源保障的应用，容器的 请求和限制 设置为相同的值。

示例 YAML 文件：

yaml 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: app-container
    image: nginx
    resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "500m"

requests 和 limits 都设置为相同的值 512Mi 和 500m。
这种配置确保了该容器会被分配并保证获得 500m 的 CPU 和 512Mi 的内存，且不会超出这个限制，因此属于 Guaranteed QoS 类型。

2. Burstable QoS 示例

Burstable QoS 适用于那些希望获得一定资源保证，但同时允许在节点有剩余资源时 "突发" 使用更多资源的应用。

示例 YAML 文件：

yaml 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: app-container
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "200m"
      limits:
        memory: "1Gi"
        cpu: "2"

requests 设置了 256Mi 的内存和 200m 的 CPU，表示容器的最小资源需求。
limits 设置了 1Gi 的内存和 2 核 CPU，表示容器的最大资源使用限制。
由于请求和限制的资源不同，因此该 Pod 会被分配到 Burstable QoS 类型。

3. BestEffort QoS 示例

BestEffort QoS 适用于那些不需要保证资源的应用，Kubernetes 会尽可能地为这些容器提供资源，但如果节点资源不足，它们会被优先驱逐。

示例 YAML 文件：

yaml 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: besteffort-pod
spec:
  containers:
  - name: app-container
    image: nginx
    resources: {}  # 没有设置 requests 和 limits

该 Pod 没有设置 requests 或 limits ，因此该 Pod 会被分配到 BestEffort QoS 类型。
它会在集群资源紧张时被优先终止，适用于不需要严格资源保证的非关键任务。

4. 混合 QoS 示例（多个容器）

在一个 Pod 中，可以有多个容器。如果某些容器的请求和限制相同，而其他容器的请求和限制不同，Kubernetes 会根据不同容器的配置来为 Pod 分配 QoS 类别。

示例 YAML 文件：

yaml 复制代码

apiVersion: v1
kind: Pod
metadata:
  name: mixed-pod
spec:
  containers:
  - name: container-1
    image: nginx
    resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "500m"
  - name: container-2
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "250m"
      limits:
        memory: "1Gi"
        cpu: "1"

container-1 是 Guaranteed 类型，因为它的 requests 和 limits 相同。
container-2 是 Burstable 类型，因为它的 requests 和 limits 不同。

在这种情况下，Pod 的 QoS 会根据容器中的最高级别来进行分配，因此这个 Pod 会被视为 Burstable。

当 Pod 中有容器的 requests 和 limits 不一致时，整个 Pod 将被分类为 Burstable，即使某些容器满足 Guaranteed 的条件。

5. Pod QoS 分配总结

Guaranteed：请求和限制都设置，且请求和限制的值相同。
Burstable：请求和限制都设置，且请求和限制的值不同，或者只设置了其中之一。
BestEffort：没有设置任何请求和限制。

查看 QoS 类别

你可以使用以下命令查看一个 Pod 的 QoS 类别：

bash 复制代码

kubectl get pod <pod-name> -o=jsonpath='{.status.qosClass}'

例如：

bash 复制代码

kubectl get pod burstable-pod -o=jsonpath='{.status.qosClass}'

输出会是类似这样的内容：

bash 复制代码

Burstable

总结

Kubernetes 的 QoS 分类是通过 请求（requests） 和 限制（limits） 来实现的，可以帮助管理员根据资源需求进行精细化控制。对于生产环境中的关键任务应用，可以使用 Guaranteed 类型来确保它们有稳定的资源；对于一些可适当突发的应用，可以使用 Burstable 类型；对于不需要严格资源控制的应用，可以使用 BestEffort 类型，降低它们的资源消耗。

通过合理设置资源请求和限制，你可以确保在节点资源有限的情况下，重要任务能够优先获得资源，而不重要的任务则能够适应资源的不足。