Kubernetes 诊断操作手册

解决什么问题

集群出问题时——Pod 反复重启、节点转成 NotReady、命名空间被配额卡死——第一反应通常是打开终端，手动跑一遍 kubectl get pods -A、kubectl describe node，再从几十页输出里翻找线索。这个过程重复且耗时，在高压的故障处理场景下，还容易因为疲劳漏掉关键事件。更麻烦的是，不同工程师的排查顺序往往不一致，同样的集群可能得出完全不同的结论。

这个技能把常见的诊断动作固化成结构化的执行流程，让每次排查覆盖相同的检查项，减少遗漏，也方便把结果写进事后复盘。

技能如何工作

技能基于两个工具运作：

• kubectl：Kubernetes 命令行客户端，用于获取集群与资源的原始状态
• kubernetes.client：官方 Python 客户端，可以在脚本或自动化流程中直接调用集群 API

诊断流程按几个固定维度推进：

• Pod 健康：检查 Pod 的 Ready 条件、重启次数（Restart Count）以及容器处于 Waiting 或 Terminating 状态的原因
• 资源配额：核对命名空间下的 ResourceQuota 与 LimitRange，确认是否出现配额耗尽导致的 Forbidden 拒绝
• 事件日志：从事件流中提取 FailedScheduling、OOMKilled、FailedMount 这类关键信号
• 节点状态：检查节点的 Ready 条件、DiskPressure、MemoryPressure 和 PIDPressure 等系统压力指标

整体思路是先收集事实，再定位症状所属的层级：是单个 Pod 的问题、资源约束的问题，还是节点层面的容量或压力问题。

适用边界与注意点

• 技能只覆盖诊断与信息收集，不执行修复操作，后续的处置仍需要人工判断
• 运行前需要有效的集群访问凭证（kubeconfig）和到 API Server 的网络连通性
• 诊断动作本身是只读查询，但在大规模集群上频繁轮询 API 仍可能带来额外负载
• 上游项目要求环境中有可用的 Docker 环境，部署前需要确认
• 事件会被 kubelet 清理，长时间之前的故障可能已经不在事件流里，需要结合 kubectl logs 与监控系统交叉验证