首页 / Kubernetes (k8s) 入门教程 / 容器资源限制(CPU/内存/QoS)

Kubernetes (k8s) 入门教程

容器资源限制(CPU/内存/QoS)

本教程共 65 篇 · 第 15 篇 · 更新于 2026-08-14 · 约 11 分钟阅读

Kubernetes资源限制QoSCPU内存requestslimits

本节目标:学完你能给容器设 CPU 和内存的 requests/limits,说清 QoS 三档优先级,知道节点内存不够时 Kubernetes 先杀谁。

如果不给容器设资源上限,一个贪婪的程序能把整台节点吃垮,同节点的其他 Pod 全跟着遭殃。资源限制就是给每个容器画好”饭量”,既保自己,也保邻居。

15-1 requests 与 limits 的区别

每个容器可以设两类值:requests(请求)和 limits(限制)。

requests 是你”至少”要多少。调度器拿它来判断节点够不够放。kubelet 也会给容器预留这么多资源,保证基本够用。

limits 是你”最多”能用多少。超了就被限制,CPU 被节流,内存超限可能被杀。

一句话:requests 影响”调度去哪台”,limits 影响”跑起来能用多少”。

containers:
- name: app
  image: myapp:1.0
  resources:
    requests:
      cpu: "250m"
      memory: "128Mi"
    limits:
      cpu: "500m"
      memory: "256Mi"
Note

只设 limits 不设 requests 时,Kubernetes 会把 requests 默认等于 limits。反过来,只设 requests 不设 limits,容器能用超过请求的量,直到节点耗尽。

15-2 CPU 怎么算

CPU 的单位是”核”。写 "1" 表示 1 核,"250m" 表示 250 毫核,即 0.25 核。

CPU 限制靠**节流(throttling)**强制:容器想用超过 limits 的 CPU,内核就压着它,让它慢下来,而不是杀它。所以 CPU 超限的表现是”变慢”,不会崩。

resources:
  limits:
    cpu: "500m"

这对延迟敏感的服务不友好:哪怕节点还有空闲 CPU,它也被按在 0.5 核内。所以是否设 CPU limits 要看场景,多租户环境通常要设,防止一个程序拖累全场。

15-3 内存怎么算

内存单位是字节,习惯用 Mi(兆比,1Mi = 1024×1024 字节)和 Gi

内存限制靠OOM 杀进程强制:容器用超 limits,内核检测到内存压力时直接终止它。注意是”被动”的——不是一超就杀,是内存紧张时才杀。

resources:
  limits:
    memory: "256Mi"

被 OOM 杀的容器退出码是 137。看到 OOMKilled 状态,就是内存超了。这种崩法很硬,程序来不及收尾。

Warning

内存 limits 千万别拍太小。Java、Node 这类有自己堆内存的程序,limits 要比堆上限再留点余量,否则动不动 OOMKilled,查起来一脸懵。

15-4 QoS 三档优先级

当节点资源紧张,Kubernetes 要挑 Pod 驱逐时,按 QoS(服务质量) 分三档。档位由你设的 requests/limits 决定。

Guaranteed(有保障):每个容器都设了 limits,且 requests 等于 limits(CPU、内存都齐)。最高优先级,最后才被杀。

Burstable(可突发):至少一个容器设了 requests 或 limits,但不符合 Guaranteed。中等优先级。

BestEffort(尽力而为):啥都没设。最低优先级,资源一紧先拿它开刀。

# Guaranteed 示例:requests == limits
resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "256Mi"
Tip

核心业务想要稳,就配成 Guaranteed。跑批处理、测试这类不重要又想省资源的,BestEffort 让它去,反正先被杀也不影响生产。

15-5 一个完整资源清单

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: app
    image: myapp:1.0
    resources:
      requests:
        cpu: "250m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "256Mi"

创建后看实际占用:

kubectl top pod resource-demo
kubectl describe pod resource-demo | grep -A 6 "Requests"

kubectl top 要装了 Metrics Server 才有数据,它是看资源用量的眼睛。

15-6 常见坑

一是单位写错。把 cpu: 1 写成 cpu: "1" 没问题,但有人漏引号、有人把 Mi 写成 M(那是 1000 进制,差不少)。

二是 requests 设太大,调度不出去。每个节点余量就那么点,requests 太贪婪,Pod 会一直 Pending

三是 limits 设太小导致频繁重启。CPU 节流拖慢、内存 OOM 杀进程,表现都是”抽风”。

Warning

生产环境我建议至少设 requests。不设的话 QoS 是 BestEffort,节点一紧张最先被驱逐,而且调度器没法合理排布,容易把节点挤爆。

资源管住了,但容器默认可能以 root 跑。下一章讲 securityContext,给容器收权限。