Kubernetes ワーカー ノード: 多数の小規模なノードですか、それとも複数の大きなノードですか?

Kubernetes クラスターを作成するとき、構成するワーカー ノードの数とタイプは何ですか?という疑問が生じることがあります。 オンプレミス クラスターにはどちらが適していますか? いくつかの強力なサーバーを購入するのと、データ センターで十数台の古いマシンを使用するのとではどちらが良いでしょうか? クラウド内に XNUMX つのシングルコア インスタンスを使用するのと、XNUMX つのクアッドコア インスタンスを使用するのはどちらが良いでしょうか?

これらの質問に対する答えは記事の中にあります。 Daniel Weibel 氏、ソフトウェア エンジニア、Learnk8s 教育プロジェクト教師 コマンドの翻訳では Mail.ru の Kubernetes aaS.

クラスター容量

一般に、Kubernetes クラスターは大規模な「スーパーノード」と考えることができます。 その総計算能力は、すべての構成ノードの能力の合計です。

希望するクラスター容量の目標を達成するには、いくつかの方法があります。 たとえば、一連のアプリケーションには非常に多くのリソースが必要となるため、合計 8 つのプロセッサ コアと 32 GB の RAM の容量を持つクラスターが必要です。 その後、16 GB のメモリを備えた 8 つのノード、または XNUMX GB のメモリを備えた XNUMX つのノード、XNUMX つのクアッドコア プロセッサまたは XNUMX つのデュアルコア プロセッサをインストールできます。

クラスターを作成する方法は XNUMX つだけあります。

どちらのオプションでも同じ容量のクラスターが生成されますが、下部の構成には XNUMX つの小さなノードがあり、上部の構成には XNUMX つの大きなノードがあります。

どちらのオプションが良いですか？

この質問に答えるために、両方のオプションの利点を見てみましょう。 表にまとめてみました。

いくつかの大規模なノード

多数の小さなノード

より簡単なクラスター管理 (オンプレミスの場合)

スムーズな自動スケーリング

安価 (オンプレミスの場合)

価格は少し異なります（クラウド内）

リソースを大量に消費するアプリケーションを実行できる

完全なレプリケーション

リソースがより効率的に使用されます (システム デーモンのオーバーヘッドが減少します)
より高いクラスター耐障害性

ここではワーカー ノードについてのみ説明していることに注意してください。 メイン ノードの数とサイズの選択は、まったく別のトピックです。

それでは、表の各ポイントについて詳しく説明していきます。

最初のオプション: 複数の大規模ノード

最も極端なオプションは、クラスター容量全体に対して 16 つのワーカー ノードを使用することです。 上の例では、これは 16 個の CPU コアと XNUMX GB の RAM を備えた単一のワーカー ノードになります。

プロたち

プラスその 1. 管理が容易になる
フリート全体よりも少数のマシンを管理する方が簡単です。 アップデートや修正の展開がより速くなり、同期も簡単になります。 失敗の絶対数も少なくなります。

上記のすべてはハードウェアやサーバーに適用され、クラウド インスタンスには適用されないことに注意してください。

クラウドでは状況が異なります。 そこでの管理はクラウド サービス プロバイダーによって行われます。 したがって、クラウド内の XNUMX 個のノードを管理することは、XNUMX つのノードを管理することとそれほど変わりません。

クラウド内のポッド間のトラフィック ルーティングと負荷分散 自動的に実行される: インターネットからのトラフィックはメイン ロード バランサーに送信され、メイン ロード バランサーはトラフィックをいずれかのノードのポートに転送します (NodePort サービスは各クラスター ノードのポートを 30000 ～ 32767 の範囲に設定します)。 kube-proxy によって設定されたルールは、ノードからポッドにトラフィックをリダイレクトします。 XNUMX つのノード上に XNUMX 個のポッドがある場合は次のようになります。

長所 #2: ノードあたりのコストが削減される
高性能な車は高価ですが、価格の上昇は必ずしも直線的ではありません。 つまり、10 GB のメモリを搭載した XNUMX コア サーバー XNUMX 台の方が、同じメモリを搭載したシングルコア サーバー XNUMX 台よりも通常は安価になります。

ただし、このルールは通常、クラウド サービスでは機能しないことに注意してください。 すべての主要なクラウド プロバイダーの現在の料金体系では、価格は容量に応じて直線的に増加します。

したがって、クラウドでは通常、より強力なサーバーを節約することはできません。

長所 #3: リソースを大量に消費するアプリケーションを実行できる
一部のアプリケーションでは、クラスター内に強力なサーバーが必要です。 たとえば、機械学習システムに 8 GB のメモリが必要な場合、1 GB のノードでは実行できませんが、少なくとも XNUMX つの大きなワーカー ノードが必要です。

