k8s统计某个节点(剩余)资源是否满足pod调度
一个设置了资源限制的pod能否成功调度到某个节点上,取决于Allocatable与Allocated resources 中Request值的差,yaml中对应资源request值的设置必须要小于或等于其,否则pod将处于pending状态。答:这是由于pod的yaml中定义的limit字段所决定的,k8s会将所有定义了limit字段pod的数值进行累加统计,所以会出现超过100%的情况。有个这个
在日常中,经常会遇到pod由于CPU、内存、临时存储不足处于Pending状态或需要统计底座机器的可用资源等问题,这种问题可以通过下面的方法解决:
环境背景描述:
节点虚拟机规格:2核,3G
kubectl describe node {nodename} | grep -A6 Capacity
试验步骤:
①首先查看该节点申请(可用)的资源总和:
kubectl describe node {nodename} | grep -A5 Allocatable
②查看该节点已分配的资源情况:(无任何业务pod负载,仅存在提供k8s服务的基础pod)
kubectl describe node {nodename} | grep -A5 'Allocated resources'
③创建测试yaml文件,test-nginx-deployment.yaml,并设置resources相关字段
(1)测试内存
该节点剩余可用内存计算方法:总量-request总和=(2793044Ki÷1024)-70Mi=2657.58Mi
有个这个值,我们将yaml的request字段设置为临界值2757Mi,看pod能否调度
[注意]:scheduler能否调度该pod取决于该节点剩余资源能否满足pod yaml中定义的request字段要求,如果不满足pod将会一直处于pending状态
执行 kubectl get pod -o wide 可以看到pod已经调度到mater节点上了
再查看节点资源使用情况:(内存使用率已经到达99%了)
从上面的测试可以看出架构Request设置为2757Mi是可以被调度的,那我们现在+1Mi进行测试,将Request调整为2758Mi
可以发现pod全部pedning了(因为2658Mi已经超出节点剩余最大内存资源使用量限制)
测试符合预期!
(2)测试CPU
该节点剩余可用内存计算方法:总量-request总和=(2c×1000)-900m=1100m
有个这个值,我们将yaml的request字段设置为临界值1100m,看pod能否调度
master节点上的pod调度正常
查看节点cpu资源使用率,可以发现资源使用率已经100%了,符合预期
那我们再将request +1m变为1101m看pod是否会pending
从上图可以看到原本应该调度到master节点的pod因为request资源超过节点的剩余可用资源而处于pending状态了
测试符合预期!
结论:
一个设置了资源限制的pod能否成功调度到某个节点上,取决于Allocatable与Allocated resources 中Request值的差,yaml中对应资源request值的设置必须要小于或等于其,否则pod将处于pending状态
举一反三:
问:在某些环境中为什么资源会出现limit超过100%的情况呢?例如:
答:这是由于pod的yaml中定义的limit字段所决定的,k8s会将所有定义了limit字段pod的数值进行累加统计,所以会出现超过100%的情况。
测试:
①查看节点资源使用情况,注意内存的limit字段
②将yaml中的内存limit字段调大
③可以看到limit的值明显已经超过100%了
测试符合预期!
更多推荐
所有评论(0)