Pritiks23/Kubernetes-Incident-Response-Lab

# Kubernetes 故障响应实验室 ## 在此观看演示，点击视频播放： [](https://www.youtube.com/watch?v=I_9eVDJnQ0M) 构建了一个 Kubernetes 故障排查实验室，其中包含 20 个基于真实生产环境启发的故障。诊断并解决了涉及网络、DNS、Ingress、存储、资源限制、配置管理、探针、调度以及容器生命周期问题的故障。为每个场景编写了故障处理手册和根因分析。 # 故障 1：Ingress 404 错误路由 ## 概述 模拟了一个 Ingress 路由故障，尽管后端服务健康且 Pod 正在运行，但流量仍返回 404。 ## 初始状态（健康） - nginx Deployment 正在运行 - ClusterIP Service 正确映射（端口 80 → 80） - Pod 在端口 80 上正常响应 - Ingress controller 已安装且功能正常 ## 注入故障 修改了 Ingress 路径： - 从 `/` → `/broken` ## 症状 - 访问 `/` 返回 404 Not Found - 访问 `/broken` 返回有效的 nginx 响应 - 在 Pod 或 Service 层面未观察到任何问题 ## 根本原因 路由规则中的 Ingress 路径配置错误。 ## 诊断方法 - kubectl describe ingress - 通过 debug pod 进行直接的 HTTP 测试 - 基于路径的响应验证 ## 解决方案 将 Ingress 规则恢复为： - `/` → nginx:80 ## 结果 - HTTP 流量完全恢复 - 端到端路由验证成功（Ingress → Service → Pod） ## 核心要点 即使后端服务健康，Ingress 配置错误也会中断路由。 # 故障 2：Service Selector 故障（隐性流量中断） ## 概述 模拟了由 Service selector 配置错误引起的 Kubernetes 服务中断。Pod 是健康的，但由于 endpoint 解析丢失，流量传输失败。 ## 初始状态（健康） - nginx Deployment 正在运行，带有标签 `app=nginx` - ClusterIP Service 正确选择了 `app=nginx` - Endpoints 正确指向 Pod IP ## 注入故障 修改了 Service selector： - 从 `app=nginx` - 改为 `app=broken` ## 症状 - Service 显示零个 endpoints - 发往 `http://nginx/` 的内部集群流量失败 - Pod 保持健康并持续运行（没有 CrashLoopBackOff 或 Pod 级别的错误） ## 根本原因 Service selector 不匹配导致 Kubernetes 无法进行 endpoint 发现，从而破坏了 service 到 pod 的路由。 ## 诊断方法 - `kubectl get endpoints nginx` 返回为空 - `kubectl describe svc nginx` 显示了 selector 不匹配 - 来自 debug pod 的 HTTP 请求失败 ## 解决方案 恢复了 Service selector： - `app=broken` → `app=nginx` ## 结果 - Endpoints 自动恢复 - 从 service 到 pod 的完整流量恢复 - 集群恢复至健康状态 ## 核心要点 Service selector 配置错误会导致隐蔽且不明显的服务中断，此时工作负载看似健康，但完全无法访问。 ## 🚨 故障 3：CrashLoopBackOff（应用故障） 📌 概述 本次故障模拟了一个生产环境中的失效场景：由于无效的容器启动命令，Kubernetes Deployment 陷入了 CrashLoopBackOff 状态。该问题导致了 Pod 的持续重启，并阻碍了应用程序提供稳定的服务。 根本原因是 Deployment spec 中配置了错误的容器 command，迫使容器立即退出（exit 1）。 🧱 环境 Cluster: kind (Kubernetes v1.36.1) Deployment: nginx Service 类型: ClusterIP Namespace: default 工具集: kubectl, docker, kind 💥 故障触发条件 通过使用无效的启动命令 patch 该 Deployment 引入了此问题： command: - sh - -c - exit 1 这导致所有新创建的 Pod 在启动后立即失败。 ⚠️ 观察到的症状 Pod 行为 Pod 不断重启 状态交替出现： Error CrashLoopBackOff Running（短暂运行） Kubernetes 信号 重启次数过高 ReplicaSet 滚动发布不稳定 Endpoints 丢失或不稳定 示例： nginx-xxxxx 0/1 CrashLoopBackOff Restarting continuously 🔍 诊断步骤 1. 检查 Pod 状态 kubectl get pods 2. 检查故障 Pod kubectl describe pod 关键发现： Exit Code: 1 Reason: Error 3. 检查日志 kubectl logs deployment/nginx 由于立即终止，日志未显示任何应用输出。 4. 验证滚动发布状态 kubectl rollout status deployment/nginx 观察到由于 ReplicaSet 失败导致的滚动发布不稳定。 🧠 根本原因 Deployment spec 包含无效的容器 command： sh -c exit 1 这迫使容器在启动后立即终止，触发了 Kubernetes 的重启策略。 Kubernetes 行为表现： 检测到故障 重启容器 进入指数退避模式（CrashLoopBackOff） 🛠️ 解决方案 步骤 1：回滚 Deployment kubectl rollout undo deployment/nginx 步骤 2：重启 Deployment kubectl rollout restart deployment/nginx 步骤 3：验证恢复情况 kubectl get pods kubectl get endpoints nginx ✅ 最终状态 Pod 所有 Pod 均处于 Running 状态 1/1 READY Endpoints Service 路由已恢复 分配了有效的 Pod IP Deployment 激活了稳定的 ReplicaSet 无重启循环 📊 收集的证据 Pod describe 输出 Deployment YAML（回滚前/后） Rollout 历史记录 Service 和 endpoint 快照 全集群资源状态 存放于： evidence/incident-3/ 📚 核心要点 1. CrashLoopBackOff 属于应用级别的故障 Kubernetes 运行正常；是容器本身出现了故障。 2. 如果 spec 仍然被篡改，仅靠回滚是不够的 如果 Deployment 模板不正确，Kubernetes 将会不断重新制造故障。 3. 调试需要多层排查： Pod 生命周期事件（describe） Deployment 滚动发布状态 ReplicaSet 协调机制 Endpoint 健康状况 4. 日志可能并不总是可用 快速崩溃的容器可能无法生成可用的日志；此时事件将成为主要的排查信号。

标签：Pandas, 子域名突变, 故障排查, 请求拦截, 运维