java网站开发案例/图片在线转外链

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

1. Guaranteed：资源请求和限制都已明确设置，并且一致。适用于最需要严格资源保证的场景。
2. Burstable：只设置了资源请求，或者请求和限制不一致，适用于对资源有一定保证，但仍然能够利用节点余量的容器。
3. 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 文件：

apiVersion: v1
kind: Pod
metadata:name: guaranteed-pod
spec:containers:- name: app-containerimage: nginxresources: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 文件：

apiVersion: v1
kind: Pod
metadata:name: burstable-pod
spec:containers:- name: app-containerimage: nginxresources: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 文件：

apiVersion: v1
kind: Pod
metadata:name: besteffort-pod
spec:containers:- name: app-containerimage: nginxresources: {}  # 没有设置 requests 和 limits

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

---

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

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

示例 YAML 文件：

apiVersion: v1
kind: Pod
metadata:name: mixed-pod
spec:containers:- name: container-1image: nginxresources:requests:memory: "512Mi"cpu: "500m"limits:memory: "512Mi"cpu: "500m"- name: container-2image: nginxresources: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 类别：

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

例如：

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

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

Burstable

总结

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

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