哈哈，又碰到K8s里Zui让人抓狂的事情之一——Pod老是Pending！这个问题就像老家隔壁那位总说"明天来借点钱"的亲戚，永远让你等待却不出现。今天咱就说说这事儿，从头到尾啰嗦一遍，包你下次遇到就Neng笑眯眯地处理掉。

Zui近有个朋友跑来说：

kubectl get pods -n xxx
NAME READY STATUS RESTARTS AGE
pod-abc-xxx 0/1 Pending 0 30m

kan起来hen正常的输出吧？但你要是去查describe，就会发现一个可怕的错误：Insufficient cloud.example.com/pod-ip。这什么鬼？IP不够？那为什么其他PodNeng正常运行呢？

真实情况往往比我们想象复杂得多。我曾经kan到过这样一个场景：某个节点上有一堆Poddou卡在ContainerCreating状态好几小时了！但是当你用kubectl describe pod查kan时发现调度器Yi经把这些Pod的IP资源request计入了节点账本。

"等等！"你可Neng会说："那不是正常吗？"不对不对不对！应该是这样：Pod被调度到节点后调度器记账——kubelet开始创建——CNI分配真实IP——网络就绪。但现实是：Pod卡在ContainerCreating阶段时虽然调度器Yi经记账了IP资源，但CNI还没真正分配出实际可用的IP地址。

Resource Requests Limits
cloud.example.com/pod-ip 1 
cloud.example.com/pod-ip 2 

"你kan这个！"朋友指着上面的输出说："显示Request=Allocatable啊！"确实如此啊...但是仔细观察后发现那个所谓的Request只是调度器的一厢情愿罢了——真实可用IP早就被其他长期卡住创建过程中的Pod占满了。

因为Kubernetes内部存在时间差!

第一步: Pod被调度到节点时,scheduler将该pod对应request.cloud.example.

第二步:

根本原因分析

需要确认业务podNeng否落地在正确候选集合上;

检查节点标签是否匹配业务需求;

观察容器创建失败日志;

具体操作步骤

kubectl get pods --all-namespaces -o wide | grep -i "pending\|containercreating"
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE
default pod-xxx / ContainerCreating / / node-xxx
default pod-yyy / Pending / / node-yyy
...

kubectl describe pod  -n 
Events:
Type Reason Age From Message
---- ------- ---- ---- -------
Warning FailedScheduling 5m default-scheduler No nodes available to schedule pods.

kubectl describe node 
Allocated resources:
Resource Requests Limits
cpu /
memory /
ephemeral-storage /
hugepages-1Gi /
hugepages-2Mi /
cloud.example.com/gpu /
cloud.example.com/pod-ip *
...
注意这里Ru果Requests接近Allocatable值表示可Neng达到限制阈值.
...

kubectl delete pod  -n