Pod 资源管理

1. 节点资源分配模型#

flowchart TB
    N0["Node：8 核 CPU / 16 GiB 内存<br/>实际可分配资源还需扣除系统预留和其他开销"]
    N1["Pod A<br/>CPU：500m<br/>内存：512Mi"]
    N2["Pod B<br/>CPU：1<br/>内存：1Gi"]
    N3["Pod C<br/>CPU：2<br/>内存：2Gi"]
    N4["其他 Pod<br/>共享剩余资源"]
    N0 --> N1
    N0 --> N2
    N0 --> N3
    N0 --> N4

示意图：Pod 的资源声明是调度与运行时资源控制的重要依据，但不是简单的静态分区。

2. Kubernetes 资源管理基础#

1. Kubernetes 管理哪些资源？#

Kubernetes 容器资源管理主要涉及：

其中，CKA 最重要的是：

• CPU
• Memory
• Requests
• Limits
• QoS

2. CPU 资源单位#

Kubernetes 中 CPU 使用核（Core）作为基础单位。

例如：

1
resources:
2
  requests:
3
    cpu: "1"

表示请求 1 个 CPU 核。

常见单位：

其中：

1
1 CPU = 1000m

例如：

1
cpu: "500m"

等于：

1
0.5 CPU

注意：

m 表示 milliCPU，不是 MB，也不是毫秒。

3. Memory 资源单位#

内存通常使用字节单位。

Kubernetes 支持十进制单位和二进制单位。

常见配置：

1
memory: "128Mi"
2
memory: "256Mi"
3
memory: "512Mi"
4
memory: "1Gi"
5
memory: "2Gi"

注意：

1
1Gi = 1024Mi
2
1G  = 1000M

生产环境通常建议使用 Mi、Gi 等二进制单位，避免单位混淆。

3. Requests：资源请求#

1. 什么是 Requests？#

Requests 表示容器运行时所请求的资源量。

例如：

1
resources:
2
  requests:
3
    cpu: "500m"
4
    memory: "512Mi"

表示：

• 请求 0.5 个 CPU 核。
• 请求 512Mi 内存。

Scheduler 会根据 Pod 的资源请求量判断节点是否有足够的可分配资源。

例如：

1
Node-1
2
CPU Allocatable：8 核
3
已分配 Requests：7.5 核
4
剩余可分配：0.5 核

现在创建一个 Pod：

1
requests:
2
  cpu: "1"

那么：

1
Node-1：不满足

因为只剩下 0.5 核可分配，而 Pod 请求 1 核。

即使节点实际 CPU 使用率只有 20%，也不代表这个 Pod 一定能够调度到该节点。

这是非常重要的知识。

Scheduler 主要根据 Requests 和节点可分配资源进行调度判断，而不是简单根据当前 CPU 实时使用率判断。

2. Requests 的作用#

主要有三个：

1. 决定 Pod 调度时的资源需求。
2. 影响节点资源分配与超卖情况。
3. 参与 QoS 等级判断和部分资源争用处理。

3. Requests 示例#

1
apiVersion: v1
2
kind: Pod
3

4
metadata:
5
  name: nginx-resource
6

7
spec:
8
  containers:
9
    - name: nginx
10
      image: nginx:1.27
11

12
      resources:
13
        requests:
14
          cpu: "500m"
15
          memory: "512Mi"

4. Limits：资源限制#

1. 什么是 Limits？#

Limits 表示容器运行时允许使用的资源上限。

例如：

1
resources:
2
  limits:
3
    cpu: "1"
4
    memory: "1Gi"

表示：

• CPU 使用上限为 1 核。
• 内存使用上限为 1Gi。

Requests 与 Limits 的区别：

2. CPU Limits#

假设：

1
resources:
2
  requests:
3
    cpu: "500m"
4

5
  limits:
6
    cpu: "1"

含义：

1
CPU 请求：0.5 核
2
CPU 上限：1 核

当容器需要大量 CPU 时：

• 在资源充足且没有触及限制时，可以使用更多 CPU。
• 达到 CPU 限制后，会受到 CPU Throttling（CPU 限流）。

注意：

CPU 是可压缩资源。

达到 CPU Limit 通常不会直接导致容器被杀死。