コンズ

欠点その 1. ノードあたりのポッドの数が多い
同じタスクがより少ないノードで実行される場合、当然、各ノードにはより多くのポッドが存在します。

これは問題になる可能性があります。

その理由は、各モジュールが kubelet や cAdvisor だけでなく、コンテナー ランタイム (Docker など) にもオーバーヘッドをもたらすためです。

たとえば、kubelet は、ノード上のすべてのコンテナの存続可能性を定期的に調査します。コンテナの数が増えると、kubelet が実行する必要のある作業も増えます。

CAdvisor はノード上のすべてのコンテナのリソース使用量統計を収集し、kubelet は定期的にこの情報をクエリし、API 経由で提供します。 繰り返しになりますが、コンテナーが増えると、cAdvisor と kubelet の両方の作業が増えます。

モジュールの数が増えると、システムの速度が低下し、信頼性が損なわれる場合もあります。

Kubernetes リポジトリにはいくつかの 不平を言ったノード上のすべてのコンテナーの定期的な kubelet チェックには時間がかかりすぎるため、ノードは Ready/NotReady ステータス間を移動します。
このため、Kubernetes ノードごとに 110 個以下のポッドを配置することをお勧めします。 ノードのパフォーマンスに応じて、ノードごとにさらに多くのポッドを実行できますが、問題が発生するか、すべてが正常に動作するかを予測するのは困難です。 事前に作業をテストする価値があります。

デメリットその2. レプリケーションの制限
ノードが少なすぎると、アプリケーション レプリケーションの有効範囲が制限されます。 たとえば、高可用性アプリケーションに XNUMX つのレプリカがあり、ノードが XNUMX つしかない場合、アプリケーションの実効レプリケーションの次数は XNUMX に減ります。

XNUMX つのレプリカは XNUMX つのノードにのみ分散でき、そのうちの XNUMX つに障害が発生すると、複数のレプリカが一度にダウンします。

XNUMX つ以上のノードがある場合、各レプリカは別のノードで実行され、XNUMX つのノードに障害が発生すると、最大 XNUMX つのレプリカが削除されます。

したがって、高可用性要件には、クラスター内の特定の最小数のノードが必要になる場合があります。

デメリットその3. 失敗した場合の最悪の結果
ノードの数が少ない場合、各障害はより深刻な結果をもたらします。 たとえば、ノードが XNUMX つしかなく、そのうちの XNUMX つで障害が発生した場合、モジュールの半分がすぐに失われます。

もちろん、Kubernetes は障害が発生したノードから他のノードにワークロードを移行します。 ただし、その数が少ない場合は、十分な空き容量がない可能性があります。 その結果、障害が発生したノードを起動するまで、一部のアプリケーションは使用できなくなります。

したがって、ノードの数が増えるほど、ハードウェア障害の影響は少なくなります。

欠点 #4: 自動スケーリングの手順が増える
Kubernetes にはクラウド インフラストラクチャ用のクラスター自動スケーリング システムがあり、現在のニーズに応じてノードを自動的に追加または削除できます。 ノードが大きくなると、自動スケーリングがより唐突で扱いにくくなります。 たとえば、50 つのノードでノードを追加すると、クラスターの容量がすぐに XNUMX% 増加します。 そして、それらのリソースが必要ない場合でも、料金を支払う必要があります。

したがって、クラスターの自動スケーリングを使用する予定がある場合、ノードが小さいほど、より柔軟でコスト効率の高いスケーリングが得られます。

次に、多数の小規模ノードの長所と短所を見てみましょう。

XNUMX 番目のオプション: 多数の小さなノード

このアプローチの利点は、基本的に、複数の大きなノードを使用する反対のオプションの欠点から生まれます。

プロたち

長所 #1: 失敗の影響が少ない
ノードが増えるほど、各ノード上のポッドの数は減ります。 たとえば、XNUMX ノードあたり XNUMX 個のモジュールがある場合、各ノードには平均 XNUMX 個のモジュールが含まれることになります。

こうすることで、ノードの 10 つに障害が発生しても、ワークロードの XNUMX% のみが失われます。 おそらく、少数のレプリカのみが影響を受け、アプリケーション全体は動作し続けると考えられます。

さらに、残りのノードには障害が発生したノードのワークロードを処理するのに十分な空きリソースがある可能性が高いため、Kubernetes はポッドを自由に再スケジュールでき、アプリケーションは比較的早く機能状態に戻ります。

長所 #2: レプリケーションが優れている
十分なノードがある場合、Kubernetes スケジューラはすべてのレプリカに異なるノードを割り当てることができます。 こうすることで、ノードに障害が発生した場合でも、影響を受けるレプリカは XNUMX つだけとなり、アプリケーションは引き続き使用可能になります。

