クイック スタート: Azure CLIを使用して GPU Linux ベースのAzure Kubernetes Service (AKS) クラスターを作成する

Azure Kubernetes Service (AKS)は、クラスターをすばやくデプロイおよび管理するために使用できるマネージド Kubernetes サービスです。 このクイック スタートでは、次の方法について説明します。

  • Azure CLIを使用して AKS クラスターをデプロイします。
  • マネージド GPU ノードが有効になっている Linux ベースの GPU ノード プールを追加します。
  • AKS がスケジューリング用に GPU ソフトウェア スタックをインストールして構成したことを確認します。

フル マネージド GPU ノードはプレビュー機能です。 マネージド GPU ノードを有効にすると、AKS は NVIDIA GPU ドライバー、NVIDIA Kubernetes デバイス プラグイン、データ センター GPU マネージャー (DCGM) メトリック エクスポーター、GPU ノード プールの GPU 正常性監視コンポーネントをインストールして管理します。 また、マネージド GPU ノードは、Azure Managed Prometheus でのインジェスト用のリアルタイム GPU メトリックと、Prometheus のマネージド サービスAzure Monitor統合します。 詳細については、「Azure Kubernetes Service (AKS) (プレビュー) でのフル マネージド GPU ノード プールの作成、Azure Kubernetes Service (AKS)での GPU 可観測性」を参照してください。

Note

この記事には、評価目的でのみクラスターをデプロイする手順が含まれています。 運用可能なクラスターをデプロイする前に、 ベースライン参照アーキテクチャ を理解して、ビジネス要件にどのように適合するかを検討してください。

Important

AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は運用環境での使用を目的としていません。 詳細については、次のサポート記事を参照してください。

始める前の準備

このクイックスタートは、Kubernetes の基本的な概念を理解していることを前提としています。 詳細については、「Azure Kubernetes Services (AKS) における Kubernetes の中心概念」を参照してください。

  • Azure アカウントをお持ちでない場合は、開始する前に 無料アカウント を作成してください。
  • Azure Cloud Shell で Bash 環境を使用します。 詳細については、「Get started with Azure Cloud Shell」を参照してください。

  • CLI 参照コマンドをローカルで実行する場合は、Azure CLI を インストール します。 Windows または macOS で実行している場合は、Docker コンテナーで Azure CLI を実行することを検討してください。 詳細については、「Docker コンテナーで Azure CLI を実行する方法」を参照してください。

    • ローカル インストールを使用する場合は、az login コマンドを使用して Azure CLI にサインインします。 認証プロセスを完了するには、ターミナルに表示される手順に従います。 他のサインインオプションについては、「Azure CLI を使用して Azure に認証する」を参照してください。

    • 初回使用時にインストールを求められたら、Azure CLI 拡張機能をインストールします。 拡張機能の詳細については、「Azure CLI で拡張機能を使用および管理する」を参照してください。

    • az version を実行して、インストールされているバージョンと依存ライブラリを検索します。 最新バージョンにアップグレードするには、az upgrade を実行します。

  • バージョン 2.85.0 以降Azure CLI必要です。 バージョンを見つけるには、 az --versionを実行します。 Azure CLI をインストールまたはアップグレードする必要がある場合は、「Azure CLI のインストール」を参照してください。
  • クラスターの作成に使用している ID に適切な最小限のアクセス許可があることを確認します。 AKS のアクセスと ID の情報については、「Azure Kubernetes Service (AKS) でのアクセスと ID オプション」を参照してください。
  • 複数のAzureサブスクリプションがある場合は、az account set コマンドを使用して、課金に適したサブスクリプション ID を選択します。 詳細については、「Azure サブスクリプションを管理する方法 - Azure CLI」を参照してください。
  • Azure サブスクリプションによっては、このクイックスタートで使用する GPU 対応 VM ファミリの vCPU クォータの引き上げを要求する必要がある場合があります。 詳細については、「 VM ファミリの vCPU クォータを増やす」を参照してください。
  • GPU 対応の VM サイズには、より高い価格とリージョンの可用性の対象となる特殊なハードウェアが含まれています。 詳細については、 GPU 最適化仮想マシンのサイズに関する説明を参照してください。

aks-preview CLI 拡張機能をインストールする

az extension add コマンドを使用して、aks-preview CLI 拡張機能をインストールします。

az extension add --name aks-preview

az extension update コマンドを使用して、拡張機能を更新して最新バージョンを確実に使用できるようにします。

az extension update --name aks-preview

プレビュー機能を登録する

az feature register コマンドを使用して、ManagedGPUExperiencePreview機能フラグをサブスクリプションに登録します。

