K8s中Pod处于Pending状态的八种原因分析

在生产环境中遇到Pod卡在Pending状态，就像外卖小哥找不到配送地址一样让人焦虑。作为踩坑无数的老司机，今天带大家拆解这个经典问题的排查思路，附赠真实战场经验。（配图：一个卡在加载状态的Pod图标）

一、资源不足：最经典的"堵车"场景

典型症状：kubectl describe显示"0/3 nodes are available: 3 Insufficient cpu, 2 Insufficient memory"

深层原因：

• 节点资源耗尽（真实案例：某次促销活动忘记扩容，节点CPU利用率达98%）
• Pod资源请求过高（常见于新人配置requests=limits）

排查武器库：

kubectl top nodes  # 查看节点资源水位
kubectl describe node <节点名> | grep -A 10 Allocated  # 查看具体分配情况

生存指南：

• 紧急扩容：kubectl scale deploy/<名称> --replicas=0先止血
• 合理配置：遵循黄金法则 - requests=limits的80%
• 自动扩缩容：安装cluster-autoscaler实现节点自动伸缩

二、调度约束：K8S版的"落花有意流水无情"

高阶踩坑现场：

• nodeSelector选了不存在的标签
• 亲和性设置过于严格（反例：必须调度到SSD+GPU节点）
• 节点污点未配置容忍（生产环境常见：专用GPU节点）

诊断秘籍：

kubectl get nodes --show-labels | grep <关键标签>
kubectl describe pod | grep -i 'affinity'  # 查看亲和性配置

避坑姿势：

tolerations:  # 污点容忍配置示例
- key: "gpu"
  operator: "Exists"
  effect: "NoSchedule"

三、存储依赖：等待永久的约会

经典连环坑：

• PVC找不到匹配的PV（尤其StatefulSet场景）
• StorageClass配置错误（测试环境用local-path，生产用ceph）
• 云盘配额不足（AWS EBS类型选错）

排查三连击：

kubectl get pvc
kubectl describe storageclass
aws ec2 describe-volumes --region <区域>  # 云平台检查

实战技巧：

• 预创建PV池应对突发流量
• 使用动态供应StorageClass
• 监控云平台配额：aws service-quotas get-service-quota --service-code ec2 --quota-code L-XXXX

四、镜像问题：你以为的下载不是下载

隐蔽陷阱：

• 私有仓库认证失败（kubelet报x509证书错误）
• 镜像tag不存在（latest标签被覆盖）
• 国内拉取gcr.io镜像超时

诊断组合拳：

kubectl describe pod | grep -i 'image'
docker pull <镜像地址>  # 在节点上手动测试
journalctl -u kubelet | grep -i 'image'  # 查看kubelet日志

救命方案：

imagePullSecrets:  # 私有仓库认证配置
- name: regcred

五、配额限制：看不见的天花板

多维限制矩阵：

• Namespace资源配额（ResourceQuota）
• Service配额（AWS的NLB数量限制）
• RBAC权限不足（ServiceAccount无create权限）

排查工具箱：

kubectl describe quota -n <命名空间>
aws service-quotas list-service-quotas --service-code ec2  # 检查云配额

破局之道：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 100Gi

六、网络暗礁：沉默的杀手

高危场景：

• 网络插件异常（Calico的IP池耗尽）
• 安全组配置错误（AWS节点间端口未开放）
• CNI配置冲突（多网络插件混用）

诊断七伤拳：

kubectl get pods -n kube-system  # 检查网络组件状态
calicoctl ipam show --show-blocks  # Calico IP地址检查
telnet <节点IP> 10250  # 检查节点间通信

终极防御：

• 定期清理IP池：calicoctl ipam release --ip=<废弃IP>
• 使用网络策略白名单
• 启用NetworkPolicy审计

七、系统级异常：底层的暴击

魔鬼藏在细节里：

• kube-scheduler进程崩溃
• 节点磁盘inode耗尽
• 内核版本不兼容（尤其使用ebpf网络插件时）

深度检测：

systemctl status kube-scheduler  # 调度器状态
df -i  # 检查inode使用
uname -r  # 核对内核版本

生存法则：

• 部署kube-scheduler的多实例
• 启用节点自动修复功能
• 定期内核漏洞扫描

八、冷门陷阱：那些年我们踩过的神坑

奇葩问题集锦：

• 时区设置导致cronjob异常
• 节点时间不同步引发证书验证失败
• kube-proxy的conntrack表溢出

诊断冷兵器：

chronyc tracking  # 检查时间同步
cat /proc/sys/net/netfilter/nf_conntrack_max  # 连接追踪表大小

防御矩阵：

• 全集群NTP时间同步
• 调整conntrack参数：

sysctl -w net.netfilter.nf_conntrack_max=1048576

终极排查路线图（思维导图见文末）

• 看事件：kubectl describe pod <名称>
• 查调度：kubectl get events --field-selector involvedObject.kind=Pod
• 核配置：kubectl get pod <名称> -o yaml
• 检资源：kubectl top系列命令
• 追日志：kubelet和容器运行时日志
• 测网络：节点间通信测试
• 审配额：云平台和K8S双重检查

武器库升级：

• 可视化工具：Lens、K9s
• 日志系统：ELK+Filebeat
• 监控体系：Prometheus+Alertmanager+Grafana黄金组合

写给开发者的生存建议：

• 给每个Pod配置合理的requests/limits
• 重要服务添加PreStopHook实现优雅终止
• 生产环境Always指定镜像tag
• 使用PDB（PodDisruptionBudget）防止意外驱逐
• 定期进行混沌工程演练

记住：Pending不是错误，而是K8S在说"我尽力了，但..."。掌握这套排查心法，下次遇到问题时你就能淡定地说："让子弹飞一会儿，我先看看调度日志。"

到此这篇关于K8s中Pod处于Pending状态的八种原因的文章就介绍到这了,更多相关K8s中Pod处于Pending状态的八种原因内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论