CLI を使用して Azure Stack Hub で Azure Kubernetes Service を使用する

これは、Azure Stack Hub で Azure Kubernetes Service (AKS) サービスの使用を開始するためのガイドです。 この記事では、Azure Stack Hub の AKS に慣れるための主なシナリオセットについて説明します。 Azure Stack Hub で使用できる機能は、グローバルな Azure で利用できるものの一部です。

以降のセクションで、次のことを行います。

  1. Azure Stack Hub で AKS を使用するための前提条件を完了します。
  2. Azure CLI と Azure Stack Hub ユーザー ポータルを使用して、AKS クラスターのライフサイクル操作を完了します。

Azure CLI のインストール

お使いのコンピューターに AKS サポートを含む Azure CLI をインストールする必要があります。 クリーンなコンピューターである Linux または Windows コンピューターを準備して、AKS サポートを含む Azure CLI のプレビュー版をインストールします。 次にインストールする Azure CLI のプレビューと競合しないように、コンピューターに Azure CLI がインストールされていないことを保証します。 以下の手順のほとんどは、Linux VM を使用していることを前提としていますが、Windows の同等の手順は製品ドキュメントで確認できます。

AKS サポートを含む Azure CLI をインストールした後、Azure CLI をアップグレードしないでください。 アップグレードすると、AKS サポートのない実稼働環境対応バージョンに置き換えられます。

Ubuntu コンピューターの場合は、「Linux に Azure CLI をインストールする」の手順に従います。

AKS サポートを含む Azure CLI をインストールしたら、次の Azure CLI コマンドを実行して、インストールが正しいことを確認します。

    az --version

Linux コンピューターから次のように出力されます。

Linux コンピューターからの出力

Azure CLI は 2.28.0 以上である必要があります。

Azure Stack Hub に接続する

  1. Azure Stack Hub エンドポイントに接続します。 Azure CLI を使用して、接続先の特定の Azure Stack Hub 環境を確立する必要があります。 手順については、「Azure Stack Hub に接続する」を参照してください

  2. Azure CLI からインスタンスの Azure Stack Hub Resource Manager エンドポイントに接続できるように環境を登録します。 次のスニペットの URL を更新し、次のコマンドを実行します。

    az cloud register \
        -n aks-preview-test \
        --endpoint-resource-manager "https://management.redmond.xbx.nxn.microsoft.com" \
        --suffix-storage-endpoint "redmond.xbx.nxn.microsoft.com" \
        --suffix-keyvault-dns ".vault.redmond.xbx.nxn.microsoft.com"
    
  3. アクティブな環境を設定します。

    az cloud set -n aks-preview-test
    
  4. 環境構成を更新します。

    az cloud update --profile 2020-09-01-hybrid
    
  5. 環境に接続します。

    az login -u 'user@contoso.onmicrosoft.com' -p 'xxxxxxx' --tenant 'contoso.onmicrosoft.com'
    

    Note

    証明書の検証失敗エラーをトリガーした場合、Azure Resource Manager エンドポイントに使用されている証明書がクライアント コンピューターによって信頼されていない可能性があります。 その場合は、Azure Stack Hub エンドポイントで使用されている証明書をエクスポートして信頼する必要があります。 手順については、Azure Stack Hub の CA ルート証明書のエクスポートに関する記事をご覧ください。

    特に、Linux マシンの場合は、「Linux 上のMicrosoft Entra ID」を参照してください。

  6. Azure CLI セッションのサブスクリプションを既定値として設定します。

    az account set --subscription <subscription-id>
    
  7. Azure Kubernetes Service リソース プロバイダーを登録します。 サブスクリプションで使用可能なリソース プロバイダーを一覧表示します。

    az provider list --query "[].{Provider:namespace, Status:registrationState}" --out table
    

    出力は次のようになります。

    出力の様子

  8. Microsoft.ContainerService リソース プロバイダーをメモしてから、プロバイダーを登録します。

    az provider register --namespace Microsoft.ContainerService
    
  9. 手順 7 を再実行して、リソース プロバイダーの登録状態を確認します。 登録が完了するまでに数分かかる場合があります。

