AKS デプロイ タイプ - Horizon Edge Gateway の要件

このページとそのサブセクションに含まれる情報は、AKS タイプの Horizon Edge Gateway デプロイを使用して第 1 世代ポッドを移行することを決定した場合に適用されます。

概要

これらのセクションでは、移行ウィザードを実行する前に満たす必要がある特定の AKS 関連の要件について説明します。

ここに記載の情報は、「デプロイ タイプを決定してその要件を満たす」セクションを読み、質問に答え、ポッドの移行に AKS タイプを使用することを決定したことを前提としています。

**重要：**AKS デプロイ タイプを使用する場合は、以下のセクションに記載の前提条件に加え、「第 1 世代の Horizon Cloud ポッドを移行するための前提条件」ページのセクションの前提条件も満たす必要があります。

特殊なケース - 他の接続されたネットワークを含むポッドの VNet に AKS が制限された IP アドレスが含まれていると判断した場合

「ポッドの VNet または接続されたネットワークに AKS 制限付き IP アドレスが含まれているかどうか判断する」セクションで説明されているように、AKS タイプを使用してデプロイするときに、第 1 世代ポッドの VNet またはその VNet に接続されているオンプレミス ネットワークに AKS が制限された IP アドレス範囲の IP アドレスが含まれている場合、AKS デプロイ タイプについて次のことを行う必要があります。

1. ポッドのサブスクリプションに、AKS が制限された範囲の IP アドレスを含まない別の VNet を設定します。
2. その VNet に新しい管理サブネットを作成し、サブネットに最小 CIDR /26 を設定します。
3. 次のページに従って、新しい VNet と管理サブネットが、必要なポートとプロトコルに対して Horizon Cloud サービスで必要なエンドポイントへのネットワーク通信を許可していることを確認します。
   • Microsoft Azure 環境に Horizon Edge Gateway をデプロイするために適切なポートと URL をアクセス可能にする
   • Microsoft Azure でのデプロイのための Horizon Cloud ポートとプロトコルの要件
4. 新しい VNet をポッドの既存の VNet とピアリングします。

上記の 4 つの手順が完了し、以下のセクションで説明する要件を満たしたら、その新しい管理サブネットと VNet を使用します。

注：

AKS が制限された次の IP アドレス範囲は回避する必要があります。

• 169.254.0.0/16
• 172.30.0.0./16
• 172.31.0.0/16
• 192.0.2.0/24

新しい VNet で上記の範囲を回避することに加えて、「AKS タイプ - AKS との競合を防ぐために必要な仮想 IP アドレス範囲を予約する」で説明されているように、自分とチームがデプロイの仮想 IP アドレス範囲に使用することを決定した CIDR の使用も回避する必要があります。

AKS タイプ - Azure リソース プロバイダの確認と新しい必須プロバイダの登録

AKS タイプの Horizon Edge Gateway デプロイには、Microsoft Azure サブスクリプションに特定のリソース プロバイダのセットが必要です。

第 1 世代ポッドのサブスクリプションで、次のリソース プロバイダがすべて Registered ステータスであることを確認します。

これらの一部は、第 1 世代ポッドのデプロイに必要なのと同じです。この表には、AKS デプロイ タイプに登録するために追加で必要なものが記載されています。

	リソース プロバイダ
Horizon Cloud AKS デプロイ タイプの場合に追加で新たに登録が必要なもの	Microsoft.ContainerService Microsoft.ManagedIdentity
第 1 世代のポッドの場合に以前に登録されていた Horizon Cloud で必要なもの	Microsoft.Authorization Microsoft.Compute Microsoft.KeyVault Microsoft.MarketplaceOrdering Microsoft.ResourceGraph Microsoft.Network Microsoft.Resources Microsoft.Security Microsoft.Storage

第 1 世代ポッドの Microsoft Azure サブスクリプションでリソース プロバイダを確認するには、次の手順を実行します。

1. Azure ポータルにログインし、ポッドのサブスクリプションを検索します。

2. サブスクリプション名をクリックし、（[リソース プロバイダ]）が表示されるまで下にスクロールします。

