K8S的oomkiller

典型现象/特征

1. 功能异常，如超时、接口报错
2. pod宕机或重启

排查确认步骤

可按照以下证据链进行确认：

1. 1.可先通过异常接口定位对应服务，确认服务是否存在宕机或重启现象；
2. 2.随后重点查看 K8S 中对应 pod 的事件信息，如果存在 OOMKilled、CrashLoopBackOff 等关键信息，可作为触发 K8S OOMKill 的直接证据。

如果上面2条信息都符合，可确认为K8S的oomkiller。但该问题可能由多个其他因素导致，还需进行如下检测：

1. 1.接着通过巡检工具或人工检查应用 yaml 中的资源配置，确认 limit、request 等参数是配置不合理，如果存在问题则需调整。
2. 2.检测异常服务是否存在生成 heapdump 文件,如果存在转入 元空间内存溢出 或 JVM堆内存溢出处理
3. 3.检查 K8S 节点监控，确认是否存在节点资源瓶颈，例如内存不足。
4. 4.最后结合应用监控判断应用本身的内存、CPU、GC、磁盘等指标是否基本正常，如果应用自身没有明显异常飙高，而 pod 却被系统回收，则更倾向于 K8S 层资源限制或节点资源不足导致。

分析工具

1. 一键采集工具
2. 系统监控查看说明 中的内存、GC和 服务器监控部分
3. 系统日志查看指引 中 info 日志查看

常见应急处理策略

1. 首先确认服务资源配置是否合理，避免存在明显偏大或不符合实际负载的资源申请与限制；如果配置不合理，应优先调整 pod 部署配置。
2. 如果集群资源分布不均，可选择负载和资源使用率较低的节点，通过增加 nodeSelector 或 nodeName 等方式，将 pod 调度到更合适的节点，缓解节点级资源争抢问题。