一讲到“磁盘调度”很多刚接触Kubernetes的人第一反应是磁盘不是kubelet管的事吗节点磁盘压力检测、镜像清理、容器日志轮转确实是kubelet的职责。但Pod能不能放到某个节点、该放在哪个节点从Pod提交到API Server的那一刻kube-scheduler就开始做磁盘调度决策了。这篇文章就围绕kube-scheduler的磁盘调度源码分析展开核心会拆掉本地临时存储、PVC持久化存储、节点磁盘压力这三条调度链路。适合正在被Pod反复Pending折磨或者想真正看懂调度器内部逻辑的工程师。先说个容易误解的点调度器并不像监控系统那样看“节点磁盘实时占用率”它用的是另一套账本。这套账本的核心是Pod声明、节点Allocatable、以及调度器自己维护的Requested累计值。想搞清楚磁盘调度就必须先接受这个前提。文章里我会把关键源码做简化展示重点讲清楚每个函数存在的理由以及不同版本里可能出现的差异。1. 调度器眼里的磁盘资源其实有三条业务线1.1 三种磁盘请求是怎么进入调度器的第一条线是ephemeral-storage。它和CPU、内存一样是节点资源的一种出现在Node的Capacity和Allocatable里。Pod里的容器可以通过resources.requests和resources.limits声明自己的临时存储需求。调度器在过滤节点时会把Pod请求的临时存储加到节点已有的请求量上然后和节点的Allocatable做比较不够就直接拒绝。我们平时在事件里看到的Insufficient ephemeral-storage就来自这一步。第二条线是持久化存储体现为PV/PVC。这一层的内容要复杂得多因为它不只比容量还要回答三个问题PVC有没有绑定的PV、PV有没有节点亲和性限制、StorageClass是不是WaitForFirstConsumer延迟绑定模式。这些问题的本质是“存储到底该创建在哪个区域”也就是说调度器要在Pod还没有落节点之前先替存储层做一道拓扑判断题。第三条线是节点自身的运行状态。当节点出现磁盘压力时kubelet会一边驱逐Pod保护文件系统一边把节点的DiskPressure状态上报。调度器这一侧则通过污点和容忍机制间接感知默认不会主动往一个已经磁盘压力的节点上塞新Pod。1.2 这些逻辑挂在调度框架的哪些扩展点kube-scheduler把调度过程切成了调度周期和绑定周期。调度周期里Pod按顺序经过PreFilter、Filter、PostFilter、PreScore、Score、NormalizeScore、PostScore这些扩展点。每个in-tree插件可以选择在某个或某几个扩展点注册自己的逻辑。磁盘相关的插件注册关系大概是下面这张表磁盘相关需求主要插件扩展点ephemeral-storage资源请求NodeResourcesFitFilter、Score本地临时存储隔离LocalStorageCapacityIsolationFilterPVC/PV卷绑定与拓扑VolumeBindingPreFilter、Filter节点卷数量限制NodeVolumeLimitsFilter磁盘压力污点TaintTolerationFilter节点资源账本NodeInfo数据缓存层这张表就是读源码时的地图。大多数磁盘容量判断发生在Filter阶段也就是先保证“这台节点能放得下Pod”而最终选择节点时还要看Score阶段对磁盘余量的偏好。把这两步分开理解后面看代码才不会被绕晕。2. 本地临时存储NodeResourcesFit 的请求计算与过滤实现2.1 computePodResourceRequestPod磁盘请求从哪来NodeResourcesFit插件的主文件在k8s.io/kubernetes/pkg/scheduler/framework/plugins/noderesources/fit.go。名字虽然叫Fit但Filter和Score它都管。它做过滤时不是直接读Pod的YAML而是先把Pod里所有容器的资源声明汇总成一个framework.Resource对象再用这个对象和节点上的可分配资源比较。汇总逻辑主要在computePodResourceRequest函数里这个函数有几个反直觉的地方值得多看两遍。第一普通容器的CPU、内存、ephemeral-storage是累加关系。一个Pod里三个容器各声明100Mi临时存储最终Pod对临时存储的请求就是300Mi。这好理解因为普通容器同时运行资源会同时被占用。第二InitContainer不是累加而是取最大值。源码会遍历所有InitContainer把每个维度上最大的请求单独记下来再和普通容器的合计值逐维度取最大值。原因也很直白InitContainer是串行执行的同一时刻只有一个在跑哪怕它瞬间吃掉很多磁盘也不会和另一个InitContainer叠加。第三如果容器只写了limits没写requestsKubernetes语义下requests默认等于limits。所以computePodResourceRequest在汇总时发现requests字段为零会去limits里取值。比如容器只写了limits.ephemeral-storage: 20Gi调度器就会按20Gi计算它的启动需求。这个细节最容易漏也是很多不合理limit“意外生效”的原因。核心逻辑简化后大概是下面这个样子func computePodResourceRequest(pod *v1.Pod) *framework.Resource { result : framework.Resource{} for _, container : range pod.Spec.Containers { requests : container.Resources.Requests if requests.EphemeralStorage().Value() 0 { result.EphemeralStorage requests.EphemeralStorage().Value() } else if limits : container.Resources.Limits.EphemeralStorage(); limits.Value() 0 { result.EphemeralStorage limits.Value() } // CPU、内存、大页等标量资源也做类似累加 } // 初始化容器逐维度取最大再与result合并 return result }注意这里的EphemeralStorage单位是字节。声明5Gi会被换算成一个很大的整数源码内部统一用字节数和Quantity避免浮点误差。2.2 fitsRequest过滤时到底在比什么节点上能调度多少资源看的不是物理磁盘剩余而是调度器在NodeInfo里维护的一份“账”Allocatable减去Requested。Allocatable来自Node对象的Status.Allocatable是经过系统预留、镜像预留之后真正能分给Pod的部分Requested是节点上所有已调度Pod的请求总和这个值由调度器自己在内存里累加和扣减。fitsRequest就是做这层减法判断的核心函数func fitsRequest(podRequest *framework.Resource, nodeInfo *framework.NodeInfo) bool { allocatable : nodeInfo.Allocatable if allocatable.EphemeralStorage podRequest.EphemeralStorage { return false } if allocatable.MilliCPU podRequest.MilliCPU { return false } if allocatable.Memory podRequest.Memory { return false } // 还要检查大页等标量资源 for rName, rQuant : range podRequest.ScalarResources { if allocatable.ScalarResources[rName] rQuant { return false } } return true }代码很朴素但隐含了一个重要前提调度器只信任Pod声明不关心节点上真实产生了多少日志、多少镜像、多少emptyDir。如果一个节点本地有大量未计入Pod请求的临时文件哪怕物理磁盘快要爆了调度器依然认为这台节点有余量。这也是为什么很多磁盘问题表面看是调度器误判实际上从一开始就没把ephemeral-storage写进资源声明。Filter阶段一旦返回失败常见的kubectl describe pod事件里就会出现Insufficient ephemeral-storage。看到这句话先别急着怀疑调度器先看节点Allocatable和已请求量再核对Pod的requests是否合理。2.3 为什么还要有LocalStorageCapacityIsolation看完NodeResourcesFit可能有人会问既然它已经检查ephemeral-storage为什么调度器里还单独放着一个LocalStorageCapacityIsolation插件这个问题在源码里有明确答案两个插件职责有重叠但策略不一样。NodeResourcesFit按“请求量”做过滤Pod不声明ephemeral-storage请求量就是0等于不设防。LocalStorageCapacityIsolation则是专门为临时存储设计的隔离策略它除了检查requests还会把Pod声明的limits纳入考虑用limits去和节点余量做比较。核心逻辑在pkg/scheduler/framework/plugins/localstorage/capacity_isolation.go这个文件里过滤时大致是这样func (c *localStorage) Filter(...) *framework.Status { allocatable : nodeInfo.Allocatable.EphemeralStorage requested : nodeInfo.Requested.EphemeralStorage podLimit : getPodLocalStorageLimit(pod) if requestedgetPodLocalStorageRequest(pod) allocatable { return framework.NewStatus(...) } if requestedpodLimit allocatable { return framework.NewStatus(...) } return nil }注意它在判断时用的是requested也就是节点上已有Pod的请求总和加上当前Pod的请求或limit。它的本质是防止一个Pod声明了很大的临时存储limit把整个节点的磁盘“画”没了逼着其他Pod无处可放。生产环境里如果遇到“节点明明还有几十GB新Pod却因为ephemeral-storage不调度”多半就是有一个巨大的、或者不合理的limit存在。处理方式不是调大节点Allocatable而是检查Pod的临时存储声明。3. 持久化磁盘VolumeBinding如何决定Pod能落在哪个节点3.1 PreFilter先把PVC和PV的绑定关系摊开持久化存储的调度不能只靠容量加减因为大多数用户的卷不是提前切好的裸盘而是通过PVC动态申请出来的。调度器如果只看节点本地磁盘完全不知道PVC背后要创建多大的PV、这块PV能不能挂到目标节点。所以VolumeBinding插件的PreFilter阶段有一个关键动作把Pod相关的所有PVC和PV关系先拉一遍。入口在pkg/scheduler/framework/plugins/volumebinding/volume_binding.go。PreFilter从Pod的spec里解析出所有PVC再通过informer cache分别查出这些PVC的当前状态。已经绑定PV的归到boundPVs还没绑定PV的归到unboundPVCs。这两类在后续Filter里走的是完全不同的检查路线。如果Pod里有PVC但PVC还处于Pending状态PreFilter阶段就会直接报错。这个逻辑很严格调度器不会把一个连卷都还没有的Pod放到某台节点上因为“放到哪台节点”这个决定会直接影响后续PV创建在哪个区域。PreFilter处理完的数据会写进一个CycleState相当于调度周期内的临时上下文。后续的Filter、Score直接从上下文拿数据不用反复查API Server也保证了同一个Pod在多个扩展点看到的卷状态完全一致。3.2 FilterPV节点亲和性、存储类拓扑与挂载能力Filter阶段才是真正回答“这台节点能不能满足该Pod的持久化存储需求”的地方。对已经绑定的PV主要检查三件事。第一PV的nodeAffinity是不是限定了一组节点。比如PV通过kubernetes.io/hostname固定到某台机器那只有这台机器能挂它。第二PV对应的存储插件在节点上是否具备挂载能力比如某些CSI驱动需要在节点上安装对应组件节点没有就是挂不上。第三如果PVC申请的size超过PV提供的容量也无法匹配。这些检查在内部约等于canSatisfyPV这个函数的职责。对还没绑定的PVCVolumeBinding要看StorageClass的volumeBindingMode。最常见也最坑的是WaitForFirstConsumer这个模式的意思是卷要等第一个Pod出现才知道该创建在哪个区域。假如StorageClass配置了allowedTopologies限定只能创建在某个zone那Pod所在节点必须带这个zone标签否则即使物理上任何地方都能挂卷调度器也会把Pod刷掉。Filter里对应的逻辑可以概化成两个函数func canSatisfyPV(pv *v1.PersistentVolume, node *v1.Node) bool { // 1. PV的节点亲和性是否匹配 // 2. 卷插件是否支持在node上挂载 // 3. PV容量是否满足PVC请求 } func canSatisfyPVC(pvc *v1.PersistentVolumeClaim, node *v1.Node) bool { class : getStorageClass(pvc) if class nil { return false } if class.VolumeBindingMode ! WaitForFirstConsumer { return false } // 检查allowedTopologies与节点标签是否匹配 return nodeMatchesTopology(class.AllowedTopologies, node) }Filter失败时调度器不会轻易重试。像unboundPVCs这种问题即使等一会儿卷创建成功了Pod也需要重新进队列触发一次完整调度。理解这个行为对排障很重要有些时候改完PVC发现Pod还是Pending就是因为调度器还没被新事件唤醒需要检查事件驱动是否生效。3.3 卷数量和卷亲和性的邻居们持久化磁盘调度里还有两个“邻居”一个是NodeVolumeLimits一个是VolumeBinding里可能出现的Score实现。NodeVolumeLimits检查的是“节点上最多能挂多少块卷”而不是容量。云环境里很常见的是单节点云盘数量限制比如某个环境限制了单个节点最多挂几十块云盘。Pod数量上去了卷数也跟着上去了没有这个检查调度器会把节点塞爆。它通过CSINode或插件配置拿到上限然后在Filter阶段数一下节点上已经挂载的卷数量。VolumeBinding本身在某些版本里还实现了Score扩展点。思路很简单节点上如果已经挂了Pod所需的某些PV就给这个节点加分。原因是同一个Pod的多个卷如果落在已经attach过的节点上可以减少后续挂载和跨节点attach的开销。源码里往scorePodOnNode这个方向找就行不过不同版本对这个能力支持程度不一样自己翻源码时留意一下就好。4. NodeInfo调度器内存里的磁盘资源视图4.1 Requested、Allocatable、NonZeroRequested分别是什么NodeInfo不是API层的对象它是调度器在内存里维护的节点账本。所有插件在Filter和Score阶段读到的资源数据基本都来自这个对象。它的定义里一般能看到四个核心字段Requested、NonZeroRequested、Allocatable、Capacity。Allocatable直接拷贝自Node对象的Status.Allocatable。Capacity是节点物理容量但调度器真正用来做容量判断的是Allocatable因为系统组件、镜像、kubelet本身都要占资源。Requested是调度器自己维护的累计值每当一个Pod被调度到节点上调度器就调用AddPod把Pod的请求加进去Pod从节点移除调用RemovePod减掉。NonZeroRequested是一个很有意思的设计。对CPU和内存如果Pod没有声明requests调度器会默认按100m CPU和200Mi内存来算这是DefaultMilliCPURequest和DefaultMemoryRequest两个常量。这个值的用途是防止完全没写资源的Pod被调度器当成“零负载”把节点资源全部占走。但注意ephemeral-storage没有类似的默认值Pod不写调度器就按0处理。所以全用NodeInfo里的磁盘数据做容量规划时必须清楚Requested.EphemeralStorage只反映所有Pod声明过的临时存储总和没声明的一律是0。这直接解答了一个高频疑问“节点Allocatable明明有100Gi为什么调度器说Insufficient ephemeral-storage”因为账本上的请求量已经超过Allocatable跟物理剩余多少没有一一对应关系。func (n *NodeInfo) AddPod(pod *v1.Pod) error { res : computePodResourceRequest(pod) n.Requested n.Requested.Add(res) n.NonZeroRequested n.NonZeroRequested.Add(res) // 还会更新端口、卷、镜像状态等字段 }上面是简化后的AddPod思路。真实代码里还要更新其他字段但磁盘部分的核心就是这行资源加法。4.2 磁盘压力状态如何参与调度磁盘压力DiskPressure是节点级别的Condition由kubelet检测并上报到Node Status。调度器这边会通过NodeInfo缓存节点的Conditions但默认情况下真正因为磁盘压力把节点拦住的是污点与容忍机制而不是某个插件在Filter里主动判断Condition。链路大概是这样的kubelet发现节点磁盘使用率超过阈值会标记节点的DiskPressure condition控制面侧的节点生命周期管理逻辑会据此给节点打上node.kubernetes.io/disk-pressure之类的污点调度器的TaintToleration插件在Filter阶段遇到这个污点如果Pod没有对应容忍就直接把节点排除。这个设计把“检测磁盘压力”和“是否允许调度”解耦了kubelet只管反映事实调度器只凭污点做准入。以后排查磁盘压力导致的不调度重点应该看节点污点而不是去调度器日志里找condition判断。5. 打分阶段磁盘碎片化与节点均衡5.1 LeastAllocated怎么给磁盘打分Filter决定“能不能放”Score决定“放到哪”。NodeResourcesFit的Score扩展点默认使用LeastAllocated策略意思是“往资源剩余最多的节点上放”。每种可打分的资源都会单独算出一个0到100的分数再按权重平均。磁盘的核心公式很简单func leastAllocatedScore(requested, capacity int64) int64 { if capacity 0 { return 0 } return ((capacity - requested) * 100) / capacity }分母是capacity分子是剩余量剩余比例越高得分越高。举个具体例子节点A的CPU是2000m里请求1000m、内存2Gi里请求1Gi、磁盘50Gi里请求10Gi节点B的CPU请求500m、内存请求0.5Gi、磁盘请求5Gi。两者磁盘得分分别是(50-10)/5010080和(50-5)/5010090再和其他资源的分数取平均节点B总分更高调度器会倾向选B。这种策略天然能缓解磁盘碎片化同一块磁盘上的Pod越少越容易拿到高分。5.2 一个容易踩的配置坑打分时会漏掉磁盘NodeResourcesFit的打分策略支持在KubeSchedulerConfiguration里用pluginConfig覆盖。在自定义resources列表时有个高频坑只写了cpu和memory忘了ephemeral-storage。这样即使Filter阶段依然检查磁盘容量Score阶段磁盘却完全不参与打分节点分布会越来越偏。配置长这样apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler pluginConfig: - name: NodeResourcesFit args: scoringStrategy: type: MostAllocated resources: - name: cpu weight: 1 - name: memory weight: 1 - name: ephemeral-storage weight: 1想用磁盘参与打分必须显式把ephemeral-storage写进resources列表。不同版本的默认值可能不同最稳妥的做法是不要依赖默认直接在配置里写清楚。实测下来这个字段写不写对调度结果影响非常大。MostAllocated策略和LeastAllocated正好相反它会尽量把Pod堆到一台节点上适合追求资源利用率的场景但也容易制造热点。如果选择MostAllocated建议同时盯着节点在磁盘、CPU上的峰值别把单点撑爆。5.3 调度器感知不到磁盘IO性能这是源码层面的边界容量能算性能没法算。NodeResourcesFit只比较容量数值不会关心这块盘是NVMe还是SATA也不管IOPS和吞吐。这是源码层面的边界不是改配置能解决的。如果集群里有不同性能的磁盘常见做法是把磁盘类型做成节点标签再通过nodeAffinity或节点选择器把对应需求的Pod导流过去。想把磁盘性能真正纳入调度打分就得走自定义调度器扩展点自己实现一个读指标信息的Score插件。这条路可行但已经不是改几行in-tree插件代码的事了。6. 从源码到实践排查磁盘调度问题的方法6.1 源码阅读路线与调试建议读kube-scheduler源码建议先锁定一个版本再按“插件注册表 - 插件实现 - NodeInfo数据维护”这条线走。插件注册集中在pkg/scheduler/framework/plugins/registry.go在那里能看到所有in-tree插件和工厂函数顺着工厂函数就能跳到具体实现。单测是理解代码最快的入口。noderesources包里有TestFitvolumebinding包里有TestPreFilter、TestFilterlocalstorage包里有容量隔离相关的测试。本地跑单测时直接在过滤器测试上打断点看它构造的NodeInfo和PodRequest比盯着代码干想快得多。想在真实环境验证调度器判断kube-scheduler日志加上--v5能打出每个节点被哪个插件拒绝的理由。磁盘相关的关键词主要是Insufficient ephemeral-storage、Insufficient memory、volume node affinity conflict。有个小技巧看日志时重点看日志里的调度Pod上下文和后面紧跟的status一次调度周期里每个Filter的返回都会打印。6.2 磁盘调度高频问题速查表现象直接原因排查入口Pod报Insufficient ephemeral-storage节点账本上Requested加新Pod大于Allocatable看Node Allocatable与已请求量检查Pod声明有PVC仍不调度Pod PendingPV节点亲和性不匹配或卷插件不支持节点describe PV检查nodeAffinity与节点标签延迟绑定PVC一直PendingStorageClass allowedTopologies与节点标签不匹配检查StorageClass、节点topology标签节点出现磁盘压力状态kubelet上报DiskPressure污点拦截看node taints、kubelet日志、本地磁盘使用量打分完全不管磁盘scoringStrategy.resources漏配ephemeral-storage检查kube-scheduler配置中的NodeResourcesFit参数所有Pod都没写ephemeral-storage调度器按0计算磁盘资源形同虚设审计工作负载补齐requests和limits6.3 给后来者几条实操建议先说最有影响的一条团队规范里要把ephemeral-storage的requests和limits列为强制字段尤其是要在宿主机上写大量日志、临时文件的Job类Pod。调度器不写就不算很容易导致一个节点被隐式撑爆。第二条关注系统保留资源。节点的Allocatable是已经扣掉系统预留之后的数值不同发行版对预留的处理不同。如果你发现节点明明很大但调度器很快说磁盘不够去看kubelet配置里的system-reserved和evictionHard那里可能已经留走了一截。第三条不要把Insufficient ephemeral-storage简单理解成“磁盘不够”要分清楚“账本不够”和“物理不够”。物理磁盘有剩余账本未必有账本有剩余物理磁盘也未必安全。两个视角要用不同工具确认前者看Node状态和调度日志后者看节点监控。我个人看完这些源码最深的体会是调度器对磁盘的管理有一种“声明式自信”。它宁可相信Pod声明的数字也不相信节点监控里的曲线。这种设计让调度决策可预测、可复现但也意味着所有参与者必须把资源声明填好。如果你想要一个磁盘调度表现稳定的集群第一件事不是去调调度器参数而是回到Pod的requests和limits上把每一份声明都当正经配置来管。
一讲到“磁盘调度”很多刚接触Kubernetes的人第一反应是磁盘不是kubelet管的事吗节点磁盘压力检测、镜像清理、容器日志轮转确实是kubelet的职责。但Pod能不能放到某个节点、该放在哪个节点从Pod提交到API Server的那一刻kube-scheduler就开始做磁盘调度决策了。这篇文章就围绕kube-scheduler的磁盘调度源码分析展开核心会拆掉本地临时存储、PVC持久化存储、节点磁盘压力这三条调度链路。适合正在被Pod反复Pending折磨或者想真正看懂调度器内部逻辑的工程师。先说个容易误解的点调度器并不像监控系统那样看“节点磁盘实时占用率”它用的是另一套账本。这套账本的核心是Pod声明、节点Allocatable、以及调度器自己维护的Requested累计值。想搞清楚磁盘调度就必须先接受这个前提。文章里我会把关键源码做简化展示重点讲清楚每个函数存在的理由以及不同版本里可能出现的差异。1. 调度器眼里的磁盘资源其实有三条业务线1.1 三种磁盘请求是怎么进入调度器的第一条线是ephemeral-storage。它和CPU、内存一样是节点资源的一种出现在Node的Capacity和Allocatable里。Pod里的容器可以通过resources.requests和resources.limits声明自己的临时存储需求。调度器在过滤节点时会把Pod请求的临时存储加到节点已有的请求量上然后和节点的Allocatable做比较不够就直接拒绝。我们平时在事件里看到的Insufficient ephemeral-storage就来自这一步。第二条线是持久化存储体现为PV/PVC。这一层的内容要复杂得多因为它不只比容量还要回答三个问题PVC有没有绑定的PV、PV有没有节点亲和性限制、StorageClass是不是WaitForFirstConsumer延迟绑定模式。这些问题的本质是“存储到底该创建在哪个区域”也就是说调度器要在Pod还没有落节点之前先替存储层做一道拓扑判断题。第三条线是节点自身的运行状态。当节点出现磁盘压力时kubelet会一边驱逐Pod保护文件系统一边把节点的DiskPressure状态上报。调度器这一侧则通过污点和容忍机制间接感知默认不会主动往一个已经磁盘压力的节点上塞新Pod。1.2 这些逻辑挂在调度框架的哪些扩展点kube-scheduler把调度过程切成了调度周期和绑定周期。调度周期里Pod按顺序经过PreFilter、Filter、PostFilter、PreScore、Score、NormalizeScore、PostScore这些扩展点。每个in-tree插件可以选择在某个或某几个扩展点注册自己的逻辑。磁盘相关的插件注册关系大概是下面这张表磁盘相关需求主要插件扩展点ephemeral-storage资源请求NodeResourcesFitFilter、Score本地临时存储隔离LocalStorageCapacityIsolationFilterPVC/PV卷绑定与拓扑VolumeBindingPreFilter、Filter节点卷数量限制NodeVolumeLimitsFilter磁盘压力污点TaintTolerationFilter节点资源账本NodeInfo数据缓存层这张表就是读源码时的地图。大多数磁盘容量判断发生在Filter阶段也就是先保证“这台节点能放得下Pod”而最终选择节点时还要看Score阶段对磁盘余量的偏好。把这两步分开理解后面看代码才不会被绕晕。2. 本地临时存储NodeResourcesFit 的请求计算与过滤实现2.1 computePodResourceRequestPod磁盘请求从哪来NodeResourcesFit插件的主文件在k8s.io/kubernetes/pkg/scheduler/framework/plugins/noderesources/fit.go。名字虽然叫Fit但Filter和Score它都管。它做过滤时不是直接读Pod的YAML而是先把Pod里所有容器的资源声明汇总成一个framework.Resource对象再用这个对象和节点上的可分配资源比较。汇总逻辑主要在computePodResourceRequest函数里这个函数有几个反直觉的地方值得多看两遍。第一普通容器的CPU、内存、ephemeral-storage是累加关系。一个Pod里三个容器各声明100Mi临时存储最终Pod对临时存储的请求就是300Mi。这好理解因为普通容器同时运行资源会同时被占用。第二InitContainer不是累加而是取最大值。源码会遍历所有InitContainer把每个维度上最大的请求单独记下来再和普通容器的合计值逐维度取最大值。原因也很直白InitContainer是串行执行的同一时刻只有一个在跑哪怕它瞬间吃掉很多磁盘也不会和另一个InitContainer叠加。第三如果容器只写了limits没写requestsKubernetes语义下requests默认等于limits。所以computePodResourceRequest在汇总时发现requests字段为零会去limits里取值。比如容器只写了limits.ephemeral-storage: 20Gi调度器就会按20Gi计算它的启动需求。这个细节最容易漏也是很多不合理limit“意外生效”的原因。核心逻辑简化后大概是下面这个样子func computePodResourceRequest(pod *v1.Pod) *framework.Resource { result : framework.Resource{} for _, container : range pod.Spec.Containers { requests : container.Resources.Requests if requests.EphemeralStorage().Value() 0 { result.EphemeralStorage requests.EphemeralStorage().Value() } else if limits : container.Resources.Limits.EphemeralStorage(); limits.Value() 0 { result.EphemeralStorage limits.Value() } // CPU、内存、大页等标量资源也做类似累加 } // 初始化容器逐维度取最大再与result合并 return result }注意这里的EphemeralStorage单位是字节。声明5Gi会被换算成一个很大的整数源码内部统一用字节数和Quantity避免浮点误差。2.2 fitsRequest过滤时到底在比什么节点上能调度多少资源看的不是物理磁盘剩余而是调度器在NodeInfo里维护的一份“账”Allocatable减去Requested。Allocatable来自Node对象的Status.Allocatable是经过系统预留、镜像预留之后真正能分给Pod的部分Requested是节点上所有已调度Pod的请求总和这个值由调度器自己在内存里累加和扣减。fitsRequest就是做这层减法判断的核心函数func fitsRequest(podRequest *framework.Resource, nodeInfo *framework.NodeInfo) bool { allocatable : nodeInfo.Allocatable if allocatable.EphemeralStorage podRequest.EphemeralStorage { return false } if allocatable.MilliCPU podRequest.MilliCPU { return false } if allocatable.Memory podRequest.Memory { return false } // 还要检查大页等标量资源 for rName, rQuant : range podRequest.ScalarResources { if allocatable.ScalarResources[rName] rQuant { return false } } return true }代码很朴素但隐含了一个重要前提调度器只信任Pod声明不关心节点上真实产生了多少日志、多少镜像、多少emptyDir。如果一个节点本地有大量未计入Pod请求的临时文件哪怕物理磁盘快要爆了调度器依然认为这台节点有余量。这也是为什么很多磁盘问题表面看是调度器误判实际上从一开始就没把ephemeral-storage写进资源声明。Filter阶段一旦返回失败常见的kubectl describe pod事件里就会出现Insufficient ephemeral-storage。看到这句话先别急着怀疑调度器先看节点Allocatable和已请求量再核对Pod的requests是否合理。2.3 为什么还要有LocalStorageCapacityIsolation看完NodeResourcesFit可能有人会问既然它已经检查ephemeral-storage为什么调度器里还单独放着一个LocalStorageCapacityIsolation插件这个问题在源码里有明确答案两个插件职责有重叠但策略不一样。NodeResourcesFit按“请求量”做过滤Pod不声明ephemeral-storage请求量就是0等于不设防。LocalStorageCapacityIsolation则是专门为临时存储设计的隔离策略它除了检查requests还会把Pod声明的limits纳入考虑用limits去和节点余量做比较。核心逻辑在pkg/scheduler/framework/plugins/localstorage/capacity_isolation.go这个文件里过滤时大致是这样func (c *localStorage) Filter(...) *framework.Status { allocatable : nodeInfo.Allocatable.EphemeralStorage requested : nodeInfo.Requested.EphemeralStorage podLimit : getPodLocalStorageLimit(pod) if requestedgetPodLocalStorageRequest(pod) allocatable { return framework.NewStatus(...) } if requestedpodLimit allocatable { return framework.NewStatus(...) } return nil }注意它在判断时用的是requested也就是节点上已有Pod的请求总和加上当前Pod的请求或limit。它的本质是防止一个Pod声明了很大的临时存储limit把整个节点的磁盘“画”没了逼着其他Pod无处可放。生产环境里如果遇到“节点明明还有几十GB新Pod却因为ephemeral-storage不调度”多半就是有一个巨大的、或者不合理的limit存在。处理方式不是调大节点Allocatable而是检查Pod的临时存储声明。3. 持久化磁盘VolumeBinding如何决定Pod能落在哪个节点3.1 PreFilter先把PVC和PV的绑定关系摊开持久化存储的调度不能只靠容量加减因为大多数用户的卷不是提前切好的裸盘而是通过PVC动态申请出来的。调度器如果只看节点本地磁盘完全不知道PVC背后要创建多大的PV、这块PV能不能挂到目标节点。所以VolumeBinding插件的PreFilter阶段有一个关键动作把Pod相关的所有PVC和PV关系先拉一遍。入口在pkg/scheduler/framework/plugins/volumebinding/volume_binding.go。PreFilter从Pod的spec里解析出所有PVC再通过informer cache分别查出这些PVC的当前状态。已经绑定PV的归到boundPVs还没绑定PV的归到unboundPVCs。这两类在后续Filter里走的是完全不同的检查路线。如果Pod里有PVC但PVC还处于Pending状态PreFilter阶段就会直接报错。这个逻辑很严格调度器不会把一个连卷都还没有的Pod放到某台节点上因为“放到哪台节点”这个决定会直接影响后续PV创建在哪个区域。PreFilter处理完的数据会写进一个CycleState相当于调度周期内的临时上下文。后续的Filter、Score直接从上下文拿数据不用反复查API Server也保证了同一个Pod在多个扩展点看到的卷状态完全一致。3.2 FilterPV节点亲和性、存储类拓扑与挂载能力Filter阶段才是真正回答“这台节点能不能满足该Pod的持久化存储需求”的地方。对已经绑定的PV主要检查三件事。第一PV的nodeAffinity是不是限定了一组节点。比如PV通过kubernetes.io/hostname固定到某台机器那只有这台机器能挂它。第二PV对应的存储插件在节点上是否具备挂载能力比如某些CSI驱动需要在节点上安装对应组件节点没有就是挂不上。第三如果PVC申请的size超过PV提供的容量也无法匹配。这些检查在内部约等于canSatisfyPV这个函数的职责。对还没绑定的PVCVolumeBinding要看StorageClass的volumeBindingMode。最常见也最坑的是WaitForFirstConsumer这个模式的意思是卷要等第一个Pod出现才知道该创建在哪个区域。假如StorageClass配置了allowedTopologies限定只能创建在某个zone那Pod所在节点必须带这个zone标签否则即使物理上任何地方都能挂卷调度器也会把Pod刷掉。Filter里对应的逻辑可以概化成两个函数func canSatisfyPV(pv *v1.PersistentVolume, node *v1.Node) bool { // 1. PV的节点亲和性是否匹配 // 2. 卷插件是否支持在node上挂载 // 3. PV容量是否满足PVC请求 } func canSatisfyPVC(pvc *v1.PersistentVolumeClaim, node *v1.Node) bool { class : getStorageClass(pvc) if class nil { return false } if class.VolumeBindingMode ! WaitForFirstConsumer { return false } // 检查allowedTopologies与节点标签是否匹配 return nodeMatchesTopology(class.AllowedTopologies, node) }Filter失败时调度器不会轻易重试。像unboundPVCs这种问题即使等一会儿卷创建成功了Pod也需要重新进队列触发一次完整调度。理解这个行为对排障很重要有些时候改完PVC发现Pod还是Pending就是因为调度器还没被新事件唤醒需要检查事件驱动是否生效。3.3 卷数量和卷亲和性的邻居们持久化磁盘调度里还有两个“邻居”一个是NodeVolumeLimits一个是VolumeBinding里可能出现的Score实现。NodeVolumeLimits检查的是“节点上最多能挂多少块卷”而不是容量。云环境里很常见的是单节点云盘数量限制比如某个环境限制了单个节点最多挂几十块云盘。Pod数量上去了卷数也跟着上去了没有这个检查调度器会把节点塞爆。它通过CSINode或插件配置拿到上限然后在Filter阶段数一下节点上已经挂载的卷数量。VolumeBinding本身在某些版本里还实现了Score扩展点。思路很简单节点上如果已经挂了Pod所需的某些PV就给这个节点加分。原因是同一个Pod的多个卷如果落在已经attach过的节点上可以减少后续挂载和跨节点attach的开销。源码里往scorePodOnNode这个方向找就行不过不同版本对这个能力支持程度不一样自己翻源码时留意一下就好。4. NodeInfo调度器内存里的磁盘资源视图4.1 Requested、Allocatable、NonZeroRequested分别是什么NodeInfo不是API层的对象它是调度器在内存里维护的节点账本。所有插件在Filter和Score阶段读到的资源数据基本都来自这个对象。它的定义里一般能看到四个核心字段Requested、NonZeroRequested、Allocatable、Capacity。Allocatable直接拷贝自Node对象的Status.Allocatable。Capacity是节点物理容量但调度器真正用来做容量判断的是Allocatable因为系统组件、镜像、kubelet本身都要占资源。Requested是调度器自己维护的累计值每当一个Pod被调度到节点上调度器就调用AddPod把Pod的请求加进去Pod从节点移除调用RemovePod减掉。NonZeroRequested是一个很有意思的设计。对CPU和内存如果Pod没有声明requests调度器会默认按100m CPU和200Mi内存来算这是DefaultMilliCPURequest和DefaultMemoryRequest两个常量。这个值的用途是防止完全没写资源的Pod被调度器当成“零负载”把节点资源全部占走。但注意ephemeral-storage没有类似的默认值Pod不写调度器就按0处理。所以全用NodeInfo里的磁盘数据做容量规划时必须清楚Requested.EphemeralStorage只反映所有Pod声明过的临时存储总和没声明的一律是0。这直接解答了一个高频疑问“节点Allocatable明明有100Gi为什么调度器说Insufficient ephemeral-storage”因为账本上的请求量已经超过Allocatable跟物理剩余多少没有一一对应关系。func (n *NodeInfo) AddPod(pod *v1.Pod) error { res : computePodResourceRequest(pod) n.Requested n.Requested.Add(res) n.NonZeroRequested n.NonZeroRequested.Add(res) // 还会更新端口、卷、镜像状态等字段 }上面是简化后的AddPod思路。真实代码里还要更新其他字段但磁盘部分的核心就是这行资源加法。4.2 磁盘压力状态如何参与调度磁盘压力DiskPressure是节点级别的Condition由kubelet检测并上报到Node Status。调度器这边会通过NodeInfo缓存节点的Conditions但默认情况下真正因为磁盘压力把节点拦住的是污点与容忍机制而不是某个插件在Filter里主动判断Condition。链路大概是这样的kubelet发现节点磁盘使用率超过阈值会标记节点的DiskPressure condition控制面侧的节点生命周期管理逻辑会据此给节点打上node.kubernetes.io/disk-pressure之类的污点调度器的TaintToleration插件在Filter阶段遇到这个污点如果Pod没有对应容忍就直接把节点排除。这个设计把“检测磁盘压力”和“是否允许调度”解耦了kubelet只管反映事实调度器只凭污点做准入。以后排查磁盘压力导致的不调度重点应该看节点污点而不是去调度器日志里找condition判断。5. 打分阶段磁盘碎片化与节点均衡5.1 LeastAllocated怎么给磁盘打分Filter决定“能不能放”Score决定“放到哪”。NodeResourcesFit的Score扩展点默认使用LeastAllocated策略意思是“往资源剩余最多的节点上放”。每种可打分的资源都会单独算出一个0到100的分数再按权重平均。磁盘的核心公式很简单func leastAllocatedScore(requested, capacity int64) int64 { if capacity 0 { return 0 } return ((capacity - requested) * 100) / capacity }分母是capacity分子是剩余量剩余比例越高得分越高。举个具体例子节点A的CPU是2000m里请求1000m、内存2Gi里请求1Gi、磁盘50Gi里请求10Gi节点B的CPU请求500m、内存请求0.5Gi、磁盘请求5Gi。两者磁盘得分分别是(50-10)/5010080和(50-5)/5010090再和其他资源的分数取平均节点B总分更高调度器会倾向选B。这种策略天然能缓解磁盘碎片化同一块磁盘上的Pod越少越容易拿到高分。5.2 一个容易踩的配置坑打分时会漏掉磁盘NodeResourcesFit的打分策略支持在KubeSchedulerConfiguration里用pluginConfig覆盖。在自定义resources列表时有个高频坑只写了cpu和memory忘了ephemeral-storage。这样即使Filter阶段依然检查磁盘容量Score阶段磁盘却完全不参与打分节点分布会越来越偏。配置长这样apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler pluginConfig: - name: NodeResourcesFit args: scoringStrategy: type: MostAllocated resources: - name: cpu weight: 1 - name: memory weight: 1 - name: ephemeral-storage weight: 1想用磁盘参与打分必须显式把ephemeral-storage写进resources列表。不同版本的默认值可能不同最稳妥的做法是不要依赖默认直接在配置里写清楚。实测下来这个字段写不写对调度结果影响非常大。MostAllocated策略和LeastAllocated正好相反它会尽量把Pod堆到一台节点上适合追求资源利用率的场景但也容易制造热点。如果选择MostAllocated建议同时盯着节点在磁盘、CPU上的峰值别把单点撑爆。5.3 调度器感知不到磁盘IO性能这是源码层面的边界容量能算性能没法算。NodeResourcesFit只比较容量数值不会关心这块盘是NVMe还是SATA也不管IOPS和吞吐。这是源码层面的边界不是改配置能解决的。如果集群里有不同性能的磁盘常见做法是把磁盘类型做成节点标签再通过nodeAffinity或节点选择器把对应需求的Pod导流过去。想把磁盘性能真正纳入调度打分就得走自定义调度器扩展点自己实现一个读指标信息的Score插件。这条路可行但已经不是改几行in-tree插件代码的事了。6. 从源码到实践排查磁盘调度问题的方法6.1 源码阅读路线与调试建议读kube-scheduler源码建议先锁定一个版本再按“插件注册表 - 插件实现 - NodeInfo数据维护”这条线走。插件注册集中在pkg/scheduler/framework/plugins/registry.go在那里能看到所有in-tree插件和工厂函数顺着工厂函数就能跳到具体实现。单测是理解代码最快的入口。noderesources包里有TestFitvolumebinding包里有TestPreFilter、TestFilterlocalstorage包里有容量隔离相关的测试。本地跑单测时直接在过滤器测试上打断点看它构造的NodeInfo和PodRequest比盯着代码干想快得多。想在真实环境验证调度器判断kube-scheduler日志加上--v5能打出每个节点被哪个插件拒绝的理由。磁盘相关的关键词主要是Insufficient ephemeral-storage、Insufficient memory、volume node affinity conflict。有个小技巧看日志时重点看日志里的调度Pod上下文和后面紧跟的status一次调度周期里每个Filter的返回都会打印。6.2 磁盘调度高频问题速查表现象直接原因排查入口Pod报Insufficient ephemeral-storage节点账本上Requested加新Pod大于Allocatable看Node Allocatable与已请求量检查Pod声明有PVC仍不调度Pod PendingPV节点亲和性不匹配或卷插件不支持节点describe PV检查nodeAffinity与节点标签延迟绑定PVC一直PendingStorageClass allowedTopologies与节点标签不匹配检查StorageClass、节点topology标签节点出现磁盘压力状态kubelet上报DiskPressure污点拦截看node taints、kubelet日志、本地磁盘使用量打分完全不管磁盘scoringStrategy.resources漏配ephemeral-storage检查kube-scheduler配置中的NodeResourcesFit参数所有Pod都没写ephemeral-storage调度器按0计算磁盘资源形同虚设审计工作负载补齐requests和limits6.3 给后来者几条实操建议先说最有影响的一条团队规范里要把ephemeral-storage的requests和limits列为强制字段尤其是要在宿主机上写大量日志、临时文件的Job类Pod。调度器不写就不算很容易导致一个节点被隐式撑爆。第二条关注系统保留资源。节点的Allocatable是已经扣掉系统预留之后的数值不同发行版对预留的处理不同。如果你发现节点明明很大但调度器很快说磁盘不够去看kubelet配置里的system-reserved和evictionHard那里可能已经留走了一截。第三条不要把Insufficient ephemeral-storage简单理解成“磁盘不够”要分清楚“账本不够”和“物理不够”。物理磁盘有剩余账本未必有账本有剩余物理磁盘也未必安全。两个视角要用不同工具确认前者看Node状态和调度日志后者看节点监控。我个人看完这些源码最深的体会是调度器对磁盘的管理有一种“声明式自信”。它宁可相信Pod声明的数字也不相信节点监控里的曲线。这种设计让调度决策可预测、可复现但也意味着所有参与者必须把资源声明填好。如果你想要一个磁盘调度表现稳定的集群第一件事不是去调调度器参数而是回到Pod的requests和limits上把每一份声明都当正经配置来管。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
