Kubernetes ワーカーノードの数を計画するにはどうすればよいですか?

[[278523]]

概要

k8s クラスターの作業ノードを計画する際に最初に検討すべき質問は、どのタイプのサーバー (Linux) インスタンス ノードを使用する必要があるか、またいくつのノードが必要かということです。

クラスター容量

通常、k8s クラスターは、複数のサーバー (Linux) ノードを大きな「スーパー サーバー ノード」に抽象化したものと考えることができます。その合計計算能力 (CPU やメモリなど) は、構成するすべてのノードの能力の合計です。クラスター上で実行される一連のアプリケーションに、合計 8 個の CPU コアと 32 GB のメモリ容量を持つクラスターが必要な場合、次の図に、2 つの可能なインスタンス タイプと数量構成を示します。

ソリューション1: 2つの4コア16GBサーバーインスタンスをk8sワーカーノードとして使用する

ソリューション2: 4つの2コア8GBサーバーインスタンスをk8sワーカーノードとして使用する

どちらの解決策がより良いでしょうか?現時点ではほとんどの人が少し混乱していると思います。この疑問を解決するために、以下ではこれら 2 つの解決策の長所と短所について説明します。

解決策1

2つの4コア16GBサーバーインスタンスをk8sワーカーノードとして使用する

利点

1. 管理コストを削減

多数のコンピュータを管理するよりも、少数のコンピュータを管理する方が労力がかかりません。

2. ノードあたりのコストを削減する

より強力なマシンはより低性能のマシンよりも高価ですが、価格上昇は必ずしも直線的ではありません。たとえば、CPU コアが 10 個で RAM が 10 GB のコンピューターは、CPU コアが 1 個で RAM が 1 GB のコンピューター 10 台よりも安価になる場合があります。

3. リソースを大量に消費するアプリケーションの実行を許可する

8 GB のメモリを必要とする機械学習アプリケーションがある場合、1 GB のメモリしかないノードを持つクラスターでは実行できません。ただし、10 GB のメモリを持つノードを持つクラスターで実行できます。

デメリット

1. 各ノードには多数のポッドがある

各ポッドは、コンテナ ランタイム (Docker など)、kubelet、cAdvisor など、そのノードで実行されている Kubernetes エージェントにいくらかのオーバーヘッドをもたらします。

kubelet は、ノード上の各コンテナに対して定期的に生存および準備状況のプローブを実行します。コンテナが増えると、各反復で kubelet の作業が増えることになります。

cAdvisor はノード上のすべてのコンテナのリソース使用統計を収集し、kubelet はこの情報を定期的に照会して API に公開します。つまり、cAdvisor と kubelet は各反復でより多くの作業を行う必要があるということです。

ポッドの数が多くなると、システムの速度が低下したり、信頼性が低下したりする可能性があります。

2. 限定版

ノードの数が少ないと、アプリケーションのレプリケーションの有効度が制限される可能性があります。 5 つのレプリカで構成される高可用性アプリケーションがあり、ノードが 2 つしかない場合、アプリケーションの有効なレプリケーションの度合いは 2 に減少します。

3. 爆発半径の拡大

ノードの数が少ない場合、ノードの障害の影響は、ノードの数が多い場合よりも大きくなります。

4. 大きなズーム比

Kubernetes は、現在の需要に基づいてノードを自動的に追加または削除するクラウド インフラストラクチャ用のクラスター オートスケーラーを提供します。

解決策2

4 つの 2 コア 8GB サーバー インスタンスを k8s ワーカー ノードとして使用する場合。このアプローチでは、少数の大きなノードではなく、多数の小さなノードでクラスターを形成します。

このアプローチの長所と短所は何ですか?

多数の小さなノードを使用することによる利点は、主に、少数の大きなノードを使用することによる欠点と一致します。

利点

1. 爆発半径の縮小

100 個のポッドと 10 個のノードがある場合、各ノードには平均 10 個のポッドのみが含まれます。したがって、いずれかのノードに障害が発生した場合、影響を受けるポッドの数は少なくなります。

影響を受けるのは一部のアプリケーションのみであり、影響を受けるレプリカもおそらく少数であるため、アプリケーション全体が影響を受けることはない可能性が高いです。

2. 高い複製を可能にし、高い信頼性を実現する

Kubernetes スケジューラは、各レプリカを複数の異なるノードに割り当てることができるため、ノードに障害が発生した場合でも、影響を受けるレプリカは最大で 1 つであり、アプリケーションは引き続き利用できます。

デメリット

1. 多数のノード

ノードが小さい場合、特定のクラスター容量に到達するには当然より多くのノードが必要になり、多数のノードは Kubernetes コントロール プレーンにとって課題となる可能性があります。

たとえば、すべてのノードは他のすべてのノードと通信できる必要があるため、可能な通信パスの数はノード数の 2 乗に比例して増加し、そのすべてをコントロール プレーンで管理する必要があります。

2. システムオーバーヘッドの増加

Kubernetes は、コンテナ ランタイム Docker、kube-proxy、kubelet などの一連のシステム デーモンを各ワーカー ノードで実行します。これらのデーモンは、一緒に一定量のリソースを消費します。多数の小さなノードが使用される場合、これらのシステム コンポーネントによって使用されるリソースの割合が大きくなります。

3. リソースの使用率を削減する

より小さなノードを使用すると、ワークロードに割り当てるには小さすぎるリソース フラグメントが大量に発生し、リソースが無駄になる可能性があります。

4. 小規模ノードにおけるポッド制限

一部のクラウド インフラストラクチャでは、小さなノードで許可される Pod の最大数は、予想よりも制限されています。これは Amazon Elastic Kubernetes Service (EKS) の場合であり、ノードあたりのポッドの最大数はインスタンスタイプによって異なります。

結論は

では、クラスターでは少数の大きなノードを使用するべきでしょうか、それとも多数の小さなノードを使用するべきでしょうか?いつものように、明確な答えはありません!

アプリケーションに 10 GB のメモリが必要な場合は、小さなノードを使用しない方がよいでしょう。クラスター内のノードには少なくとも 10 GB のメモリが必要です。

アプリケーションが高可用性のために10倍のレプリケーションを必要とする場合、おそらく2ノードだけを使用するべきではありません。クラスターは少なくとも10ノードで構成する必要があります。