3. Memory Limits#

例如：

1
resources:
2
  requests:
3
    memory: "512Mi"
4

5
  limits:
6
    memory: "1Gi"

含义：

1
内存请求：512Mi
2
内存上限：1Gi

如果容器实际使用内存超过限制：

flowchart TB
    N0["Memory Usage > Memory Limit"]
    N1["触发 OOM 处理"]
    N2["可能被 OOM Kill"]
    N0 --> N1
    N1 --> N2

通常容器会出现：

1
Reason: OOMKilled
2
Exit Code: 137

注意：

内存限制不是像 CPU 那样可以持续限流。内存属于不可压缩资源，超限时可能被内核 OOM 机制终止进程。

5. Requests 与 Limits 综合理解#

假设创建一个 Pod：

1
apiVersion: v1
2
kind: Pod
3

4
metadata:
5
  name: resource-demo
6

7
spec:
8
  containers:
9
    - name: app
10
      image: nginx:1.27
11

12
      resources:
13
        requests:
14
          cpu: "500m"
15
          memory: "512Mi"
16

17
        limits:
18
          cpu: "1"
19
          memory: "1Gi"

资源关系：

CPU 资源 500m Requests：调度请求 0.5 核

Limits：最多 1 核

Memory 资源 512Mi Requests：调度请求 512Mi

Limits：最多 1Gi（1024Mi）

这里需要记住：

Requests 不代表容器只能使用这么多资源。

例如：

1
CPU Requests = 500m
2
CPU Limits   = 1000m

在没有触及 CPU Limit 且节点有可用 CPU 的情况下，容器可以使用超过 500m 的 CPU。

同样：

1
Memory Requests = 512Mi
2
Memory Limits   = 1Gi

容器可以在运行时使用超过 512Mi 的内存，但不能保证它一定能获得这部分内存；超过 1Gi 则可能触发 OOM Kill。

6. CPU Throttling：CPU 限流机制#

这是 Kubernetes 资源管理中非常重要的底层知识。

1. 什么是 CPU Throttling？#

CPU Throttling 指 CPU 限流。

当容器使用 CPU 达到配置的 Limit 后，Linux 内核会通过 CFS（Completely Fair Scheduler）配额机制限制容器继续使用 CPU。

例如：

1
resources:
2
  requests:
3
    cpu: "500m"
4

5
  limits:
6
    cpu: "1"

表示：

• CPU Requests：0.5 核。
• CPU Limits：1 核。

假设应用突然需要 2 核 CPU：

flowchart TB
    N0["应用需要：2 核<br/>CPU Limit：1 核"]
    N1["内核限制 CPU 使用"]
    N2["容器受到 CPU Throttling"]
    N0 --> N1
    N1 --> N2

容器不会因为 CPU 超过 Limit 就直接退出，而是需要等待后续 CPU 配额周期。

2. CPU 限流底层原理#

Linux 使用 CFS 带宽控制机制对容器 CPU 使用进行限制。

在启用 CFS 配额的情况下，常见参数包括：

在 cgroup v2 中，对应的主要参数为：

1
cpu.max
2
cpu.weight

例如：

1
cpu.max = 100000 100000

表示：

• 周期：100000 微秒。
• 配额：100000 微秒。

相当于一个 CPU 核的使用额度。

如果：

1
cpu.max = 50000 100000

则表示：

每 100000 微秒周期，最多可以使用 50000 微秒 CPU 时间。

即 0.5 个 CPU 核的配额。

3. 如何排查 CPU 限流？#

首先查看 Pod 资源配置：

1
kubectl describe pod nginx

如果集群安装了 Metrics Server：

1
kubectl top pods

查看节点：

1
kubectl top nodes

注意：

kubectl top 显示的是资源使用量，不直接显示 CPU Throttling 次数。

生产环境通常结合 Prometheus 和 cAdvisor 监控：

1
rate(container_cpu_cfs_throttled_periods_total[5m])
2
/
3
rate(container_cpu_cfs_periods_total[5m])

这个指标可以用于观察容器 CPU 限流周期的比例。

如果该比例长期很高，同时应用延迟明显增加，就需要检查 CPU Limit 是否设置过低。

