看起来几乎不可能处理。
基于answer on Github关于OMM Kill上的优雅停止：
当前无法更改OOM行为。每当容器接近其内存限制时，Kubernetes（或运行时）可以向您的容器提供信号。这将是尽最大努力的基础，因为内存峰值可能无法及时处理。
以下是官方文档：
如果节点在kubelet能够回收内存之前发生了系统OOM（内存不足）事件，则节点依赖于oom_killer来响应。kubelet根据Pod的服务质量为每个容器设置一个oom_score_adj值。
所以，正如你所理解的，你没有太多的机会来处理它。这里是关于OOM处理的大article，我将在这里只取一小部分，关于内存控制器的内存处理：
不幸的是，这个进程可能没有太多其他的方法来响应OOM情况。如果它已经用mlock（）或mlockall（）将其文本锁定到内存中，或者它已经驻留在内存中，那么它现在就知道内存控制器内存不足了。但是，它不能做任何其他事情，因为大多数感兴趣的操作都需要分配更多的内存。
我唯一能提供的是从cAdvisor（这里你可以得到一个OOM Killer事件）或从Kubernetes API获取数据，当你看到指标非常接近内存不足时运行你的命令。我不确定你会有时间在你得到OOM Killer事件后做些什么。

以下是我们用来分析K8S中的Pod OOMKilled的一些步骤。

• 通过Prometheus监控内存使用情况
• 不仅使用container_memory_working_set_bytes指标来监控内存使用情况，还使用container_memory_max_usage_bytes指标。
• 我们可以从上述指标中发现一些异常的内存增加，以进一步研究基于我们的逻辑代码。
• 检查系统日志
• 在基于systemd的Linux发行版中。要使用的工具是journalctl。

sudo journalctl --utc -ke

• -ke只显示内核消息并跳转到日志的末尾。

memory: usage 4194304kB, limit 4194304kB, failcnt 1239
  memory+swap: usage 4194304kB, limit 9007199254740988kB, failcnt 0
  kmem: usage 13608kB, limit 9007199254740988kB, failcnt 0
  Memory cgroup stats for /kubepods.slice/kubepods-burstable.slice/kubepods-burst...

• 我们可以在系统视图中发现一些不正常的内存使用情况。
• 从上述文件夹中检查内存cgroup统计信息
• 检查文件夹/sys/fs/cgroup/memory/kubepods.slice/kubepods-burstable.slice下的文件以查找内存分配信息。
• pod的内存转储
• 我们可以在pod的preStop中添加一个钩子来转储pod的内存，可以根据转储文件进行进一步的调查。

lifecycle:
    preStop:
      exec:
        command:
        - sh
        - -c
        - "jmap -dump:live,format=b,file=/folder/dump_file 1"