Kubernetes Pod Pending — 调度失败与 PVC 未绑定

读取调度器事件、节点可分配资源、污点与亲和性规则以及 PVC 状态，定位 Kubernetes Pod 长期 Pending 的原因并修正清单。

现象

Pod 长时间处于 Pending，容器从未启动；事件显示 0/3 nodes are available: 3 Insufficient cpu；提示 node(s) had untolerated taint 或节点亲和性不匹配；或出现 pod has unbound immediate PersistentVolumeClaims。

诊断

Pending 阶段没有容器日志，唯一有效证据是调度事件：

kubectl describe pod -n app api-7d9c8f6b5-4xl2q | sed -n '/Events:/,$p'
kubectl get events -n app --sort-by=.lastTimestamp | tail -30

FailedScheduling 后面的每个分句都是一种阻塞原因，需要全部读完。再对比节点可分配量与已分配 request：

kubectl describe node ip-10-0-3-17 | grep -A12 -E 'Allocatable:|Allocated resources:'
kubectl get pvc -n app
kubectl get resourcequota -n app -o describe

调度依据是 request 而不是实际使用量；16 GiB 内存的节点若已被 request 占满，就无法再放下新 Pod。PVC 处于 Pending 时，使用 Immediate 绑定的 Pod 也无法调度。

修复

把 CPU/内存 request 调整为实测值，扩容节点或启用自动伸缩；让 nodeSelector 与亲和性匹配节点上真实存在的标签；只为自己管理的污点添加 toleration。存储侧安装 provisioner，或改用 WaitForFirstConsumer 的 StorageClass，使卷在正确可用区创建：

resources:
  requests:
    cpu: 100m
    memory: 128Mi
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: api

验证

重新应用清单后观察 Pod 进入 Running，事件中出现 Scheduled，kubectl get pod -o wide 能显示节点与 Pod IP，PVC 状态为 Bound。如果 Pod 已调度却反复重启，那属于容器或探针问题，应转向日志继续排查。