配额限制的是控制周期内累计消耗的 CPU 时间，不意味着程序只能使用某个固定 CPU 核心的前半段时间。

7. OOMKilled：内存溢出机制#

与 CPU 不同，内存属于不可压缩资源。

这是 Kubernetes 资源管理中最重要的知识点之一。

1. 什么是 OOMKilled？#

OOM 是 Out Of Memory 的缩写。

当容器使用内存超过限制，Linux 内核可能触发 OOM Killer，终止相关进程以释放内存。

例如：

1
resources:
2
  requests:
3
    memory: "256Mi"
4

5
  limits:
6
    memory: "512Mi"

假设应用不断申请内存：

1
100Mi
2
200Mi
3
300Mi
4
400Mi
5
500Mi
6
550Mi

当内存使用超过 512Mi 时，可能触发 OOM Kill。

Pod 状态可能显示：

1
NAME    READY   STATUS
2
nginx   0/1     OOMKilled

2. OOMKilled 与 Exit Code 137#

排查：

1
kubectl describe pod nginx

可能看到：

1
Last State:     Terminated
2
Reason:         OOMKilled
3
Exit Code:      137

其中：

注意：

137 通常对应 128 + 9，表示进程被 SIGKILL 终止，但并不是所有 137 都一定是 OOM。

需要结合 Reason、事件和节点日志判断。

3. 如何排查 OOMKilled？#

第一步：

1
kubectl get pods

第二步：

1
kubectl describe pod <pod-name>

第三步：

1
kubectl logs <pod-name> --previous

第四步：

1
kubectl top pod <pod-name>

如果是容器反复重启：

1
kubectl get pod <pod-name> -o yaml

重点检查：

1
resources:
2
  requests:
3
    memory: 256Mi
4
  limits:
5
    memory: 512Mi

4. 如何解决 OOMKilled？#

常见解决方式：

1. 合理提高 Memory Limits。
2. 检查应用是否存在内存泄漏。
3. 优化缓存和内存使用。
4. 减少单个 Pod 承载的业务量。
5. 必要时增加 Pod 副本。
6. 检查 JVM、Go 等运行时自身的内存配置。

特别注意：

增加 Memory Limits 不代表一定能解决问题。

如果应用本身存在内存泄漏，只会延后 OOM 发生的时间。

8. QoS：服务质量等级#

现在学习 Kubernetes 的一个核心机制：

QoS Class（Quality of Service Class）。

QoS 用于区分不同 Pod 的资源保障等级，并影响节点资源压力下的驱逐行为。

Kubernetes 主要有三个 QoS 等级：

1. Guaranteed
2. Burstable
3. BestEffort

1. Guaranteed：最高保障等级#

满足以下条件：

• Pod 中每个容器都设置 CPU Requests 和 Limits。
• Pod 中每个容器都设置 Memory Requests 和 Limits。
• 每个容器的 CPU Requests 等于 CPU Limits。
• 每个容器的 Memory Requests 等于 Memory Limits。

例如：

1
apiVersion: v1
2
kind: Pod
3

4
metadata:
5
  name: guaranteed-pod
6

7
spec:
8
  containers:
9
    - name: app
10
      image: nginx:1.27
11

12
      resources:
13
        requests:
14
          cpu: "1"
15
          memory: "512Mi"
16

17
        limits:
18
          cpu: "1"
19
          memory: "512Mi"

这里：

1
CPU Requests = CPU Limits
2
Memory Requests = Memory Limits

因此：

Guaranteed

2. Burstable：弹性资源等级#

只要 Pod 不满足 Guaranteed，并且至少一个容器设置了 CPU 或 Memory 的 Requests 或 Limits，就属于 Burstable。

例如：

1
apiVersion: v1
2
kind: Pod
3

4
metadata:
5
  name: burstable-pod
6

7
spec:
8
  containers:
9
    - name: app
10
      image: nginx:1.27
11

12
      resources:
13
        requests:
14
          cpu: "500m"
15
          memory: "256Mi"
16

17
        limits:
18
          cpu: "1"
19
          memory: "512Mi"

这里：

1
CPU Requests：500m
2
CPU Limits：1

1
Memory Requests：256Mi
2
Memory Limits：512Mi

Requests 和 Limits 不相等。