az feature register --namespace Microsoft.ContainerService --name ManagedGPUExperiencePreview

状態が [登録済み] と表示されるまでに数分かかります。 登録の状態は、az feature show コマンドを使って確認します。

az feature show --namespace Microsoft.ContainerService --name ManagedGPUExperiencePreview --query properties.state

状態が [登録済み] と表示されたらaz provider register コマンドを使用して、Microsoft.ContainerService リソース プロバイダーの登録を更新します。

az provider register --namespace Microsoft.ContainerService

環境変数を定義する

このクイック スタート全体で使用する次の環境変数を定義します。

export RANDOM_STRING=$(printf '%05d%05d' "$RANDOM" "$RANDOM")
export RESOURCE_GROUP="myAKSResourceGroup$RANDOM_STRING"
export CLUSTER_NAME="myAKSCluster$RANDOM_STRING"
export GPU_NP="gpunp"
export GPU_VM_SIZE="Standard_NC4as_T4_v3"
export LOCATION="westus"

RANDOM_STRING変数には、ランダムな 10 桁の文字列が格納されます。 RESOURCE_GROUP変数とCLUSTER_NAME変数の値がRANDOM_STRING値と連結され、一意の名前が作成されます。 GPU_NP変数には、マネージド GPU ノード プールの名前が格納されます。 GPU_VM_SIZE変数には、ノード プールの GPU 対応 VM サイズが格納されます。 LOCATION変数の値は westus です。 これらの変数値を使用することも、独自の値を作成することもできます。 echo コマンドを使用して、echo $RANDOM_STRINGなどの変数値を表示します。

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

Azure リソース グループは、Azure リソースをデプロイおよび管理するための論理グループです。 リソース グループを作成するときに、場所を指定します。 この場所は、リソース の作成時に別のリージョンを指定しない場合に、リソース グループメタデータが格納され、リソースがAzureで実行される場所です。

az group create コマンドを使用してリソース グループを作成します。

az group create --name $RESOURCE_GROUP --location $LOCATION

次の例は、結果を示しています。

{
  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myAKSResourceGroup<randomStringValue>",
  "location": "westus",
  "managedBy": null,
  "name": "myAKSResourceGroup<randomStringValue>",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

AKS クラスターを作成する

AKS クラスターを作成するには、az aks create コマンドを使用します。 次の例では、1 つのシステム ノードでクラスターを作成し、システム割り当てマネージド ID を有効にします。

az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --node-count 1 \
  --generate-ssh-keys

新しいクラスターを作成すると、AKS リソースを保存するための 2 つ目のリソース グループが自動的に作成されます。 詳細については、「AKS と一緒にリソース グループが 2 つ作成されるのはなぜでしょうか?」を参照してください。

この例のクラスターでは、時間とリソースを節約するためにノード数を 1 に指定します。 運用環境では、3 つ以上のノード数を使用します。 ノード数を指定しない場合、 az aks create コマンドは既定で 3 つのノードに設定されます。

マネージド GPU ノード プールを追加する

az aks nodepool add コマンドを使用して、Linux ベースのマネージド GPU ノード プールをクラスターに追加します。 --enable-managed-gpu=true パラメーターは、ノード プールに NVIDIA GPU ドライバー、NVIDIA Kubernetes デバイス プラグイン、DCGM メトリック エクスポーター、GPU 正常性監視コンポーネントをインストールして管理するように AKS を構成します。

次の例では、既定の Ubuntu Linux オペレーティング システムを使用して、マネージド GPU ノード プールを追加します。

az aks nodepool add \
  --resource-group $RESOURCE_GROUP \
  --cluster-name $CLUSTER_NAME \
  --name $GPU_NP \
  --node-count 1 \
  --node-vm-size $GPU_VM_SIZE \
  --node-taints sku=gpu:NoSchedule \
  --enable-managed-gpu=true

--node-taints sku=gpu:NoSchedule パラメーターは、ワークロードに一致する容認が含まれている場合を除き、GPU ノード プールから GPU 以外のワークロードを保持します。

ノード プールを作成したら、 az aks nodepool show コマンドを使用して、マネージド GPU プロファイルが有効になっていることを確認します。

az aks nodepool show \
  --resource-group $RESOURCE_GROUP \
  --cluster-name $CLUSTER_NAME \
  --name $GPU_NP \
  --query "{Name:name, Mode:mode, VmSize:vmSize, Taints:nodeTaints, GpuProfile:gpuProfile}"

出力には、次の値が含まれている必要があります。

{
  "GpuProfile": {
    "driver": "Install",
    "driverType": "",
    "nvidia": {
      "managementMode": "Managed",
      "migStrategy": null
    }
  },
  "Mode": "User",
  "Name": "gpunp",
  "Taints": [
    "sku=gpu:NoSchedule"
  ],
  "VmSize": "Standard_NC4as_T4_v3"
}

クラスターに接続する

Kubernetes クラスターを管理するには、Kubernetes のコマンドライン クライアントである kubectl を使います。 Azure Cloud Shell を使用している場合、kubectl は既にインストールされています。 kubectl をローカルにインストールするには、az aks install-cli コマンドを使用します。

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

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
    
  2. kubectl get コマンドを使用して、クラスターへの接続を確認します。 このコマンドは、クラスター ノードの一覧を返し、各ノードのノード プールを示します。

    kubectl get nodes -L kubernetes.azure.com/agentpool,kubernetes.azure.com/mode
    
    NAME                                STATUS   ROLES    AGE     VERSION   AGENTPOOL   MODE
    aks-nodepool1-123456789-vmss000000  Ready    <none>   20m     v1.34.4   nodepool1   system
    aks-gpunp-123456789-vmss000000      Ready    <none>   5m36s   v1.34.4   gpunp       user
    
  3. Kubernetes がマネージド GPU ノード プールで GPU ワークロードをスケジュールできることを確認します。

    kubectl get nodes -l kubernetes.azure.com/agentpool=$GPU_NP -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.allocatable.nvidia\.com/gpu}{"\n"}{end}'
    

    出力には、マネージド GPU ノード プール内の各ノードに割り当て可能な GPU 数が表示されます。

    aks-gpunp-123456789-vmss000000  1
    

