当前位置：首页 > news >正文

k8s之 Pod 资源管理与 QoS

news 2025/8/27 14:43:45

在使用 Kubernetes 编排容器时，你可能已经习惯了编写 Pod 的 YAML 文件。但你是否真正理解其中的 resources 部分，以及它如何影响你的应用在集群中的行为和稳定性？

本篇文章将深入探讨 Kubernetes 中 Pod 的资源需求 (requests) 和资源限制 (limits)，以及它们如何决定 Pod 的服务质量 (QoS)，并最终影响到 Linux 内核的 OOM 评分。

1. 资源需求 (Requests) 与资源限制 (Limits)：为何二者缺一不可？

当你在 Pod YAML 中定义 resources 时，通常会看到两个关键字段：requests 和 limits。

资源需求 (Requests)

这就像你向房东承诺的“最低租金”。它告诉 Kubernetes 调度器（Scheduler），你的 Pod 至少需要多少 CPU 和内存才能正常启动和运行。

CPU：单位是millicores (m)。例如，cpu: 500m 表示需要 0.5 个 CPU 核心。
内存 (Memory)：单位是MeBiBytes (Mi) 或 GiBiBytes (Gi)。例如，memory: 256Mi 表示需要 256 MiB 的内存。

核心作用：调度。调度器会根据一个节点上所有 Pod 的 requests 总和来判断该节点是否还有足够的剩余资源来接纳新的 Pod。如果一个节点的可用资源小于 Pod 的 requests，调度器就不会将其部署到这个节点上。这确保了你的应用在启动时至少能获得其正常运行所需的最低资源，避免了“饿死”的情况。

资源限制 (Limits)

这就像房东设置的“电费上限”。它定义了你的 Pod 能够使用的最大资源量。

CPU：如果 Pod 的 CPU 使用量超过 limits，Kubelet 会对它进行节流（throttling），限制其使用，但不会终止进程。
内存：如果 Pod 的内存使用量超过 limits，Linux 内核会立即**终止（kill）**该 Pod 的进程，并将其状态标记为 OOMKilled（Out Of Memory Killed）。

核心作用：保护。limits 就像一道安全网，防止某个 Pod 因异常（例如内存泄漏）而耗尽整个节点的资源，从而保护了同一节点上的其他 Pod 和宿主机的稳定性。

最佳实践：始终设置 requests 和 limits。 requests 定义了你的应用运行的“基本保障”，而 limits 则设置了“安全上限”。一个健康的设置通常是 requests < limits，这让你的应用在资源充足时可以“突发”使用更多资源，同时又不会失控。

2. 服务质量 (QoS)：Pod 的“阶级”划分

Kubernetes 不仅使用 requests 和 limits 来调度和限制资源，还根据它们的设置方式，自动将 Pod 划分成三种服务质量 (QoS) 类别。这些类别决定了当节点资源不足时，哪个 Pod 会先被“牺牲”。

Guaranteed (保证型)

这是最高优先级的 QoS。

条件：Pod 中的每个容器都必须为 CPU 和内存同时设置 requests 和 limits，且 requests 等于 limits。
特点：拥有最高的资源保障和优先级。这类 Pod 几乎不会被 Kubelet 终止以释放资源。
适用场景：对性能要求极高、不能中断的核心服务，例如数据库或关键 API。

Burstable (突发型)

这是最常见的 QoS。

条件：至少有一个容器设置了 requests，但 Pod 不满足 Guaranteed 的条件（例如，requests < limits，或只设置了 requests）。
特点：中等优先级。它们可以在资源充足时突发使用更多资源，但在资源紧张时仍有可能被终止。
适用场景：绝大多数常规应用，如 Web 服务器、微服务等。

BestEffort (尽力而为型)

这是最低优先级的 QoS。

条件：Pod 中的所有容器都没有设置任何 requests 或 limits。
特点：没有资源保障，优先级最低。当节点资源不足时，这类 Pod 会最先被终止。
适用场景：非关键任务、低优先级的应用，如开发测试环境中的临时作业。

3. OOM 评分：决定谁被“献祭”的秘密

你可能会好奇，Kubelet 是如何根据 QoS 来决定终止哪个 Pod 的？答案就在于 Linux 内核的 OOM Killer（Out Of Memory Killer）和OOM 评分（OOM Score）机制。

每个 Linux 进程都有一个 OOM 评分，评分越高，在内存不足时被 OOM Killer 杀死的可能性就越大。Kubernetes Kubelet 会根据 Pod 的 QoS 类别，为其中的容器进程设置不同的 OOM 评分调整值 (oom_score_adj)。

Guaranteed：oom_score_adj 被设置为 -998。这个极低的值保证了这类 Pod 几乎不会被 OOM Killer 杀死。
Burstable：oom_score_adj 被设置为 2 到 999 之间。这赋予了它们中等优先级。
BestEffort：oom_score_adj 被设置为 1000。这是最高分，意味着它们是 OOM Killer 的首要目标。

通过这种机制，Kubernetes 完美地将它的 QoS 策略映射到了 Linux 内核的资源管理机制上，确保了在内存不足时，总是先杀死优先级最低的 Pod。

4. 资源配置清单示例

下面是一些常见的 Pod 资源配置示例，你可以根据自己的需求进行参考和修改。

示例 1: Burstable QoS (最常用)

apiVersion: v1
kind: Pod
metadata:name: my-web-server
spec:containers:- name: nginx-containerimage: nginx:1.23resources:requests:memory: "128Mi"cpu: "250m"limits:memory: "256Mi"cpu: "500m"

说明：这个 Pod 会被归类为 Burstable QoS。它被保证至少有 128Mi 内存和 250m CPU，但在资源不紧张时，它可以突发使用高达 256Mi 内存和 500m CPU。

示例 2: Guaranteed QoS (最高保障)

apiVersion: v1
kind: Pod
metadata:name: my-database
spec:containers:- name: mysql-containerimage: mysql:8.0resources:requests:memory: "1Gi"cpu: "1000m"limits:memory: "1Gi"cpu: "1000m"

说明：这个 Pod 被归类为 Guaranteed QoS。它的 CPU 不会被节流，内存也得到了完全的保证。非常适合对性能和稳定性要求极高的关键应用。

示例 3: 多容器 Pod

apiVersion: v1
kind: Pod
metadata:name: my-app-with-sidecar
spec:containers:- name: main-app-containerimage: my-app:latestresources:requests:memory: "256Mi"cpu: "500m"limits:memory: "512Mi"cpu: "1000m"- name: logging-sidecarimage: fluentd:latestresources:requests:memory: "64Mi"cpu: "100m"limits:memory: "128Mi"cpu: "200m"