因此：

Burstable

3. BestEffort：最低保障等级#

如果 Pod 中所有容器都没有设置 CPU 和 Memory 的 Requests、Limits，则属于 BestEffort。

例如：

1
apiVersion: v1
2
kind: Pod
3

4
metadata:
5
  name: besteffort-pod
6

7
spec:
8
  containers:
9
    - name: app
10
      image: nginx:1.27

没有设置 CPU 和 Memory 资源配置。

因此：

BestEffort

4. 三种 QoS 对比#

注意：QoS 不是调度优先级，也不是 CPU 使用优先级的简单排序。它主要参与资源压力下的驱逐决策。

Guaranteed 不意味着绝对不会被 OOM 终止，也不意味着拥有独占 CPU；它是 Kubernetes QoS 分类的一部分。

9. QoS 与节点驱逐机制#

这是 CKA 非常重要的考点。

假设：

Node-1 的内存总量为 8Gi。

现在有三个 Pod：

此时节点内存不足。

Kubelet 需要进行节点压力驱逐（Node-pressure Eviction）。

一般来说，驱逐优先级会考虑：

1. Pod 是否超过 Requests。
2. Pod 的 Priority。
3. Pod 相对于 Requests 的资源使用情况。

QoS 类别也会影响整体驱逐顺序。

1. 驱逐的大致顺序#

在其他条件相同的情况下，可以这样理解：

flowchart TB
    N0["BestEffort"]
    N1["Burstable（超出 Requests 的 Pod）"]
    N2["Guaranteed"]
    N0 --> N1
    N1 --> N2

但要注意：

不能简单认为所有 BestEffort 一定先于所有 Burstable，也不能认为 Guaranteed 绝对不会被驱逐。

实际驱逐还会受到 Pod Priority、资源超出 Requests 的程度等因素影响。

2. 节点内存压力#

例如：

1
Node-1
2
总内存：8Gi
3
实际使用：7.8Gi

继续运行新任务可能导致节点不稳定。

Kubelet 会根据节点资源压力和驱逐阈值进行处理。

查看：

1
kubectl describe node worker-1

关注：

1
Conditions:
2
  MemoryPressure

如果：

1
MemoryPressure=True

说明节点存在内存压力。

节点还可能被添加：

1
node.kubernetes.io/memory-pressure

污点，从而影响新 Pod 的调度。

3. Eviction 与 OOMKilled 的区别#

这是一个非常容易混淆的知识点。

简单理解：

• Eviction：Kubernetes 主动驱逐 Pod。
• OOMKilled：Linux 内核终止进程。

10. Requests 与 Limits 对调度的影响#

假设：

Node-1：

1
CPU Allocatable：8 核
2
Memory Allocatable：16Gi
3

4
已分配 CPU Requests：7 核
5
已分配 Memory Requests：14Gi

现在创建一个 Pod：

1
resources:
2
  requests:
3
    cpu: "2"
4
    memory: "4Gi"

会发生什么？

计算：

1
CPU 剩余可分配：8 - 7 = 1 核
2

3
Memory 剩余可分配：16 - 14 = 2Gi

Pod 需要：

1
CPU：2 核
2
Memory：4Gi

因此 Node-1 无法满足要求。

即使实际 CPU 使用率只有 10%，Memory 使用率只有 30%，也不代表能够调度成功。

1. Requests 与节点资源计算#

Scheduler 主要检查：

[ 可分配资源-已分配 Requests ]

是否满足新 Pod 的资源请求。

例如：

Pod 需要：

结果：

无法调度

2. 查看节点资源分配#

查看节点资源：

1
kubectl describe node worker-1

找到：

1
Capacity:
2
  cpu:                8
3
  memory:             16Gi
4

5
Allocatable:
6
  cpu:                7800m
7
  memory:             15Gi
8

9
Allocated resources:
10
  Resource           Requests
11
  cpu                7000m
12
  memory             14Gi

这里需要区分：

• Capacity：节点总资源。
• Allocatable：Kubernetes 可分配资源。
• Allocated resources：已经分配给 Pod 的资源请求和限制汇总。

为什么 Allocatable 比 Capacity 小？

因为节点需要预留资源给：

