GCP容器中可能的OOM – 如何debugging？
芹菜在GCP的docker集装箱上与Kubernetes一起运行。 它的工人最近已经开始kill -9 – 这看起来跟OOMKiller有点关系。 在kubectl get events中没有OOM事件，如果这些事件仅在一个pod已经侵入resources.limits.memory值时才会出现，那么这是事件。
所以，我的理论是，芹菜进程被杀是linux自己的OOMKiller的一个工作。 这样做没有任何意义：如果OOMKiller进入舞台，消耗的内存太多了，那么这个播客怎么可能排在第一位？ （假设Kubernetes不允许在resources.limits.memory的总和超过系统可用内存量的情况下调度新的豆荚）。
但是，我不知道这些SIGKILL的其他合理原因比OOMKiller。
芹菜错误的例子（每个工人都有一个）：
[2017-08-12 07:00:12,124: ERROR/MainProcess] Process 'ForkPoolWorker-7' pid:16 exited with 'signal 9 (SIGKILL)' [2017-08-12 07:00:12,208: ERROR/MainProcess] Task handler raised error: WorkerLostError('Worker exited prematurely: signal 9 (SIGKILL).',)
容器可以被OOMKILLY有两个原因。
- 如果超过了设定的内存限制。 限制是在每个容器的基础上指定的，如果容器使用的内存超过了限制，它将被OOMKilled。 从过程的angular度来看，这与系统内存不足相同。
-
如果系统内存不足。 Kubernetes中有两种资源规范： 请求和限制 。 限制指定容器在OOMKilled之前可以使用的最大内存量。 如果未指定，请求将用于计划Pod并默认为限制。 请求必须小于或等于容器限制。 这意味着如果多个容器同时使用比它们各自的请求更多的内存，那么容器可能在节点上被过度使用，并被OOMKilled。
例如，如果进程A和进程B都有1GB的请求和2GB的限制，则它们都可以在具有2GB内存的节点上进行调度，因为请求是用于调度的。 要求低于限制通常意味着容器可以突破2GB，但通常使用不到1GB。 现在，如果同时爆发1GB以上，则系统可能会耗尽内存，并且一个容器将在低于容器上设置的限制的情况下被OOMKilled。
您可以通过检查Pod上的containerStatuses字段来debugging容器是否被OOMKilled。
$ kubectl get pod X -o json | jq '.status.containerStatuses'
如果这个吊舱是OOMKILLED的话，通常会在最后一个状态字段中说一些这样的事情。 在你的情况下，它看起来可能是一个OOM错误的基础上对芹菜（如这个问题）提起的问题。