K18NV部署时Pod始终处于Pending状态，常见原因有哪些？

Question

K18NV（应为 Kubernetes，疑似笔误）部署时 Pod 长期处于 Pending 状态，常见原因包括：① 节点资源不足（CPU/内存配额耗尽或未满足 requests）；② 节点污点（Taint）与 Pod 容忍度（Toleration）不匹配；③ 无可用节点满足亲和性（Affinity）、反亲和性或节点选择器（nodeSelector）约束；④ 所需 PV 未就绪或 PVC 处于 Pending（如 StorageClass 不存在、动态供给失败、权限不足）；⑤ 镜像拉取失败（私有仓库凭证缺失、镜像名错误、网络策略拦截）；⑥ 调度器异常或被替换（如自定义调度器未启用）；⑦ 命名空间资源配额（ResourceQuota）或 LimitRange 限制触发。排查建议：`kubectl describe pod ` 查看 Events 字段，结合 `kubectl get nodes -o wide`、`kubectl get pvc/pv` 和 `kubectl get events --sort-by=.lastTimestamp` 综合诊断。

Answer 1

```html

一、现象定位：从 Pod 状态切入诊断起点

当 Kubernetes（文中“K18NV”为明显笔误，应统一为 kubectl get pods 所示的 Pending 状态）中 Pod 长期停滞于 Pending，表明其未被成功调度或无法进入容器运行阶段。该状态本身不具错误语义，但持续超时（>60s）即构成典型故障信号。首要动作是执行：
kubectl describe pod <pod-name> -n <namespace>，重点关注 Events 区域——90% 以上 Pending 根因直接暴露于此。

二、分层归因：七类核心阻塞路径深度拆解

依据调度生命周期与资源绑定链路，Pending 可划分为以下七个正交维度，按发生顺序由浅入深排列：

1. 节点资源不可用：CPU/Memory requests 超出所有 Node 的 Allocatable 剩余量（非 Capacity）；LimitRange 强制注入默认 requests 导致隐式超限。
2. 污点-容忍度失配：Node 设置 Taint（如 node-role.kubernetes.io/control-plane:NoSchedule），而 Pod 未声明对应 Toleration。
3. 节点约束失效：Pod 定义了 nodeSelector、nodeAffinity 或 podAntiAffinity，但集群中无节点同时满足全部标签/拓扑规则。
4. 存储供给中断：PVC 处于 Pending，原因包括：StorageClass 不存在、Provisioner Pod 崩溃、RBAC 权限缺失（如 system:serviceaccounts:<ns>:default 缺少 storage.k8s.io/v1 权限）。
5. 镜像拉取失败：私有 Registry 凭据（imagePullSecrets）未挂载、Secret 名称拼写错误、网络策略（NetworkPolicy）阻断节点到 Registry 的 443/5000 端口。
6. 调度器异常：默认 kube-scheduler CrashLoopBackOff、自定义调度器未部署或未通过 --policy-config-file 加载策略、调度器配置了错误的 --scheduler-name 而 Pod 未显式指定。
7. 命名空间级配额压制：ResourceQuota 已耗尽 requests.cpu 或 count/pods，或 LimitRange 对新 Pod 强制设定了不可满足的 limits。

三、诊断工具链：结构化命令矩阵

目标维度	关键命令	输出解读要点
节点资源	kubectl get nodes -o wide && kubectl describe nodes	检查 Non-terminated Pods 列及 Allocatable vs Requests 对比
PVC/PV 状态	kubectl get pvc,pv -A && kubectl describe pvc <name> -n <ns>	关注 PVC 的 VolumeMode、StorageClass、Phase 及 Events 中的 ProvisionFailed
全局事件流	kubectl get events --sort-by=.lastTimestamp -A --field-selector involvedObject.name=<pod-name>	过滤出与该 Pod 直接关联的最近 20 条事件，识别 “FailedScheduling”、“FailedAttachVolume” 等关键字

四、根因验证流程图

graph TD A[Pod Pending] --> B{kubectl describe pod
Events 中是否有 FailedScheduling?} B -->|Yes| C[检查 Nodes 资源/Taints/Affinity] B -->|No| D[Events 是否含 VolumeBinding？] D -->|Yes| E[检查 PVC/PV/StorageClass] D -->|No| F[Events 是否含 ErrImagePull？] F -->|Yes| G[验证 imagePullSecrets & Registry 连通性] F -->|No| H[检查 kube-scheduler Pod 状态
及 ResourceQuota] C --> I[执行 kubectl get nodes -o wide
kubectl describe node XXX] E --> J[kubectl get sc,pvc,pv -A] G --> K[curl -v https://registry.example.com/v2/ -H “Authorization: Bearer XXX”] H --> L[kubectl get quota,limitrange -n target-ns]

五、高阶避坑指南（面向 5+ 年从业者）

• 动态调度器切换陷阱：启用 kube-scheduler 多实例时，若未通过 --scheduler-name=custom-scheduler 显式指定且 Pod 未设置 schedulerName，将导致默认调度器静默跳过该 Pod。
• TopologySpreadConstraints 隐式锁死：当 topologyKey: topology.kubernetes.io/zone 且可用 Zone 数 < 小于 maxSkew，所有节点均被判定为“违反约束”，结果等效于无节点可选。
• LimitRange 的 request/limit 注入副作用：若命名空间启用了 LimitRange 且未定义 defaultRequest，仅定义了 default，则新 Pod 会继承 default limit 但无 request —— 导致 scheduler 按 0 request 调度，而实际运行时因 limit > 0 触发 OOMKill，形成“假 Pending”表象（实为 CrashLoopBackOff 后被 evict）。
• CSI Driver 升级导致 PVC Pending：新版 CSI Controller 可能拒绝旧版 PV 的 volumeHandle 格式，表现为 PVC Pending 且 Events 显示 “failed to get plugin from registry”。

```