Azure Stack Edge に Azure Kubernetes サービスをデプロイする

適用対象: Azure Stack Edge Pro - GPUAzure Stack Edge Pro 2Azure Stack Edge Pro R

Note

この手順は、SAP または PMEC のお客様である場合にのみ使用してください。

この記事では、Azure Stack Edge デバイスに Azure Kubernetes サービス (AKS) をデプロイして管理する方法について説明します。 また、この記事を使用すると、永続ボリュームを作成したり、GitOps を使用して Arc 対応 Kubernetes クラスターを管理したり、AKS や Azure Arc を削除したりすることもできます。

この記事の対象読者は、Azure Stack Edge デバイスでのワークロードの設定とデプロイに精通している IT 管理者です。

Azure Stack Edge 上の Azure Kubernetes サービスについて

Azure Stack Edge は、高パフォーマンスのネットワーク I/O 機能を備えた AI 対応のエッジ コンピューティング デバイスです。 Azure Stack Edge デバイスでコンピューティングを構成したら、Azure portal を使用して Azure Kubernetes サービス (インフラストラクチャ VM を含む) をデプロイできます。 その後、AKS クラスターは Azure Arc を使用したワークロードのデプロイに使用されます。

前提条件

開始する前に、次の要件が満たされていることを確認します。

• Azure portal にアクセスするための資格情報と、Azure Stack Edge Pro GPU デバイスへのアクセス権を持つ Microsoft アカウントがあること。 Azure Stack Edge デバイスは、デバイスの設定とアクティブ化に関するページにある手順を使用して構成およびアクティブ化されます。

• Azure Stack Edge デバイスで少なくとも 1 つの仮想スイッチが作成され、コンピューティングに対して有効になっていること。 詳細な手順については、仮想スイッチの作成に関するページを参照してください。

• サポートされるオペレーティング システムを実行しているデバイスにアクセスするためのクライアントがあること。 Windows クライアントを使用している場合は、PowerShell 5.0 以降が実行されていることを確認してください。

• Kubernetes クラスターで Azure Arc を有効にする前に、サブスクリプションに対して Microsoft.Kubernetes および Microsoft.KubernetesConfiguration リソース プロバイダーを有効にして登録していることを確認してください。 詳細な手順については、Azure CLI を使用したリソース プロバイダーの登録に関するページを参照してください。

• Azure Arc for Kubernetes クラスターをデプロイする場合は、リソース グループを作成する必要があります。 このリソース グループへの所有者レベルのアクセス権が必要です。

  リソース グループへのアクセス レベルを確認するには、[リソース グループ]>[アクセス制御 (IAM)]>[アクセス権の表示] の順に移動します。 [ロールの割り当て] で、所有者として一覧表示されている必要があります。

  

デプロイするワークロードによっては、次のオプションの手順も完了していることの確認が必要になる場合があります。

• Arc 対応クラスターにカスタムの場所をデプロイする場合は、サブスクリプションに対して Microsoft.ExtendedLocation リソース プロバイダーを登録する必要があります。

  カスタム場所オブジェクト ID をフェッチし、それを使用して、デバイスの PowerShell インターフェイス経由でカスタムの場所を有効にする必要があります。

  az login
  az ad sp show --id bc313c14-387c-4e7d-a58e-70417303ee3b --query id -o tsv
  

  Azure CLI を使用したサンプル出力を次に示します。 これらの同じコマンドは、Azure portal で Cloud Shell を使用して実行できます。

  PS /home/user> az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query id -o tsv
  51dfe1e8-70c6-4de5-a08e-e18aff23d815
  PS /home/user>
  

  詳細については、Arc 対応 Kubernetes でのカスタムの場所の作成および管理に関するページを参照してください。

• Kubernetes または PMEC ワークロードをデプロイしている場合:

  • ローカル UI または PowerShell を使用して、特定のワークロード プロファイルが選択されている可能性があります。 詳細な手順は、ローカル UI の場合は「コンピューティング IP を構成する」に、PowerShell の場合は「Kubernetes ワークロード プロファイルを変更する」に記載されています。
  • 仮想ネットワークの作成の手順を使用して追加した仮想ネットワークが必要になる場合があります。

