k8s统计某个节点（剩余）资源是否满足pod调度

在日常中，经常会遇到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%了

测试符合预期！