1. Request与Limit：资源数字背后的调度潜规则

开头

做K8s运维这几年，我最大的感受是：大部分Pod调度问题，根源不在调度器本身，而在编写Deployment时随手填的那两个数字——resources.requests和resources.limits。很多人对K8s资源调度有误解，以为Pod能不能跑起来取决于节点剩余内存够不够大，其实不对。调度器做决策时根本不看节点当前真实使用量，只看节点上已分配资源的累计值。这意味着，哪怕一台节点实际空闲得发慌，只要它上面所有Pod的request总和已经超过节点容量，新Pod照样调度不上去。

这篇文章我从调度机制、节点选择策略、QoS驱逐规则、真实排障、HPA联动五个层面，把Pod资源调度的核心链路完整梳理一遍。适合刚接触K8s没多久、正在被Pod Pending折磨的初学者，也适合那些想搞明白“为什么明明有空闲资源、Pod却卡在调度队列里”的进阶选手。不说空话，全部是实际操作中验证过的东西。

1.1 这几个数字到底决定什么

资源配置通常长这样：

yaml复制resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: "2"
    memory: 2Gi

两个数字作用完全不同。

requests是给调度器看的。调度器为Pod选节点时，会把Pod的request累加到节点“已分配资源”上，保证所有Pod的request总和不超过节点容量。它本质上是“预留额度”，是一种逻辑上的资源承诺，不是实时用量。kubelet每10秒会上报一次节点状态，其中allocatable就是节点总容量减去系统预留和kubelet自身保留后的可分配值，调度时用的就是它。

limits是给运行时看的。容器实际使用超过limit时，CPU会被限流（throttling），内存超过limit会触发OOM Killer，直接杀掉容器进程。也就是说，limit更多是保护邻居、保护节点，不是用来保障自己。

有两个细节经常被忽略。

第一，CPU的request单位是核，500m就是0.5核，可以写成500m，也可以写成0.5。CPU是可压缩资源，超过limit只是被限流，容器不会死。内存是不可压缩资源，无路可退时内核只能杀进程。

第二，如果只写limit不写request，K8s有一个隐含行为：它会自动把request值设为limit值。这个设计本意是帮用户兜底，因为它会把Pod自动归为最高QoS等级，避免用户因为忘记写request导致Pod变成BestEffort。很多人在测试环境图省事只写limit，结果数量一多，每个Pod实际预留的都等于limit，节点资源瞬间被“凭空”占满。我见过不止一次测试环境节点莫名其妙地调度不上新Pod，查到最后全是这个原因。

1.2 从监控反推合理的Request值

Request值设多大，不能拍脑袋。我的习惯是：先压测，再看监控，然后留buffer。

具体操作流程是这样。第一步，把业务容器没有配置资源的Pod（或不设limits）部署到一台独立测试节点上，确认监控系统在采集容器CPU和内存的working_set。第二步，用压测工具（Jmeter、wrk、k6都行）把流量打到预期的日常峰值的1.5到2倍。第三步，观察这段压测时间内的P99内存使用和CPU使用曲线。

拿到数据后，我的建议是请求值取“P99观测值 × 1.3”，limit取“请求值 × 2到3倍”。比如某个服务P99内存是400Mi，request设512Mi，limit设2Gi，CPU同理。这个写法既让调度器为Pod预留了足够“过冬”的粮食，又允许它在突发流量下临时借助节点空余资源，而不是一超限就死。

有人会问：为什么不直接request等于limit，这样QoS等级最高，最稳？这需要看你集群的资源利用率和业务重要程度。如果节点资源充足、成本不敏感、集群规模小，那我支持这种做法。但如果你在一个业务线很多、节点资源长期处于70%以上水位的大集群里，所有Pod都Guaranteed，资源浪费会很严重，之后就必然面对加节点、提成本的压力。至于是不是Guaranteed一定最好，下面QoS章节我会展开讲。

2. 调度器的工作闭环：Pod从提交到Running经历了什么

