AKS クラスターを委任する

Azure Private 5G Core サービス内のパケット コア インスタンスは、Azure Stack Edge (ASE) デバイス上の Arc 対応 Azure Kubernetes Service (AKS) クラスターで実行されます。 このハウツー ガイドでは、ASE 上の AKS クラスターを委任して、そこでパケット コア インスタンスをデプロイできるように準備する方法を示します。

重要

この手順は、Azure Private 5G Core にのみ使用する必要があります。 ASE 上の AKS は、他のサービスではサポートされていません。

前提条件

• プライベート モバイル ネットワークをデプロイするために前提となるタスクを完了する。
• Azure Stack Edge リソースのリソース グループに対する所有者アクセス許可が必要になります。

  Note

  Azure Stack Edge のリソース グループを書き留めておいてください。 この手順で作成される AKS クラスターとカスタムの場所は、このリソース グループに属している必要があります。

• Azure Stack Edge 仮想マシンのサイズ変更を確認して、ASE にクラスターを委任するために使用できる十分な領域があることを確認してください。

Azure Stack Edge デバイスで Azure プライベート MEC 用に Kubernetes を構成する

次の手順では、Azure Stack Edge デバイス上の Kubernetes クラスターを変更して、それを Azure プライベート マルチアクセス エッジ コンピューティング (MEC) ワークロード用に最適化します。

1. ローカル UI で、左側のメニューの [Kubernetes] を選択します。
2. [シナリオを最もよく表しているオプションを選択してください] で、[環境内の Azure プライベート MEC ソリューション] を選択します。
3. [ワークロードの確認] ポップアップで、[環境内の Azure プライベート MEC を実行していることを確認します] を選択し、[適用] をクリックしてポップアップを閉じます。
4. [適用] をクリックして変更を保存します。

ローカル UI に更新されたオプションが表示されます。次の図に示すように、[Kubernetes] が [Kubernetes (プレビュー)] になります。

Azure portal に移動して Azure Stack Edge リソースに移動すると、[Azure Kubernetes Service] オプションが表示されます。 Azure Kubernetes Service は、「クラスターを起動して Arc を設定する」で設定します。

高度なネットワークを設定する

次に、これらのスイッチで仮想スイッチと仮想ネットワークを構成する必要があります。 このタスクを実行するには、Azure Stack Edge ローカル UI の [高度なネットワーク] セクションを使用します。

このページのすべての設定を入力してから下部にある [適用] を選択して、すべてを一度に適用できます。

1. 3 つの仮想スイッチを構成します。 次の手順の前に、各ポートに関連付けられた仮想スイッチが存在する必要があります。 他の仮想ネットワーク機能 (VNF) が設定されている場合は、仮想スイッチが既に存在する可能性があります。 [仮想スイッチの追加] を選択し、スイッチごとにサイド パネルに適切に入力してから、[変更] を選択してその構成を保存します。

   • コンピューティングが有効になっているポート (管理ポート) 上に仮想スイッチを作成します。 形式 vswitch-portX の使用をお勧めします。ここで、X はポートの番号です。 たとえば、ポート 2 に vswitch-port2 を作成します。
   • ポート 3 に vswitch-port3 という名前の仮想スイッチを作成します。
   • ポート 4 に vswitch-port4 という名前の仮想スイッチを作成します。

   次の図のような画面が表示されるようになったはずです。

1. 3 つの仮想スイッチを構成します。 次の手順の前に、各ポートに関連付けられた仮想スイッチが存在する必要があります。 他の仮想ネットワーク機能 (VNF) が設定されている場合は、仮想スイッチが既に存在する可能性があります。 [仮想スイッチの追加] を選択し、スイッチごとにサイド パネルに適切に入力してから、[変更] を選択してその構成を保存します。

   • コンピューティングが有効になっているポート (管理ポート) 上に仮想スイッチを作成します。 形式 vswitch-portX の使用をお勧めします。ここで、X はポートの番号です。 たとえば、ポート 3 に vswitch-port3 を作成します。
   • ポート 5 に vswitch-port5 という名前の仮想スイッチを作成します。
   • ポート 6 に vswitch-port6 という名前の仮想スイッチを作成します。

   次の図のような画面が表示されるようになったはずです。

