一、应急响应阶段：快速定位异常Pod

当监控系统触发K8s集群告警时，首要任务是通过标准化命令快速锁定异常容器。以下排查路径基于生产环境验证，可覆盖80%以上的基础故障场景：

1.1 全局异常Pod扫描

# 识别非Running/Succeeded状态的Pod（含CrashLoopBackOff、Error等）
kubectl get pods --all-namespaces \
  --field-selector=status.phase!=Running,status.phase!=Succeeded \
  -o wide | grep -v Completed

该命令可快速定位集群中所有异常状态的Pod，建议结合-o wide参数查看关联节点信息。对于大规模集群，可添加--no-headers | wc -l统计异常数量。

1.2 重启次数排序分析

# 按容器重启次数降序排列（取前20条）
kubectl get pods -A --sort-by='.status.containerStatuses[0].restartCount' \
  | awk '{if(NR>1) print}' | tail -20

高频重启往往是配置错误或资源竞争的典型特征。需注意：

多容器Pod需调整.status.containerStatuses[N]索引
结合--field-selector=status.phase=Running过滤已终止Pod

1.3 事件日志深度解析

# 获取Pod完整事件链（重点关注Warning级别事件）
kubectl describe pod <pod-name> -n <namespace> \
  | grep -A 30 "^Events:" | grep -i warning

典型异常事件包括：

FailedScheduling：资源不足或节点选择器不匹配
BackOff：容器持续崩溃导致重试间隔指数增长
FailedCreatePodSandBox：CNI网络初始化失败

1.4 容器生命周期诊断

# 获取容器退出码（非0值表明异常终止）
kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'
# 查看前一次崩溃日志（关键调试信息）
kubectl logs <pod-name> -n <namespace> --previous --tail=100

常见退出码解析：

137：OOM Killer触发（内存超限）
139：段错误（程序bug或内存越界）
255：应用内部错误（需结合日志分析）

二、系统层诊断：节点资源与网络验证

当Pod级排查无果时，需扩展至节点维度进行系统性诊断：

2.1 节点资源压力测试

# 实时资源使用率监控
kubectl top nodes --no-headers | awk '{print $1,$4,$6}'
# 详细资源分配分析（重点关注Allocated resources部分）
kubectl describe node <node-name> | grep -A 15 "Allocated resources"

资源不足的典型表现：

CPU Throttling：频繁达到requests/limits边界
Memory Pressure：触发kubelet的内存回收机制
Disk Pressure：Ephemeral存储使用率超过85%

2.2 CNI网络健康检查

# 以Calico为例验证网络组件状态
calicoctl node status | grep -i "Ready"
calicoctl ipam show --show-blocks | grep "CIDR"
# 验证节点iptables规则数量（阈值建议<5万条）
iptables-save | wc -l

网络问题常见表现：

Pod间通信延迟突增
Service ClusterIP无法访问
网络策略配置冲突

2.3 内核级故障排查

# 检查OOM事件记录（时间戳已本地化）
dmesg -T | grep -i "kill process" | tail -20
# 系统日志中的OOM记录（含进程树信息）
journalctl -k -p err | grep -i "oom-kill" | tail -10

OOM分析要点：

对比dmesg与容器日志中的时间戳
检查被杀进程的PID是否匹配容器主进程
验证Pod的memory limit是否低于实际需求

三、根因分析：典型配置错误案例

某生产环境案例显示，凌晨3点的集群告警源于Deployment配置缺陷：

3.1 致命配置解析

# 问题配置片段（已脱敏）
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10  # 启动准备时间不足
  periodSeconds: 5         # 探测频率过高
  timeoutSeconds: 2        # 超时阈值过短
  failureThreshold: 2      # 容错窗口太小

该配置导致的问题链：

应用启动需要15秒完成初始化，但10秒后即开始健康检查
首次探测失败后，每5秒重试一次，连续失败2次即重启容器
夜间流量低峰期，依赖服务响应变慢，触发超时
最终导致Pod每分钟重启2-3次，引发集群级告警

3.2 健康检查最佳实践

建议配置参数范围：
| 参数 | 合理范围 | 风险点 |
|——————————|———————-|—————————————-|
| initialDelaySeconds | 2×应用启动时间 | 过短导致误杀 |
| periodSeconds | 10-60秒 | 过频增加系统负载 |
| timeoutSeconds | 3-10秒 | 过短误判健康状态 |
| failureThreshold | 3-5次 | 过低缺乏容错能力 |

修正后的配置示例：

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 30
  timeoutSeconds: 5
  failureThreshold: 3

四、预防性措施：构建健壮的K8s运维体系

标准化配置模板：使用Helm/Kustomize强制实施健康检查基线
动态资源调整：结合HPA与VPA实现资源弹性适配
全链路监控：集成Prometheus+Grafana实现从Pod到节点的可观测性
混沌工程实践：定期注入故障验证系统容错能力
自动化巡检：通过CronJob定期执行配置合规性检查

五、故障排查checklist

阶段	检查项	验证方法
快速定位	异常Pod数量统计	`kubectl get pods -A	grep -v Running`
	重启次数排序	`kubectl get pods -A --sort-by='.status.containerStatuses[0].restartCount'`
深度诊断	容器退出码分析	`kubectl get pod -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'`
	节点资源分配	`kubectl describe node	grep -A 15 “Allocated resources”`
根因验证	健康检查配置审计	`kubectl get deployment -o yaml	grep -A 20 livenessProbe`
	网络规则数量监控	`iptables-save	wc -l`

通过系统化的排查流程与预防性措施，可将K8s集群夜间故障的MTTR（平均修复时间）降低60%以上。建议运维团队将本文checklist集成到自动化运维平台，实现故障响应的标准化与可追溯性。

K8s集群凌晨告警：从故障定位到根因分析全流程解析