2.1 调度、预选、优选：kube-scheduler的完整决策链路

提交一个Deployment后，资源调度的主流程是这样的。

Pod先进入API Server，被写入etcd。这时它的状态是Pending，spec.nodeName还是空的。kube-scheduler监听到这个没有归属节点的Pod，把它放进调度队列，开始处理。

调度过程分两阶段：Filter（预选）和Score（优选）。

Filter阶段是硬性的，淘汰制。调度器会用一系列predicate插件检查节点。比如NodeResourcesFit检查节点剩余可分配资源是否满足Pod的request，NodeAffinity检查节点标签是否匹配Pod声明的亲和性规则，TaintToleration检查节点上的污点Pod是否容忍，PodTopologySpread检查拓扑分布约束是否被违反。任何一个插件返回false，节点直接出局。如果最后没有节点通过，Pod就卡在Pending，事件里会写明失败原因。

Score阶段是软性的，排名制。所有通过筛选的节点会参与打分，调度器按一系列score插件的规则给每个节点打分（0到100），取最高分。NodeResourcesFit在打分阶段会倾向于“分配后剩余资源更均衡”的节点，ImageLocality会优先选已经有业务镜像的节点，PodAffinity会根据存量Pod和待调度Pod的关系调整得分，NodeAffinity的权重也会影响最终排序。注意Filter和Score可以使用同一个插件名，但职责完全不同。

我刚开始学K8s时总以为调度器是“看哪个节点空闲就往哪放”，其实不对。更准确的描述是：调度器先做排除法，把硬件条件、软性约束、规则匹配不上的节点全部剔除，然后在剩下的候选者中按策略打分排序。如果你配置了NodeAffinity反亲和性，它还会考察节点上正在运行的其他Pod的标签，这是很多人容易漏掉的一个点。

2.2 节点资源碎片化：为什么有空闲却调不上去

这是生产中特别常见的现象，而且极具迷惑性。用kubectl top nodes看，节点内存利用率才60%，但新Pod就是调度不上去，提示Insufficient memory。

原因在第一节已经埋了伏笔：调度器用的是“已分配量”，不是“实时使用量”。假设节点内存总量是32Gi，上面跑了10个Pod，每个request可能写了2Gi，实际使用只有几百Mi。此时节点“已分配量”已经是20Gi，如果另一个Pod需要调度4Gi内存，节点剩余可分配可能不足4Gi，这轮Filter就把节点淘汰了。但你用kubectl top node看实际使用，可能只有30%。

用生活化的比喻来说：你在一个青年旅舍，每个床铺都被人预定了，即使有些人只是把行李放上去、人根本不在，后来的人也住不进来。

应对节点资源碎片化有几个方向：

• 提高节点规格，减少节点数量，让分配粒度变大。
• 合理收敛request值，避免过度预留。
• 使用descheduler定期把Pod重新调度，让节点资源分配更紧凑。
• 对已知的“预定不用”的服务，比如偶发性的离线任务，考虑使用优先级（PriorityClass）配合低request，把它们放到资源压力大的节点上。

2.3 调度失败时的标准排查姿势

Pod调度不上时，常规排查动作就五步。不要上来就翻日志，先看事件，事件信息量最大。

bash复制kubectl get events --sort-by=.lastTimestamp | tail -50
kubectl describe pod <pod-name>

describe里的Events字段基本会把调度器拒绝的原因写得很直白，比如：

• 0/5 nodes are available: 3 Insufficient cpu, 2 node(s) didn't match node affinity
• 0/5 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate

如果只看yaml文件排查，你会漏掉很多信息。Event信息来源于调度器的真实反馈，通常已经把“为什么不调度”讲到一个可以定位的粒度了。拿到原因后，再结合kubectl describe node <node-name>查看节点分配资源量，确认到底是request超了还是亲和性不满足。这套流程走完，绝大多数调度问题都能定位到根因。

3. 节点选择策略：从nodeSelector到反亲和性的实战选型

