Kubernetes 里 Pod 一直 Pending？先看这 5 个常见原因

部署新服务后，kubectl get pods 发现 Pod 一直停在 Pending，是集群运维里最常见的卡点之一。Pending 表示调度器还没把它放到某个节点上。下面按排查顺序整理 5 个高频原因和对应命令。

1. 资源不够：CPU / 内存请求过大

kubectl describe pod <pod-name>

Events 里若出现 Insufficient cpu 或 Insufficient memory，说明当前节点满足不了该 Pod 的 requests。可以：

• 临时调小 resources.requests（不要只改 limits）；
• 扩容节点或把工作负载迁到资源更空闲的节点池；
• 用 kubectl top nodes 看各节点实际占用。

2. 节点选择器 / 亲和性配错

kubectl get nodes --show-labels
kubectl describe pod <pod-name> | grep -A20 Events

nodeSelector、nodeAffinity、tolerations 写错时，调度器找不到匹配节点，Events 常提示 didn't match node selector 或 had untolerated taint。对照节点 label 和污点改配置，或给目标节点补上对应 label / taint 容忍。

3. PVC 未绑定成功

依赖持久卷的 Pod 会等 PVC 变成 Bound。检查：

kubectl get pvc
kubectl describe pvc <pvc-name>

常见问题：StorageClass 不存在、可用区与节点不一致、云盘配额用尽。先把 PVC 调到 Bound，Pod 才会继续调度。

4. 镜像拉取策略或密钥问题（有时表现为 ContainerCreating）

严格说镜像问题多在 ContainerCreating / ErrImagePull，但排查 Pending 时一并看一眼：

kubectl describe pod <pod-name>
kubectl get events --field-selector involvedObject.name=<pod-name>

私有仓库需要正确的 imagePullSecrets；公共镜像偶发网络超时可重试或换加速源。

5. 调度器本身或集群异常

少数情况下是控制面问题：

kubectl get cs
kubectl -n kube-system get pods | grep scheduler
kubectl logs -n kube-system deploy/kube-scheduler --tail=100

确认 scheduler 健康、API Server 可访问后，再回头看业务 YAML。

排查顺序建议

describe pod 看 Events → 核对 requests / 亲和性 / 污点 → 检查 PVC → 再看镜像与控制面。大多数 Pending 都能在前三步定位。改完配置后用 kubectl apply 更新，或删除 Pod 让控制器重建，观察是否进入 Running。