Kubernetes常见故障排查指南：6类证据链与命令清单

使用方式：本文不是Kubernetes命令库，而是一套故障排查证据链。命令只用于取证，最终目标是判断影响面、定位根因、恢复服务并留下可复盘材料。

Kubernetes常见故障排查最容易走向两个极端：一种是看到Pod异常就立刻重启，先把现象压下去；另一种是收藏大量kubectl命令，却不知道在什么场景下使用。对企业生产环境来说，这两种方式都不够。排障需要先确认影响面，再逐层收集资源状态、事件、日志、节点、网络、存储和发布变更证据，最后形成结论和复盘。

如果没有证据链，故障处理会变成个人经验；如果只有命令清单，没有判断顺序，团队也很难把经验沉淀为稳定性能力。

先判断影响面：不要一上来就重启Pod

排障第一步不是执行命令，而是回答影响面问题。影响面决定排障优先级，也决定是否需要升级应急响应。

建议先确认：

• 是单个Pod异常，还是同一应用多个副本异常
• 是单个Namespace异常，还是多个团队或多个集群受影响
• 是新版本发布后异常，还是无明显变更的运行时异常
• 是应用不可访问，还是性能变慢、错误率上升或任务堆积
• 是否影响核心业务路径，是否需要先回滚或切流

如果影响面扩大，不应由单个工程师在命令行里持续试错。应同步应用负责人、平台值班、安全或网络相关角色，并记录开始时间、现象、影响范围和已执行动作。

排障的第一条原则，是先保护证据和服务，再选择修复动作。盲目删除Pod、清理节点或修改配置，可能让现场证据丢失，也可能把局部故障扩大为平台故障。

证据一：Pod状态和容器日志

Pod是大多数Kubernetes故障的第一观察对象，但Pod状态不能单独解释全部问题。`Pending`可能是资源不足、调度约束或镜像问题；`CrashLoopBackOff`可能是应用启动失败、配置错误、依赖不可用或探针设置不当；`Running`也不代表业务可用。

常用取证命令包括：

“`bash

kubectl get pod -n <namespace> -o wide

kubectl describe pod <pod-name> -n <namespace>

kubectl logs <pod-name> -n <namespace> –previous

kubectl get pod <pod-name> -n <namespace> -o yaml

“`

查看Pod时，应重点关注4类信息：调度到哪个节点，容器是否反复重启，事件里是否有镜像拉取、探针、资源或挂载错误，日志是否能解释应用自身异常。

如果只看到容器重启而不看`–previous`日志，就可能错过上一次崩溃前的关键错误；如果只看当前日志，不看事件，就可能把镜像拉取失败、存储挂载失败或调度失败误判为应用问题。

证据二：事件不是噪音，而是控制面的时间线

Kubernetes事件记录了控制器、调度器、kubelet和相关组件对资源的操作结果。很多故障在日志里看不到，但事件会留下线索，例如镜像拉取失败、节点不可调度、资源不足、探针失败、PVC挂载失败、Secret不存在等。

常用命令包括：

“`bash

kubectl get events -n <namespace> –sort-by=.lastTimestamp

kubectl describe deployment <deployment-name> -n <namespace>

kubectl describe rs -n <namespace>

“`

事件排查要看时间顺序。不要只看最后一条，也不要忽略重复次数。比如一个Pod最终处于Running，但事件里出现过多次探针失败，说明启动过程可能不稳定；一个Deployment副本不足，事件里可能已经提示资源配额、镜像或调度约束问题。

对企业平台团队来说，事件还可以作为复盘材料。它能说明故障何时开始、控制器做过什么、失败发生在哪一层，以及人工操作是否改变了资源状态。

证据三：节点和资源压力

当多个Pod同时异常，或者Pod长期Pending、频繁驱逐、调度失败时，需要从节点和资源层排查。节点问题常见于CPU、内存、磁盘、网络、kubelet状态、运行时异常或节点不可达。

常用命令包括：

“`bash

kubectl get nodes -o wide

kubectl describe node <node-name>

kubectl top node

kubectl top pod -n <namespace>

“`

如果集群没有安装指标采集组件，`kubectl top`可能不可用，此时应结合平台监控、节点监控和日志系统查看资源趋势。

节点排查时应注意三个判断：

• Pod无法调度，是节点资源不足、污点、亲和性、配额还是存储约束导致
• Pod被驱逐，是内存、磁盘、PID、临时存储还是节点压力导致
• 多个应用异常，是同一节点问题，还是同一镜像、同一发布或同一依赖问题

节点层排障不要轻易把问题归因于“Kubernetes不稳定”。很多节点异常背后是容量规划不足、资源请求不准、磁盘清理不及时、镜像缓存膨胀或运行时维护缺失。

证据四：网络路径和服务发现

应用不可访问时，很多团队会先怀疑网络。但Kubernetes网络问题往往要分层看：Service选择器是否匹配Pod，Pod是否Ready，端口是否正确，DNS是否解析，NetworkPolicy是否限制访问，Ingress或网关是否配置正确，下游服务是否可达。

常用取证命令包括：