3.1 四种节点选择方式的取舍

K8s控制Pod落在哪个节点上，有四个层级的工具，按从简到繁排：

• nodeName：直接把Pod钉死在某台节点，不经过调度器。这种方式最直接，但会破坏调度器的自主性，管理节点下线或故障时非常被动，一般只适合测试，不建议上生产。
• nodeSelector：最简单的标签匹配，Pod只选择带指定标签的节点，适合“把某些服务固定到某类机器”的场景，比如所有数据库Pod都落在带disk=ssd标签的节点上。
• nodeAffinity：比nodeSelector灵活得多，支持requiredDuringScheduling（硬性必须满足）和preferredDuringScheduling（软性尽量满足），还支持多个匹配规则，可表达“必须落在GPU节点上，优先落在所在可用区是A的节点上”这种复合约束。
• 反亲和性（podAntiAffinity）和topologySpreadConstraints：前者用来控制“不要让某类Pod落在同一个节点或同一个可用区”，后者用来控制Pod在拓扑域上的均匀分布。

如果你管的是一个十几个节点的小集群，用nodeSelector可能够用了。但凡是服务超过3个副本、或者有跨可用区多活要求的业务，我从实际经验讲，podAntiAffinity基本是标配，不然副本全挤在同一台节点上一挂挂一片，就失去多副本的意义了。

3.2 把同一服务实例打散到不同节点

这个实践最常用的标签是app。比如有一个服务叫order-service，三个副本，最朴素且有效的方式：

yaml复制affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: app
              operator: In
              values:
                - order-service
        topologyKey: kubernetes.io/hostname

topologyKey字段决定了反亲和的“反”的粒度。填kubernetes.io/hostname表示同一节点上不能出现两个同样标签的Pod；填topology.kubernetes.io/zone表示同一可用区里不能放两个同样的副本。后者通常用在多可用区容灾场景。

这里有个坑需要提醒。requiredDuringScheduling在节点数量不足时，会直接导致调度失败。比如你只有两台节点，却想让四个order-service副本分别落在不同节点上，那最多只能调度上去两个，剩下两个一直Pending，业务方会很难受。所以生产环境我一般会配合preferredDuringScheduling来使用软性反亲和，让调度器“尽量打散”，实在打散不了也别致命。核心业务可以硬亲和，非核心业务建议软亲和，这个度要根据业务重要性和集群资源富余程度来权衡。

3.3 taint与toleration：节点准入控制的关键

污点（taint）是节点侧的“拒绝规则”，容忍（toleration）是Pod侧的“通行证”。两者配合实现了“节点可以拒绝哪些Pod进来”的准入控制能力。

常见场景有三个。第一，给GPU节点打污点，只有声明了容忍并且需要GPU资源的Pod才能调度上去，防止普通业务把GPU节点的CPU和内存挤占掉。第二，给运维系统专用的节点打污点，业务Pod默认不上去。第三，控制面节点（master节点）默认带污点，普通业务Pod不会调度到master上。

等保这条线，我觉得想强调的核心是：污点值还有一种用法是配合NoExecute。当一个节点被打上NoExecute污点时，K8s不仅会阻止新Pod调度上去，还会把已经运行在该节点上、不容忍这个污点的Pod全部驱逐。这个特性在节点需要临时下线维护时非常有用，运维可以通过给节点打污点优雅地把业务腾挪走，而不必直接drain节点导致很多次要告警爆炸。

4. 资源争抢时的生死规则：QoS等级与驱逐优先级

4.1 三种QoS等级，以及谁会被最先杀死

K8s按request和limit的设置方式把Pod划分为三个QoS等级：

• Guaranteed：每个容器都设置了request和limit，且两者相等。
• Burstable：至少一个容器设置了request或limit，且不满足Guaranteed条件。
• BestEffort：所有容器都没有设置任何request和limit。