2. 次のインターフェイスを表す仮想ネットワークを作成します (これのサブネットと IP アドレスは、「サブネットと IP アドレスを割り当てる」で割り当てました)。

   • コントロール プレーン アクセス インターフェイス
   • ユーザー プレーン アクセス インターフェイス
   • ユーザー プレーン データ インターフェイス

   これらのネットワークには自分で名前を付けることができますが、その名前は、Azure Private 5G Core をデプロイするときに Azure portal で構成するものに一致している必要があります。 VLAN トランキング (HA デプロイに必要) を使用している場合は、IP 情報のない単一 N6 仮想ネットワークが 1 つあります。 VLAN と IP 情報は、モバイル ネットワークを構成するときに行われます。 このセットアップでは、名前 N2、N3、N6 を使用できます。

   アクセス VLAN または非 VLAN モードでは、アタッチされたデータ ネットワークごとに N6 仮想ネットワークがあります。 名前 N2、N3 と、最大 10 個の N6-DNX を使用できます (ここで、X は複数 DN デプロイではデータ ネットワーク (DN) 番号 1-10、単一 DN デプロイでは N6 だけです)。 必要に応じて、仮想ローカル エリア ネットワーク識別子 (VLAN ID) で各仮想ネットワークを構成して、レイヤー 2 トラフィックの分離を有効にすることができます。 次の例は、VLAN のない 5G 複数 DN デプロイの場合です。

3. VLAN トランキング (HA デプロイに必要) を使用している場合は、次の手順を 3 回実行します。
   1. [仮想ネットワークの追加] を選択し、次のようにサイド パネルに入力します。
      • 仮想スイッチ: N2 と N3 に vswitch-port3 を選択します。 N6 には vswitch-port4 を選択します。
      • 名前: N2、N3、または N6。
      • VLAN の種類: トランク VLAN
      • 許可される VLAN ID 範囲: 構成する VLAN ID のセットを入力します。
   2. [変更] を選択して、この仮想ネットワークの構成を保存します。
   3. ページの下部にある [適用] を選択し、設定が適用されたことを確認する通知 (ベルのアイコン) を待ちます。 設定が適用されるまでに約 8 分かかります。
4. アクセス VLAN または非 VLAN モードを使用する場合、次の手順を 3 回、さらに追加のデータ ネットワークごとに 1 回ずつ (最大 10 個のデータ ネットワークがある場合は、合計 12 回) 実行します。

   重要

   データ ネットワークにポート 3 を使用している場合は、それを予測される最も低い負荷のために使用することをお勧めします。

   1. [仮想ネットワークの追加] を選択し、次のようにサイド パネルに入力します。
      • [仮想スイッチ]: N2、N3 と最大 4 つの DN に [vswitch-port3] を選択し、最大 6 つの DN に [vswitch-port4] を選択します。
      • [名前]: N2、N3、または N6-DNX (ここで、X は DN 番号 1-10)。
      • [VLAN]: VLAN ID、または VLAN を使用していない場合は 0。
      • [ネットワーク] と [ゲートウェイ]: ASE ポートで構成されている IP アドレスの正しいサブネットとゲートウェイを使用します (その ASE ポート自体にゲートウェイが設定されていない場合でも)。
        • たとえば、10.232.44.0/24 と 10.232.44.1 とします。
        • サブネットに既定のゲートウェイがない場合は、アドレス解決プロトコル (ARP) 要求に応答するサブネット内の別の IP アドレス (いずれかの RAN IP アドレスなど) を使用します。 スイッチ経由で複数の gNB が接続されている場合は、ゲートウェイのいずれかの IP アドレスを選択します。
      • [DNS サーバー] と [DNS サフィックス] は、空白のままにしておく必要があります。
   2. [変更] を選択して、この仮想ネットワークの構成を保存します。
   3. ページの下部にある [適用] を選択し、設定が適用されたことを確認する通知 (ベルのアイコン) を待ちます。 設定が適用されるまでに約 8 分かかります。 これで、ページは次の図のようになるはずです。

