Kubernetes クラスターの容量とリソースを管理する方法

[51CTO.com クイック翻訳] ご存知のとおり、システム リソースは無制限ではありません。大規模なクラスター・アズ・ア・サービスのシナリオでは、クラスター・リソースを慎重に計画して割り当てる必要があります。しかし、さまざまなソフトウェア プロジェクトでは、仮想化とコンテナ化によってリソースが自由に使用できる巨大なプールのように見えるようになると開発者が誤解していることがよくあります。たとえば、特に自動スケーリングが有効になっているクラスター上で、大量のリソースを必要とするアプリケーションを実行しようとすると、次のような画面が表示されることがあります。

どうやら、kubectl get を実行すると、5 つのポッドのみを実行したい場合でも、数十のポッドが削除されていることがわかります。この時点で、Kubernetes クラスター リソースを管理して、容量とリソースを自動的に割り当てることが必要になる場合があります。

2つの例

[[341211]]

上の図に示すように、16 個の仮想 CPU と 64 GB の RAM を備えた Kubernetes クラスターがあるとします。では、20GB のメモリを必要とする AI コンテナをスムーズに実行できるでしょうか?

クラスター内に 4 つのワーカーがあり、それぞれに 16 GB の使用可能なメモリが必要であると仮定します (実際には、DaemonSet とシステム サービスの両方が 1 つのノードで実行され、少量のリソースを占有する必要があるため、実際に使用可能なメモリは少なくなる可能性があります)。したがって、この場合、コンテナに 16 GB のメモリのみを割り当てると、スムーズな動作を保証することはできません。