等级越低，越容易被优先驱逐。当节点内存紧张触发驱逐时，顺序是BestEffort先死，Burstable中间，Guaranteed最后。这个顺序在kubelet的eviction manager模块里是硬编码的优先级逻辑。调度器决定Pod能不能上来，QoS等级决定节点资源不够时谁先下去，两者是两条独立的决策链。

很多人以为Guaranteed最安全，所以把自己的Pod全部配成Guaranteed。但我的观点是：Guaranteed只是“不容易被驱逐”，不意味着“永远不会被驱逐”。节点在极端情况下，比如system.oom事件引发kubelet主动回收时，Guaranteed Pod如果超过limit一样会被杀死。更关键的是，Guaranteed Pod占用的资源是死额度，调度时已经把limit当作request预留出去了，CPU和内存使用率低时也无法共享给其他Pod，集群资源利用率会很难看。我一般建议：核心且有状态的服务配Guaranteed；普通无状态业务配Burstable，但request的估算要靠谱一点。

4.2 节点压力驱逐的触发机制

kubelet持续监控节点文件系统、内存、镜像存储的使用量，一旦超过阈值，就启动驱逐流程。节点内存驱逐主要是参考memory.available，它的计算方式是节点容量减去working_set（kubelet统计出来的活跃内存集合），而不是直接把node.status.allocatable减去全部容器使用量。当memory.available低于--eviction-hard设置的阈值，比如memory.available<500Mi时，kubelet会先尝试回收可回收资源（比如空Pod占用的镜像层、已经停掉的容器），如果回收无效，就按QoS顺序驱逐Pod。

这个机制所有节点默认开启，但阈值可以调。生产环境我建议把eviction-soft和eviction-hard分别设置，用来制造一个“软驱逐预警告警，硬驱逐强制执行”的缓冲区间。具体参数在kubelet配置文件中：

yaml复制evictionSoft:
  memory.available: "1Gi"
evictionSoftGracePeriod:
  memory.available: "1m30s"
evictionHard:
  memory.available: "500Mi"

软驱逐（soft eviction）到硬驱逐（hard eviction）之间会有宽限期，给Pod时间优雅退出。对正常情况下的节点资源管理很有用。另外，监控告警必须覆盖eviction_manager的驱逐事件，不然一旦发生批量驱逐，业务影响可能非常突然。我建议给“节点内存驱逐”单独做一条告警规则，一旦出现就PROJECT2级别的响应处理，这比服务本身报警来得更早、更容易排查。

4.3 通过PriorityClass和QoS组合保护核心业务

QoS决定Pod在节点层面谁先被驱逐，PriorityClass决定Pod在调度队列里谁先被调度，也决定低优先级Pod是否会被抢占（preemption）。

生产集群我通常会定义三档PriorityClass：system-cluster-critical、platform-high、business-default。核心基础组件（coredns、kube-proxy、metrics-server）用cluster-critical，自家核心中间件用platform-high，普通业务服务用business-default。这可以解决一个场景：当集群资源紧张时，新来的高优先级任务可以抢占低优先级Pod的资源，低优先级Pod会被驱逐到别的节点或进入Pending等待，而不是让所有Pod都在那儿磨蹭。

说句实话，PriorityClass配合QoS的组合在一般中小集群里用到的频率并不高，但一旦集群上运行业务多样、资源集中竞争，这套分层机制就是秩序基础。我见过一个集群同时跑在线交易、离线数仓任务和测试任务，如果不分层，离线任务的大内存request会把在线业务的调度窗口完全挤占。加了PriorityClass之后，离线任务变成低优先级、可抢占，在线业务几乎再也没被波及过。

5. 一次真实排障实录：Pod卡在Pending三天

5.1 现象：事件里写“不满足PodAffinity”

我遇到过一个典型情况：新上的user-service三个Pod，一个Running两个Pending，卡了快三天。describe看到的事件信息是：

code复制0/12 nodes are available: 2 Insufficient cpu, 10 node(s) didn't match pod anti-affinity rules.