GPU メトリック収集を有効にする

マネージド GPU ノード プールには、DCGM メトリック エクスポーターが含まれます。 GPU メトリックAzure Managed Prometheus に取り込むには、まず AKS クラスターで Prometheus Azure Monitorマネージド サービスを有効にします。 次に、Azure Monitor エージェントでdcgmexporterスクレイピング プロファイルを有効にする ConfigMap を作成します。

cat <<EOF | kubectl create -f -
kind: ConfigMap
apiVersion: v1
data:
  schema-version:
    v1
  config-version:
    ver1
  default-scrape-settings-enabled: |-
    dcgmexporter = true
metadata:
  name: ama-metrics-settings-configmap
  namespace: kube-system
EOF

この ConfigMap を適用すると、クラスター上のすべての既存および新しい NVIDIA GPU ノード プールが自動的にスクレイピングされます。 Azure Managed Grafanaで GPU メトリックを表示するには、Azure Kubernetes Service (AKS)での GPU 可観測性に関する説明を参照してください。

アプリケーションをデプロイする

GPU ワークロードをデプロイして、マネージド GPU ノード プールが実際のアプリケーションを実行できることを確認します。 この例では、OpenAI と互換性のある API を介して小規模なオープンソースの大規模言語モデル (Llama 3.2 1B) に対応する Ollama を実行します。 Ollama はllama.cpp上に構築されており、このクイックスタートで使用する Standard_NC4as_T4_v3 ノード プールの NVIDIA T4 GPU をサポートします。

次のマニフェストでは、 DeploymentServiceが作成されます。 Deploymentは 1 つの GPU (nvidia.com/gpu: 1) を要求し、sku=gpu:NoScheduleテイントの容認を含み、ノード セレクターを使用してマネージド GPU ノード プールをターゲットにします。 コンテナーが起動すると、Ollama サーバーが起動し、 llama3.2:1b モデルがプルされ、ポッドが要求を処理する準備が整います。

次のコマンドを使用して、アプリケーションをデプロイします。

