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

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

これらの質問への答えは記事にあります ダニエル・ワイベル、教育プロジェクトLearnk8sのソフトウェアエンジニア兼教師 チームの翻訳において Mail.ru の Kubernetes aaS.

クラスター容量

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

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

クラスターを作成する方法は次の 2 つがあります。

どちらのオプションも同じ容量のクラスターを提供しますが、下部の構成には 4 つの小さいノードがあり、上部の構成には 2 つの大きいノードがあります。

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

この質問に答えるために、両方の選択肢の利点を見てみましょう。それを表にまとめました。

複数の大きなノード

たくさんの小さな結び目

クラスタ管理が容易になる（オンプレミスの場合）

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

安価（オンプレミスの場合）

価格はそれほど変わらない（クラウドの場合）

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

完全な複製

リソースがより効率的に使用される（システムデーモンのオーバーヘッドが減少）
クラスタのフォールトトレランスの向上

ここでは動作中のノードについてのみ説明していることに注意してください。マスターノードの数とサイズの選択はまったく別のトピックです。

それでは、表の各ポイントについてさらに詳しく説明しましょう。

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

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

プロたち

プラス＃1。制御が容易
車両全体を管理するよりも、少数の車両を管理する方が簡単です。更新と修正をより速く展開し、同期をより簡単にします。失敗の絶対数も少なくなります。

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

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

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

利点その2: ノードあたりのコストが低い
パワフルな車はより高価ですが、価格上昇は必ずしも直線的ではありません。つまり、10 GB のメモリを搭載した XNUMX コア サーバー XNUMX 台は、通常、同じ量のメモリを搭載した XNUMX 台のシングル コア サーバーよりも安価です。

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

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

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

コンズ

デメリット1: ノードあたりのポッドが多すぎる
同じタスクがより少ないノードで実行される場合、各ノードには当然より多くのポッドが存在します。

これは問題になるかもしれません。

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

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

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

モジュールの数が増えると、システムの速度が低下し、信頼性も低下する可能性があります。

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

マイナス2。レプリケーションの制限
ノードが少なすぎると、アプリケーションのレプリケーションの有効度が制限されます。たとえば、レプリカが 5 つあり、ノードが 2 つしかない高可用性アプリケーションがある場合、アプリケーションの有効なレプリケーション度は 2 に減少します。

5 つのレプリカは 2 つのノードにのみ分散でき、そのうちの 1 つに障害が発生すると、複数のレプリカが直ちに停止します。

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

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

マイナス3。失敗のより悪い結果
ノード数が少ないと、各障害の影響はより深刻になります。たとえば、ノードが 2 つしかなく、そのうちの 1 つに障害が発生した場合、モジュールの半分が一度に消えてしまいます。

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

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

マイナス4。自動スケーリングのステップが増える
Kubernetes は、クラウド インフラストラクチャ用のクラスター自動スケーリング システムを提供し、現在のニーズに基づいてノードを自動的に追加または削除できるようにします。ノードが大きくなると、自動スケーリングは不安定になり、不格好になります。たとえば、50 つのノードにノードを追加すると、クラスターの容量が一度に XNUMX% 増加します。そして、これらのリソースは、必要ない場合であっても料金を支払う必要があります。

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

ここで、多数の小さなノードを持つことの利点と欠点を見てみましょう。

オプション2: 多数の小さなノード

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

プロたち

メリット1: 失敗の影響が少ない
ノードの数が増えると、各ノード上のポッドの数は少なくなります。たとえば、10 個のノードに 100 個のモジュールがある場合、各ノードには平均 10 個のモジュールがあることになります。

したがって、10 つのノードに障害が発生した場合でも、失われるのはワークロードの XNUMX% のみです。影響を受けるレプリカは少数であり、アプリケーション全体は引き続き機能する可能性があります。

さらに、残りのノードには障害が発生したノードのワークロードを処理するのに十分な予備容量がある可能性が高いため、Kubernetes はポッドを自由に再スケジュールでき、アプリケーションは比較的迅速に復旧して実行されるようになります。

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

コンズ

マイナス1: 制御が難しい
ノードの数が多くなると、管理が難しくなります。たとえば、各 Kubernetes ノードは他のすべてのノードと通信する必要があるため、接続数は 2 乗的に増加し、これらの接続をすべて追跡する必要があります。

Kubernetes コントローラー マネージャーのノード コントローラーは、クラスター内のすべてのノードを定期的に検査して正常性を確認します。ノードの数が増えるほど、コントローラーの負荷も大きくなります。

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

一般に、各ワーカーノードは、メインノードのシステム コンポーネントに追加の負荷をかけます。

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

多数のワーカーノードを管理するには、より効率的なマスターノードを選択する必要があります。例えば、kube-up 自動的にインストールされます ワーカーノードの数に応じて、マスターノードの VM サイズを修正します。つまり、稼働ノードの数が増えるほど、メインノードの生産性も高まる必要があります。

これらの特定の問題を解決するために、次のような特別な開発があります。 仮想クベレット。このシステムにより、制限を回避し、膨大な数の作業ノードを持つクラスターを構築できます。

デメリット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 GB のメモリを搭載したノードが 0,25 個ある場合、XNUMX 個のポッドを実行でき、各ノードには XNUMX GB の未使用メモリが残ります。

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

10 GB のメモリを搭載した大規模ノードでは、これらのモジュールを 13 個実行しても、未使用の 0,25 GB のチャンクが XNUMX つだけ残ります。

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

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

少数の大きなノードか、それとも多数の小さなノードか?

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

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

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

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

唯一のレシピというものはなく、それぞれの状況によって微妙な違いがあり、真実は実際に作ってみることでしかわかりません。

クラウドプラットフォームチームによる翻訳 Mail.ru クラウド ソリューション.

Kubernetes の詳細: クラスターの管理と展開に役立つ25のツール.

出所： habr.com