3. 上記の表でリソース プロバイダを探し、それぞれが （[登録済み]）ステータスを示していることを確認します。

   Azure ポータルを使用して、上記の表から、ステータスが NotRegistered のリソース プロバイダを登録します。

**重要：**登録済みのリソース プロバイダを登録解除しないでください。

ポッドのサブスクリプションで、Horizon Cloud Edge Gateway に必要なリソース プロバイダのステータスがすでに Registered であることがわかる場合があります。また、Microsoft.Billing など、Horizon Cloud サービスに必要なリソース プロバイダとは無関係なものが登録されている場合もあります。ステータスがこのように変更されるのは、標準の Microsoft Azure の動作の結果であり、通常はすべての Azure サブスクリプションに対して登録されたリソース プロバイダのセットがあります。

AKS タイプ - NAT ゲートウェイまたはルート テーブルの設定と管理サブネットへの関連付け

クラウド制御プレーンとの送信通信の場合、Horizon Edge Gateway デプロイの AKS タイプには、管理サブネットに関連付けられた NAT ゲートウェイまたはルート テーブルのいずれかの項目が必要です。

ポッドの Microsoft Azure サブスクリプションで、使用するサブスクリプションを作成し、ポッドの管理サブネットに関連付けます。

• NAT ゲートウェイ
• ルート テーブル(これはより高度な選択肢です。通常、ポッドの VNet に第 1 世代ポッドで使用されているルート テーブルがすでに存在する場合にのみ使用されます)

**重要：**いずれかを作成する場合は、AKS が制限された IP アドレスを持つ VNet を回避するために新しい管理サブネットを作成する必要がある場合は、ポッドの既存の管理サブネットまたは新しい管理サブネットのいずれか、適切な管理サブネットに関連付けます。

NAT ゲートウェイの使用 - NAT ゲートウェイの作成と管理サブネットへの関連付け

Microsoft Azure のドキュメントに従って、NAT ゲートウェイを作成するには、使用するパブリック IP アドレス、パブリック IP プリフィックス、またはその両方が必要です。

Azure ポータルの NAT ゲートウェイの作成ウィザードでは、選択する必要があります。次の手順では、NAT ゲートウェイに使用する新しいパブリック IP アドレスを作成することを選択します。

1. Azure ポータルにログインし、検索バーを使用して「NAT ゲートウェイ」を検索し、そのカテゴリを選択します。

   

2. [+ 作成] をクリックして [NAT ゲートウェイの作成] ウィザードを開始します。

3. NAT ゲートウェイの作成 ウィザードのこの最初の手順で、ポッドのサブスクリプションが選択されていることを確認し、NAT ゲートウェイが配置されるリソース グループを選択します。

4. NAT ゲートウェイに名前を付け、選択したリージョンがポッドの Azure リージョンであることを確認します。入力したら、クリックして [送信 IP アドレス] の手順に進みます。

   次のスクリーンショットは、NAT ゲートウェイに first-pod-migration という名前を付ける例を示します。Azure リージョン West US 2 にあります。

   

5. [送信 IP アドレス] の手順で、画面上の指示に従って、この NAT ゲートウェイにパブリック IP アドレスを使用するかパブリック IP アドレスのプリフィックスを使用するかを選択します。

   次のスクリーンショットは、この NAT ゲートウェイで使用する新しいパブリック IP アドレスを作成し、first-pod-NAT-gtway という名前を付ける手順を示します。

   この手順を完了したら、クリックしてウィザードの次の手順である [サブネット] に進みます。

   

6. ウィザードの [サブネット] 手順で、次のいずれかを実行します。

   • AKS が制限された IP アドレスを VNet に含めるのを回避しない場合は、ポッドの VNet とその管理サブネットを選択します。
   • それ以外の場合は、AKS が制限された IP アドレスを持つポッドの VNet を回避するために新しい VNet と管理サブネットを作成した場合は、新しい VNet と新しい管理サブネットを選択します。 次のスクリーンショットは、ポッドの VNet とその管理サブネットを選択し、サブネットをこの NAT ゲートウェイに関連付けて行うこの手順を示しています。

   

7. [確認と作成] をクリックします。

   検証に成功したら、[作成] をクリックして、この NAT ゲートウェイを作成します。