これらの前提条件の手順が完了したら、次のシナリオのテストに進むことができます。

AKS クラスターを作成する

グローバルな Azure の手順については、「Azure CLI を使用して Azure Kubernetes Service クラスターをデプロイする」を参照してください。 ここでの手順は、Azure Stack Hub で AKS を使用する際の制限事項を反映しています。 Azure CLI を使用して、Linux または Windows コンテナー用の AKS クラスターを作成できます。

  1. リソース グループを作成します。

    az group create --name myResourceGroup --location <Azure Stack Hub location>
    
  2. クラスターを作成するために、サブスクリプションに共同作成者のアクセス許可を持つサービス プリンシパル ID があることを確認します。

    1. Microsoft Entra ID を使用してサービス プリンシパル (SPN) を作成するには、次の手順に従います。
    2. Active Directory フェデレーション サービス (AD FS) を使用して SPN を作成するには、次の手順に従います。
    3. SPN に "共同作成者" ロールを割り当てるには、手順を参照してください。 必ず "共同作成者" ロールを選択してください。
  3. 3 つのエージェント ノードの AKS クラスターを作成します。 次のパラメーターに値を指定します。例を示します。 次を実行します。

    az aks create \
    --resource-group myResourceGroup \
    --name myakscluster \
    --dns-name-prefix myakscluster \
    --nodepool-name mynodepool \
    --admin-username azureuser \
    --service-principal xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
    --client-secret xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
    --node-count 3 \
    --generate-ssh-keys \
    --load-balancer-sku basic \
    --vm-set-type VirtualMachineScaleSets \
    --location <Azure Stack Hub location> \
    --kubernetes-version 1.20.7
    

    この操作からの出力は json 形式であり、生成される SSH 公開キー、クラスターで使用される完全修飾ドメイン名 (FQDN) などのプロパティが含まれるクラスターの仕様が出力されます。 コマンドを実行すると、秘密キーの場所を強調する次のようなテキストが出力されます。SSH key files '/home/azureuser/.ssh/id_rsa''/home/azureuser/.ssh/id_rsa.pub' が、VM への SSH アクセスを許可するために、\~/.ssh に生成されています。 これらのキーは安全な場所に保存して、問題のトラブルシューティングを行うときのように、VM に SSH 接続する必要がある場合に使用できるようにします。

  4. これで、スケールのテストの繰り返し、アプリのデプロイ削除を行うことができます。

クラスターに接続する

  1. Kubernetes クラスターを管理するには、Kubernetes のコマンドライン クライアントである kubectl を使用します。 kubectl をローカルにインストールするには、az aks install-cli コマンドを使用します (最初に 'sudo' を使用して、インストールするためのアクセス許可を持つことが必要な場合があります)。

    az aks install-cli
    
  2. Kubernetes クラスターに接続するように kubectl を構成するには、az aks get-credentials コマンドを使用します。 このコマンドは、資格情報をダウンロードし、それを使用するように Kubernetes CLI を構成します。

    az aks get-credentials --resource-group myResourceGroup --name myakscluster --admin
    
  3. クラスターへの接続を確認するには、クラスター ノードの一覧を返す kubectl get コマンドを使用します。

    kubectl get nodes
    

クラスターへの接続を確認する

クラスターのスケーリング

もう 1 つのクラスター管理タスクがクラスターのスケーリングです。 クラスターは、az aks scale コマンドを使用して作成した後、いつでもスケーリングできます。 クラスターを最初の 3 つのノードから 4 つにスケーリングするには、以下を実行します。

    az aks scale --resource-group myResourceGroup --name myakscluster --node-count 4

クラスターのスケーリングが正常に完了すると、出力には次の例のような "agentPoolProfiles" が含まれます。

    "agentPoolProfiles": [
        {
        "availabilityZones": null,
        "count": 4,
        "enableAutoScaling": null,
        "enableNodePublicIp": false,
        "maxCount": null,
        "maxPods": 110,
        "minCount": null,
        "mode": "System",
        "name": "mynodepool",
        "nodeLabels": {},
        "nodeTaints": null,
        "orchestratorVersion": "1.20.7",
        "osDiskSizeGb": 100,
        "osType": "Linux",
        "provisioningState": "Succeeded",
        "scaleSetEvictionPolicy": null,
        "scaleSetPriority": null,
        "spotMaxPrice": null,
        "tags": null,
        "type": "VirtualMachineScaleSets",
        "vmSize": " Standard_DS2_v2",
        "vnetSubnetId": null
        }
    ]