実際、このような大規模なコンテナーをデプロイする場合だけでなく、他の複雑なデプロイを実行する場合、Helm チャートなどのすぐに使用できる製品を使用する場合でも (https://grapeup.com/blog/asp-net-core-ci-cd-on-azure-pipelines-with-kubernetes-and-helm/ を参照)、常にリソースの制限を考慮する必要があります。

別の例、つまり同じクラスターに Ceph をデプロイする例を見てみましょう。私たちの実装目標は、1TB のストレージ スペースを 10 個の OSD (オブジェクト ストレージ デーモン) と 3 個の ceph MON (モニター) に分割することです。これを 2 つのノードに配置し、残りの 2 つをそのストレージを使用する必要があるデプロイメント用に残しておきます。これは非常にスケーラブルなアーキテクチャになります。

ほとんどのユーザーが最初に考えることは、OSD の数を 10、MON の数を 3 に設定し、Ceph ポッドに許容値を追加し、テイントをノード 1 とノード 2 に一致させることです。すべての Ceph デプロイメントとポッドでは、nodeSelector がノード 1 と 2 のみをターゲットにするように設定されています。

下の図に示すように、Kubernetes は mon-1、mon-2、および 5 つの osd を最初のワーカーで実行し、mon-3 と別の 5 つの osd を 2 番目のワーカーで実行します。アプリケーションは大量のファイルを Ceph に素早く保存できます。

ダッシュボードを展開してレプリケーション プールを作成すると、使用可能な 1 TB のストレージと 10 個の OSD のステータスも視覚化できます。

しかし、しばらく実行してみると、実際に使用可能なストレージ容量は 400 GB しかなく、削除された OSD ポッドが多数出現し、同時に 4 つの OSD が実行されていることがわかりました。このため、初期の展開構成を再検討する必要があります。

制限と範囲

通常、13 個の Pod (そのうち 3 個のモニターがある場合があります) を実行しても、リソースをあまり消費しませんが、OSD の場合はそうではありません。 Ceph は大量のデータをメモリにキャッシュするため、使用頻度が高くなるほど、必要なリソースも多くなります。同時に、さまざまなストレージ コンテナーのデータ複製とバランス調整にも、一定量のスペースが消費されます。したがって、最初のデプロイメント後のメモリ割り当ては次のようになります。

数時間連続して操作すると、クラスターは次の状況になります。

ご覧のとおり、ポッドの約 50% が失われました。そして、これは最終状態ではありません。残りのコンテナに高スループットを目標とした場合、すぐにさらに多くのコンテナが失われることになります。つまり、Ceph クラスターに 32 GB を超えるメモリを構成する必要があるということですか?いいえ。制限を正しく設定している限り (https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-requests-and-limits-of-pod-and-container を参照)、単一の OSD が他のポッドから使​​用可能なメモリをすべて取得することはできません。

つまり、この場合、最も単純なアプローチは、mon 全体に 2GB のメモリを割り当てて予約し、mon ごとに 650MB の制限を設けることです。合計 30 GB のメモリを 10 個の OSD で割ります (下の図を参照)。

OSD に 15 GB のメモリを割り当て、各ポッドに 650 MB のメモリを構成したため、最初のノードには 15 + 2 * 0.65 = 16.3 GB が必要になります。さらに、同じノードで実行されている DaemonSet のログも考慮する必要があります。したがって、修正値は次のようになります。

サービス品質

制限と完全に一致する Pod のリクエストも設定した場合、Kubernetes は、次の図に示すように、そのような Pod を異なる方法で処理します。

この構成により、Kubernetes の QoS が保証済み (そうでない場合はバースト可能) に設定されます。 Guaranteed の Pod が削除されることはありません。同じリクエストと制限を設定することで、Kubernetes が Pod を移動または管理するかどうかに関係なく、Pod のリソース使用率を確保できます。これにより、スケジューラの柔軟性は低下しますが、展開方法全体の柔軟性は高まります。

環境内のリソースを自動的にスケーリングする

ミッションクリティカルなシステムの場合、必要なリソースを見積もり、クラスターのサイズを一致させ、適切な制限を設定するだけでは不十分です。場合によっては、水平方向の拡張を実現し、利用可能なワーカーの数を調整するために、より複雑な構成と固定されていないクラスター容量を使用する必要があります。

リソースが直線的に拡張されると仮定すると、最小クラスター容量と最大クラスター容量の両方を計画できます。ポッドがクラスターの水平方向および垂直方向の比例拡張を追跡できる場合、比例して縮小するときに他のポッドを「排除」する可能性があります。この問題を緩和するために、Kubernetes は Pod Priority と Pod Disruption Budget という 2 つの主要な概念を提案しています。

次に、テストシナリオの作成から始めましょう。今回は多数のノードは必要ありません。通常のインスタンス (永続的と呼ばれる) で構成されるノード グループと、プリエンプティブ/スポット インスタンスで構成されるノード グループの 2 つのノード グループを持つクラスターを作成するだけです。次の図に示すように、VM (既存ノード) の CPU 使用率が 0.7 (つまり 70%) を超えると、プリエンプティブ ノード グループが拡張されます。

プリエンプティブ インスタンスの利点は、同じパフォーマンスを持つ通常の VM よりも実装がはるかに簡単なことです。唯一の欠点は、そのライフサイクルが保証されないことです。つまり、インスタンスはメンテナンスの目的で「削除」されるか、クラウド プロバイダーがインスタンスが他の場所で必要であると判断した場合、24 時間後に「削除」される可能性があります。したがって、フォールト トレラントなステートレス ワークロードのみを実行できます。

では、なぜクラスター内に永続ノードが 1 つしかないのでしょうか?これは極端な状況に備えるためです。すべてのプリエンプティブ ノードが実行されていない場合、最小限のコンテナー セットを維持して、アプリケーションの操作性を管理および保証します。次の表は、このようなルーチンの構造を示しています。ノード セレクターを使用して、Redis マスターが永続ノード上で実行できるように構成できます。

ポッドの優先度

次に、Horizo​​ntal Pod Autoscaler (HPA) の例を見てみましょう。

フロントエンド：

後部：

ビデオコンバーター:

ビデオコンバーターとしての目標は、平均的なリソース使用量を削減することです。つまり、スケーリング ポリシーを確認すると、複数の変換キューがある場合、平均 CPU 使用率がすぐに 25% に達する可能性があり、その場合は新しい自動スケーリングが生成されます。たとえば、約 10 分間に 50 回のビデオ変換が必要な場合、コンバーターは 25 インスタンスにスケールアウトします。したがって、クラスター内の他のコンテナが削除されるのを回避するために、優先度カテゴリを作成できます (https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption を参照)。優先度の高いポッドは、スケジューラにとって値が高くなります。優先度の低いポッドは削除される可能性があります。

したがって、コンバーターに低い優先度を与えると、フロントエンドとバックエンドの Pod の方が重要であることを暗黙的に認識することになります。最悪の場合、ビデオコンバーターがクラスターから削除される可能性があります。

ポッド破壊予算

ポッドを制御およびスケジュールするためのより優れた方法として、ポッド中断バジェット (PDB) を使用すると、一度に最小数のポッドを構成できます。これは、Pod Priority のみを使用するよりも厳格であり、ノード リソースが枯渇するのを効果的に防ぎます。他のワーカーにポッドを再スケジュールするのに十分なスペースがない場合は、レプリカの数が割り当て可能な予約数よりも少なくならないようにします。

上記の表は最も基本的な構成を示しています。そのうち、フロントエンドのコピーの数は 2 未満ではありません。これを使用して、すべてのポッドに最小値を割り当て、リクエストを処理できるポッドが常に少なくとも 1 つまたは 2 つあることを確認できます。

これは、ポッドが自動的にスケーリングされ、クラスターがスケーリングされることを保証する最もシンプルで安全な方法です。中断予約を備えたコンテナの最小セットを構成する限り、全体的な安定性に影響を与えることなく、最小のクラスター容量とさまざまなリクエストの最小処理要件を満たすことができます。

この時点で、安定したソリューションを作成するために必要なコンポーネントがすべて揃っています。スケジューラのジョブを簡素化するために、PDB と同じ最小数のレプリカを持つように HPA を構成できます。同時に、クラスターの最大数に基づいて制限数がリクエスト数と同じであり、ポッドが削除されないことを確認する必要があります。具体的な構成は次の表のとおりです。

上記のスケジューラの柔軟性に基づいて、フロントエンドとバックエンドの負荷が低すぎるが、変換するデータの量が多い場合、コンバーターは自動的に 19 ～ 21 個のインスタンスをスケールアウトします。

自動スケーリングに関する注意事項

自動拡張に関しては、次の 2 つの点に注意する必要があります。

まず、クラウド サービス プロバイダーが仮想マシンを起動するのにかかる時間 (数秒の場合もあれば、数分かかる場合もあります) を判断できないため、自動スケーリングによってピーク負荷の問題を解決できるかどうかは保証できません。

次に、クラスターが縮小された場合、実行中のコンポーネントについては、アプリケーションの操作を中断することなく仮想マシンを効果的にシャットダウンできるように、スケジューラが負荷を他のワーカーにすばやく移動できるように、繰り返しテストを実施する必要があります。

Kubernetes クラスタ管理: サイズとリソース

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。