问题现象

在 K8s 排障过程中，Pod 长时间处于 Pending 状态是最常见且最让人抓狂的场景之一。很多人以为只要看 kubectl describe pod 的 Events。发现资源不足就调低 request，节点不够就扩容即可。但实际情况往往比想象复杂得多。

一次认证服务的上线故障让我们深刻体会到这一点：

• 新版本上线后Pod 一直卡在 Pending。
• 第一次 describe 显示 FailedScheduling我们立刻把 CPU request 降到 500m，以为解决了——结果仍然 Pending。
• 第二次 describe 出现 FailedMountPVC 绑定失败。根源是 PVC 引用了一个根本不存在的 StorageClass。怎么说呢，

痛点：表面上是资源请求过高。实际还叠加了存储配置错误，两层问题叠加导致排查时间翻倍。

排查过程

至于第一步先，查看调度事件。锁定资源不足

kubectl describe pod 是排查 Pending 的起点。Events 字段记录了调度器、kubelet、volume controller 在各阶段抛出的关键信息。

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 5m default-scheduler 0/3 nodes are available: Insufficient cpu。Insufficient memory

Pain point：只看到 “Insufficient cpu” 就急着改 request，却忽视了是否还有其他隐藏错误。

接下来的观点是，查看节点资源，发现请求冲突

kubectl top node

NAME CPU MEMORY
k8s-node-1 92% 78%
k8s-node-2 88% 81%
k8s-node-3 90% 80%

kubectl describe node k8s-node-1 显示已分配的 CPU Requests 已接近 allocatable 上限。而新版本 Deployment 的 CPU request 为 2000m(相当于两核），导致所有节点都无法满足调度需求。

：调低资源后仍然 Pending

将 Deployment 中的 CPU request 从 "2000m" 调整为 "500m" 并重新部署后Pod 进入 Pending，但这次 Events 已经变为：

Warning FailedMount ... MountVolume.SetUp failed for volume "auth-data": pvc-xxx has not been bound yet
Failed to mount PVC: persistentvolumeclaim "auth-data-pvc" not found

Pain point：The problem “moves” from scheduling to volume mounting – if you stop after fixing first error you’ll be stuck again.

至于第四步。检查 PVC 和 StorageClass

kubectl get pvc -n auth | grep auth-data-pvc

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
auth-data-pvc Pending — — RWO fast-storage 6m

Kubectl describe pvc auth-data-pvc -n auth

Warning ProvisioningFailed: storageclass.storage.k8s.io "fast-storage" not found

The referenced StorageClass does not exist in cluster;only "standard" and "slow" are present.

说到第五步，确认 StorageClass 清单并定位根因叠加

kubectl get sc
NAME PROVISIONER RECLAIM-POLICY AGE
standard k8s.io/minikube-hostpath Delete 30d
slow kubernetes.io/gce-pd Delete 30d

Pain point：The deployment simultaneously suffers from:

1. C​PU request 超标导致 FailedScheduling。
2. PVC 引用了不存在的 StorageClass 导致 FailedMount。

根因分析

子原因一的观点是。CPU request 严重偏离基线

• Lack of historical metrics：
• No reference to previous version baseline：
• Aggressive over‑commit：

子原因二的观点是，排障只停留在第一层

POD Pending 常常是多层错误叠加。修复第一层后才会暴露第二层。如果只关注首个 Event，就会误以为已解决掉。

说到子原因三。StorageClass 缺乏一致性校验

• PVC 中写死了 “fast-storage”，但集群中根本没有对应对象。
• K8s 在 apply 时不会检查引用对象是否存在只会在实际绑定时报错。
• C​I 流水线缺少对 StorageClass 存在性的自动校验环节。

累计效应的观点是。调度 + 存储组合拳

A single上线事件同时触发了两类独立错误，使得排障时间几乎翻倍。若能在第一次 describe 时就看到多个 Event 并并行处理，可将整体恢复时间缩短约50%。

修复方案

说到第一步先，修正资源限制

resources:
requests:
cpu这方面，"500m"
memory的观点是，"512Mi"
从limits来看，cpu: "800m"
说到memory，"1Gi"

接下来的观点是，修正 StorageClass

apiVersion: v1
从kind来看，PersistentVolumeClaim
metadata:
name的观点是，auth-data-pvc
spec这方面。storageClassName: standard # 改为集群真实存在的 SC
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi

：CI 流水线增加 pre‑deploy 校验

1. C​PU Request 合理性校验：
2. PVC StorageClass 存在性校验：KUBECTL get sc -o name | grep -w $SC_NAME || exit 1.

验证结果

即时指标的观点是，Pod 成功运行

• 再看Status，Running，无重启记录。
• PVC 状态：Bound，与 PV 正常绑定。
• /api/auth/login 接口响应时间恢复至正常水平。
• Kube‑let logs 不再出现挂载错误。

持续观察

部署后观察了30分钟。两个 Pod 的 CPU 使用稳定在约 300 m，内存保持在 350 Mi。PVC 挂载方法 /data/sessions 读写正常。此时我们 确认集群已经安装了所需 CSI 驱动。否则即使使用正确的 StorageClass，也会因为缺少 provisioner 而卡住。Pain point 消除：

• - 不再出现 “Pending – Insufficient cpu”。
• - 不再出现 “FailedMount – storageclass not found”。
• - 故障定位时间从原来的约 45 分钟压缩至 15 分钟。

团队复盘

1. C​PU Request 必须基于监控数据设定，不得盲目写大值。
2. POD Pending 排查要全程查看 Events，多阶段错误必须并行处理。
3. C​I 必须加入 PV/PVC/StorageClass 的存在性检查，避免人为笔误进入生产环境。

避坑建议

1. C​PU/Memory Request 必须参考历史基线：
2. POD Pending 排查要看全 Events：Kubectl describe pod …| grep -i Event -A5，确保没有新的异常出现。
3. PVC 引用的 StorageClass 必须事前确认： 在提交 PR 前，用脚本自动查询目标集群中是否存在对应 SC；若不存在立即报错阻止合并。
4. 区分 Scheduling 与 Mounting 阶段 ： Pending→Scheduled→ContainerCreating→Running，每一步都有独立日志来源。怎么说呢，定位时先判断卡在哪一步再深入调查。

---