“`bash

kubectl get svc,endpoints,endpointslice -n <namespace>

kubectl describe svc <service-name> -n <namespace>

kubectl get ingress -n <namespace>

kubectl exec -n <namespace> <pod-name> — nslookup <service-name>

“`

如果Service没有Endpoints，通常先检查标签选择器和Pod就绪状态；如果Endpoints存在但访问失败，再看端口、协议、网络策略、DNS和网关配置。不要一开始就把问题推给底层网络插件。

企业环境还要注意多集群、跨Namespace和网关链路。一次访问失败可能经过DNS、Service、Sidecar、网关、负载均衡和外部依赖，排查时应画出请求路径，按路径逐段验证。

证据五：存储和配置变更

有状态应用、日志目录、上传目录、数据库客户端缓存、消息中间件和批处理任务，都会让故障与存储或配置有关。常见现象包括Pod无法启动、PVC无法绑定、挂载失败、应用启动后找不到配置、Secret缺失或配置更新没有生效。

常用命令包括：

“`bash

kubectl get pvc,pv -n <namespace>

kubectl describe pvc <pvc-name> -n <namespace>

kubectl get configmap,secret -n <namespace>

kubectl describe deployment <deployment-name> -n <namespace>

“`

存储问题不能只看PVC是否Bound，还要看挂载事件、节点可用性、存储类、访问模式和应用读写方式。配置问题也不能只看对象是否存在，还要确认应用是否引用了正确Key，配置更新是否需要重启，密钥是否由正确流程发放。

如果故障发生在配置变更之后，应优先回看变更记录和发布流水线。很多“应用突然坏了”并不是运行时故障，而是配置、Secret、镜像Tag或依赖地址被修改后缺少验证。

证据六：发布变更和回滚边界

Kubernetes故障经常与发布变更相关。镜像版本、环境变量、资源限制、探针、网络策略、Ingress规则、HPA策略和依赖配置都可能引发问题。排障时必须把“最近发生了什么”纳入证据链。

常用命令包括：

“`bash

kubectl rollout status deployment/<deployment-name> -n <namespace>

kubectl rollout history deployment/<deployment-name> -n <namespace>

kubectl describe deployment <deployment-name> -n <namespace>

“`

回滚前要确认问题是否真的由应用版本引起。若故障来自数据库变更、配置中心、外部依赖、存储挂载或网络策略，单纯回滚Deployment可能不能恢复服务，甚至会引入兼容性问题。

更稳妥的做法是把发布变更和观测数据结合起来：发布前后错误率是否变化，是否集中在某个版本，是否只有新Pod异常，是否所有流量都经过同一路径，是否存在未同步配置或依赖变更。

命令清单：只作为取证入口

以下命令适合作为排障辅助清单，但不应脱离场景机械执行。

这张表的意义是快速取证，不是鼓励在生产环境中边猜边改。涉及删除、强制重启、修改资源、回滚发布、驱逐Pod或下线节点的动作，应遵守变更流程和应急权限边界。

把一次排障变成团队能力

故障恢复后，排障并没有结束。平台团队应把证据整理成复盘材料，至少包含：现象和影响面、时间线、触发因素、直接原因、根因判断、恢复动作、残余风险和改进项。

如果复盘只写“重启后恢复”，下次仍然会重复救火。更有价值的复盘应回答：为什么监控没有提前发现，为什么发布前没有拦住，为什么权限或配置允许风险进入生产，为什么团队没有清晰回滚边界。

这也是Kubernetes平台化运维的重要差异。单个工程师可以靠经验处理一次故障，但企业需要把经验沉淀为监控规则、发布门禁、资源配额、安全策略、知识库和演练机制。

下一步建议

建议平台团队先选择最近3次Kubernetes故障复盘，按本文的6类证据链重新整理一次：Pod与日志、事件、节点资源、网络路径、存储配置、发布变更。检查哪些证据当时缺失，哪些命令依赖个人经验，哪些信息没有进入统一可观测系统。

下一步可以把高频故障固化为平台检查项：发布前自动检查探针、资源请求、镜像来源和配置引用；运行中统一采集事件、日志、指标和审计；故障后沉淀复盘模板和改进项闭环。若当前工具链无法支撑这些动作，可以进一步评估企业级容器平台、可观测体系和稳定性治理能力。

FAQ

Kubernetes故障排查第一步应该做什么？

第一步应确认影响面和业务优先级：是单个Pod、单个应用、单个Namespace，还是多个集群或核心业务受影响。影响面确定后，再决定是否先止血、回滚、切流或进入完整排查。

Pod是Running为什么应用仍然不可用？

Running只表示容器进程处于运行状态，不代表业务可服务。还需要检查Readiness探针、Service端点、网关路由、应用日志、下游依赖、错误率和关键接口是否正常。

命令清单能否替代排障流程？

不能。命令清单只能帮助取证，真正的排障流程需要判断现象、收集证据、验证假设、执行恢复、保留现场并复盘。没有判断顺序的命令越多，越容易造成误操作。

什么时候应该回滚Deployment？

当证据显示故障与新镜像、新配置或Deployment变更高度相关，并且回滚不会引入数据、依赖或兼容风险时，可以按变更流程回滚。若问题来自外部依赖、存储、网络策略或数据库变更，单纯回滚可能无效。