クラスターを削除する

前の操作を実行したら、クラスターの削除に進むことができます。 次を実行します。

az aks delete --name myakscluster --resource-group myResourceGroup

カスタム VNET を使用して AKS クラスターを作成する

クラスターを作成してユーザー指定のネットワークにデプロイすることは、一般的なシナリオです。 ネットワーク構成の計画には、いくつかの準備が必要です。 また、AKS では、既定のネットワーク プラグインは Azure CNI であり、AKS エンジンの場合のように Kubernet ではないことに注意してください。 Azure CNI では、すべてのポッドによって、サブネットから IP アドレスが取得され、直接アクセスできます (Kubernet の場合のように、ルーティング テーブルは必要ありません)。 これらの IP アドレスは、ネットワーク空間全体で一意である必要があり、計画されている必要があります。 次の記事で、カスタム VNET デプロイを計画するプロセスについて説明します。 ニーズに合ったさまざまなネットワーク構成を見つけてテストできます。 最初のテストでは、次の 2 つの手順で基本的なプロセスを示します。

  1. こちらの記事の手順に従って、Azure CNI を使用したデプロイを計画します。 たとえば、ポータルを使用して、"myTest-rg" という名前のリソース グループに、"myAKSVnet" という名前で IP 範囲が 10.0.0.0/8 の VNet を作成して、サブネットを "myAKSSubnet"、IP 範囲 10.240.0.0/16 に設定できます。 次に、クラスターの作成に次の手順を使用します。

    az network vnet create \
        --resource-group myTest-rg \
        --name myAKSVnet \
        --address-prefixes 10.0.0.0/8 \
        --subnet-name myAKSSubnet \
        --subnet-prefix 10.240.0.0/16    
    
  2. Azure にデプロイする場合、Azure の記事で提供されているクラスター コマンドは正常に動作します。Azure Stack Hub にデプロイするには、次の例のように追加のパラメーターを指定する必要があります。 vnet サブネット ID は、'/subscriptions/dfdfdff-5dfdf-dfdf-dfdf-dfdfdfdfdfd/resourceGroups/myTest-rg/providers/Microsoft.Network/virtualNetworks/myAKSVnet/subnets/myAKSSubnet' のようになるはずです。

    az aks create  \ 
    --resource-group myTest-rg \
    --name aksvnet \
    --dns-name-prefix  aksvnet \
    --nodepool-name mynodepool \
    --admin-username azureuser \
    --service-principal xvxvxvxvx-ffff-ffff-xvxvxvx-8xbxbxbx8  \
    --client-secret dccbcbcbcbcbcbcbcbbcbcbcbcbcbcbc-LNX \
    --node-count 3 \
    --generate-ssh-keys \
    --load-balancer-sku basic \
    --vm-set-type VirtualMachineScaleSets \
    --network-plugin azure \
    --vnet-subnet-id '<subnet-resource-id>' \
    --skip-subnet-role-assignment \
    --docker-bridge-address 172.17.0.1/16 \
    --dns-service-ip 10.0.0.10 \
    --location redmond
    
  3. 「クラスターに接続する」セクションの手順に従って、Kubernetes クラスターに接続し、アプリケーションをデプロイします。

Consistency check

Azure と Azure Stack Hub の間の整合性チェック

  1. 上記でテストしたコマンド、下の「コマンド リファレンス」セクション、またはご自分が日常的に使用するスクリプトから、コマンドの組み合わせを選択します。
  2. Azure に適用し、その後、Azure Stack Hub に適用します。 予想外の矛盾がないか注意し、フィードバックをご提供ください。

次の手順

Azure Stack Hub 上の AKS について学習する