3. VLAN トランキング (HA デプロイに必要) を使用している場合は、次の手順を 3 回実行します。
   1. [仮想ネットワークの追加] を選択し、次のようにサイド パネルに入力します。
      • 仮想スイッチ: N2 と N3 に vswitch-port5 を選択します。 N6 には vswitch-port6 を選択します。
      • 名前: N2、N3、または N6。
      • VLAN の種類: トランク VLAN
      • 許可される VLAN ID 範囲: 構成する VLAN ID のセットを入力します。
   2. [変更] を選択して、この仮想ネットワークの構成を保存します。
   3. ページの下部にある [適用] を選択し、設定が適用されたことを確認する通知 (ベルのアイコン) を待ちます。 設定が適用されるまでに約 8 分かかります。
4. アクセス VLAN または非 VLAN モードを使用する場合、次の手順を 3 回、さらに追加のデータ ネットワークごとに 1 回ずつ (最大 10 個のデータ ネットワークがある場合は、合計 12 回) 実行します。

   重要

   データ ネットワークにポート 5 を使用している場合は、それを予測される最も低い負荷のために使用することをお勧めします。

   1. [仮想ネットワークの追加] を選択し、次のようにサイド パネルに入力します。
      • [仮想スイッチ]: N2、N3 と最大 4 つの DN に [vswitch-port5] を選択し、最大 6 つの DN に [vswitch-port6] を選択します。
      • [名前]: N2、N3、または N6-DNX (ここで、X は DN 番号 1-10)。
      • VLAN の種類: 必要に応じて選択します。
      • [VLAN]: VLAN ID、または VLAN を使用していない場合は 0。
      • [ネットワーク] と [ゲートウェイ]: ASE ポートで構成されている IP アドレスの正しいサブネットとゲートウェイを使用します (その ASE ポート自体にゲートウェイが設定されていない場合でも)。
        • たとえば、10.232.44.0/24 と 10.232.44.1 とします。
        • サブネットに既定のゲートウェイがない場合は、アドレス解決プロトコル (ARP) 要求に応答するサブネット内の別の IP アドレス (いずれかの RAN IP アドレスなど) を使用します。 スイッチ経由で複数の gNB が接続されている場合は、ゲートウェイのいずれかの IP アドレスを選択します。
      • [DNS サーバー] と [DNS サフィックス] は、空白のままにしておく必要があります。
   2. [変更] を選択して、この仮想ネットワークの構成を保存します。
   3. ページの下部にある [適用] を選択し、設定が適用されたことを確認する通知 (ベルのアイコン) を待ちます。 設定が適用されるまでに約 8 分かかります。

これで、ページは次の図のようになるはずです。

コンピューティングと IP アドレスを追加する

Azure Stack Edge ローカル UI で、[Kubernetes (プレビュー)] ページに移動します。 すべての構成を設定した後、「高度なネットワークを設定する」で行ったように、それを 1 回適用します。

1. [コンピューティング仮想スイッチ] で、[変更] を選択します。
   1. コンピューティング インテントを持つ vswitch (vswitch-port2 など) を選択します。
   2. 管理ネットワーク上のノード IP アドレスの範囲内にある 6 つの IP アドレスを入力します。
   3. 同様に管理ネットワーク上のサービス IP アドレスの範囲内にある 1 つの IP アドレスを入力します。 これは、パケット コア インスタンスのローカル監視ツールにアクセスするために使用されます。
   4. パネルの下部にある [変更] を選択して構成を保存します。

   重要

   VLAN トランキング (HA デプロイに必要) を使用している場合、この時点で仮想ネットワークに対して IP 構成は行われません。 IP 構成は、モバイル ネットワークを構成するときに行われます。

2. [仮想ネットワーク] で、仮想ネットワークを選択します。 VLAN トランキング モードでは、これは N2、N3、N6 のいずれかになります。 それ以外の場合は、N2、N3、N6-DNX (ここで、X は DN 番号 1-10) の中から選択します。 サイド パネルで、次の操作を行います。
   1. Kubernetes の仮想ネットワークを有効にし、IP アドレスのプールを追加します。 VLAN トランキング モードでない場合は、IP アドレスのプールも追加します。
   2. 標準的なデプロイの場合は、適切なアドレス (先に収集した N2、N3、または N6-DNX) の 1 つの IP アドレスの範囲を追加します。 たとえば、10.10.10.20-10.10.10.20 とします。
   3. HA デプロイの場合は、仮想ネットワークごとに 2 つの IP アドレスの範囲を追加します。N2 と N3 ポッドの IP アドレスはローカル アクセス サブネットにあり、N6 ポッドの IP アドレスは適切なローカル データ サブネットにあります。
   4. N2、N3、N6-DNX の各仮想ネットワークについて繰り返します。
   5. パネルの下部にある [変更] を選択して構成を保存します。
