GKEのコンテナ最適化OSのメモリ不足がフリーズする
GKEのコンテナ最適化OSに問題があります。この単純なコマンドを実行すると https://Pastebin.com/raw/0WPAnAzn すべてのRAMを消費すると、ある時点でホストがフリーズし、何にも応答しなくなります。期待される動作：プロセスはOOMキラーによって強制終了されます。在庫のUbuntuおよびCentOSイメージでこれを試しましたが、完全に機能します。プロセスはフリーズせずに強制終了されます。
シリアルコンソールには、次の3つの可能なkmsg出力があります。
- 場合によっては、ログにフリーズに関連するものが含まれていません
- 他のプロセスの一連のOOMキルと、それに続く関連メッセージなしのフリーズが発生する場合があります。
- そして最も興味深いのは、OOMキルとそれに続くカーネルパニック（ https://Pastebin.com/raw/gtdsg6vQ ）
フリーズには、ほぼ100％のCPU負荷が伴います。
それで、これは予想される動作ですか、それとも何か問題がありますか？
いくつかの実験の結果、GKEやGCPに関連していないことがわかりました。また、COSイメージとは関係ありません。
実際には、LinuxカーネルがOOMを処理する方法です。 OOMキラーの起動が遅すぎて、メモリが非常に限られた環境で動作しています。プロセスのoom_scoreを使用して、どのプロセスを強制終了するかを決定します。
ホストでKubernetesを実行すると、oom_score_adjust値が高いプロセスが多数あります（これらはポッドです 仕様にメモリ制限なし ）。 RAMイーターポッドに制限が設定されている場合、結果のoom_scoreはおそらく他の多くのプロセスよりも低くなります。
この場合、OOM killerは、本当に貪欲なプロセスを強制終了する前に、最初にoom_scoreが最も高い多くのプロセスを強制終了します。理由はわかりませんが、このような状況ではLinuxが完全にフリーズします。
回避策として、私は このツール を見つけました。 DaemonSetとしてインストールすると、問題が解決します。それは容赦なく貪欲なプロセスを殺します。
この動作は予期されたものであり、 COSイメージ 自体が原因ではありません。代わりに、Kubernetesがどのように処理するかに関連しています ノードOOM 。この場合、スクリプトはPODではなくノードで実行されています。コンテナは殺されていますが、メモリを枯渇させているメインプロセスではありません。
いくつかの 提案 とノードのリソースを予約するのに役立つ実装 OSデーモン があります。
バージョン1.7.6を保持するノード以降、Google Container Engineは、Kubernetes ノード割り当て可能機能 を使用して、システムオーバーヘッド用に各ノードのコンピューティングリソースの一部を予約します。これにより、システムコンポーネントの信頼性が向上しますが、システムのオーバーヘッドは増加しません。この変更により、システムコンポーネントがすでに消費している可能性のある計算リソースが明示的に予約されます。