1. Kubernetes故障上下文：运维老兵的实战指南
在Kubernetes集群管理过程中，最令人头疼的莫过于半夜被报警吵醒，面对一堆模糊的报错信息却无从下手。经过多年实战，我发现故障上下文（Failure Context）的构建能力，直接决定了问题排查效率。今天就来分享如何系统性地建立Kubernetes故障分析框架。
2. 故障上下文的核心要素解析
2.1 时间维度：故障时间线的精确还原
在排查Kubernetes集群问题时，精确的时间线还原能揭示80%的异常原因。我通常采用以下命令组合建立时间轴：
# 获取节点事件（按时间倒序） kubectl get events --sort-by='.lastTimestamp' -A # 查看特定Pod的生命周期事件 kubectl describe pod <pod-name> | grep -A 10 Events关键技巧：
- 使用
--since参数限定时间范围（如--since=2h） - 结合
jq处理JSON格式事件：kubectl get events -o json | jq '.items[] | select(.lastTimestamp > "2023-07-20T00:00:00Z")'
2.2 资源状态：三维健康检查模型
我总结的"CPU-Memory-Disk"三维检查法：
# 节点资源概览（含资源预留情况） kubectl describe nodes | grep -E 'Allocatable|Allocated' # 容器级资源监控（需提前部署metrics-server） kubectl top pods --containers常见陷阱：
- 内存不足往往表现为OOMKilled，但实际可能是内存碎片化导致
- CPU Throttling容易被忽略，需检查
container_spec_cpu_quota指标
3. 高级诊断工具链配置
3.1 诊断工具矩阵
根据问题类型选择工具：
| 问题类型 | 首选工具 | 备用方案 |
|---|---|---|
| 网络问题 | ksniff + wireshark | cilium connectivity test |
| 存储问题 | kubectl debug ephemeral | strace |
| 调度问题 | kube-scheduler logs | events --watch |
3.2 自定义检查脚本示例
这是我常用的节点健康检查脚本：
#!/bin/bash function check_kubelet() { local node=${1:-$(hostname)} ssh $node "sudo journalctl -u kubelet --since '1 hour ago' | grep -i error" } function check_docker() { docker stats --no-stream | awk 'NR>1 {print $1,$2,$3}' | sort -k3 -hr }4. 典型故障模式速查手册
4.1 证书过期问题
症状：API Server不可用，controller-manager/调度器报TLS错误
应急步骤：
- 检查证书有效期：
openssl x509 -noout -dates -in /etc/kubernetes/pki/apiserver.crt - 快速续期（适用于kubeadm）：
kubeadm alpha certs renew all systemctl restart kubelet
4.2 网络插件崩溃
当Calico/Cilium异常时：
- 临时恢复通信：
iptables -P FORWARD ACCEPT - 诊断CNI配置：
ls -l /etc/cni/net.d/ cat /var/log/calico/cni.log
5. 日志收集最佳实践
5.1 结构化日志方案
推荐使用Loki+Promtail+Grafana组合：
# promtail-config.yaml clients: - url: http://loki:3100/loki/api/v1/push scrape_configs: - job_name: kubernetes kubernetes_sd_configs: {...}5.2 关键日志来源
- Kubelet：
journalctl -u kubelet -f - 容器运行时：
docker logs --since 5m <container-id> - 控制平面：
kubectl logs -n kube-system <pod-name>
6. 预防性运维策略
6.1 混沌工程检查清单
每月执行以下测试：
- 随机删除Pod：
kubectl delete pod --force --grace-period=0 <pod> - 节点隔离测试：
kubectl cordon <node> - 网络延迟注入：使用
tc工具模拟
6.2 健康检查黄金指标
必须配置的探针参数：
livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 # 重要！避免启动时误杀 periodSeconds: 5 failureThreshold: 3 # 根据业务容忍度调整7. 故障复盘模板
每次重大故障后，我会用以下结构记录：
### 时间线 - [ ] 00:00 首次报警触发（CPU负载>90%） - [ ] 00:05 确认kube-proxy异常 ### 根本原因 kube-proxy IPVS规则堆积导致CPU飙升 ### 修复方案 1. 清理无效规则：`ipvsadm -C` 2. 升级到v1.22+（修复IPVS内存泄漏） ### 预防措施 - 增加IPVS规则监控 - 设置kube-proxy滚动重启策略经过多年实践，我深刻体会到：好的故障上下文就像侦探的线索板，能把碎片信息变成清晰的证据链。建议每个团队都建立自己的Kubernetes故障知识库，把每次踩坑的经验转化为预防措施。
