4. 故障现象描述：Pod 处于 Pending 状态，kubectl describe 显示 FailedScheduling

在证书轮换操作后的数分钟内，运维人员发现某关键业务 Pod 无法正常启动，始终停留在 Pending 状态。通过 kubectl get pods 可以快速确认 Pod 的当前状态，但需要进一步使用 kubectl describe pod 来获取详细的调度失败原因。

4.1 故障现象确认步骤

以下是在实际环境中复现该故障的标准操作流程：

1. 查看 Pod 状态：执行 kubectl get pods -n <namespace>，观察到目标 Pod 的 STATUS 列为 Pending，且持续数分钟未发生变化。
2. 获取调度事件：执行 kubectl describe pod <pod-name> -n <namespace>，在输出的 Events 部分定位到关键信息。
3. 识别错误码：在 Events 中看到 FailedScheduling 事件，并附带具体的错误原因描述。

4.2 典型输出示例

以下是从实际故障环境中截取的 kubectl describe pod 输出片段，其中包含了诊断所需的核心信息：

Name:             web-app-7d8f9c4b6c-x2y3z
Namespace:        production
...
Status:           Pending
...
Events:
  Type     Reason            Age   From                Message
  ----     ------            ----  ----                -------
  Warning  FailedScheduling  2m    default-scheduler   0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 2 node(s) had untolerated taint {node.kubernetes.io/disk-pressure: }. preemption: 0/3 nodes are available: 1 Preemption is not helpful for scheduling, 2 No preemption victims found for incoming pod.

4.3 故障现象与证书轮换的关联分析

证书轮换导致 Pod 调度失败的现象并非直接由证书本身引起，而是通过影响节点上的 kubelet 组件 与 API Server 之间的通信链路，进而触发了一系列连锁反应。下表梳理了从证书轮换到 Pod Pending 的完整逻辑链条：

4.4 故障现象的可视化流程

下图以流程图的形式展示了从证书轮换到 Pod 进入 Pending 状态的完整链路，帮助理解各个组件之间的依赖关系：

4.5 故障现象总结

本故障的核心现象可以归纳为以下三点：

• 表象：Pod 处于 Pending 状态，调度器无法找到可用节点。
• 直接原因：节点被添加了 node.kubernetes.io/disk-pressure 污点，且 Pod 未设置对应的容忍度。
• 深层诱因：证书轮换后 kubelet 未能成功更新证书，导致与 API Server 的心跳中断，Node Controller 根据节点条件自动添加了污点。