• 操作系统。
• kubelet。
• 容器运行时。
• Kubernetes 系统组件。
• 节点级守护进程。

3. Pod 没有设置 Requests 会怎样？#

例如：

1
containers:
2
  - name: nginx
3
    image: nginx

默认情况下：

如果没有设置 Requests，Scheduler 通常按照 0 资源请求处理该容器的 CPU 和内存。

但是需要注意一个重要规则：

如果只设置了 Limit，没有设置 Request，而且没有其他机制覆盖，那么 Kubernetes 通常会将对应资源的 Limit 自动复制为 Request。

例如：

1
resources:
2
  limits:
3
    cpu: "1"
4
    memory: "512Mi"

通常会得到：

1
resources:
2
  requests:
3
    cpu: "1"
4
    memory: "512Mi"
5

6
  limits:
7
    cpu: "1"
8
    memory: "512Mi"

因此该容器在这种情况下满足 Guaranteed 资源配置条件（前提是 Pod 中其他容器也满足）。

这也是 CKA 容易考查的细节。

11. LimitRange：命名空间资源默认限制#

现在考虑一个生产问题：

假设一个 Namespace 中有 100 个开发人员，每个人都可以创建 Pod。

如果有人创建 Pod 时完全不配置 Requests 和 Limits，会有什么问题？

• Pod 资源请求不可预测。
• 容器可能过度占用节点资源。
• 难以进行资源规划。
• 资源分配不规范。

Kubernetes 提供了 LimitRange。

1. 什么是 LimitRange？#

LimitRange 用于限制一个 Namespace 内的单个 Pod 或 Container 的资源配置。

它可以设置：

1. 默认 Requests。
2. 默认 Limits。
3. 最小资源请求。
4. 最大资源限制。
5. Requests 与 Limits 的比例约束。

注意：

LimitRange 管理的是单个 Pod 或 Container 的资源范围，不是整个 Namespace 的总资源配额。

2. 设置默认资源#

创建：

1
apiVersion: v1
2
kind: LimitRange
3

4
metadata:
5
  name: resource-limits
6
  namespace: default
7

8
spec:
9
  limits:
10
    - type: Container
11

12
      default:
13
        cpu: "1"
14
        memory: "512Mi"
15

16
      defaultRequest:
17
        cpu: "500m"
18
        memory: "256Mi"

解释：

当用户创建没有资源配置的容器时，LimitRange 可以自动补充默认资源。

例如创建：

1
apiVersion: v1
2
kind: Pod
3

4
metadata:
5
  name: nginx
6

7
spec:
8
  containers:
9
    - name: nginx
10
      image: nginx:1.27

检查：

1
kubectl get pod nginx -o yaml

可能看到：

1
resources:
2
  requests:
3
    cpu: 500m
4
    memory: 256Mi
5

6
  limits:
7
    cpu: "1"
8
    memory: 512Mi

3. 设置最大与最小资源#

例如：

1
apiVersion: v1
2
kind: LimitRange
3

4
metadata:
5
  name: container-range
6

7
spec:
8
  limits:
9
    - type: Container
10

11
      min:
12
        cpu: "100m"
13
        memory: "128Mi"
14

15
      max:
16
        cpu: "2"
17
        memory: "2Gi"

含义：

1
CPU 最小：100m
2
CPU 最大：2 核
3

4
内存最小：128Mi
5
内存最大：2Gi

如果创建的容器超过最大限制，就可能被 API Server 拒绝。

4. 设置 Requests 与 Limits 比例#

还可以设置：

1
maxLimitRequestRatio:
2
  cpu: "4"
3
  memory: "2"

例如：

1
CPU Limits / CPU Requests ≤ 4
2
Memory Limits / Memory Requests ≤ 2

这样可以防止用户申请很小的 Requests，却设置特别大的 Limits。

5. 查看 LimitRange#

1
kubectl get limitrange

查看详细配置：

1
kubectl describe limitrange resource-limits

12. ResourceQuota：命名空间资源配额#

LimitRange 解决的是单个 Pod 或 Container 的资源限制。

但还有一个问题：

假设某个 Namespace 中有 100 个 Pod，每个 Pod 都配置了：

1
requests:
2
  cpu: "1"
3
  memory: "1Gi"