これで、NAT ゲートウェイが管理サブネットに関連付けられているため、移行ウィザードで を選択できます。

ルート テーブルを選択した場合 - ルート テーブルを作成して管理サブネットに関連付ける

このルート テーブルを、Virtual appliance または Virtual network gateway タイプのネクスト ホップを指すデフォルト ルート 0.0.0.0/0 で構成します。

1. Azure ポータルにログインし、検索バーを使用して「ルート テーブル」を検索し、そのカテゴリを選択します。

   

2. [+ 作成] をクリックして [ルート テーブルの作成] ウィザードを開始します。

3. ルート テーブルの作成 ウィザードのこの最初の手順で、ポッドのサブスクリプションが選択されていることを確認し、ルート テーブルを配置するリソース グループを選択します。

   **注：**ルート テーブルを VNet のリソース グループとは異なるリソース グループに配置し、第 1 世代ポッドのサービス プリンシパルがカスタム ロールを使用する場合、カスタム ロールには、このルート テーブルのリソース グループに対する Network Contributor 権限が必要であることに注意してください。第 1 世代の展開にカスタム ロールを使用することは一定ではありません。ルート テーブルのリソース グループに対してその権限が必要になる理由は、AKS 展開タイプが管理サブネットに関連付けられているルート テーブルにエントリを追加する必要があるためです。これらのエントリは、AKS タイプの Horizon Edge Gateway デプロイ内の Kubernetes ポッドの内部ルーティング用です。

4. ルート テーブルに名前を付け、選択したリージョンがポッドの Azure リージョンであることを確認します。

   [ゲートウェイ ルートを伝達する] には [いいえ] を選択します。

   次のスクリーンショットは、ルート テーブルに first-pod-migration という名前を付ける例を示します。Azure リージョン West US 2 にあります。

   

5. [ルート テーブルの作成] フォームに入力したら、[確認と作成] をクリックします。

   検証に成功したら、[作成] をクリックして、このルート テーブルを作成します。

6. 次に、新しく作成されたルート テーブルに移動して、Virtual network gateway または Virtual appliance タイプのネクスト ホップを指すデフォルト ルート 0.0.0.0/0 で構成します。

   AKS はこれら 2 つのネクスト ホップ タイプのみをサポートするため、Horizon Edge Gateway デプロイの AKS タイプではこれらの 2 つが特にサポートされます。

   Virtual Appliance は通常、ポッドの VNet とパブリック インターネット間の送信トラフィックのフローを制御する Azure Network Virtual Appliance (NVA) がある場合に使用されます。

   ルートの追加 フォームでは、送信インターネット接続を提供できる NVA の IP アドレスを指定する必要があります。

   管理サブネット(Horizon Edge Gateway のデプロイ先)から IP アドレスにアクセスできることを確認する必要があります。この NVA では、Horizon Cloud 環境が AKS デプロイ タイプで必要とするエンドポイントへのトラフィックを許可する必要があります。

7. [ルート] をクリックし、[+ 追加] をクリックしてそのデフォルト ルートを追加します。

   次のスクリーンショットは、この手順を示しています。この図では [ネクスト ホップ タイプ] メニューが展開され、サポートされている選択肢 Virtual network gateway と Virtual appliance が表示される場所が示されています。また、ルートの名前と 0.0.0.0/0 宛先 IP アドレスを入力しました。

   

   次のスクリーンショットは、Virtual Network Gateway のネクスト ホップが入力された [ルートの追加] フォームを示します。

   

8. [追加] をクリックして、このルートをルート テーブルに追加します。

9. 次に、[サブネット] および [+ 関連付け] をクリックして、新しいルート テーブルを管理サブネットに関連付けます。

   次のスクリーンショットは、この手順を示しています。次に従って、適切な VNet と管理サブネットを選択します。

   • AKS が制限された IP アドレスを VNet に含めるのを回避しない場合は、ポッドの VNet とその管理サブネットを選択します。
   • それ以外の場合は、AKS が制限された IP アドレスを持つポッドの VNet を回避するために新しい VNet と管理サブネットを作成した場合は、新しい VNet と新しい管理サブネットを選択します。

