Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2023年1月25日にJAVIER MARTÍNEZ が投稿したブログ（https://sysdig.com/blog/troubleshoot-kubernetes-oom)を元に日本語に翻訳・再構成した内容となっております。
Kubernetesを使用する場合、Out of Memory (OOM) エラーとCPUスロットリングは、クラウドアプリケーションのリソース処理で主に頭を悩ませる問題です。なぜでしょうか？
クラウドアプリケーションにおけるCPUとメモリの要件は、クラウドのコストに直接結びついているため、これまで以上に重要です。
リミットとリクエストを使用すると、リソースの枯渇を防ぎ、クラウドのコストを調整するために、Pod がメモリと CPU のリソースをどのように割り当てるべきかを設定できます。
ノードに十分なリソースがない場合、Podはプリエンプションやノードプレッシャーによってevictedさせられるかもしれません。プロセスがOut Of Memory (OOM) になると、必要なリソースがないため強制終了されます。CPUの消費量が実際に制限された量よりも多い場合、そのプロセスはスロットルされ始めます。
しかし、KubernetesのPodがOOMやCPUスロットリングにどれだけ近づいているかを積極的に監視するにはどうしたらよいでしょうか。
Pod内のすべてのコンテナは、実行するためにメモリを必要とします。
Kubernetesのリミットは、Pod定義またはデプロイメント定義のいずれかで、コンテナごとに設定されます。
すべてのモダンなUnixシステムには、メモリを再利用する必要がある場合に備えて、プロセスをKillする方法があります。これは、エラー137または OOMKilledとしてマークされます。
State: Running
Started: Thu, 10 Oct 2019 11:14:13 +0200
Last State: Terminated
Reason: OOMKilled
Exit Code: 137
Started: Thu, 10 Oct 2019 11:04:03 +0200
Finished: Thu, 10 Oct 2019 11:14:11 +0200
このExit Code 137は、プロセスが許容量以上のメモリを使用し、終了させなければならなかったことを意味します。
これはLinuxに存在する機能で、カーネルはシステムで動作しているプロセスに対して oom_score という値を設定します。さらに、KubernetesがQuality of Serviceを許可するために使用する oom_score_adjという値の設定も可能になっています。また、 OOM Killerという機能もあり、プロセスを見直し、必要以上にメモリを使用しているプロセスを終了させることができます。
なお、Kubernetesでは、プロセスはこれらのリミットのいずれかに達する可能性があります：
リミットはリクエストよりも高くなることがあるため、すべてのリミットの合計がノード容量よりも高くなることがあります。これはオーバーコミット（overcommit）と呼ばれ、非常に一般的です。実際には、すべてのコンテナが要求以上のメモリを使用すると、ノードのメモリを使い果たすことがあります。これは通常、一部のメモリを解放するために一部のPodを亡くさせる原因となります。
Prometheusでnode exporterを使用する場合、 node_vmstat_oom_killと呼ばれるメトリクスが存在します。OOM killがいつ発生するかを追跡することは重要ですが、そのようなイベントが発生する前に先回りして可視化したいと思うかもしれません。
その代わりに、プロセスがKubernetesのリミットにどれだけ近いかを確認することができます。
(sum by (namespace,pod,container)
(rate(container_cpu_usage_seconds_total{container!=""}[5m])) / sum by
(namespace,pod,container)
(kube_pod_container_resource_limits{resource="cpu"})) > 0.8
CPUスロットリングは、プロセスが何らかのリソースリミットに到達しそうになったときに、プロセスを減速させる動作です。
メモリの場合と同様に、これらのリミットは次のようなものが考えられます。
次のようなアナロジーを考えてみてください。高速道路があり、そこそこ交通量があるとします。
ここでいうスロットルとは、渋滞のようなもので、最終的にはすべてのプロセスが動くが、すべてが遅くなることを表しています。
Kubernetesでは、CPUはシェアで処理されます。各CPUコアを1024個のシェアに分割し、Linuxカーネルのcgroups（コントロールグループ）機能を使って、実行中の全プロセスで分割します。
CPUが現在の全プロセスを処理できる場合は、何もする必要はありません。プロセスが100%以上のCPUを使用している場合、共有が行われるようになります。他のLinuxカーネルと同様に、KubernetesはCFS（Completely Fair Scheduler）メカニズムを使用しているため、より多くのシェアを持つプロセスがより多くのCPU時間を得ることになります。
メモリと違って、KubernetesはスロットリングのためにPodをKillすることはありません。
CPUの統計情報は、/sys/fs/cgroup/cpu/cpu.statで確認することができます。
リミットとリクエストの記事で見たように、プロセスのリソース消費を制限したい場合は、リミットやリクエストを設定することが重要です。とはいえ、実際のCPUサイズよりも大きな総リクエストを設定すると、すべてのコンテナが保証された量のCPUを持つことになるため、注意が必要です。
あるプロセスがKubernetesのリミットにどれだけ近づいているかを確認することができます：
(sum by (namespace,pod,container)(rate(container_cpu_usage_seconds_total
{container!=""}[5m])) / sum by (namespace,pod,container)
(kube_pod_container_resource_limits{resource="cpu"})) > 0.8
クラスターで起きているスロットリングの量を追跡したい場合、cadvisorは container_cpu_cfs_throttled_periods_total と container_cpu_cfs_periods_totalを提供します。この 2 つを使用すると、すべての CPU 期間でスロットリングの % を簡単に計算することができます。
リミットは、ノード内のリソースの最大上限を設定する方法ですが、プロセスがスロットルされたり、強制終了されたりする可能性があるため、慎重に扱う必要があります。
非常に低いリクエストを設定することで、CPUまたはMemoryのいずれかをプロセスに最低限付与すると思うかもしれません。しかし、kubelet は使用量がリクエスト数より多いPodを最初にevictさせるので、それらを最初にKillされるものとしてマークすることになります。
特定のPodをプリエンプション（ kube-scheduler が新しいPodを割り当てる必要があるとき）から保護する必要がある場合は、最も重要なプロセスにPriority Classを割り当ててください。
非現実的なリミットを設定したり、オーバーコミットしたりすると、プロセスがスロットルされ、パフォーマンスに影響を与えていることに気づかないことがあります。CPU使用率を積極的に監視し、コンテナとネームスペースの両方で実際のリミット値を把握しましょう。
CPUとMemoryのKubernetesリソース管理に関するチートシートをご紹介しました。これは、現在の記事と、同じシリーズのこれらの記事をまとめたものです。
Sysdig Monitorの新機能であるCost Advisorを使えば、Kubernetesのコストを最適化することができます。
アウトオブボックスのKubernetes Dashboardsを使用すれば、数回のクリックで十分に活用されていないリソースを発見することができます。
30日間無料でお試しください！
