Kubernetes Pod卡在Pending状态的排查与优化

1. 理解Pod卡在Pending状态的核心问题

在Kubernetes集群运维过程中，Pod卡在Pending状态是最常见也最容易被忽视的问题之一。很多初级运维人员看到Pod没有直接失败就放松警惕，实际上Pending状态往往是集群深层问题的早期预警信号。

1.1 Pending状态的真实含义

Pending状态表明Pod已经被API Server接收，但尚未被调度到合适的节点运行。具体可能卡在两个阶段：

1. 调度前阶段：Scheduler尚未将Pod分配到任何Node
2. 调度后阶段：Pod已分配到Node，但运行前置条件未满足（如镜像拉取、资源准备等）

关键诊断点：通过kubectl describe pod查看Node字段

• 如果Node字段为<none>：说明尚未完成调度
• 如果Node字段有值但仍Pending：问题出在节点执行环节

1.2 为什么Pending状态不容忽视

在生产环境中，我们发现Pending状态往往预示着：

• 资源配额设置不合理（特别是requests配置）
• 节点标签(Label)或污点(Taint)配置错误
• 存储系统(PVC/PV)出现问题
• 集群组件（如CNI、kubelet）异常

这些问题如果不及时处理，随着业务负载增加，最终会导致服务不可用。

2. 系统化排查流程与方法论

2.1 第一步：获取Pod详细信息

所有排查都从这条命令开始：

bash复制kubectl describe pod <pod-name> -n <namespace>

重点关注两个部分：

1. Events部分：90%的问题线索都在这里
2. Node字段：判断问题发生的阶段

2.1.1 Events中的关键信息

典型的调度失败信息示例：

code复制Warning  FailedScheduling  default-scheduler  0/5 nodes are available: 
3 Insufficient cpu, 2 node(s) didn't match Pod affinity rules.

这种明确的信息可以直接指向问题根源。

2.2 调度失败(FailedScheduling)的六大常见原因

2.2.1 节点资源不足（最高频问题）

典型表现：

• Events中出现"Insufficient cpu/memory/ephemeral-storage"
• 节点已无足够可分配资源

诊断命令：

bash复制kubectl describe node <node-name>
kubectl top node

关键检查点：

• Allocatable资源量
• 现有Pod的requests总和
• 新Pod的requests配置

重要原则：调度器(Scheduler)只认requests不认limits。requests配置过高会导致Pod永远无法调度。

2.2.2 NodeSelector/NodeAffinity不匹配

典型报错：

code复制node(s) didn't match node selector

排查步骤：

1. 查看Pod的节点选择规则：

bash复制kubectl get pod <pod-name> -o yaml | grep nodeSelector -A5

2. 检查节点标签：

bash复制kubectl get nodes --show-labels

常见错误：

• Pod指定了disktype: ssd标签，但集群中没有节点有此标签
• 标签拼写错误（如ssd vs SSD）

2.2.3 Taints污点导致调度失败

典型表现：

code复制node(s) had taint {node-role.kubernetes.io/control-plane: NoSchedule}

诊断方法：

bash复制kubectl describe node <node-name> | grep Taints

解决方案：

1. 为Pod添加对应的toleration
2. 或者移除节点的污点（生产环境不推荐）

2.2.4 PodAffinity/AntiAffinity规则过严

典型问题：

• 使用requiredDuringScheduling硬性约束
• 集群规模小无法满足分布要求

建议：

• 优先使用preferredDuringScheduling
• 确保约束规则符合实际集群规模

2.2.5 PVC未绑定（生产环境重灾区）

典型现象：

• Pod和PVC都处于Pending状态
• Events中出现"Pod has unbound immediate PersistentVolumeClaims"

排查步骤：

bash复制kubectl get pvc
kubectl describe pvc <pvc-name>

常见问题：

• StorageClass配置错误
• 动态存储插件异常
• 物理存储资源不足

2.2.6 资源碎片化问题

在大规模集群中，可能出现：

• 单节点资源不足
• 但多个节点剩余资源总和足够

解决方案：

• 调整Pod的requests配置
• 使用descheduler进行碎片整理

2.3 已调度但卡在Pending的问题排查

如果Pod已分配Node但仍Pending，问题通常出在节点执行环节。