3. ページの下部にある [適用] を選択し、設定が適用されるまで待ちます。 設定が適用されるまでに約 5 分かかります。

これで、ページは次の図のようになるはずです (VLAN トランキング モード)。

ASE で仮想マシンの管理を有効にする

1. Azure portal にアクセスし、Azure portal で作成された Azure Stack Edge リソースに移動します。
2. [Edge サービス] を選択します。
3. [仮想マシン] を選択します。
4. [有効化] を選択します。

クラスターを起動して Arc を設定する

Azure Stack Edge で他の仮想マシン (VM) を実行している場合は、それをここで停止し、クラスターがデプロイされた後に再び起動することをお勧めします。 このクラスターには、その実行中の VM が既に使用している可能性のある特定の CPU リソースへのアクセスが必要です。

1. Azure portal にアクセスし、Azure portal で作成された Azure Stack Edge リソースに移動します。

2. クラスターをデプロイするには、[Kubernetes] オプションを選択し、[追加] ボタンを選択してクラスターを構成します。

   

3. [ノード サイズ] で、[Standard_F16s_HPN] を選択します。

4. [Arc 対応 Kubernetes] チェックボックスがオンになっていることを確認します。

5. [変更] リンクを選択し、「オブジェクト ID (OID) を取得する」で取得したカスタムの場所の Microsoft Entra アプリケーション オブジェクト ID (OID) を入力します。

   

6. Arc 対応 Kubernetes サービスは、Azure Stack Edge リソースと同じリソース グループ内に自動的に作成されます。 Azure Stack Edge リソース グループが Azure Private 5G Core をサポートするリージョン内にない場合は、リージョンを変更する必要があります。

7. [構成] をクリックして構成を適用します。

8. [リージョン] および [Microsoft Entra アプリケーション オブジェクト ID (OID)] フィールドに適切な値が表示されていることを確認してから、[作成] をクリックします。

9. プロンプトに従ってサービスを設定します。

Kubernetes クラスターの作成には約 20 分かかります。 作成中に、Azure Stack Edge リソースに重大なアラームが表示されることがあります。 このアラームは予測されるものであり、数分後に消えます。

デプロイが終了すると、ポータルの概要ページに [Kubernetes サービスは実行中です] と表示されます。

kubectl アクセスを設定する

クラスターが正常にデプロイされたことを確認するには、kubectl アクセスが必要になります。 クラスターへの読み取り専用 kubectl アクセスの場合は、ASE ローカル UI から kubeconfig ファイルをダウンロードできます。 [デバイス] で、[構成をダウンロードする] を選択します。

ダウンロードされるファイルは config.json と呼ばれます。 このファイルには、ポッドを記述したりログを表示したりするためのアクセス許可がありますが、kubectl exec でポッドにアクセスすることはできません。

ポータル アクセスを設定する

Azure portal で Azure Stack Edge リソースを開きます。 Azure Kubernetes Service ペイン (「クラスターを起動して Arc を設定する」に示されています) に移動し、[管理] リンクを選択して [Arc] ペインを開きます。

[Kubernetes リソース (プレビュー)] メニューのオプションを使用してクラスターを探索します。

最初に、サインイン要求のボックスが表示されます。 サインインに使用するトークンは、「kubectl アクセスを設定する」でローカル UI からダウンロードした kubeconfig ファイルから取得されます。 kubeconfig ファイルの最後の辺りに、先頭に token: が付いた文字列があります。 この文字列をポータル内のボックスにコピーし (改行文字がコピーされていないことを確認してください)、[サインイン] を選択します。

これて、クラスターで何が実行されているかに関する情報を表示できるようになりました。[ワークロード] ペインの例を次に示します。

クラスター構成の検証

「kubectl アクセスを設定する」で UI からダウンロードした kubeconfig を使用して、次の kubectl コマンドを実行して AKS クラスターが正しく設定されていることを確認する必要があります。

