容器资源限制(CPU/内存/QoS)
本教程共 65 篇 · 第 15 篇 · 更新于 2026-08-14 · 约 11 分钟阅读
本节目标:学完你能给容器设 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,给容器收权限。