线上排障四步走：通过 Describe、Logs、Exec 与 Events 快速定位故障根源

在复杂的云原生环境中，应用故障的排查效率直接决定了系统的可用性。Kubernetes（K8s）提供了强大的工具集，但如何系统地使用它们是关键。本文将介绍一套高效的“线上排障四步走”方法论，即利用 Events、Describe、Logs 和 Exec 这四个核心操作，快速锁定故障的根本原因。

预备知识：定位目标

所有排查都从确定故障应用（Pod/Deployment）和其当前状态开始。通常通过 kubectl get pods 来观察状态（如 CrashLoopBackOff, ImagePullBackOff, Error 等）。

# 示例：查看所有 Pod 状态
kubectl get pods -n production

第一步：Events 与 Describe——了解“发生了什么”

这是宏观诊断的第一步。我们不直接看应用代码，而是先检查系统层面记录的事件和资源配置。

1. 检查 Events (历史事件)

系统事件记录了资源（如 Pod、Deployment、Node）过去一段时间内的状态变化。这对于判断故障是配置问题、资源不足还是调度失败至关重要。

# 查看最近的系统事件
kubectl get events --sort-by='.lastTimestamp'

# 或者针对性地查看某一资源相关的事件（推荐）
kubectl get events --field-selector involvedObject.name=my-failing-pod-xyz

2. Describe (详细配置与状态)

Describe 命令提供了 Pod 的完整配置、状态以及最近的容器启动尝试信息。这是判断容器为什么无法启动（如内存不足、Volume挂载失败、Liveness/Readiness 探针失败）的首选工具。

实操示例：

假设我们有一个名为 my-failing-app-5b6d7c8f9-abcdg 的 Pod 处于 CrashLoopBackOff 状态。

kubectl describe pod my-failing-app-5b6d7c8f9-abcdg

关注点：

• Status/Conditions: 容器当前的状态。
• Resource Limits: 是否因为 CPU/内存限制而导致 OOMKilled。
• Events 区域 (底部): 查看最近的事件列表，例如 Failed to pull image 或 Liveness probe failed。

第二步：Logs——查看“应用怎么说”

如果 Describe 显示容器成功启动过但随后退出，那么故障原因通常在应用代码或配置层面。此时需要查看容器的标准输出和标准错误。

1. 查看当前日志

# 查看当前运行中（或正在重启中）容器的实时日志
kubectl logs my-failing-app-5b6d7c8f9-abcdg

2. 查看前次退出的日志

对于 CrashLoopBackOff 的情况，应用日志可能在容器退出后才产生。我们必须查看上一个容器实例的日志。

# -p 或 --previous 选项用于查看前一个容器实例的日志
kubectl logs -p my-failing-app-5b6d7c8f9-abcdg

关注点： 查找 Java 栈追踪、数据库连接失败、配置文件读取错误等应用级错误信息。

第三步：Exec——进入“现场”检验

如果日志输出不明确，或者我们需要测试网络连通性、检查文件路径等，就需要进入容器内部环境进行实时诊断。

1. 进入容器 Shell

使用 exec 启动一个交互式的 Shell 会话。注意，许多基础镜像（如 Alpine）默认使用 sh，而大型镜像可能使用 bash。

# 尝试进入 Bash Shell
kubectl exec -it my-failing-app-5b6d7c8f9-abcdg -- bash

# 如果没有 bash，尝试 sh
kubectl exec -it my-failing-app-5b6d7c8f9-abcdg -- sh

2. 现场诊断命令

进入容器后，可以执行标准的 Linux 诊断命令：

# 示例：在容器内测试到数据库服务的连通性
kubectl exec my-failing-app-5b6d7c8f9-abcdg -- ping -c 3 db-service.default.svc.cluster.local

第四步：Debug/Events 闭环——解决与确认

1. 确认修复

根据前三步定位到的问题（例如，发现配置错误、网络不通或依赖缺失），进行相应的配置或代码修改，并重新部署。

2. 使用 K8s Debug 容器（高级）

如果需要更深入的诊断（例如，容器内没有安装必要的工具如 tcpdump 或 netstat），可以使用 kubectl debug 命令创建临时调试容器，并附加到故障 Pod 的命名空间或节点上，从而利用更丰富的工具集进行分析。

# 示例：创建临时调试 Pod，共享故障 Pod 的命名空间
kubectl debug -it my-failing-app-5b6d7c8f9-abcdg --image=busybox:1.36 --target=my-failing-app

3. 检查新的 Events

故障解决并重新部署后，再次使用 kubectl describe pod 检查底部的 Events，确认所有探针（Startup/Liveness/Readiness）均已成功，且没有新的错误事件产生，从而形成故障排查的闭环。