kubectl get nodes

このコマンドは、nodepool-aaa-bbb という名前のノードと target-cluster-control-plane-ccc という名前のノードの 2 つのノードを返します。

実行中のすべてのポッドを表示するには、次を実行します。

kubectl get pods -A

さらに、この AKS クラスターは、ポータルで Azure Stack Edge リソースから表示できるようになっています。

Kubernetes 拡張機能の変数を収集する

次の表にある各値を収集します。

Value	変数名
Azure リソースがデプロイされている Azure サブスクリプションの ID。	SUBSCRIPTION_ID
AKS クラスターがデプロイされているリソース グループの名前。 これは、Azure portal の [Azure Kubernetes Service] ペインにある [管理] ボタンを使用して見つけることができます。	RESOURCE_GROUP_NAME
AKS クラスター リソースの名前。 これは、Azure portal の [Azure Kubernetes Service] ペインにある [管理] ボタンを使用して見つけることができます。	RESOURCE_NAME
Azure リソースがデプロイされているリージョン。 これは、モバイル ネットワークがデプロイされるリージョンに一致している必要があります。また、AP5GC でサポートされているリージョンのいずれかである必要があります。 この値はリージョンのコード名である必要があります。	LOCATION
AKS クラスターのために作成される [カスタムの場所] リソースの名前。 この値は、先頭と最後が英数字である必要があり、使用できるのは英数字、-、. だけです。	CUSTOM_LOCATION

Kubernetes 拡張機能をインストールする

Azure Private 5G Core プライベート モバイル ネットワークには、Azure Cloud Shell で Azure CLI を使用して構成する必要のあるカスタムの場所と特定の Kubernetes 拡張機能が必要です。

1. Azure Cloud Shell を使用して Azure CLI にサインインし、ドロップダウン メニューから [Bash] を選択します。

2. デプロイに必要な値を使用して、次の環境変数を設定します。

   SUBSCRIPTION_ID=<subscription ID>
   RESOURCE_GROUP_NAME=<resource group name>
   LOCATION=<deployment region, for example eastus>
   CUSTOM_LOCATION=<custom location for the AKS cluster>
   ARC_CLUSTER_RESOURCE_NAME=<resource name>
   TEMP_FILE=./tmpfile
   

3. シェル環境を準備します。

   az account set --subscription "$SUBSCRIPTION_ID"
   az extension add --upgrade --name k8s-extension
   az extension add --upgrade --name customlocation
   

4. Network Function Operator の Kubernetes 拡張機能を作成します。

   cat > $TEMP_FILE <<EOF
   {
     "helm.versions": "v3",
     "Microsoft.CustomLocation.ServiceAccount": "azurehybridnetwork-networkfunction-operator",
     "meta.helm.sh/release-name": "networkfunction-operator",
     "meta.helm.sh/release-namespace": "azurehybridnetwork",
     "app.kubernetes.io/managed-by": "helm",
     "helm.release-name": "networkfunction-operator",
     "helm.release-namespace": "azurehybridnetwork",
     "managed-by": "helm"
   }
   EOF 
   

   az k8s-extension create \
   --name networkfunction-operator \
   --cluster-name "$ARC_CLUSTER_RESOURCE_NAME" \
   --resource-group "$RESOURCE_GROUP_NAME" \
   --cluster-type connectedClusters \
   --extension-type "Microsoft.Azure.HybridNetwork" \
   --auto-upgrade-minor-version "true" \
   --scope cluster \
   --release-namespace azurehybridnetwork \
   --release-train preview \
   --config-settings-file $TEMP_FILE 
   

5. Packet Core Monitor の Kubernetes 拡張機能を作成します。

   az k8s-extension create \
   --name packet-core-monitor \
   --cluster-name "$ARC_CLUSTER_RESOURCE_NAME" \
   --resource-group "$RESOURCE_GROUP_NAME" \
   --cluster-type connectedClusters \
   --extension-type "Microsoft.Azure.MobileNetwork.PacketCoreMonitor" \
   --release-train stable \
   --auto-upgrade true 
   