乍一看很莫名其妙。第一反应是节点资源不够？但看集群，空闲节点一大把。真正的问题是didn't match pod anti-affinity rules——反亲和性规则把大部分节点都挡住了。

那为什么明明没有给user-service配置反亲和性，事件里却出现反亲和性规则？答案很反直觉：不是user-service的反亲和性挡了自己，而是平台上其他服务配置了podAntiAffinity，它们要求“不要和带有某标签的Pod放在同一节点”。而user-service恰好带了那个标签，于是它自己成了被其他Pod排斥的对象，调度器一筛选，大部分节点都被别的服务“占住”了，剩下能去的地方CPU又不够。

5.2 完整排查链路：从事件到标签再到亲和性配置

这个问题的排查链路值得完整走一遍，因为每步都能学到东西。

第一步，看事件明确失败原因。上面已经提到，是反亲和性规则不满足。

第二步，确认是谁的反亲和规则。用kubectl get pods -A -o yaml | grep -B5 -A20 podAntiAffinity把集群里所有配置了反亲和性的Pod列出来，然后定位到具体Deployment，看它匹配的标签是什么。这一步很费时，但也是必须做的。我建议用kubectl get deploy -n <namespace> -o yaml逐个排查，或者用kubectl api-resources看有没有可用的策略报告工具。现成的第三方工具如polaris也能扫出部分配置问题，但亲和性语境还是要自己看。

第三步，核对节点上的标签。用kubectl get nodes --show-labels查看当前节点标签，看是不是某几个节点因为被人为打了标签（比如节点加入GPU资源池）而匹配了别的服务反亲和规则。

第四步，发现真相。最终定位到：平台上好几个核心服务都配置了“不与app=platform-core标签共存”的反亲和规则，而user-service因为是基础用户服务，正好也被打上了app=platform-core标签。这个标签是一位同事为了方便管理统一打的，结果触发了和别的服务的排挤关系。

第五步，修复动作分两层。短期快速恢复：把user-service的标签改掉，不和其他核心服务共用一个标签，调度立刻恢复。长期治理：在CI流水线中加入admission校验，不允许团队随意改动Pod标签；同时在命名空间层面用ValidatingAdmissionPolicy或者OpaGatekeeper拦截可能和现有反亲和规则冲突的标签组合。

5.3 修复后为什么还会复发

修完当天正常了，但隔了三周又出现同类型问题。这次是另一个服务的新版本上线，同样莫名其妙调度不上去，事件原因一模一样。这说明只处理一次问题没用，必须把根因堵住。

我后来做了一套平台内部的自检脚本，每天晚上跑一次，扫描集群中所有Deployment的亲和性规则和标签组合，生成冲突报告。规则不复杂，就是读取全部Pod的标签和亲和性声明，判断是否存在“A服务声明不与X标签共存，B服务又正好带X标签，且两者目标节点重叠”的组合关系，命中就报警。这个脚本看起来简单，但实际运行时全靠它及时发现配置冲突，并且给出建议的标签调整方案。

这里也顺便聊一下K8s和Docker的关系，因为调度问题排查时经常会绕到“我明明用的是Docker，怎么还需要管K8s调度”这种疑问。简化的理解是：Docker负责单个容器的生命周期，K8s负责一堆容器在多个机器上如何组织、如何保证服务可用；调度器就是K8s里做“把容器放到哪台机器”决策的核心模块。你仍然可以单独使用Docker，只是在K8s集群里，Pod才是调度单元，Docker只是底层运行时之一（目前还有containerd、CRI-O等可选）。

6. 从单副本到自动伸缩：资源调度与HPA的联动配置

6.1 HPA究竟依据什么伸缩

很多人以为HPA是看“CPU使用率达到多少就扩容”，这个理解是半对半错。准确地说，HPA是通过metrics-server采集Pod当前的实际使用量，然后用下面的公式计算目标副本数：

code复制desiredReplicas = ceil(currentReplicas × (currentMetricValue / desiredMetricValue))