10. サブネットを選択したら、[OK] をクリックします。

これで、ルート テーブルが管理サブネットに関連付けられているため、移行ウィザードで を選択できます。

AKS タイプ - ユーザーが割り当てた管理対象 ID を作成し、必要なロール権限を割り当てる

AKS タイプの Horizon Edge Gateway デプロイを使用する場合、ポッドの Microsoft Azure サブスクリプションにはユーザーが割り当てた管理対象 ID が必要です。

ユーザーまたは IT チームは、Azure ポータルを使用してこの ID を作成および構成できます。

ユーザーが割り当てた管理対象 ID は、次の特性で構成する必要があります。

• VNet のリソース グループの範囲における Network Contributor ロール。該当する VNet は次のいずれかです。
  • AKS が制限された IP アドレスを VNet に含めなくても、ポッドの VNet を使用できます。
  • それ以外の場合は、AKS が制限された IP アドレスを持つポッドの VNet を回避するために新しい VNet を作成した場合、その VNet。
• ポッドの Microsoft Azure サブスクリプションの範囲における Managed Identity Operator ロール。

AKS 展開タイプでこの管理対象 ID が必要になる理由は、デプロイされたゲートウェイ内の Azure Kubernetes Service (AKS) クラスタが Azure リソースにアクセスするために ID を必要とするためです。したがって、移行ワークフローがこのタイプを展開するには、この ID が必要です。

ユーザー割り当て管理対象 ID の作成

1. Azure ポータルにログインし、検索バーを使用して「ユーザー割り当て」を検索し、[ユーザーが割り当てた管理対象 ID] の結果を選択します。

   次のスクリーンショットは、ポータルで検索するこの手順を示しています。

   

2. [ユーザーが割り当てた管理対象 ID] の検索結果をクリックすると、[ユーザーが割り当てた管理対象 ID の作成] ウィザードが起動します。

   ポッドのサブスクリプションと、作成後にこの ID リソースを保存するリソース グループを選択します。

   ポッドの Azure リージョンを選択し、このユーザー割り当ての管理対象 ID の名前を入力します。

   次のスクリーンショットは、この手順を示しています。一部はプライバシーのために編集されています。ここでは、ユーザーが割り当てた管理対象 ID に AKS-Edge-identity という名前を付けました。

   

3. [確認と作成] をクリックして、ウィザードの最後の手順に移動します。

4. 情報を確認し、[作成] をクリックしてウィザードを完了し、ユーザーが割り当てた管理対象 ID を作成します。

   このスクリーンショットは、[作成] をクリックする前の最後の手順を示しています。

   

5. 次のセクションの説明に従って、新しく作成された ID にロール権限を追加します。

必要なロール権限の割り当て - Azure プレビュー方法

このセクションの手順では、Azure プレビュー手順を使用して、管理対象 ID にロールを割り当てる方法について説明します。以下の手順に従って、ユーザーが割り当てた管理対象 ID の [Azure ロールの割り当て] 領域を表示したときに [+ ロールの割り当ての追加 (プレビュー)] ボタンが表示されない場合は、代わりに、次のセクションにある代替方法を使用してロール権限を割り当てることができます。

ユーザー割り当ての管理対象 ID に追加する権限は次のとおりです。

ロール権限	範囲
Managed Identity Operator ロール	ポッドの Microsoft Azure サブスクリプション
Network Contributor ロール	VNet のリソース グループ。該当する VNet は次のいずれかです。 AKS が制限された IP アドレスを VNet に含めるのを回避しない場合、ポッドの VNet のリソース グループ。 それ以外の場合は、AKS が制限された IP アドレスをポッドの VNet に含めるのを回避するために新しい VNet を作成した場合、その VNet のリソース グループ。

注：Microsoft の RBAC ドキュメントによると、Azure ロールを割り当てるには Microsoft.Authorization/roleAssignments/write アクセス権限が必要です。

1. Azure ポータルで、新しく作成したユーザーが割り当てた管理対象 ID に移動し、[ロールの割り当ての追加 (プレビュー)] フォームが表示されるまで、[Azure ロールの割り当て] および [ロールの割り当ての追加 (プレビュー)] をクリックします。

   次のスクリーンショットは、その手順を示しています。

   