6. カスタムの場所を作成する:

   az customlocation create \
   -n "$CUSTOM_LOCATION" \
   -g "$RESOURCE_GROUP_NAME" \
   --location "$LOCATION" \
   --namespace azurehybridnetwork \
   --host-resource-id "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP_NAME/providers/Microsoft.Kubernetes/connectedClusters/$ARC_CLUSTER_RESOURCE_NAME" \
   --cluster-extension-ids "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP_NAME/providers/Microsoft.Kubernetes/connectedClusters/$ARC_CLUSTER_RESOURCE_NAME/providers/Microsoft.KubernetesConfiguration/extensions/networkfunction-operator"
   

Azure portal の指定されたリソース グループ内に、新しい [カスタムの場所] がリソースとして表示されます。 また、kubectl get pods -A コマンド (kubeconfig ファイルにアクセスできます) を使用すると、インストールされた拡張機能に対応する新しいポッドも表示されます。 ポッドは azurehybridnetwork 名前空間に 1 つと、packet-core-monitor 名前空間に 1 つ存在するはずです。

ロールバック

Azure Stack Edge の構成でエラーが発生した場合は、ポータルを使用して AKS クラスターを削除できます (「Azure Stack Edge に Azure Kubernetes サービスをデプロイする」を参照)。 その後、ローカル UI を使用して設定を変更できます。

あるいは、ローカル UI で [デバイスのリセット] ブレードを使用して完全なリセットを実行してから (Azure Stack Edge デバイスのリセットと再アクティブ化に関するページを参照)、この手順を再開することもできます。 この場合は、Azure Stack Edge のリセットを完了した後、Azure portal に残っている関連付けられたリソースをすべて削除することも必要です。 これには、このプロセスをどこまで実行しているかに応じて、次の一部またはすべてが含まれます。

• Azure Stack Edge リソース
• Azure Stack Edge リソースに関連付けられている自動生成された KeyVault
• Azure Stack Edge リソースに関連付けられている自動生成された StorageAccount
• Azure Kubernetes クラスター (正常に作成された場合)
• カスタムの場所 (正常に作成された場合)

デプロイ後の ASE 構成の変更

パケット コアをデプロイした後に ASE 構成を更新する (アタッチされたデータ ネットワークを追加または削除したり、IP アドレスを変更するなど) ことが必要になる場合があります。 ASE 構成を変更するには、[カスタムの場所] および Azure Kubernetes Service リソースを破棄し、ASE 構成の変更を行ってから、これらのリソースを再作成します。 これにより、パケット コアを破棄して再作成するのではなく一時的に切断できるため、必要な再構成が最小限に抑えられます。 また、パケット コア構成にも同等の変更を加えることが必要になる場合があります。

注意事項

この手順中、パケット コアは使用できなくなります。 正常なパケット コア インスタンスに変更を加える場合は、サービスへの影響を最小限に抑えるために、この手順をメンテナンス期間中に実行することをお勧めします。

1. Azure portal で (パケット コアが含まれているリソース グループの) リソース グループの概要に移動します。 [パケット コア コントロール プレーン] リソースを選択し、[パケット コアの変更] を選択します。 [Azure Arc カスタムの場所] を [なし] に設定し、[変更] を選択します。
2. [カスタムの場所] リソースが含まれているリソース グループに移動します。 [カスタムの場所] リソースのチェック ボックスをオンにして、[削除] を選択します。 削除を確認します。
3. Azure Stack Edge リソースに移動し、Azure Kubernetes Service のすべての構成を削除します。
4. ASE ローカル UI にアクセスし、必要に応じて構成を更新します。
5. Kubernetes クラスターを再作成します。 「クラスターを起動して Arc を設定する」を参照してください。
6. カスタムの場所リソースを再作成します。 [パケット コア コントロール プレーン] リソースを選択し、[カスタムの場所の構成] を選択します。

パケット コアが、更新された ASE 構成で動作するようになりました。 パケット コア構成を更新するには、「パケット コア インスタンスを変更する」を参照してください。

次のステップ

これて、Azure Stack Edge デバイスが Azure Private 5G Core に対して準備できました。 HA デプロイの場合は、ルーターを構成する必要もあります。 それ以外の場合、次のステップでは、プライベート ネットワークをデプロイするために必要な情報を収集します。

• 高可用性 (HA) のデプロイ用にルーターを構成する
• プライベート モバイル ネットワークをデプロイするために必要な情報を収集する