cat <<'EOF' | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama
  labels:
    app: ollama
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ollama
  template:
    metadata:
      labels:
        app: ollama
    spec:
      # Schedule onto the managed GPU node pool created in this quickstart.
      nodeSelector:
        kubernetes.azure.com/agentpool: gpunp
      # Tolerate the GPU node pool taint (sku=gpu:NoSchedule).
      tolerations:
        - key: "sku"
          operator: "Equal"
          value: "gpu"
          effect: "NoSchedule"
      containers:
        - name: ollama
          image: ollama/ollama:0.30.10
          ports:
            - name: http
              containerPort: 11434
          env:
            # Listen on all interfaces so the Service and kubelet probes can reach it.
            - name: OLLAMA_HOST
              value: "0.0.0.0:11434"
            # Model to pull and serve on startup. Fits comfortably on a 16-GB T4.
            - name: MODEL
              value: "llama3.2:1b"
          # Start the server, wait until it's ready, and then pull the model so the
          # pod is self-contained (no manual "ollama pull" step required).
          command: ["/bin/sh", "-c"]
          args:
            - |
              ollama serve &
              pid=$!
              echo "Waiting for the Ollama server to be ready..."
              until ollama list >/dev/null 2>&1; do sleep 2; done
              echo "Server ready. Pulling model: $MODEL"
              ollama pull "$MODEL" || echo "WARN: pull failed; run 'kubectl exec deploy/ollama -- ollama pull $MODEL' manually"
              echo "Model $MODEL is ready to serve."
              wait $pid
          resources:
            requests:
              cpu: "1"
              memory: 4Gi
            limits:
              cpu: "4"
              memory: 16Gi
              nvidia.com/gpu: 1
          startupProbe:
            httpGet:
              path: /api/tags
              port: http
            periodSeconds: 5
            failureThreshold: 60
          readinessProbe:
            httpGet:
              path: /api/tags
              port: http
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /
              port: http
            periodSeconds: 20
          volumeMounts:
            - name: ollama-data
              mountPath: /root/.ollama
      volumes:
        - name: ollama-data
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: ollama
  labels:
    app: ollama
spec:
  type: ClusterIP
  selector:
    app: ollama
  ports:
    - name: http
      port: 11434
      targetPort: http
EOF

Note

このマニフェストは、 gpunp ノード プールを対象とします。 GPU_NP変数に別の値を使用した場合は、マニフェストを適用する前に、kubernetes.azure.com/agentpool ノード セレクターの値を一致するように更新します。

kubectl ロールアウト状態コマンドを使用して、デプロイの準備ができていることを確認します。 最初のモデルのダウンロードには数分かかる場合があります。

kubectl rollout status deployment/ollama --timeout=600s

kubectl get コマンドを使用して、ポッドがマネージド GPU ノード プールで実行されていることを確認します。

kubectl get pods -l app=ollama -o wide

出力には、 gpunp ノード プール内のノードで実行されているポッドが表示されます。

NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE                            NOMINATED NODE   READINESS GATES
ollama-5b8f6c9d4f-2xq7p   1/1     Running   0          5m    10.244.1.10   aks-gpunp-12345678-vmss000000   <none>           <none>

アプリケーションをテストする

kubectl port-forward コマンドを使用して、ローカル ポートをServiceに転送します。 このコマンドを実行したまま、残りの手順用に 2 つ目のターミナルを開きます。

kubectl port-forward svc/ollama 11434:11434

2 番目のターミナルで、OpenAI と互換性のあるチャット入力候補エンドポイントを使用して、モデルにプロンプトを送信します。

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.2:1b",
    "messages": [{"role": "user", "content": "In one sentence, what is Azure Kubernetes Service?"}]
  }'

このモデルは、生成された回答を含む JSON 応答を返します。これは、ワークロードがマネージド GPU ノード プールからの推論を処理していることを確認します。

ollama ps コマンドを使用して、モデルが GPU に読み込まれたことを確認します。 PROCESSOR列には、モデルが T4 で実行されたときの100% GPUが表示されます。

kubectl exec deploy/ollama -- ollama ps
NAME          ID              SIZE      PROCESSOR    CONTEXT   UNTIL
llama3.2:1b   baf6a787fdff    1.5 GB    100% GPU     4096      4 minutes from now

nvidia-smi コマンドを使用して、ポッド内から直接 GPU を表示することもできます。

kubectl exec deploy/ollama -- nvidia-smi

テストが完了したら、ターミナルで Ctrl + C キーを押して、kubectl port-forward プロセスを停止します。 次の手順でクラスターを削除すると、アプリケーションは削除されます。

クラスターを削除する

AKS チュートリアルを実行する予定がない場合は、不要なリソースをクリーンアップして、Azure の課金料金を回避します。 az group delete コマンドを使用して、リソース グループ、コンテナー サービス、およびすべての関連リソースを削除できます。

az group delete --name $RESOURCE_GROUP --no-wait --yes

システム割り当てマネージド ID を使用して AKS クラスターを作成しました。これは、このクイックスタートで使用される既定の ID オプションです。 この ID はプラットフォームによって管理されるため、手動で削除する必要はありません。

次のステップ

このクイック スタートでは、Kubernetes クラスターをデプロイした後、Linux ベースのマネージド GPU ノード プールを追加しました。 マネージド GPU ノードと GPU メトリックの詳細については、次の記事を参照してください。

AKS の詳細を確認し、完全なコードからデプロイの例を実行するには、Kubernetes クラスターのチュートリアルに進んでください。