那么整个 Namespace 可能申请：

1
CPU：100 核
2
Memory：100Gi

如果集群资源不足，就可能影响其他业务。

因此 Kubernetes 提供了 ResourceQuota。

1. 什么是 ResourceQuota？#

ResourceQuota 用于限制 Namespace 范围内的资源总量。

它可以限制：

• CPU Requests 总量。
• CPU Limits 总量。
• Memory Requests 总量。
• Memory Limits 总量。
• Pod 数量。
• PVC 数量。
• Service 数量。
• Secret 数量等。

2. CPU 和 Memory 配额#

创建：

1
apiVersion: v1
2
kind: ResourceQuota
3

4
metadata:
5
  name: compute-quota
6
  namespace: default
7

8
spec:
9
  hard:
10
    requests.cpu: "10"
11
    requests.memory: "20Gi"
12

13
    limits.cpu: "20"
14
    limits.memory: "40Gi"
15

16
    pods: "20"

解释：

3. ResourceQuota 工作原理#

假设：

1
Namespace：development
2

3
CPU Requests 配额：10 核
4
已经使用：9 核

现在创建一个 Pod：

1
resources:
2
  requests:
3
    cpu: "2"

那么：

1
9 + 2 = 11 核

超过了 10 核的配额。

Kubernetes 会拒绝创建这个 Pod。

可能看到：

1
Error from server (Forbidden):
2
exceeded quota

注意：

ResourceQuota 是 API 资源准入阶段的配额检查，不是 Scheduler 的节点选择检查。

4. 查看 ResourceQuota#

1
kubectl get resourcequota

查看详细信息：

1
kubectl describe resourcequota compute-quota

可能看到：

1
Resource          Used    Hard
2
--------          ----    ----
3
requests.cpu      9       10
4
requests.memory   18Gi    20Gi
5
limits.cpu        15      20
6
limits.memory     30Gi    40Gi
7
pods              15      20

5. LimitRange 与 ResourceQuota 对比#

记忆：

• LimitRange：限制单个对象。
• ResourceQuota：限制整个 Namespace。

13. Ephemeral Storage：临时存储资源管理#

前面学习的 CPU 和 Memory 是最常见的资源类型。

但 Kubernetes 还有一种很重要的资源：

Ephemeral Storage（临时存储）。

例如：

容器运行时产生：

• 日志文件。
• 临时文件。
• 容器可写层数据。
• EmptyDir 临时卷数据。

这些内容可能占用节点本地磁盘空间。

如果不进行限制，某个容器可能占用大量节点磁盘，导致节点出现 DiskPressure。

1. 配置临时存储 Requests 和 Limits#

例如：

1
apiVersion: v1
2
kind: Pod
3

4
metadata:
5
  name: storage-demo
6

7
spec:
8
  containers:
9
    - name: app
10
      image: busybox:1.36
11

12
      command:
13
        - sh
14
        - -c
15
        - "sleep 3600"
16

17
      resources:
18
        requests:
19
          ephemeral-storage: "1Gi"
20

21
        limits:
22
          ephemeral-storage: "2Gi"

含义：

1
临时存储请求：1Gi
2
临时存储上限：2Gi

2. 临时存储使用场景#

注意：

Ephemeral Storage 不适合保存需要长期保留的数据。

Pod 删除后，关联的 EmptyDir 数据也会被删除。

如果业务需要持久化数据，应该使用 PV/PVC 等持久化存储机制。

3. 查看节点磁盘压力#

1
kubectl describe node worker-1

关注：

1
DiskPressure

如果出现：

1
DiskPressure=True

说明节点存在磁盘资源压力。

进一步检查：

1
df -h

查看磁盘使用情况：

1
du -sh /var/lib/containerd

具体路径取决于容器运行时配置。

14. 本节必须掌握的命令#

注意：kubectl top 需要 Metrics Server 正常运行。

15. 本节知识体系总结#

Kubernetes 资源管理体系

Pod Resource Management 容器资源管理

Requests 资源请求，参与调度

Limits 运行时资源上限

QoS 资源保障等级

Eviction 节点资源压力驱逐

LimitRange 单个对象资源约束

ResourceQuota Namespace 总量配额

核心概念对照