2. [ロールの割り当ての追加 (プレビュー)] フォームで、[範囲] に [サブスクリプション] を選択し、ポッドのサブスクリプションを選択して、Managed Identity Operator の [ロール] を選択します。

   

3. [保存] をクリックして、ID へのその Managed Identity Operator ロールの割り当てを保存します。

4. [更新] をクリックすると、新しく追加されたロールが一覧表示されます。

   

5. [ロールの割り当ての追加 (プレビュー)] をクリックして、[ロールの割り当ての追加 (プレビュー)] フォームを再度開きます。

6. 今回は、[範囲] に [リソース グループ] を選択し、該当する VNet のリソース グループを選択して、Network Contributor の [ロール] を選択します。

   

7. [保存] をクリックして、ID へのその Network Contributor ロールの割り当てを保存します。

8. [更新] をクリックすると、新しく追加されたロールが表示されます。次に、2 つのロールを一覧表示します。

   

これで、必要なユーザーが割り当てた管理対象 ID が取得され、AKS デプロイ タイプに必要なロール権限を持つようになりました。

必要なロール権限を割り当てる別の方法

ユーザーが割り当てた管理対象 ID の [Azure ロールの割り当て] 領域を表示したときに [+ ロールの割り当ての追加 (プレビュー)] ボタンが表示されない場合は、この代替方法を使用してロール権限を割り当てることができます。

ユーザー割り当ての管理対象 ID に追加する権限は次のとおりです。

ロール権限	範囲
Managed Identity Operator ロール	ポッドの Microsoft Azure サブスクリプション
Network Contributor ロール	VNet のリソース グループ。該当する VNet は次のいずれかです。 AKS が制限された IP アドレスを VNet に含めるのを回避しない場合、ポッドの VNet のリソース グループ。 それ以外の場合は、AKS が制限された IP アドレスをポッドの VNet に含めるのを回避するために新しい VNet を作成した場合、その VNet のリソース グループ。

注：Microsoft の RBAC ドキュメントによると、Azure ロールを割り当てるには Azure の userID に Microsoft.Authorization/roleAssignments/write アクセス権限が必要です。

1. まず、ポッドのサブスクリプションの範囲に Managed Identity Operator 権限を追加します。

   1. Azure ポータルで、サブスクリプションに移動します。

   2. そのサブスクリプションのページで、[アクセス管理 (IAM)] をクリックし、[ロールの割り当て] タブをクリックします。

      

   3. [+ 追加] > [ロールの割り当ての追加] をクリックします。

      

      [ロールの割り当ての追加] ウィザードが表示されます。

   4. このウィザードの [ロール] タブで、Managed Identity Operator ロールを検索して選択します。[次へ] をクリックする前に、その行が選択されていることを確認します。

      

   5. [次へ] をクリックして [メンバー] タブに移動します。

   6. [メンバー] タブで、[管理対象 ID] を選択し、[+ メンバーの選択] を選択すると、[管理対象 ID の選択] フォームが表示されます。

      次の手順では、サンプルのスクリーンショットを示します。

   7. [管理対象 ID の選択] フォームの [管理対象 ID] メニューで、[ユーザーが割り当てた管理対象 ID] を選択します。

      

   8. 次に、作成したユーザーが割り当てた管理対象 ID を選択し、[選択] ボタンをクリックして [メンバー] タブに追加します。

      

   9. 次に [確認と割り当て] をクリックして、ウィザードの [確認と割り当て] タブに移動します。

      

   10. [確認と割り当て] タブで、最後の [確認と割り当て] ボタンをクリックして、サブスクリプション範囲での ID へのこのロールの割り当てを完了します。

       

