在K8S中，探测存活 pod 状态为 CrashLoopBackOff 如何处理?

K8S中处理 CrashLoopBackOff 的排查步骤（笔试题简洁版）：

核心原因：

Pod 反复崩溃 → Kubelet 启动失败重试 → 触发指数退避等待（BackOff）

---

🔍 排查步骤（笔试推荐顺序）：

1. 查看 Pod 日志

   kubectl logs <pod-name> --previous  # 获取上次崩溃日志
   

   关键点：检查应用启动报错（如配置错误、依赖缺失）

2. 检查资源限制

   kubectl describe pod <pod-name> | grep -A 5 "Limits"  
   

   关键点：确认是否因 OOMKilled（内存不足）或 CPU 资源不足

3. 验证探针配置

   kubectl get pod <pod-name> -o yaml | grep -A 10 "livenessProbe"
   

   关键点：存活探针（livenessProbe）失败会导致容器重启

4. 检查持久化存储

   kubectl describe pod <pod-name> | grep -A 10 "Volumes"
   

   关键点：PVC 绑定失败/权限错误导致容器无法启动

5. 查看事件记录

   kubectl describe pod <pod-name> | grep -A 20 "Events"
   

   关键点：定位 K8S 调度层错误（如镜像拉取失败、节点亲和性冲突）

---

🛠️ 常见解决方案：

故障类型	解决方式
应用启动报错	修复代码/配置文件 → 重新构建镜像
内存不足(OOM)	增加 resources.limits.memory 值
探针配置错误	调整 livenessProbe 超时时间/检测路径
镜像拉取失败	检查镜像地址/凭证 → imagePullSecrets
依赖服务未就绪	添加 initContainers 等待依赖服务
存储挂载问题	检查 PVC/PV 状态 → 确保 StorageClass 有效

---

⚠️ 强制重启（临时恢复）：

kubectl delete pod <pod-name> --force --grace-period=0

注意：仅用于临时恢复，需同步排查根本原因！

---

📝 笔试题最简回答（30秒内）：

四步排查：

1. kubectl logs --previous → 查应用错误
2. kubectl describe pod → 看资源/OOM/事件
3. 检查探针配置 → 调整 livenessProbe 参数
4. 验证存储/PVC → 确保挂载正常
   根本解决：修复应用或调整资源配置

---

✅ 附：CrashLoopBackOff 生命周期

graph LR A[容器启动] --> B{启动成功?} B -- 是 --> C[运行中] B -- 否 --> D[容器退出] D --> E[Kubelet 重启容器] E --> F{连续崩溃?} F -- 是 --> G[指数增加等待时间 CrashLoopBackOff] F -- 否 --> A