• インフラストラクチャ VM として HPN VM を使用している場合は、vCPU が自動的に予約されるはずです。 この予約を確認するには、次のコマンドを実行します。

  Get-HcsNumaLpMapping
  

• この構成は、Azure Stack Edge 2307 をインストールするか、またはこのバージョンに更新するときに適用されます。 更新中にこの構成が適用されないシナリオには、次の 2 つがあります。

  • Numa0 の 4 vCPU + Numa1 のすべての vCPU より多くの minroot vCPU が構成されている場合。 このシナリオは主に、すべての vCPU を minroot 用に構成する Azure Stack Edge ゲートウェイの顧客に適用されます。 Azure Stack Edge Pro 2 の場合、Numa は 1 つしかありません。 40 コアを備えた Azure Stack Edge Pro 2 では 24 vCPU より多くの minroot vCPU が構成され、48 vCPU を備えた Azure Stack Edge Pro 2 では 28 を超える vCPU が構成されています。

  • HPN VM がデプロイされており、40 コアを備えたマシンで 16 を超える vCPU を、または HPN VM 用に 48 コアを備えたマシンで 20 を超える vCPU を消費している場合。

  Azure Stack Edge Pro GPU

  Azure Stack Edge Pro GPU の場合のサンプル出力を次に示します。

  Hardware:
    { Numa Node #0 : CPUs [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] }
  
    { Numa Node #1 : CPUs [20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39] }
  
  HpnCapableLpMapping:
    { Numa Node #0 : CPUs [4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] }
  
    { Numa Node #1 : CPUs [24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39] }
  
  7MT0SZ2:
   HpnLpMapping:
    { Numa Node #0 : CPUs [4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] }
  
    { Numa Node #1 : CPUs [] }
  
  HpnLpAvailable:
    { Numa Node #0 : CPUs [4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] }
  
    { Numa Node #1 : CPUs [] }
  

  Azure Stack Edge Pro 2

  Azure Stack Edge Pro 2 の場合のサンプル出力を次に示します。

  Hardware:
    { Numa Node #0 : CPUs [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39] }
  
  HpnCapableLpMapping:
    { Numa Node #0 : CPUs [8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39] }
  
  B4P1076003103B:
  HpnLpMapping:
    { Numa Node #0 : CPUs [24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39] }
  
  HpnLpAvailable:
    { Numa Node #0 : CPUs [24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39] }
  

Azure Stack Edge に AKS をデプロイする

Azure Stack Edge に AKS をデプロイする手順は複数あります。 下に示すように、一部の手順は省略可能です。

AKS が有効になっていることを確認する

AKS が有効になっていることを確認するには、Azure portal で Azure Stack Edge リソースに移動します。 [概要] ペインで、[Azure Kubernetes Service] タイルを選択します。

カスタムの場所を設定する (省略可能)

1. デバイスの PowerShell インターフェイスに接続します。

2. カスタムの場所を設定するためのオプションとして、次のコマンドを実行します。 前提条件を完了するときにフェッチしたカスタム場所オブジェクト ID を入力します。

   Set-HcsKubeClusterArcInfo –CustomLocationsObjectId <custom_location_object_id>
   

   Azure CLI を使用したサンプル出力を次に示します。 これらの同じコマンドは、Azure portal で Cloud Shell を使用して実行できます。

   [1d9nhq2.microsoftdatabox.com]: PS> Set-HcsKubeClusterArcInfo –CustomLocationsObjectId 51dfe1e8-70c6-4de5-a08e-e18aff23d815
   [1d9nhq2.microsoftdatabox.com]: PS>
   

静的 IP プールを指定する (省略可能)

Kubernetes ポッドで使用される仮想ネットワークの IP プールを割り当てることができる省略可能な手順です。

Note

SAP の顧客は、この手順をスキップできます。

Kubernetes に対して有効になっている仮想ネットワークごとに静的 IP アドレス プールを指定できます。 Kubernetes に対して有効になっている仮想ネットワークでは、Kubernetes クラスターのために作成される NetworkAttachmentDefinition が生成されます。

アプリケーションのプロビジョニング中に、Kubernetes ポッドでは、コンテナー シングル ルート I/O 仮想化 (SR-IOV) インターフェイスなどのコンテナー ネットワーク インターフェイスの IP プール内の静的 IP アドレスを使用できます。 これは、PodSpec で NetworkAttachmentDefinition を指すことによって行うことができます。

デバイスのローカル UI で静的 IP プールを割り当てるには、次の手順を使用します。

1. Azure portal で [高度なネットワーク] ページに移動します。

2. 前に仮想ネットワークを作成しなかった場合は、[仮想ネットワークの追加] を選択して仮想ネットワークを作成します。 その仮想ネットワークに関連付けられた仮想スイッチ、VLAN ID、サブネット マスク、ゲートウェイを指定する必要があります。

3. ここに示されている例では、3 つの仮想ネットワークを構成しました。 これらの各仮想ネットワークでは、VLAN は 0 であり、サブネット マスクとゲートウェイは外部の値 (255.255.0.0 と 192.168.0.1 など) に一致します。

   1. 最初の仮想ネットワーク – [名前] は N2 であり、vswitch-port5 に関連付けられています。

   2. 2 番目の仮想ネットワーク – [名前] は N3 であり、vswitch-port5 に関連付けられています。

   3. 3 番目の仮想ネットワーク – [名前] は N6 であり、vswitch-port6 に関連付けられています。

   4. 3 つの仮想ネットワークがすべて構成されると、次のように [仮想ネットワーク] の下に一覧表示されます。

      

4. 仮想ネットワークに IP アドレス プールを割り当てます。

   1. [Kubernetes] ページで、作成した仮想ネットワークを選択し、それを Kubernetes に対して有効にします。

   2. 仮想ネットワーク内の Kubernetes ポッドの静的 IP の連続した範囲を指定します。 この例では、作成した 3 つの各仮想ネットワークに対して 1 つの IP アドレスの範囲が指定されました。

5. [適用] を選択して、すべての仮想ネットワークの変更を適用します。

   Note

   AKS クラスターがデプロイされた後に IP プールの設定を変更することはできません。

   

コンピューティング仮想スイッチを構成する

Kubernetes コンピューティング トラフィック用に仮想スイッチを構成するには、この手順を使用します。

1. デバイスのローカル UI で、[Kubernetes] ページに移動します。

2. [変更] を選択して、Kubernetes コンピューティング トラフィック用に仮想スイッチを構成します。

   

3. インターネットにアクセスできるポートでコンピューティングを有効にします。 たとえば、この場合は、インターネットに接続されたポート 2 でコンピューティングが有効になっています。 インターネット アクセスを使用すると、AKS からコンテナー イメージを取得できます。

   Azure 整合サービスの仮想 IP は、外部ルーティングを介して、または同じネットワーク上に Azure 整合サービスの仮想 IP を作成することによって、このコンピューティング仮想スイッチ ネットワークに到達できる必要があります。

4. Kubernetes ノードの場合は、このポートのネットワークと同じサブネット内の 6 つの静的 IP の連続した範囲を指定します。

   AKS のデプロイの一部として、管理クラスターとターゲット クラスターの 2 つのクラスターが作成されます。 指定した IP は、次のように使用されます。

   • 管理クラスターには、2 つの IP = 管理コントロール プレーンのネットワーク インターフェイス用に 1 つの IP + API サーバー (VIP) 用に 1 つの IP が必要です。

   • ターゲット クラスターには、(2+n) 個の IP = ターゲット クラスター コントロール プレーンのネットワーク インターフェイス用に 1 つの IP + API サーバー (VIP) 用に 1 つの IP + ノードの数 n が必要です。

   • ローリング アップデートには追加の IP が使用されます。

     単一ノード デバイスの場合は、上記により、Kubernetes クラスターをデプロイするために 6 つの IP が必要になります。 2 ノード クラスターの場合は、7 つの IP が必要です。

5. Kubernetes 外部サービス IP の場合は、Kubernetes クラスターの外部に公開されているサービスの静的 IP を指定します。 このような各サービスに 1 つの IP が必要です。

   

VM のクラウド管理を有効にする

この手順は、Azure Stack Edge ポータルで、AKS の (たとえば、ターゲット クラスターのワーカー ノード用の) Azure Stack Edge デバイスにインフラストラクチャ VM をデプロイできるようにするために必要です。

1. Azure portal で、Azure Stack Edge リソースに移動します。

2. [概要] に移動し、[仮想マシン] タイルを選択します。

   

3. [仮想マシン]>[概要] ページで、[仮想マシンのクラウド管理] の [有効化] を選択します。

   

Kubernetes クラスターを設定して Arc を有効にする

Kubernetes クラスターを設定してデプロイし、それを Arc 経由で管理に対して有効にするには、この手順を使用します。

重要

Kubernetes クラスターを作成する前に、次の点に注意してください。

• AKS クラスターがデプロイされた後に IP プールの設定を変更することはできません。
• この記事の「カスタムの場所を設定する (省略可能)」セクションで、省略可能なコマンドを使用してオブジェクト ID が渡された場合は、AKS ターゲット クラスターでの Arc の有効化の一部としてカスタムの場所が有効になります。 カスタムの場所を有効にしなかった場合は、Kubernetes クラスターが作成される前に、引き続きそれを行うことを選択できます。 クラスターのデプロイが開始されると、カスタムの場所を設定できなくなります。

AKS クラスターをデプロイするには、次の手順に従います。

1. Azure portal で、Azure Stack Edge リソースに移動します。

2. [Azure Kubernetes Service] タイルを選択します。

3. [追加] を選択して AKS を構成します。

4. [Kubernetes サービスの作成] ダイアログで、インフラストラクチャ VM の Kubernetes [ノード サイズ] を選択します。 デプロイしているワークロード サイズに適した VM ノード サイズを選択します。 この例では、VM サイズ [Standard_F16s_HPN – 16 vCPU、32.77 GB メモリ] を選択しました。

   SAP のデプロイの場合は、VM ノード サイズ [Standard_DS5_v2] を選択します。

   Note

   [ノード サイズ] ドロップダウン メニューにデータが入力されていない場合は、前の手順で VM が有効になった後、数分待って同期されるようにします。

5. [Arc 対応 Kubernetes を使用してクラウドからコンテナーを管理します] をオンにします。 このオプションは (オンになっているとき)、Kubernetes クラスターが作成されたときに Arc を有効にします。

6. [変更] を選択した場合は、サブスクリプション名、リソース グループ、クラスター名、リージョンを指定する必要があります。

   

   1. サブスクリプション名には自動的にデータが入力されます。

   2. 一意のリソース グループ名を指定します。 また、Azure Stack Edge リソースをデプロイしたのと同じリソース グループの使用を選択することもできます。 このリソース グループへの所有者レベルのアクセス権が必要です。 リソース グループへのアクセス レベルを確認するには、[リソース グループ]>[アクセス制御 (IAM)]>[アクセス権の表示] の順に移動します。 [ロールの割り当て] で、所有者として一覧表示されている必要があります。

      

   3. Arc 対応 Kubernetes クラスターの名前を指定するか、または既定値をそのまま使用します。

   4. Arc 対応 Kubernetes クラスターのリソースが作成されるリージョンを選択します。 サポートされているリージョンのフィルター処理された一覧がドロップダウン リストに表示されます。

   5. [構成] をクリックします。 また、[既定値にリセット] オプションを選択して Arc 設定をリセットすることもできます。

7. [作成] を選択して Kubernetes サービスを作成します。

   

8. クラスターの作成が開始されると、通知が表示されます。

   1. Kubernetes クラスターが作成されると、Azure Kubernetes Service が [実行中] であることがわかります。

      

      [Arc 対応 Kubernetes] も [実行中] として表示されます。

      

      Kubernetes ワークロードをデプロイする予定がある場合は、次に、ストレージを割り当てるための永続ボリュームの作成が必要になることがあります。

永続ボリュームを追加する

PersistentVolume (PV) は、Kubernetes クラスター内のストレージの一部を指します。 Kubernetes ストレージは PersistentVolume として静的にプロビジョニングできます。 また、StorageClass として動的にプロビジョニングすることもできます。 詳細については、「Kubernetes ポッドのストレージ要件」を参照してください。

PV を作成するためのワークフローには、共有が作成されるときにコンピューティングがインラインで有効になるかどうかに応じて 2 種類あります。 これらの各ワークフローについては、以降のセクションで説明されます。

共有の作成中にコンピューティングがインラインで有効になっている状態で永続ボリュームを作成する

Azure Stack Edge Pro デバイスでは、デバイスのストレージ機能を使用して、静的にプロビジョニングされた PersistentVolumes が作成されます。 共有をプロビジョニングしたときに、[Edge コンピューティングで共有を使用する] オプションが有効になっている場合、このアクションでは Kubernetes クラスター内に PV リソースが自動的に作成されます。

クラウドの階層化を使用するには、[Edge コンピューティングで共有を使用する] オプションを有効にした状態で Edge クラウド共有を作成できます。 この共有に対しても、PV が自動的に作成されます。 このオプションを有効にすると、Edge 共有に書き込むアプリケーション データはすべてクラウドに階層化されます。

共有の作成中にコンピューティングがインラインで有効になっていない状態で永続ボリュームを作成する

[Edge コンピューティングで共有を使用する] オプションをオフにした状態で作成された共有の場合は、次の手順を使用して永続ボリュームを追加できます。

1. Azure portal で、デバイスの Azure Stack Edge リソースに移動します。 [クラウド ストレージ ゲートウェイ]>[共有] の順に移動します。 デバイスで現在、共有の [コンピューティングに使用] 状態が有効になっていることを確認できます。

   

2. [+ 共有の追加] を選択します。 この共有では、[Edge コンピューティングで共有を使用する] がオフになっていることを確認します。

   

3. 共有の一覧内の新しく作成された共有と [コンピューティングに使用] 状態が [無効] であることを確認できます。

   

4. [Azure Stack Edge リソース]>[概要] に戻ります。 右側のペインで、[Azure Kubernetes Service] タイルを選択します。

   

5. [Azure Kubernetes Service]>[概要] ページの [永続ボリューム] タイルに、存在する永続ボリュームが表示されます。 これらのボリュームは、[Edge コンピューティングで共有を使用する] オプションを有効にした状態で共有が作成されたときに自動的に作成されました。 新しい永続ボリュームを作成するには、[+ 永続ボリュームの追加] を選択します。

6. [永続ボリュームの追加] ダイアログで、永続ボリュームを作成する共有を選択します。

   

7. 永続ボリュームが作成中であることを示す通知が表示されます。 この操作は、完了するまでに数分かかります。

   

8. 永続ボリュームが作成されると、[概要] ページが更新され、新しく追加された永続ボリュームが含まれています。

   

9. 新しく作成された永続ボリュームを確認するには、[すべての永続ボリュームを表示する] を選択します。

Azure Kubernetes サービスを削除する

AKS を削除するには、Azure portal で次の手順を使用します。

1. Azure Stack Edge リソースで、[Azure Kubernetes Service]>[概要] の順に移動します。

2. 上部のコマンド バーから、[削除] を選択します。

   

3. AKS と共に削除する構成済みのアドオンを選択します。 Azure Arc 対応 Kubernetes はアドオンです。 [削除] を選択すると、すべての Kubernetes 構成と選択されたアドオンが削除されます。 この操作は元に戻せないため、取り消すことはできません。

4. OKを選択して操作を確定します。

   

次のステップ

• Azure Kubernetes Services のトラブルシューティングに関するドキュメント。