クラスター サイズの見積もり - ノード数
次に、必要な仮想マシン (VM) ノードの種類と、実行する必要があるノードの数を判断する必要があります。
どのサイズの仮想マシンが必要でしょうか?
Azure Kubernetes Service (AKS) では、クラスター内の各ノードは Azure VM です。 VM には、さまざまな種類のアプリケーションの要求をサポートするために各種の仕様があります。 アプリケーションによって、高い処理能力が必要なもの、多くのメモリが必要なもの、高速なストレージが必要なものがあります。 VM のカテゴリとインスタンスは、アプリケーションのニーズを満たすように選ぶ必要があります。
VM の種類は、アプリケーションに応じた十分なメモリと処理能力を備えていることを確認する必要があります。 VM のすべてのメモリと処理能力がアプリケーションで使用できるわけではありません。 一部は、オペレーティング システムと Kubernetes システム コンポーネントのために必要になります。 AKS は、こうした主要なシステム コンポーネントが必要に応じて動作できるよう、一定量のメモリと処理能力を自動的に予約します。
AKS クラスターの一部としてデプロイされる既定の VM の種類は、"D2 v3 汎用仮想マシン" です。これは、8 GB のメモリを備えた 2 コアの VM です。 AKS によって、100 ミリコアのプロセッサと 3.55 GiB のメモリが予約され、残りの 1,900 ミリコア (1.9 コア) と 5.45 Gi のメモリはアプリケーション用に解放されます。
ヒント
予約済みプロセッサとメモリの量は、選択した VM の種類によって異なります。 VM のサイズが大きくなると、プロセッサとメモリの量は比例して小さくなります。
その他の考慮事項に、座礁リソースがあります。 3 つのアプリケーションを 1 つの D2 v3 ノードにデプロイするとします。 これらの各アプリケーションには、プロセッサの 600 ミリコアとメモリの 500Mi が必要です。 これらのアプリケーションをデプロイすると、100 ミリコアのプロセッサが残り、未使用メモリは約 2.05 GiB となります。 このアプリケーションの 4 番目のインスタンスがデプロイされるときには、100 ミリコアの残りでは不足が生じるため、そのインスタンスは新しいノードに送信する必要があります。 ただし、ノードには使用できない 2 GiB のメモリが存在しています。 そのメモリ リソースが、座礁と呼ばれます。
理想的な VM の選択肢は、リソースを座礁させることなくワークロードを実行するために十分な容量を備えたものです。 ワークロードのスケールアップおよびスケールダウンが動的な場合は、日常の使用シナリオをカバーできるだけでなく、必要に応じて柔軟にスケールアップするための十分なリソースが必要になります。
いくつのノードが必要ですか?
目的のアプリケーションは、常に使用可能であり、基盤になるノードの障害に対処できることが必要です。 複数のノードに分散された複数のアプリケーションのレプリカを使用することで復元性が得られます。
AKS には、同じ種類の VM のグループであるノード プールがあります。 複数のノード プールを使用できます。 たとえば、汎用 VM を含むノード プール、メモリが最適化された VM を備えたノード プール、GPU 搭載の VM を備えたノード プールを使用できます。 次に、ワークロードが適切なノード プールと VM の種類にデプロイされるようにするために、Kubernetes のネイティブ スケジューリング機能を使用できます。
ノード プールは、次の 2 つのモードのいずれかをサポートできます。システムまたはユーザー。 システム ノード プールは、Kubernetes クラスターの操作に不可欠となる重要なシステム ポッドを実行します。これには、ストレージ ドライバー、DNS、メトリック サーバーなどのサービスが含まれます。 ユーザー ノード プールでは、アプリケーションを実行します。
既定の構成では、AKS クラスターには単一のシステム ノード プールが含まれています。このノード プールが、すべてを実行するために使用されます。 必要に応じて、システム ノード プールまたはユーザー ノード プールを追加したり、ユーザー ノード プールでのみ実行するようにアプリケーション ポッドを構成したりできます。 重要なシステム ポッドはシステム ノード プールでのみ実行されます。 システム ノード プールとユーザー ノード プールを使用することで、正しく構成されていないアプリケーションが重要なシステム サービスの操作に影響を与えないようにし、クラスターに障害を発生させる可能性を防止できます。
Kubernetes では、必要に応じてノードを追加または削除することもできます。 この機能を使用する場合は、Kubernetes によるスケールアップを許容するノードの最大数に上限を定義する必要があります。 そのようにしてから、その最大数に沿ったネットワーク設計を計画します。 更新プロセスを正常に実行できるようにするには、クラスターごとにノードを 1 つ以上追加するよう考慮する必要があります。
ヒント
指定した時間に更新されるノードの数を設定できます。既定値は 1 です。 一度に複数のノードをアップグレードすると、クラスターのアップグレード全体にかかる時間が短縮される可能性があります。 計画の一環として、追加のノードを考慮する必要があります。
いくつのノードを実行する必要がありますか?
実行するノードの数を判断するには、アプリケーションのプロセッサ要件とメモリ要件について理解する必要があります。 開発チームが、パフォーマンス テストの結果とサービスに必要なプロセッサとメモリの量の詳細を提供します。 この結果には、ベースライン要件と、負荷の高い期間中の最大量が含まれます。
| サービス | プロセッサ: 最大/最小 | メモリ: 最大/最小 |
|---|---|---|
| Web サイト フロント エンド | 250m/1000m | 250Mi/1Gi |
| Identity API | 100m/500m | 250Mi/500Mi |
| Catalog API | 500m ～ 1000m | 1Gi/1Gi |
| Orders API | 100m ～ 1000m | 100Mi/1Gi |
| Orders Helper | 100m ～ 1000m | 100Mi/1Gi |
| Basket API | 100m ～ 1000m | 500Mi/500Mi |
| Marketing API | 250m ～ 750m | 500Mi/1Gi |
| Locations API | 100m ～ 500m | 100 Mi/500 Mi |
ヒント
- Kubernetes では、プロセッサの使用量がミリコア (1,000 分の 1 コア) 単位で測定されます。 そのため、100m はコアの 10 分の 1 に相当し、1000m は単一のプロセッサ コアに相当します。
- メモリはさまざまな方法で測定できます。 パフォーマンス テストの結果グラフの例では、Mi と Gi を使用します。Mi と Gi は、メガバイトとギガバイトの 2 つの等価の累乗です。 そのため、一般に 500Mi は 500 メガバイト、1Gi は 1 ギガバイトと呼ばれます。
ノードのサイズ設定
各サービスで実行する必要があるレプリカの最小数と、各サービスに必要なプロセッサ コアとメモリの最小数が決まりました。 この計算により、開始点として 1.5 コアと 2.8 Gi のメモリという数字が得られます。 アプリケーションが最大レプリカ数にスケール アップし、その最大のプロセッサ コア数とメモリ量を使用している場合は、53 コアと 50 GB のメモリが必要です。
このシナリオでは、ワークロードで CPU を集中的に使用します。 既定の D2 v3 汎用 VM を使用すると、このワークロードのプロセッサ要件を満たすために多数の仮想マシンが必要になります。 この構成を使用すると、VM 全体で大量のメモリが未使用になります。 コンピューティング集中型のワークロードを対象とした VM の種類を考えてみましょう。 たとえば、Fsv2 シリーズの VM では、プロセッサの要件を満たすために必要な VM が少なくなり、未使用メモリの量も少なくなります。
F8s v2 の VM には、8 コアと 16 GB のメモリが用意されています。 AKS のリソース予約により、ノードごとに 7820 ミリコアと 12.65Gi が提供されます。 最大スケールで実行するときには、ワークロードの処理に 7 つの VM が必要になります。
次に、ネットワークを見る必要があります。