2. 次に、Network Contributor 権限を VNet のリソース グループの範囲に追加します。

   1. Azure ポータルで、該当する VNet のリソース グループに移動します。該当する VNet は次のいずれかです。

      • AKS が制限された IP アドレスを VNet に含めるのを回避しない場合、ポッドの VNet のリソース グループ。
      • それ以外の場合は、AKS が制限された IP アドレスをポッドの VNet に含めるのを回避するために新しい VNet を作成した場合、その VNet のリソース グループ。

   2. そのリソース グループのページで、サブスクリプションの権限に対して上記と同様の手順を使用します。

      [アクセス管理 (IAM)] をクリックし、[ロールの割り当て] タブをクリックします。

      このスクリーンショットは、hcsvnet-RG という名前の VNet のリソース グループに対するこの手順を示しています。

      

   3. [+ 追加] > [ロールの割り当ての追加] をクリックします。[ロールの割り当ての追加] ウィザードが表示されます。

   4. このウィザードの [ロール] タブで、Network Contributor ロールを検索して選択します。[次へ] をクリックする前に、その行が選択されていることを確認します。

      

   5. 次に、他の権限についても同じように、[次へ] をクリックして [メンバー] タブに移動し、[管理対象 ID] を選択してから [+ メンバーの選択] を選択します。これにより、[管理対象 ID の選択] フォームが表示されます。

      

   6. [管理対象 ID の選択] フォームの [管理対象 ID] メニューで、[ユーザーが割り当てた管理対象 ID] を選択します。

   7. 次に、作成したユーザーが割り当てた管理対象 ID を選択し、[選択] ボタンをクリックして [メンバー] タブに追加します。

      

   8. ウィザードの [確認と割り当て] タブに移動し、[確認と割り当て] ボタンをクリックして、VNet のリソース グループの範囲での ID へのこのロールの割り当てを完了します。

      このスクリーンショットは、hcsvnet-RG という名前の VNet のリソース グループに対するこの手順を示しています。

      

これで、必要なユーザーが割り当てた管理対象 ID が取得され、AKS デプロイ タイプに必要なロール権限を持つようになりました。

ユーザーが割り当てた管理対象 ID に 2 つのロールがあることを確認するには、Azure ポータルで ID に移動し、その Azure ロールの割り当てページを表示します。

次のスクリーンショットは、Azure ロールの割り当てにリストされている 2 つのロールを持つユーザーが割り当てた管理対象 ID を示しています。

AKS タイプ - AKS との競合を防ぐために必要な仮想 IP アドレス範囲を予約する

この情報は、Horizon Edge Gateway デプロイの AKS タイプを使用してポッドを移行することを決定した場合に適用されます。AKS デプロイ タイプでは、選択した IP アドレス管理方法（IP アドレス管理システム）で一部の仮想 IP アドレス範囲を予約する必要があります。

概要

これらの範囲は、Horizon Edge Gateway の AKS タイプのみを使用するために予約される仮想 IP アドレス範囲です

設計上、Kubernetes は Horizon Edge Gateway 内の Kubernetes クラスタ内に仮想ネットワークを作成します。

これらの仮想ネットワークは、クラスタ内で実行されるコンテナをホストします。

これらの範囲が Edge の内部にある場合、これらの範囲を予約する必要がある理由

これらの範囲を予約する目的は、ネットワーク空間内の他のマシンがそれらの IP アドレスを割り当てて使用できないようにすることです。

Edge の Kubernetes クラスタの仮想ネットワークは Horizon Edge Gateway の内部にあり、実際には管理ネットワーク上にありませんが、クラスタの仮想ネットワークは Azure VNet の管理サブネットに接続します。

AKS クラスタの外部で実行されるサービスは、AKS-cluster-internal ネットワークにトラフィックをルーティングします。たとえば、VDI デスクトップの Horizon Agent は、この AKS クラスタで実行されているサービスにデータを送信する必要があります。

したがって、範囲が予約されておらず、ネットワーク上の別のマシンに範囲から IP アドレスが割り当てられると、ルーティングに影響を与え、AKS クラスタ内部ネットワークへの必要なサービス トラフィックで競合が発生する可能性があります。

ポッドの移行の前に IP アドレス管理システムの IP アドレス範囲を予約することで、このような潜在的な競合を回避できます。

これらの範囲のサブネットを作成する必要がありますか?

いいえ、これらの範囲のサブネットを作成する必要はありません。

これらの仮想 IP アドレス範囲は、移行プロセスの一環として Horizon Edge がデプロイされると、Horizon Edge Gateway の AKS クラスタの仮想ネットワーク内に存在します。

