4. 故障诊断与排查方法论：日志分析、事件排查、资源监控、CrashLoopBackOff 等通用诊断流程
通用故障诊断流程
容器平台故障诊断遵循“信息收集 → 日志分析 → 事件排查 → 资源监控 → 根因定位”五步闭环。下表概括各阶段核心动作与工具：
| 步骤 | 核心动作 | 常用命令/工具 |
|---|---|---|
| 1. 收集信息 | 获取 Pod 状态、Events、节点状态 | kubectl describe pod、kubectl get events |
| 2. 日志分析 | 抓取应用日志，定位异常堆栈 | kubectl logs --previous、kubectl exec、EFK/Loki |
| 3. 事件排查 | 分析 Warning/Error 事件链 | kubectl describe pod 中的 Events 字段 |
| 4. 资源监控 | 检查 CPU/Memory 使用趋势，识别 OOM/资源争抢 | kubectl top pod、Prometheus + Grafana |
| 5. 根因定位 | 关联所有线索，确定故障根本原因 | 结合配置检查、版本对比、上下游调用链 |
面试高频题眼：CrashLoopBackOff 是最常被问的排错场景，回答时务必覆盖
--previous 日志、Events 中的 OOMKilled/Waiting 状态、Resource Limits 检查三个关键步骤。
面试问答卡
Q1
Pod 处于 CrashLoopBackOff 状态，如何系统化排查？
| 考察点 | 容器排错流程、kubectl 命令熟练度、日志与事件分析能力 |
|---|---|
| 回答框架 | ① kubectl describe pod 查看 Events → ② kubectl logs --previous 获取崩溃前日志 → ③ 检查资源限制（OOMKilled）→ ④ 检查 Init 容器状态、存活/就绪探针 → ⑤ 检查 ConfigMap/Secret 挂载及镜像拉取策略 |
| 示例回答 | 先用 kubectl describe pod 看 Events，若出现 OOMKilled 则增大 memory limit；否则用 kubectl logs --previous 获取应用崩溃日志，分析 panic 或错误配置。若日志为空，检查 init container 是否退出码非零，最后确认存活探针 URL 是否可达。 |
| 可能追问 | • 日志全是乱码或空行怎么办？ • Init 容器失败如何处理？ • 如何区分是存活探针失败还是容器自身崩溃？ |
| 避坑提醒 | ⚠️ 忽略 Events 中的 Warning 只关注 Error；⚠️ 忘记添加 --previous 只查当前日志；⚠️ 未检查 Pod 所在节点资源水位。 |
Q2
通过日志分析快速定位容器平台故障，你采用什么思路？
| 考察点 | 日志工具熟练度、过滤策略、时间线关联、日志聚合理解 |
|---|---|
| 回答框架 | ① 确定日志源（stdout/stderr / 文件日志）→ ② 用 kubectl logs --previous --tail=50 尾部截取 → ③ 使用 grep 过滤 Error、Fatal、panic 等关键字 → ④ 关联 Events 时间戳，缩小定位范围 → ⑤ 对分布式系统使用 EFK/Loki 聚合检索 |
| 示例回答 | 先确认 Pod 能否 running，若已 Crash 执行 kubectl logs pod --previous --tail=100。快速 grep“error”或“FATAL”。若日志量巨大，用 --since=10m 缩小窗口，再结合 Events 中的“Started/Failed”时间戳比对业务日志。最后检查是否有日志轮转导致的截断。 |
| 可能追问 | • 日志轮转丢日志如何补救？ • 多容器 Pod 如何区分各容器日志？ • 如何区分应用日志和系统日志？ |
| 避坑提醒 | ⚠️ 不要只依赖 kubectl logs，有时需要 kubectl exec 进容器查看文件日志；⚠️ 注意容器时区与宿主时区差异导致时间误判。 |
Q3
资源监控在故障诊断中起什么作用？你常用哪些具体指标？
| 考察点 | 监控指标理解、资源与故障关联、PromQL/prometheus 使用经验 |
|---|---|
| 回答框架 | ① 资源瓶颈导致 Pod OOM、CPU Throttling 触发重启 → ② 关键指标：container_memory_working_set_bytes、container_cpu_usage_seconds_total、container_oom_events_total → ③ 使用 kubectl top pod 实时观察，或 Prometheus 查询历史趋势 → ④ 对比 resource.limits 评估是否分配不足 |
| 示例回答 | CrashLoopBackOff 最常见根因是 OOM。我会用 kubectl top pod 看实时内存，再用 PromQL：container_memory_working_set_bytes{container=“app”} > 0.9 * limit。若内存使用接近 limit 并出现 OOMKilled 事件，应增大 memory limit 或排查内存泄漏。 |
| 可能追问 | • 如何区分应用内存泄漏还是初始分配不足？ • 监控数据存在 5 分钟延迟如何应对？ • 如何根据监控数据设置合理的 request/limit？ |
| 避坑提醒 | ⚠️ 不要只看当前时间点，要查看崩溃前 5～10 分钟的峰值；⚠️ 区分 container_memory_usage_bytes（含缓存）与 working_set（真实占用），OOM 判定以 working_set 为准。 |
要点总结：诊断容器故障时，Events + 日志 + 资源监控 形成三角验证。面试中能对 CrashLoopBackOff 从 describe、logs、资源三线并行展开，是区分候选人的关键。