K8sGPT智能诊断集群OOM崩溃宕机各类故障
前言：K8sGPT能解决什么问题？
当你管理的Kubernetes集群突然出现Pod被OOMKilled、节点NotReady甚至整个集群崩溃时，传统做法是靠堆日志和逐条运行kubectl命令来拼凑根因，对新手极不友好。
K8sGPT（Kubernetes GPT）正是为这种场景设计的——它利用大语言模型（如OpenAI或本地部署的模型）自动聚合集群事件、资源状态和审计日志，直接输出诊断结论和修复建议。
本文面向零基础用户，从安装到实战诊断一次讲透。
环境准备与安装K8sGPT
K8sGPT目前提供二进制和Homebrew两种安装方式，以Linux服务器为例，推荐直接下载二进制：
# 下载最新版本（以v0.3.44为例，实际请从官方release获取最新版本号）
wget https://github.com/k8sgpt-ai/k8sgpt/releases/download/v0.3.44/k8sgpt_amd64.deb
# 安装
sudo dpkg -i k8sgpt_amd64.deb
# 验证安装
k8sgpt version安装完成后需要配置AI后端。
K8sGPT默认使用OpenAI，你需要准备一个API Key：
export OPENAI_API_KEY=sk-xxxx
k8sgpt auth如果不想使用OpenAI，也可以配置Ollama等本地模型，具体见官方文档。
首次使用建议先运行 k8sgpt analyze --explain 测试连通性。
实战排查：直击OOM与崩溃故障
诊断集群OOM的关键是找出哪个Pod或节点耗尽了内存。
在发生故障的命名空间执行：
k8sgpt analyze --explain --filter=Pod,OOMKilledK8sGPT会自动扫描集群中处于OOMKilled状态的Pod，并给出分析。
例如输出可能包含：
- Pod
nginx-xxx在节点node-1上因内存超过limit被OOM Kill - 建议：调整Pod的资源limits或增加节点内存
对于整个节点宕机或集群崩溃，使用更宽泛的过滤：
k8sgpt analyze --explain --filter=Node,CrashLoopBackOff,NotReadyK8sGPT会聚合节点状态、事件和Pod重启信息，直接告诉你可能导致宕机的根因（如节点内存碎片、Docker/Containerd故障、磁盘压力等）。
如果你只想看某段时间内发生的异常，可以配合 --namespace 或配合kubectl筛选出特定资源后管道输入：
kubectl get pods --all-namespaces | grep -i oom | k8sgpt analyze --explain但建议优先使用原生分析命令，输出更结构化。
避坑指南：常见问题与正确姿势
1. API Key泄露风险：不要把 OPENAI_API_KEY 直接写死在脚本里，建议通过K8sGPT的 k8sgpt auth 命令保存到配置文件（默认路径 ~/.config/k8sgpt）。
2. 诊断结果过于笼统：K8sGPT的输出依赖集群当前资源快照，如果事件窗口太旧或日志被清理，诊断可能不准确。建议在故障发生后尽快运行分析，同时配合 kubectl describe pod 和 kubectl top node 交叉验证。
3. 多后端模型兼容性：OpenAI模型英文能力最强，如果集群日志含大量中文，诊断效果可能下降；改用本地Mistral或Qwen系列效果更佳。
4. 权限不足：确保运行K8sGPT的kubeconfig有集群范围的读取权限（至少 get pods, events, nodes）。
效果验证与后续操作
分析完成后，K8sGPT会输出一段自然语言描述，并附带修复建议。
验证诊断是否准确的方法分两步：
- 对照
kubectl describe pod中的Last State: Terminated: OOMKilled确认根因。 - 检查节点
kubectl top node内存使用率，若发现某节点内存长期超过90%，说明调整Pod limits或增加节点资源是正确方向。
如果你确认了K8sGPT的建议，可以直接根据它给出的修复指令操作（例如修改Deployment的resources字段），然后重新部署并观察Pod是否稳定。
后续可以结合 k8sgpt analyze --explain --anonymize 在敏感场景下脱敏输出。
提示：K8sGPT并非万能，对于硬件故障、内核bug或网络分区等问题，仍需结合系统日志和硬件监控工具。但作为日常集群诊断的第一道筛查工具，它已经能帮运维节省大量时间。
