Azure Operator Nexus Kubernetes でのリソースの配置
Operator Nexus インスタンスは、顧客のオンプレミスにデプロイされます。 各インスタンスは、1 ラック以上のベア メタル サーバーで構成されます。
ユーザーは、Nexus Kubernetes クラスター (NKS) を作成するときに、Kubernetes コントロール プレーンと 1 つ以上のエージェント プールを構成する仮想マシン (VM) の数と Stock Keeping Unit (SKU) を指定します。 エージェント プールは、顧客のコンテナー化されたネットワーク機能が実行されるワーカー ノードのセットです。
Nexus プラットフォームは、各 NKS VM が起動するベア メタル サーバーを決定する役割を担います。
Nexus プラットフォームが Nexus Kubernetes クラスター VM をスケジュールする方法
Nexus はまず、NKS VM SKU のリソース要件をすべて満たすベア メタル サーバーの候補のセットを識別します。 たとえば、ユーザーがエージェント プールに NC_G48_224_v1 VM SKU を指定した場合、Nexus は、48 vCPU、224Gi の RAM などの使用可能な容量を持つベア メタル サーバーを収集します。
その後、Nexus は、スケジュールされているエージェント プールまたはコントロール プレーンの AvailabilityZones フィールドを調べます。 このフィールドが空でない場合、Nexus はベア メタル サーバーの候補一覧を、指定された可用性ゾーン (ラック) 内のサーバーのみにフィルター処理します。 この動作は、ハード スケジューリングの制約です。 フィルター処理された一覧にベア メタル サーバーがない場合、Nexus は、NKS VM をスケジュールせず、クラスターのプロビジョニングに失敗します。
Nexus が、NKS VM を配置するベア メタル サーバーの一覧を識別したら、次の並べ替え規則を適用した後、ベア メタル サーバーの 1 つを選択します。
この NKS クラスターの NKS VM を持たない可用性ゾーン (ラック) にベア メタル サーバーを優先します。 言い換えると、NKS クラスターの NKS VM を可用性ゾーンに分散させます。
同じ NKS クラスターの他の NKS VM を持たない単一の可用性ゾーン (ラック) 内のベア メタル サーバーを優先します。 言い換えると、可用性ゾーン内のベア メタル サーバー間で、NKS クラスターの NKS VM を分散させます。
NKS VM SKU が
NC_G48_224_v1またはNC_P46_224_v1の場合は、他の NKS クラスターのNC_G48_224_v1またはNC_P46_224_v1の NKS VM を既に収容しているベア メタル サーバーを優先します。 言い換えると、同じベア メタル サーバー上の異なる NKS クラスターで特大 VM をグループ化します。 このルールは、使用可能なコンピューティング リソースの断片化を減らすために、特大 VM を "ビン パック" します。
配置シナリオの例
次のセクションでは、Nexus ユーザーが Operator Nexus 環境に対して NKS クラスターを作成するときの動作について説明します。
ヒント: NKS KubernetesCluster リソースの
nodes.bareMetalMachineIdプロパティを調べるか、Azure portal の Kubernetes クラスター ノードの表示で [ホスト] 列を見ることで、NKS VM がどのベア メタル サーバーにスケジュールされたかを確認できます。
Operator Nexus 環境の例には、次の仕様があります。
- 16 台のベア メタル サーバーの 8 ラック
- 各ベア メタル サーバーには、2 つの Non-Uniform Memory Access (NUMA) セルが含まれています
- 各 NUMA セルには、48 CPU と 224Gi RAM が用意されています
空の環境
指定された容量を持つ空の Operator Nexus 環境を想定して、サイズの異なる Nexus Kubernetes クラスターを 3 つの作成します。
NKS クラスターにはこれらの仕様があるため、この演習では、ユーザーが次の順序で 3 つのクラスターを作成することを前提としています。
クラスター A
- コントロール プレーン、
NC_G12_56_v1SKU、3 カウント - エージェント プール #1、
NC_P46_224_v1SKU、24 カウント - エージェント プール #2、
NC_G6_28_v1SKU、6 カウント
クラスター B
- コントロール プレーン、
NC_G24_112_v1SKU、5 カウント - エージェント プール #1、
NC_P46_224_v1SKU、48 カウント - エージェント プール #2、
NC_P22_112_v1SKU、24 カウント
クラスター C
- コントロール プレーン、
NC_G12_56_v1SKU、3 カウント - エージェント プール #1、
NC_P46_224_v1SKU、12 カウント、AvailabilityZones = [1,4]
空の Operator Nexus 環境でクラスター A、B、C を起動した後に表示される内容をまとめた表はこちらです。
| クラスター | プール | SKU | 合計数 | 予想される # ラック数 | 実際の # ラック数 | ラックあたりの予想される # VM 数 | ラックあたりの実際の # VM 数 |
|---|---|---|---|---|---|---|---|
| A | コントロール プレーン | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| A | エージェント プール #1 | NC_P46_224_v1 |
24 | 8 | 8 | 3 | 3 |
| A | エージェント プール #2 | NC_G6_28_v1 |
6 | 6 | 6 | 1 | 1 |
| B | コントロール プレーン | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| B | エージェント プール #1 | NC_P46_224_v1 |
48 | 8 | 8 | 6 | 6 |
| B | エージェント プール #2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
| C | コントロール プレーン | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| C | エージェント プール #1 | NC_P46_224_v1 |
12 | 2 | 2 | 6 | 6 |
8 つのラックがあるため、各プールの VM は最大 8 つのラックに分散されます。 VM が 8 台を超えるプールでは、ラックごとに複数の VM を異なるベア メタル サーバーに分散する必要があります。
クラスター C エージェント プール #1 には 12 台の VM が AvailabilityZones [1, 4] に制限されているため、12 台のベア メタル サーバー上に 12 台の VM があり、ラック 1 と 4 にそれぞれ 6 台の VM が搭載されます。
異なるクラスターからの特大 VM (NC_P46_224_v1 SKU) は、同じベア メタル サーバーに配置されます (「Nexus プラットフォームが Nexus Kubernetes クラスター VM をスケジュールする方法」のルール #3 を参照)。
クラスター A、B、C を空の環境にデプロイした後に表示される可能性があるレイアウトの視覚化を次に示します。
ハーフフル環境
次に、ターゲット環境がハーフフル状態のときに別の NKS クラスターを起動する例を示します。 ターゲット環境は、クラスター A、B、および C がターゲット環境にデプロイされた後、ハーフフルになります。
クラスター D の仕様は次のとおりです。
- コントロール プレーン、
NC_G24_112_v1SKU、5 カウント - エージェント プール #1、
NC_P46_224_v1SKU、24 カウント、AvailabilityZones = [7,8] - エージェント プール #2、
NC_P22_112_v1SKU、24 カウント
クラスター A、B、および C を起動した後に存在するハーフフル状態の Operator Nexus 環境にクラスター D を起動した後に表示される内容をまとめた表はこちらです。
| クラスター | プール | SKU | 合計数 | 予想される # ラック数 | 実際の # ラック数 | ラックあたりの予想される # VM 数 | ラックあたりの実際の # VM 数 |
|---|---|---|---|---|---|---|---|
| D | コントロール プレーン | NC_G12_56_v1 |
5 | 5 | 5 | 1 | 1 |
| D | エージェント プール #1 | NC_P46_224_v1 |
24 | 2 | 2 | 12 | 12 |
| D | エージェント プール #2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
クラスター D エージェント プール #1 には 12 台の VM が AvailabilityZones [7, 8] に制限されているため、12 台のベア メタル サーバー上に 12 台の VM があり、ラック 7 と 8 にそれぞれ 6 台の VM が搭載されます。 これらの VM は、異なるクラスターの特大 VM を同じベア メタル サーバーにグループ化する並べ替え規則により、他のクラスターの特大 VM を収容するベア メタル サーバーにも配置されます。
クラスター D コントロール プレーン VM がラック 7 または 8 に配置されている場合、クラスター D エージェント プール #1 VM がそのクラスター D コントロール プレーン VM と同じベア メタル サーバーに配置されている可能性があります。 この動作は、エージェント プール #1 がラック 7 と 8 に "ピン留め" されているためです。 これらのラックの容量の制約により、スケジューラは同じ NKS クラスターのコントロール プレーン VM とエージェント プール #1 VM を併置します。
クラスター D のエージェント プール #2 には、8 つのラックごとに異なるベア メタル サーバー上に 3 台の VM があります。 容量の制約は、クラスター D のエージェント プール #1 がラック 7 と 8 にピン留めされていることによって発生しました。 そのため、クラスター D のエージェント プール #1 とエージェント プール #2 の VM は、ラック 7 と 8 の同じベア メタル サーバーに併置されます。
クラスター D をターゲット環境にデプロイした後に表示される可能性があるレイアウトの視覚化を次に示します。
ほぼフル環境
この例のターゲット環境では、8 つのラックのうち 4 つのラックの容量が満杯に近い状態です。 別の NKS クラスターを起動してみましょう。
クラスター E には、次の仕様があります。
- コントロール プレーン、
NC_G24_112_v1SKU、5 カウント - エージェント プール #1、
NC_P46_224_v1SKU、32 カウント
ターゲット環境でクラスター E を起動した後に表示される内容をまとめた表はこちらです。
| クラスター | プール | SKU | 合計数 | 予想される # ラック数 | 実際の # ラック数 | ラックあたりの予想される # VM 数 | ラックあたりの実際の # VM 数 |
|---|---|---|---|---|---|---|---|
| E | コントロール プレーン | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| E | エージェント プール #1 | NC_P46_224_v1 |
32 | 8 | 8 | 4 | 3、4、または 5 |
クラスター E のエージェント プール #1 は、8 つのラックすべてに不均等に分散されます。 ラック 7 とラック 8 では、クラスター A から D をスケジュールした後に、これらのラック内に特大 SKU VM の容量がなくなったため、予想される 4 台の NKS VM ではなく、エージェント プール #1 の 3 台の NKS VM が配置されます。ラック 7 とラック 8 には、エージェント プール #1 の 4 番目の特大 SKU の容量がないため、5 台の NKS VM が最も使用率の低い 2 つのラックに配置されます。 この例では、最も使用率の低いラックはラック 3 とラック 6 でした。
クラスター E をターゲット環境にデプロイした後に表示される可能性があるレイアウトの視覚化を次に示します。
ランタイム アップグレード中の配置
2024 年 4 月現在 (Network Cloud 2304.1 リリース)、ランタイム アップグレードはラックごとの戦略を使用して実行されます。 ラック 1 のベア メタル サーバーは、一度にすべて再イメージ化されます。 アップグレード プロセスは、すべてのベア メタル サーバーが正常に再起動し、ワークロードを受け取る準備ができたことを Nexus に伝えるまで一時停止します。
Note
ラック内のベア メタル サーバの一部のみを一度に再イメージ化するように Operator Nexus に指示できますが、デフォルトでは、ラック内のすべてのベア メタル サーバを並列して再イメージ化します。
個々のベア メタル サーバーが再イメージ化されると、すべての NKS VM を含む、そのベア メタル サーバーで実行されているすべてのワークロードの電源と接続が失われます。 NKS VM 上で実行されているワークロード コンテナーの電源と接続が失われます。 これらのワークロード コンテナーに到達できない状態が 1 分間続くと、NKS クラスターの Kubernetes コントロール プレーンは、対応するポッドを異常としてマークします。 ポッドが Deployment または StatefulSet のメンバーである場合、NKS クラスターの Kubernetes コントロール プレーンは、Deployment または StatefulSet の観測されたレプリカ数を目的のレプリカ数に戻すために、代替ポッドの起動を試みます。
新しいポッドは、残りの正常な NKS VM にポッド用の使用可能な容量がある場合にのみ起動します。 2024 年 4 月現在 (Network Cloud 2304.1 リリース)、新しい NKS VM は、再イメージ化中のベア メタル サーバー上の NKS VM を置き換えるために作成されません。
ベア メタル サーバーが正常に再イメージ化され、新しい NKS VM を受け入れることができたら、元々同じベア メタル サーバー上にあった NKS VM が、新しく再イメージ化されたベア メタル サーバー上で再起動されます。 その後、ワークロード コンテナーがこれらの NKS VM にスケジュールされ、ベア メタル サーバー上の NKS VM にポッドが存在していた Deployment または StatefulSet が復元される可能性があります。
Note
この動作は、NKS VM がベア メタル サーバーから "移動" していないように見える可能性がありますが、実際には、同一の NKS VM の新しいインスタンスが、再イメージ化する前と同じベア メタル サーバー名を保持する、新しく再イメージ化されたベア メタル サーバー上で起動されています。
ベスト プラクティス
Operator Nexus を使用する場合は、次のベスト プラクティスに留意してください。
- エージェント プールに
AvailabilityZonesを指定しないでください。 - より大きな NKS クラスターをより小さなクラスターより先に起動します。
- VM SKU サイズを小さくする前に、エージェント プールの数を減らしてください。
エージェント プールに AvailabilityZones を指定しないでください
上記の配置シナリオからわかるように、エージェント プールに AvailabilityZones を指定することが、同じ NKS クラスターの NKS VM が同じベア メタル サーバーに配置される主な理由です。 AvailabilityZones を指定することで、エージェント プールをラックのサブセットに "ピン留め" するため、他の NKS クラスターと同じ NKS クラスターの他のエージェント プール VM が配置されるラック セット内の潜在的なベア メタル サーバーの数を制限できます。
そのため、最初のベスト プラクティスは、エージェント プールに AvailabilityZones を指定しないことです。 エージェント プールを可用性ゾーンのセットにピン留めする必要がある場合は、発生する可能性のある不均衡を最小限に抑えるために、そのセットをできるだけ大きくしてください。
このベスト プラクティスの 1 つの例外は、エージェント プールに 2 つまたは 3 つの VM しかないシナリオがある場合です。 ランタイムのアップグレード中に可用性を高めるために、そのエージェント プールの AvailabilityZones を [1,3,5,7] または [0,2,4,6] に設定することを検討してください。
より大きな NKS クラスターをより小さなクラスターより先に起動する
2024 年 4 月および Network Cloud 2403.1 リリース以降、NKS クラスターは作成順にスケジュールされています。 ターゲット環境を最も効率的にパックするには、より大きな NKS クラスターを作成してから小さなクラスターを作成することをお勧めします。 同様に、大きなエージェント プールを小さなエージェント プールより先にスケジュールすることもお勧めします。
この推奨事項は、特大 NC_G48_224_v1 または NC_P46_224_v1 SKU を使用するエージェント プールで重要です。 これらの特大 SKU VM の数が最も多いエージェント プールをスケジュールすることで、他の NKS クラスター内のエージェント プールの他の特大 SKU VM が併置できる、より大きなベア メタル サーバーのセットが作成されます。
VM SKU サイズを小さくする前に、エージェント プールの数を減らす
NKS クラスターまたはエージェント プールを起動するときに容量の制約が発生した場合は、VM SKU サイズを調整する前にエージェント プールの数を減らします。 たとえば、VM SKU サイズが NC_P46_224_v1、24 のエージェント プールを持つ NKS クラスターを作成しようとした場合、リソース不足のために、NKS クラスターのプロビジョニングに失敗したと返されると、VM SKU サイズを NC_P36_168_v1 に変更し、エージェント プールを 24 のままで再度作成したくなるかもしれません。 ただし、ワークロード VM がベア メタル サーバ上の単一の NUMA セルに合わせる必要があるため、同じ要求で同様のリソース不足のエラーが発生する可能性があります。 VM SKU のサイズを小さくする代わりに、エージェント プールの数を 20 に減らすことを検討してください。 VM SKU のサイズを小さくした場合よりも、要求がターゲット環境のリソース容量に収まり、デプロイ全体の CPU コア数が増える可能性が高くなります。