コンズ

デメリットその1.コントロールが難しい
ノードの数が多いと管理が難しくなります。 たとえば、各 Kubernetes ノードは他のすべてのノードと通信する必要があります。つまり、接続数は二次関数的に増加し、これらすべての接続を追跡する必要があります。

Kubernetes Controller Manager のノード コントローラーは、クラスター内のすべてのノードを定期的に調べて正常性をチェックします。ノードが増えると、コントローラーの負荷も増加します。

etcd データベースの負荷も増加しています - 各 kubelet および kube-proxy 呼び出し ウォッチャー etcd の場合 (API 経由)、etcd はオブジェクトの更新をブロードキャストする必要があります。

一般に、各ワーカー ノードはマスター ノードのシステム コンポーネントに追加の負荷を課します。

Kubernetes は、次のクラスタを正式にサポートしています。 ノード数は最大5000。 ただし、実際にはすでに 500 個のノードが存在します。 重大な問題を引き起こす可能性がある.

多数のワーカー ノードを管理するには、より強力なマスター ノードを選択する必要があります。 たとえば、クベアップ 自動的にインストールされます ワーカー ノードの数に応じて、マスター ノードの適切な VM サイズが決まります。 つまり、ワーカー ノードが増えれば増えるほど、マスター ノードの生産性も向上するはずです。

これらの特定の問題を解決するために、次のような特別な開発が行われています。 仮想Kubelet。 このシステムを使用すると、制限を回避して、膨大な数のワーカー ノードを含むクラスターを構築できます。

デメリット #2: 諸経費が増加します。
各ワーカー ノードで、Kubernetes は一連のシステム デーモンを実行します。これらには、コンテナー ランタイム (Docker など)、kube-proxy、kubelet (cAdvisor を含む) が含まれます。 これらは一緒に一定量のリソースを消費します。

小規模なノードが多数ある場合、各ノードにおけるこのオーバーヘッドの割合は大きくなります。 たとえば、単一ノード上のすべてのシステム デーモンが合わせて 0,1 CPU コアと 0,1 GB のメモリを使用すると想像してください。 10 GB のメモリを備えた 1 コア ノードが 1 つある場合、デーモンはクラスター容量の 10% を消費します。 一方、XNUMX GB のメモリを備えた XNUMX 個のシングルコア ノードでは、デーモンがクラスター容量の XNUMX% を占有します。

したがって、ノードが少ないほど、インフラストラクチャがより効率的に使用されます。

デメリットその3. リソースの非効率な使用
小規模なノードでは、残りのリソース チャンクが小さすぎてワークロードを割り当てることができないため、未使用のままになる場合があります。

たとえば、各ポッドには 0,75 GB のメモリが必要です。 ノードが 1 個あり、それぞれに 0,25 GB のメモリがある場合、XNUMX 個のポッドを実行でき、各ノードには XNUMX GB の未使用メモリが残ります。

これは、クラスター全体のメモリの 25% が無駄になっていることを意味します。

10 GB のメモリを備えた大規模なノードでは、これらのモジュールを 13 個実行できますが、未使用のフラグメントは 0,25 GB の XNUMX つだけになります。

この場合、メモリの 2,5% のみが無駄になります。

したがって、大規模なノードではリソースがより最適に使用されます。

大きなノードがいくつかあるのか、それとも小さなノードがたくさんあるのか?

それでは、クラスター内に少数の大きなノードと多数の小さなノードではどちらが優れているのでしょうか? いつものように、明確な答えはありません。 多くはアプリケーションの種類に依存します。

たとえば、アプリケーションが 10 GB のメモリを必要とする場合、より大きなノードを選択するのは明らかです。 また、アプリケーションが高可用性のために XNUMX 倍のレプリケーションを必要とする場合、たった XNUMX つのノードにレプリカを配置するリスクを冒す価値はほとんどありません。クラスター内には少なくとも XNUMX 個のノードが必要です。

中間の状況では、各オプションの長所と短所に基づいて選択を行ってください。 おそらく、いくつかの議論は他の議論よりもあなたの状況に関連しています。

また、すべてのノードを同じサイズにする必要はまったくありません。 最初に同じサイズのノードを試してから、それらに異なるサイズのノードを追加して、それらをクラスター内で結合することを妨げるものはありません。 Kubernetes クラスター内のワーカー ノードは完全に異種混合にすることができます。 したがって、両方のアプローチの利点を組み合わせてみることができます。

単一のレシピはなく、それぞれの状況には独自のニュアンスがあり、生産だけが真実を示します。

クラウドプラットフォームチームが翻訳を作成 Mail.ru クラウド ソリューション.

Kubernetes についてさらに詳しく: クラスターの管理とデプロイに役立つ 25 のツール.

出所： habr.com