关键点在于currentMetricValue的求法。如果用的是ResourceMetricSource，currentMetricValue是所有目标Pod的实际使用率（currentUtilization）的平均值。而currentUtilization的计算方式是用Pod当前使用量除以requests里面声明的值，再乘以100。如果Pod没有配置request，HPA的CPU/内存指标就无法计算，这会让HPA完全失效。所以，HPA和资源调度是深度联动的，你给Pod写的request值会直接影响伸缩的灵敏度和最终副本数。

举一个实际例子。你的服务request设了1核CPU，HPA目标利用率设50%，当前Pod实际用了0.6核。此时当前利用率为60%（0.6/1），高于目标50%，HPA就会扩容。如果你把request设成0.5核，同样0.6的使用量，当前利用率就到了120%，HPA会立刻扩容更多副本，甚至引发扩容风暴。这里的核心思想是：HPA不是在直接响应节点压力，而是在响应你定义的资源水位的相对值。request写得太低，扩容会很激进；写得过高，缩容又可能不及时。

6.2 TargetCPUUtilization设置多少才合理

目标利用率设置过高（比如80%），Pod实际使用冲到80%时才开始扩容，从扩容到新Pod Ready需要几秒到几十秒，期间业务可能已经出现响应变慢。目标利用率设置过低（比如30%），副本数容易偏多，成本上升。

我的建议是分两类：

• 无状态业务、延迟敏感型（比如API网关、用户接口）：目标利用率40%-55%，并配置好HPA的最小副本数，确保高峰期的突发流量能快速拉起新副本。
• 后台任务、异步队列消费者（对延迟不那么敏感）：目标利用率60%-75%，让资源复用更充分。

HPA还需要考虑扩容冷却时间和缩容冷却时间。K8s v1.25之后可以通过behavior字段控制：

yaml复制behavior:
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
      - type: Percent
        value: 100
        periodSeconds: 15
  scaleDown:
    stabilizationWindowSeconds: 300

这样配置可以保证快速扩容，但缩容要经过5分钟的稳定窗口，避免流量抖一下副本数跟着乱抖。我一直觉得：缩容冷却比扩容冷却更重要，没有稳定窗口的HPA会在流量波动时反复横跳，反而会制造更多调度压力。

6.3 用ResourceQuota和LimitRange给乱象兜底

资源调度不是只管Pod自己，还要管租户之间、团队之间的资源分配。在K8s里，ResourceQuota和LimitRange就是干这个的。

ResourceQuota可以限制一个命名空间下所有Pod的request和limit总量。比如开发环境命名空间限制总CPU request不超过20核、内存不超过40Gi，超过之后新的Deployment就无法创建。这个能力在多人共享集群时尤其有用。没有配额时，每个团队都觉得自己多用一点没事，最后整个集群被各种夸张配置占满，谁的服务都跑不顺手。

LimitRange则是给“没有显式配置资源的容器”注入默认配置，或者限制单个Pod的资源配置范围。比如你可以设置一个默认的requests和limits值，凡是Deployment没写资源，系统会自动补上。这在一定程度上减少了前面说的“只写limit不写request”的坑，因为哪怕用户忘了写resources，LimitRange也会帮你填一组合理值，不会让所有容器默认变成BestEffort。

我在团队内部推行的规范是：每个命名空间必须配置ResourceQuota和LimitRange，测试环境配额可以宽松，生产环境配额必须紧。在配额基础上，再配合CI检查里强制每个Deployment必须声明resources字段，这两种机制双管齐下，资源调度的“乱象”基本就能杜绝一半以上。

另外再多提一句，很多人在网上搜“k8s和docker区别”，其实在生产调度场景里，这两者是互补关系，不是替代关系。Docker镜像负责打包，K8s调度Pod负责决定“镜像跑在哪、怎么跑、跑多少份”。理解到这个层面，很多调度问题你就不会再去容器运行时层面找原因了，会直接回到调度器和资源配置本身。