1. 问题现象
pod一直重启，通过grafana查看，发现内存使用率并没有100%。
2. 排查过程
2.1 describe查看pod最新一次的状态
可以明显看到，最近一次的重启就是因为内存不足导致的。
2.2 describe 查看node节点状态
找到原因了，原来是触发了节点压力驱逐。
这就是为啥pod是因为oom被杀死的，而监控上却显示内存并没有达到上限。
3. 原因分析
3.1 kubelet工作原理回顾
3.1.1 面向容器
官方文档：kubelet | Kubernetes
kubelet 是基于 PodSpec 来工作的。每个 PodSpec 是一个描述 Pod 的 YAML 或 JSON 对象。 kubelet 接受通过各种机制（主要是通过 apiserver）提供的一组 PodSpec，并确保这些 PodSpec 中描述的容器处于运行状态且运行状况良好。
简单点说：你给我yaml，我按照你的要求创建pod并监测它们是running的。
3.1.2 面向node节点
官方文档：节点压力驱逐 | Kubernetes
kubelet 监控集群节点的内存、磁盘空间和文件系统的 inode 等资源。 当这些资源中的一个或者多个达到特定的消耗水平， kubelet 可以主动地使节点上一个或者多个 Pod 失效，以回收资源防止饥饿。
这个过程，被称为“节点压力驱逐”，在节点压力驱逐期间，kubelet 将所选 Pod 的阶段 设置为Failed并终止 Pod。
但我们常见的驱逐状态不是“Eviction”吗，为什么我次的场景中并没有看到该状态呢？继续往下看。
3.2 驱逐
首先系统学习过k8s的铁子们肯定都知道，kubelet启动时，是可以配置系统资源预留的，通过--eviction相关的参数，可以配置给系统预留多少资源。如下：
imagefs.available<15%,memory.available<100Mi,nodefs.available<10%
一旦达到预留的阈值，就会触发“驱逐”。pod状态如下图：
但还是有一种情况，pod不会出现这个驱逐状态，而是反复的被kubelet 直接杀死对应的进程，那就是“节点内存不足行为”。
3.3 节点内存不足行为
如果 kubelet 在节点遇到 OOM 之前无法回收内存， 则 oom_killer 根据它在节点上使用的内存百分比计算 oom_score， 然后加上 oom_score_adj 得到每个容器有效的 oom_score。 然后它会杀死得分最高的容器。
这意味着低 QoS Pod 中相对于其调度请求消耗内存较多的容器，将首先被杀死。
与 Pod 驱逐不同，如果容器被 OOM 杀死， kubelet 可以根据其 restartPolicy 重新启动它。
