GCPコンテナ内のOOMの可能性 - デバッグ方法

Question

私はKubernetesとGCPのドッカーコンテナでセロリを実行しています。その従業員は最近kill -9を取得し始めました - これはOOMKillerと関係があるようです。 kubectl get eventsにOOMイベントはありません。これは、ポッドがresources.limits.memoryの値を侵入したときにのみ表示されるイベントです。

だから、私の理論は殺さセロリのプロセスは、Linux自身OOMKillerの仕事であるということです。しかし、これは理にかなっていません.OOMKillerがステージに入るほど多くのメモリが消費された場合、このポッドは最初にスケジュールされていた可能性はありますか？ （Kubernetesがresources.limits.memoryの合計がシステムで使用可能なメモリの量を超えた場合、新しいポッドのスケジューリングを許可しないと仮定します）。

しかし、私はOOMKillerよりこれらSIGKILLsするための他の任意のもっともらしい理由を知りません。

セロリエラーの例は、（すべての労働者のための1つが存在する）

[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).',) 

Answer 1

容器は二つの理由OOMKilledすることができます。

1. それらのセットのメモリ制限を超えている場合。制限はコンテナ単位で指定され、コンテナが制限より多くのメモリを使用する場合はOOMKilledになります。プロセスの観点からは、システムのメモリが不足している場合と同じです。

2. システムのメモリが不足している場合。 Kubernetesには、requests and limitsの2種類のリソース指定があります。制限は、コンテナがOOMKilledされる前に使用できるメモリの最大量を指定します。要求は、ポッドをスケジュールするために使用され、指定されていない場合はデフォルト値に制限されます。要求はコンテナの制限値以下でなければなりません。つまり、複数のコンテナがそれぞれの要求よりも多くのメモリを同時に使用している場合、コンテナはノード上でオーバーコミットされ、OOMKilledされる可能性があります。プロセスAおよびプロセスBの両方が1ギガバイトの要求と2ギガバイトの限界を持っている場合、要求は、スケジューリングのために使用されるものであるため、それらは両方とも2GBのメモリを有するノード上でスケジュールすることができる。例えば

   、。制限を下回る要求があるということは、通常、コンテナが最大2GBまでバーストできることを意味しますが、通常は1GB未満を使用します。今、両方のバーストが同時に1GBを超えるとシステムがメモリ不足になり、1つのコンテナがOOMKilledになり、コンテナに設定されている制限値を下回った場合。

あなたは、コンテナがポッドにcontainerStatusesフィールドを調べることによってOOMKilledされているかどうかをデバッグすることができます。

$ kubectl get pod X -o json | jq '.status.containerStatuses' 

ポッドであった場合OOMKilledそれは通常 lastStateフィールドにその効果に何かを言うだろう。あなたのケースでは、それはセロリ（例えば this oneのような）に対して提出された問題に基づいて、OOMエラーであったようです。