半夜两点收到告警节点CPU跑到100%持续了十五分钟紧跟着内存告警两个Pod被OOMKilled。我登录集群一看同一个节点上堆了十几个没有设置任何资源限制的Pod另一个节点却闲得发呆。这种“旱的旱死涝的涝死”是我接手Kubernetes之后遇到最多的问题。后来我把Pod的requests、limits、QoS、ResourceQuota完整梳理了一遍资源争抢和浪费才算真正被堵住。这篇文章不是单纯列举API参数而是从实际故障出发把Pod资源管理的设计逻辑、配置方法和排查套路一次性讲透适合正在管理K8s集群的运维、开发和SRE同学参考。1. 先理解Pod资源管理到底解决什么问题1.1 为什么CPU和内存会成为事故导火索Kubernetes里的Pod是最小的调度单位容器只在Pod内部运行。如果你不去声明这个Pod“至少要多少资源、最多能用多少资源”调度器就只能靠猜运行时也只能靠底层Linux cgroup的默认行为兜底。兜不住的后果很典型某个业务突发流量上来容器疯狂消耗CPU把节点上其他容器的CPU时间挤占掉或者某个容器的内存像漏水一样上涨触发了系统OOM结果被杀的往往是别的无辜进程。我遇到过最典型的场景是业务方说“我只要一个Pod镜像不大启动很快”然后直接kubectl run什么资源参数都没写。开发本地测试没问题一上生产多个服务挤在一个节点上监控里CPU使用率变成锯齿状接口耗时忽高忽低。原因很简单一个Pod吃满CPU之后Linux CFS调度器是按权重分配CPU时间片的没设置CPU limits的容器权重很高大量请求进来会抢占其他容器的CPU份额。这不是Pod“坏”了而是资源边界没有定义好。资源管理的本质是给每个Pod划定边界调度时按声明值“预留”资源运行时按限制值“约束”资源。边界清晰了节点上的所有Pod才不会互相争抢也不会因为某个Pod的异常把所有资源吃掉。1.2 requests和limits一对容易混淆的数字Kubernetes里最核心的两个参数是requests和limits。这两个词看起来简单但很多人用反了。requests是给调度器看的表示这个Pod启动时“至少需要预留多少资源”。调度器选择一个节点时会看节点上所有Pod的requests总和加上新Pod的requests不能超过节点的可分配资源。可以理解成订酒店时先付定金把房间锁住。limits是给kubelet和cgroup看的表示这个Pod最多能使用多少资源。超过CPU limit会发生CPU Throttling超过内存limit会被OOMKilled。这相当于酒店房间的入住上限超过会被赶出去。这里有个关键点CPU是可压缩资源内存是不可压缩资源。CPU超限的表现是变慢进程还在内存超限就危险了直接杀掉容器。所以内存的limits一定要重点盯。四个组合逻辑如下配置方式QoS等级调度保证运行时行为只写requestsBurstable节点预留了对应CPU/内存内存可能超出requests导致节点内存紧张只写limitsBurstable调度时不预留limits形同虚设容器可能被调度到资源不足的节点requestslimitsGuaranteed精确预留也精确限制最稳定适合核心服务都不写BestEffort不保证任何资源资源紧张时最先被驱逐生产环境里我建议对核心业务把requests和limits设置成相同值也就是Guaranteed QoS。这样调度器能精确知道每个Pod的资源占用运行时也不会因为某个Pod超过requests但低于limits造成节点超卖失控。如果觉得100%限制太浪费可以在非核心服务上放宽limits比如requests给200m CPUlimits给500m让它可以短暂突发但也要承担资源紧张时被驱逐的风险。2. 从调度到运行避免“争抢”的机制与参数2.1 QoS等级资源紧张时谁先出局Kubernetes会自动根据Pod的requests和limits设置把Pod划分到三个QoS等级Guaranteed、Burstable、BestEffort。这个等级不是我之前理解的“服务优先级”而是节点资源不足时kubelet选择驱逐哪些Pod的依据。当节点内存使用超过阈值kubelet会开始驱逐Pod顺序是BestEffort优先驱逐其次是Burstable中超过requests的Pod最后才动Guaranteed Pod。只有在极端情况下比如Guaranteed Pod自己也超过limits才会被杀掉。这个设计很符合直觉没有声明资源需求的Pod就要承担资源不确定性带来的后果。所以你的关键业务一定要做成Guaranteed。哪怕你只把内存和CPU的requests与limits设置成一样的值就能享受这个保护。不要迷信PriorityClassQoS等级是资源层面的第一道保险两者不是一回事。还有一种情况是节点出现磁盘压力或文件系统压力QoS驱逐顺序也是类似的。BestEffort Pod最容易因为ephemeral-storage超限被清理。如果你有一些离线任务Pod能容忍不定时中断那可以故意不做资源限制让它变成BestEffort这样节点空间紧张时会被优先腾退反而保护了在线业务。这个用法可以作为一种“可牺牲队列”的设计思路。2.2 调度器眼里不是“实际用量”而是“声明的requests”调度器判断一个Pod能不能落到某个节点用的不是节点当前的实际内存/CPU使用率而是所有已分配Pod的requests总和。这个设计经常让新手困惑明明节点监控显示内存用了不到50%但新Pod就是调度不上去事件里写Insufficient memory。原因可能是节点上已有的多个Pod虽然实际使用量低但它们的requests总和已经把节点内存接近填满了。比如有10个Pod每个都声明了memory: 1Gi但实际只用了100Mi节点总内存是16Gi那么新Pod想申请2Gi内存调度器一算已有requests总和10Gi 新Pod 2Gi 12Gi看起来够但还要考虑系统预留和驱逐阈值剩下的额度可能就不够了。反之如果这些Pod都没写requests调度器会把节点看作非常空闲导致大量Pod打上去运行后实际使用暴涨引发争抢。理解这一点之后你就会明白合理设置requests不只是在保护Pod自身也是在帮助调度器做出正确决策。写requests时不要拍脑袋要参考压测和监控数据的P95值。比如CPU平均使用300m峰值500m那么requests给500m、limits给1比较好既有调度保证也能容忍突发。还有一点值得注意调度器只处理节点维度同一个节点上多个Pod之间如果存在亲和性、污点、拓扑分布约束则还需要满足这些条件。资源充足不代表一定能调度成功但资源不充足一定调度失败。2.3 抢占机制与“no preemption victims found”当集群里所有节点都无法容纳一个新的高优先级Pod时调度器会尝试抢占。抢占的意思是从低优先级Pod所在的节点上挑一些Pod驱逐腾出地方给高优先级Pod。这是Kubernetes默认开启的调度行为前提是被抢占的Pod优先级低于当前Pod且不会被PodDisruptionBudgetPDB阻止。我之前在处理一个线上问题时看到Pod一直Pending事件里出现no preemption victims found for incoming pod。这个报错字面意思是“没有找到可以被抢占的Pod”。说实话很多人看到这个就慌了以为是抢占功能坏了。其实不是。出现这个报错一般有三种常见情况。第一种集群里确实没有低优先级Pod全都是相同优先级或者更高优先级的Pod调度器不能抢占“同级别”的Pod。第二种虽然存在低优先级Pod但它们都受到PDB保护无法被安全驱逐。第三种低优先级Pod所在节点满足不了高优先级Pod的亲和性或污点容忍要求即使把低优先级Pod赶走高优先级Pod也进不去那个节点。这种情况下调度器计算完会放弃事件里就会留下这条消息。要解决这类问题不能只盯着抢占配置。正确思路是看当前集群剩余资源看低优先级Pod的分布看PDB策略。如果集群真的没有资源加节点或让业务缩容才是根本。PriorityClass不能凭空变出资源它只能让高优先级Pod插队。实践中我给核心系统单独设置了高PriorityClass给批量任务设置了默认PriorityClass这样当批量任务占满节点时核心系统仍然可以通过抢占获得资源。但一定要避免所有Pod都用高优先级否则抢占调度器每次都扫描一遍最后得出“无受害者”的结论只会增加调度延迟。3. 从单Pod到集群避免“浪费”的规模化治理3.1 ResourceQuota和LimitRange先上一道锁单靠每个开发自觉写requests和limits等于没管理。人总是会忘迭代多了还会有人图省事写个很大的值然后常年占着资源。为了从集群层面避免浪费我建议每个namespace都配置两个对象ResourceQuota和LimitRange。ResourceQuota用来限制整个namespace的累计资源。比如开发环境有10个服务每个最多4Gi内存你直接设置limits.memory总量50Gi还能省出10Gi给临时任务。示例apiVersion: v1 kind: ResourceQuota metadata: name: dev-quota namespace: dev spec: hard: requests.cpu: 4 requests.memory: 8Gi limits.cpu: 8 limits.memory: 16Gi scopeSelector: matchExpressions: - key: podPriority operator: In values: - low-priority这样设置代表dev这个命名空间里的普通Pod累计requests不能超过4核8Gilimits不能超过8核16Gi。如果某个Deployment的新版本要申请超过配额API Server会直接拒绝Kubernetes会把这个原因写进ReplicaSet的事件里。LimitRange的作用跟ResourceQuota互补它是给单个Pod或容器设置默认值和边界。比如下面这个配置apiVersion: v1 kind: LimitRange metadata: name: dev-limitrange namespace: dev spec: limits: - max: cpu: 2 memory: 4Gi min: cpu: 50m memory: 64Mi default: cpu: 500m memory: 512Mi defaultRequest: cpu: 100m memory: 128Mi type: Container有了LimitRange只要Pod容器没有显式设置requests/limits就会被自动填入默认值。这至少保证了“不写资源限制”的Pod不会变成BestEffort失去了QoS保护。同时max和min能阻止有人把requests设成10核或者1B这种没有意义的配置直接报错。我实际使用中也会碰到开发来问“为什么我创建Pod失败了报错说exceeded quota”这时通常是ResourceQuota已经在发挥作用说明新的发布规格加起来的资源超过了该namespace上限。解决方式不是删掉配额而是评估是否有必要扩容或者清理无人使用的旧版本。3.2 2c4g的Pod能撑多少并发估算与压测“2c4g的Pod能支持多大并发”是群里面出现概率极高的问题。说实话任何脱离业务模型给具体数字的回答都是拍脑袋。但我可以给一套可行的估算思路避免你拿着机器规格去硬套。首先明确并发量的含义。如果指“同时活跃的连接数”这个数字往往比“同时正在处理的请求数”大得多因为连接建立后可能长时间空闲。真正影响CPU和内存的是活跃请求数也就是单位时间内正在处理中的请求数。常用的模型是Littles LawL λ × W。L是平均活跃请求数λ是每秒进入的请求数QPSW是平均处理时长秒。举个例子假设一个请求平均响应时间50ms也就是0.05秒那么要支撑200 QPS平均活跃请求数L 200 × 0.05 10。也就是说同时只有10个请求在处理中。如果单请求CPU消耗是0.02核那么这10个请求大概需要0.2核CPU。2核的Pod可以轻松承载这个量级。内存估算也要分两部分看基础常驻内存加每个请求的额外内存。一个Java服务基础堆可能就要2Gi再叠加连接池、缓存、GC开销这时候4Gi内存可能只能支撑几十个并发请求。换成一个Go写的轻量服务4Gi可能能支撑上千并发。所以正确的做法是先用压测工具wrk、hey、k6打压力观察kubectl top pod里的CPU和内存使用率。记录下不同并发下对应的CPU请求量和内存占用。以稳定运行时的P95 CPU和内存作为requests参考以峰值的1.5倍到2倍作为limits参考。再根据“单副本能承受的最大QPS”反向推出副本数。我看过太多人按“2c4g500并发”去预估容量结果线上一个Java应用在200并发就开始频繁Full GC。根本原因是每个请求的CPU消耗和内存开销完全不同。如果不想一开始就压测可以先给一个宽松的承接值上线后观测两周再逐步调整requests和limits把资源“瘦身”。这个过程叫right-sizing是避免浪费最有效的手段。3.3 HPA扩缩容的正确姿势很多团队把HPA当作“自动扩缩容”的银弹但忽略了前置条件Pod必须设置了requests否则HPA算出来的“资源利用率”完全没有分母。HPA默认的算法是当前副本数 × 当前Pod实际使用量 / 当前Pod requests总和如果Pod没写requestsHPA会因为无法计算而一直不触发扩容。CPU-based HPA配置大概是apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-hpa namespace: dev spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70这里averageUtilization: 70的意思是“所有副本的CPU平均使用率为requests的70%”。如果requests设置得太大实际使用率很低HPA永远不扩容如果requests设置得太小实际使用率容易打到100%HPA会激进扩容。所以requests的值不能只是“预估够用”还要配合业务模型。内存HPA我一般建议谨慎开启。内存回收有滞后性某些语言比如Java在GC前内存会持续保持高位HPA看到持续高内存就会不断扩容后面GC一触发内存又跌下来导致副本数反复抖动。如果非要做内存HPA可以把目标利用率设低一点比如60%并且配合冷却时间降低震荡。HPA真正解决的是“波动型业务”的浪费问题。稳定业务更适合用VPA或直接固定副本数频繁扩缩容反而会增加创建Pod的调度延迟。记住一句话先right-sizing再谈扩缩容。4. 实操与排障把资源管理落到日常操作里4.1 用Dashboard创建带资源规格的Pod如果你想在Web界面上快速创建一个带资源限制的新PodKubernetes Dashboard是够用的。先进入目标namespace点右上角 CREATE选择“从表单创建”。表单里有“资源请求”和“资源限制”区域直接填CPU和内存值即可。但我更推荐切到“从YAML创建”因为YAML模式可以一次性定义多个对象比如Deployment加Service避免表单字段不完整。一个最常见的发布方式是这样的apiVersion: apps/v1 kind: Deployment metadata: name: web namespace: dev spec: replicas: 2 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: web image: registry.example.com/web:latest ports: - containerPort: 8080 resources: requests: cpu: 500m memory: 512Mi limits: cpu: 2 memory: 1Gi restartPolicy: Always --- apiVersion: v1 kind: Service metadata: name: web namespace: dev spec: selector: app: web ports: - port: 80 targetPort: 8080 type: ClusterIP在Dashboard的YAML编辑框里粘贴以上内容点击Upload即可。注意左侧输入框会自动提示语法错误资源字段的格式一定要正确CPU可以用500m代表0.5核内存可以用512Mi或1Gi。创建后如果Pod一直Pending点开Deployment的状态查看事件里有没有Insufficient cpu或FailedScheduling。如果看到这些就说明当前namespace或节点资源配额不够优先检查ResourceQuota再检查节点余量。用Dashboard创建裸Pod虽然可行但我不推荐裸Pod。新服务发布应该用Deployment管理这样有滚动更新、故障自愈和副本控制能力。裸Pod被删了不会自动重建发布等于没有兜底。4.2 多容器Pod的资源边界与启动失败影响Kubernetes允许一个Pod里放多个容器比如nginx加sidecar日志采集器。有人问“如果Pod里一个容器启动失败会不会影响其他容器”这个问题要分几个层面看。第一是生命周期层面。Pod里的容器共享网络命名空间和存储卷但kubelet会分别管理每个容器的生命周期。一个容器启动失败不代表其他容器会被主动停止。如果失败容器持续CrashLoopBackOffPod会处于CrashLoopBackOff状态但这个Pod里的另一个已经Running的容器仍然在运行。不过要注意Pod的Ready状态是所有容器都满足就绪条件如果失败容器没有进入ReadyService的EndpointList里就不会包含这个Pod外部流量不会打到它。所以从服务角度看它确实“被影响了”。第二是资源层面。多容器Pod的requests和limits是所有容器资源的累加。比如一个Pod有两个容器一个声明cpu: 250m一个声明cpu: 250m那么整个Pod的request就是500m。调度器按500m来预留运行时cgroup的QoS级别也按Pod粒度计算。如果一个容器内存超限可能触发整个Pod的OOMKilled甚至影响同Pod的其他容器。所以sidecar的资源请求不能“顺手填一个小值”它会把Pod总资源顶高导致调度紧张。第三是启动顺序层面。如果你需要严格的启动顺序比如主业务容器必须等初始化容器执行完再启动那就用initContainer而不是指望普通容器的启动顺序。普通容器之间基本是并行启动的没有内置依赖关系。热词里说的“一个容器没成功启动影响其它容器”往往是sidecar中有文件锁、Unix socket或共享目录等待逻辑导致主容器启动后找不到依赖而失败。这种问题最好的解决办法是在业务容器里做就绪探测和重试逻辑不要假设sidecar一定比自己快。4.3 资源类问题排查速查表我把日常遇到比较多的资源问题汇总成一张速查表可以直接当排障手册用。现象可能原因排查思路Pod一直Pending事件显示Insufficient cpu/memory节点资源不足或ResourceQuota限制kubectl describe pod看调度事件kubectl top nodes看节点余量检查namespace配额Pod反复重启lastState为OOMKilled内存limit设置过小或容器内存泄漏kubectl describe pod看last state用kubectl logs看业务日志适当调大内存limits或定位泄漏CPU使用率被限制请求变慢CPU limits设置过低容器被Throttlingkubectl exec进容器看/sys/fs/cgroup/cpu.stat的throttled时间调大limits或优化代码Dashboard创建Pod后无法访问Service selector与Pod label不匹配检查Service的selector和Deployment的template.metadata.labels是否一致再检查端口某节点负载特别高其他节点空闲requests设置不合理调度器按requests分配不均检查各Pod的requests结合节点亲和性、topologySpreadConstraints调整调度策略HPA不生效Pod没有配置requests补requests字段等待几个采集周期后重新观察事件出现no preemption victims found没有可抢占的低优先级Pod或PDB限制检查PriorityClass和PDB考虑增加节点或减少高优先级Pod实际排障过程中我最常用的命令是kubectl describe pod pod-name里面包含了调度事件、容器状态、上次退出原因。几乎所有资源问题都能从这个命令里找到第一手线索。然后配合kubectl top nodes和kubectl top pods确认真实用量就能定位到是requests不准确还是limits太小又或是配额问题。还有一个细节容易被忽略Pod被驱逐后的事件里可能没有明显错误只是显示节点内存压力。这时要去看节点上的systemd日志比如journalctl -u kubelet里面会有EvictionManager的驱逐原因。有时候是节点本身有长时间运行的容器累积了页面缓存导致nodefs或imagefs压力不一定是Pod requests的问题。最后再分享一个日常习惯每次发布新服务我都会要求带上资源字段并且在一个测试namespace里配置LimitRange做默认值校验。上线后第一周每天看资源使用曲线第二周根据曲线调整一次requests和limits。这个动作看似很小但能把“争抢”和“浪费”这两个问题同时按下去。如果你也总是被资源问题折腾建议从今天起给每个Deployment补上resources字段再在namespace上卡一个ResourceQuota后面你的告警邮件一定能安静不少。