2.3.1 CNI网络插件异常

典型表现：

code复制Failed to create Pod sandbox

排查方法：

bash复制kubectl get pods -n kube-system | grep cni
journalctl -u kubelet | grep -i cni

常见问题：

• CNI插件CrashLoopBackOff
• 网络策略冲突
• IP地址耗尽

2.3.2 节点NotReady状态

检查命令：

bash复制kubectl get nodes

处理流程：

1. 检查kubelet状态：systemctl status kubelet
2. 查看节点资源：是否内存/磁盘耗尽
3. 检查网络连接：节点与API Server通信是否正常

2.3.3 镜像拉取失败

诊断方法：

bash复制kubectl describe pod <pod-name> | grep -i image
docker pull <image-name> # 在节点上手动测试

常见问题：

• 镜像仓库认证失败
• 镜像tag不存在
• 私有仓库网络不通

3. 生产环境最佳实践与经验总结

3.1 资源配置黄金法则

1. Requests设置原则：

   • CPU：按实际需求的70-80%设置
   • 内存：按实际需求+30%缓冲设置
   • 避免requests=limits的"静态分配"

2. 重要Pod保障方案：

yaml复制priorityClassName: system-cluster-critical
resources:
  requests:
    cpu: "500m"
    memory: "1Gi"

3.2 调度策略优化建议

1. 节点标记规范：

bash复制kubectl label nodes <node-name> disktype=ssd accelerator=gpu

2. 污点管理策略：

• 专用节点：dedicated=special:NoSchedule
• 维护模式：maintenance=true:NoExecute

3. 亲和性规则示例：

yaml复制affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      preference:
        matchExpressions:
        - key: disktype
          operator: In
          values: [ssd]

3.3 标准化排查流程图

建议团队将以下流程制作成应急手册：

code复制Pod Pending
   │
   ├─ kubectl describe pod <pod>
   │   ├─ Events中有FailedScheduling? → 检查资源/标签/污点/PVC
   │   └─ 已分配Node? → 检查kubelet/CNI/镜像
   │
   ├─ kubectl get nodes → 检查节点状态
   ├─ kubectl get pods -n kube-system → 检查系统组件
   └─ kubectl logs <scheduler-pod> -n kube-system → 调度器日志

3.4 常见误区和避坑指南

1. 资源限制误区：

   • 错误：只设limits不设requests → 导致requests=limits
   • 正确：始终明确设置requests

2. 标签管理陷阱：

   • 混用大小写标签（SSD vs ssd）
   • 标签值包含特殊字符

3. 存储配置坑点：

   • PVC的storageClassName设为""会禁用动态供应
   • 不同StorageClass的volumeBindingMode差异

4. 调度性能优化：

   • 大规模集群启用Scheduler的--parallelism参数
   • 使用PodTopologySpread替代PodAntiAffinity

4. 高级诊断技巧与工具链

4.1 调度器调试技巧

查看调度决策详情：

bash复制kubectl get events --field-selector involvedObject.kind=Pod,reason=FailedScheduling

启用调度器详细日志：

bash复制kubectl edit deploy kube-scheduler -n kube-system
# 在args中添加 --v=4

4.2 自定义调度器配置

示例：配置多调度器

yaml复制apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  schedulerName: my-custom-scheduler
  containers:
  - name: nginx
    image: nginx

4.3 关键监控指标

1. 调度延迟：

   • scheduler_pending_pods
   • scheduler_scheduling_attempt_duration_seconds

2. 资源利用率：

   • kube_pod_container_resource_requests
   • kube_node_status_allocatable

3. 存储状态：

   • kube_persistentvolumeclaim_status_phase
   • storage_operation_duration_seconds

4.4 自动化处理方案

1. 使用Descheduler重平衡：

bash复制kubectl create -f https://github.com/kubernetes-sigs/descheduler/raw/master/kubernetes/base/rbac.yaml

2. 配置Pod中断预算(PDB)：

yaml复制apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

在长期运维实践中，我们总结出一个核心认知：Pending状态不是"没问题"，而是"问题还没爆发"。成熟的Kubernetes运维团队应该建立Pending Pod的监控告警机制，在问题影响业务前就主动发现并解决。