4. 故障诊断口径：kubectl describe node、journalctl、crictl logs、节点事件时间线（Event Timeline）重建

节点故障的MTTR（平均修复时间）高度依赖诊断口径的准确性与效率。在Kubernetes环境中，kubectl describe node、journalctl、crictl logs 以及 事件时间线重建 构成了四大核心诊断支柱。本章将逐一拆解每个工具的输出解读、关键字段提取方法，以及如何将碎片化信息拼接成完整的故障时间线。

4.1 诊断工具矩阵与适用场景

4.2 kubectl describe node：节点状态快照与关键字段

kubectl describe node 是诊断节点故障的第一入口。其输出结构分为多个区块，每个区块对应不同的诊断维度。

4.2.1 核心区块解读

• Conditions：节点健康状态的核心指标。重点关注 Ready、DiskPressure、MemoryPressure、PIDPressure 和 NetworkUnavailable。每个Condition包含 LastHeartbeatTime 和 LastTransitionTime，用于判断故障持续时间。
• Addresses：节点IP（InternalIP、ExternalIP、Hostname）。当网络故障时，检查IP是否与预期一致。
• Capacity / Allocatable：资源总量与可分配量。当Pod调度失败时，对比这两个字段判断是否资源耗尽。
• System Info：操作系统、内核版本、容器运行时版本。用于判断版本兼容性问题。
• Events：节点级别的事件列表，包含 Type（Normal/Warning）、Reason、Message、FirstTimestamp、LastTimestamp、Count。这是重建事件时间线的核心数据源。

4.2.2 关键字段提取命令

# 提取节点Conditions状态（JSON格式）
kubectl get node <node-name> -o json | jq '.status.conditions[] | {type: .type, status: .status, lastTransitionTime: .lastTransitionTime, message: .message}'

# 提取节点事件（按时间排序）
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=<node-name> --sort-by='.lastTimestamp'

# 提取节点资源压力状态
kubectl describe node <node-name> | grep -A 5 "Conditions"

4.3 journalctl：系统日志的深度挖掘

journalctl 是访问systemd日志的接口，对于诊断kubelet、容器运行时（containerd/cri-o）以及内核级别的故障至关重要。

4.3.1 常用过滤与时间窗口

# 查看kubelet日志（最近30分钟）
journalctl -u kubelet --since "30 minutes ago" --no-pager

# 查看containerd日志（指定时间范围）
journalctl -u containerd --since "2025-01-15 14:00:00" --until "2025-01-15 14:30:00"

# 查看内核日志（OOM相关）
journalctl -k --grep="oom_kill" --since "1 hour ago"

# 查看特定PID的日志（从kubelet日志中获取PID后使用）
journalctl _PID=12345 --no-pager

4.3.2 关键日志模式与故障映射

4.4 crictl logs：容器运行时的精确诊断

crictl 是CRI兼容的容器运行时CLI工具，用于直接与containerd或cri-o交互。当 kubectl logs 无法获取日志（如Pod处于CrashLoopBackOff状态）时，crictl logs 是备用方案。

4.4.1 常用命令组合

# 列出所有容器（包括已停止的）
crictl ps -a

# 查看特定容器的日志（最近100行）
crictl logs --tail=100 <container-id>

# 查看容器日志并持续跟踪
crictl logs -f <container-id>

# 查看容器日志（指定时间范围，需容器运行时支持）
crictl logs --since="2025-01-15T14:00:00Z" --until="2025-01-15T14:30:00Z" <container-id>

4.4.2 与kubectl logs的对比

4.5 节点事件时间线（Event Timeline）重建

事件时间线重建是将来自不同源的离散事件按照时间顺序拼接成完整的故障演进图。这是MTTR复盘中最关键的步骤，也是从“知道发生了什么”到“理解为什么发生”的跨越。

4.5.1 时间线重建步骤

1. 收集原始事件：从 kubectl get events、journalctl、crictl logs 中提取所有与故障节点相关的事件。
2. 标准化时间戳：将所有事件的时间戳统一为UTC格式（ISO 8601），消除时区差异。
3. 排序与去重：按时间戳升序排列，合并重复事件（相同Reason、相同Message、时间窗口在1秒内）。
4. 关联上下文：将系统日志中的错误信息与Kubernetes事件中的状态变化关联。例如，journalctl中的 OOM 日志应与 kubectl describe node 中的 MemoryPressure 事件关联。
5. 绘制时间线：将关联后的事件按时间轴可视化，标注关键转折点（如节点状态从Ready变为NotReady的时间点）。

4.5.2 时间线重建示例（SVG）

4.5.3 时间线重建自动化脚本框架

#!/bin/bash
# 节点故障事件时间线重建脚本（示例框架）
NODE_NAME=$1
SINCE="1 hour ago"

echo "=== 1. 收集Kubernetes节点事件 ==="
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=$NODE_NAME \
  --sort-by='.lastTimestamp' -o json | jq '.items[] | {time: .lastTimestamp, type: .type, reason: .reason, message: .message}'

echo "=== 2. 收集kubelet系统日志 ==="
journalctl -u kubelet --since "$SINCE" --no-pager -o json | jq '. | {time: .__REALTIME_TIMESTAMP, message: .MESSAGE}' 2>/dev/null

echo "=== 3. 收集内核OOM日志 ==="
journalctl -k --grep="oom_kill" --since "$SINCE" --no-pager -o json | jq '. | {time: .__REALTIME_TIMESTAMP, message: .MESSAGE}'

echo "=== 4. 时间线合并（按时间排序） ==="
# 将上述输出合并到临时文件，使用sort -k1进行排序
# 实际生产环境建议使用Python/Go编写更健壮的聚合逻辑

4.6 诊断口径的最佳实践与避坑指南

• 时间同步：确保集群所有节点的时间同步（使用NTP）。时间偏差超过5秒会导致事件时间线重建出现逻辑错误。
• 日志持久化：默认情况下，Kubernetes事件和系统日志都有保留期限。建议将关键日志实时发送到集中式日志系统（如Elasticsearch/Loki），保留周期至少30天。
• 自动化触发：配置Prometheus告警规则，当节点状态变化时自动触发诊断脚本，收集上述四个数据源的快照并保存到对象存储中。
• 避免过度依赖kubectl：当API Server不可用时，kubectl命令会失效。此时应优先使用 journalctl 和 crictl 进行本地诊断。