ポッドの移行では、予約された範囲を知る必要がありますか?

はい。AKS 展開タイプを選択する予定がある場合は、その展開の目的のために自分とチームが予約した範囲を把握しておく必要があります。

移行ウィザードのユーザー インターフェイスでは、[サービス CIDR] と [ポッド CIDR] という名前のフィールドに 2 つの IP アドレス範囲 (CIDR) を入力する必要があります。

したがって、移行ウィザードを実行する前に、自分とチームが予約する範囲を決定する必要があります。

予約する必要がある範囲のタイプ

Horizon Edge Gateway の AKS タイプでは、使用するために 2 つの仮想 IP アドレス範囲を予約する必要があります。

• [サービス CIDR] の場合は最小 /27 の CIDR 範囲
• [ポッド CIDR] の場合は最小 /21 の CIDR 範囲

これら 2 つの IP アドレス範囲が重複したり、互いに衝突したりすることはできません。

**重要：**Azure のドキュメントに従って、これらの CIDR では次の AKS が制限された範囲を使用しないようにしてください。

• 169.254.0.0/16
• 172.30.0.0./16
• 172.31.0.0/16
• 192.0.2.0/24

予約する IP アドレス範囲	詳細
サービス CIDR	[サービス CIDR] の IP アドレス範囲を決定し、他のマシンがその範囲の IP アドレスを使用できないように、IP アドレス管理でその IP アドレス空間を予約します。/27 以上の範囲が必要です。 注意：前述のように、これは仮想 IP アドレス範囲であり、この範囲のサブネットを作成する必要はありません。ネットワーク内の他のマシンにこれらのアドレスが割り当てられないようにする必要があります。 IP アドレス範囲を決定する場合は、次の点に注意してください。 この範囲に対して決定した IP アドレスがそのネットワークで他のマシンまたはアイテムによって使用されていないことを確認します。 AKS クラスタの仮想ネットワークは管理ネットワークに接続するため、他のマシンがこれらのアドレスを使用している場合、競合が発生する可能性があります。 この CIDR 範囲のアドレスが、ネットワーク内の他の主要な IP アドレス（DNS サーバ IP アドレス、Active Directory サーバ IP アドレス、管理サブネットに接続されている第 1 世代のデプロイの Unified Access Gateway インスタンスで使用されている IP アドレスなど）と競合しないことを確認してください。 Horizon Edge の AKS タイプのこの CIDR の目的は、この仮想 IP アドレス範囲のアドレスが Edge の AKS クラスタ内で実行されているサービスに割り当てられる点です。
ポッド CIDR	[ポッド CIDR] の IP アドレス範囲を決定し、他のマシンがその範囲の IP アドレスを使用できないように、IP アドレス管理でその IP アドレス空間を予約します。/21 以上の範囲が必要です。 注意：前述のように、これは仮想 IP アドレス範囲であり、この範囲のサブネットを作成する必要はありません。ネットワーク内の他のマシンにこれらのアドレスが割り当てられないようにする必要があります。 IP アドレス範囲を決定する場合は、次の点に注意してください。 この範囲に対して決定した IP アドレスがそのネットワークで他のマシンまたはアイテムによって使用されていないことを確認します。 AKS クラスタの仮想ネットワークは管理ネットワークに接続するため、他のマシンがこれらのアドレスを使用している場合、競合が発生する可能性があります。 この CIDR 範囲のアドレスが、ネットワーク内の他の主要な IP アドレス（DNS サーバ IP アドレス、Active Directory サーバ IP アドレス、管理サブネットに接続されている第 1 世代のデプロイの Unified Access Gateway インスタンスで使用されている IP アドレスなど）と競合しないことを確認してください。 Horizon Edge の AKS タイプでのこの CIDR の目的は、この仮想 IP アドレス範囲のアドレスが Edge の AKS クラスタ内で実行されているサービスに割り当てられる点です。 AKS クラスタのノード数に関連しているため、/21 の範囲サイズが必要です。各 AKS クラスタ ノードには、この範囲から 256 個の IP アドレスが事前に割り当てられます。