Azure 上のクラスタ

このトピックでは、Microsoft Azure 固有の機能、およびクラスタのフラット構成ファイルや Kubernetes スタイルのオブジェクト仕様では完全に構成できない機能を使用するように、Tanzu Kubernetes Grid (TKG) ワークロード クラスタを構成する方法について説明します。

構成ファイルとオブジェクト仕様を使用して、Azure でワークロード クラスタを構成する方法については、「Azure クラスタの構成ファイル」を参照してください。

重要

Tanzu Kubernetes Grid v2.4.x は、Azure での TKG ワークロード クラスタの作成をサポートする TKG の最後のバージョンです。Azure で TKG ワークロード クラスタを作成する機能は、Tanzu Kubernetes Grid v2.5 リリースで削除される予定です。

以降、VMware では、Azure で新しい TKG ワークロード クラスタを作成する代わりに、Tanzu Mission Control を使用してネイティブの Azure AKS クラスタを作成することをお勧めします。Tanzu Mission Control を使用してネイティブの Azure AKS クラスタを作成する方法については、Tanzu Mission Control ドキュメントの「Azure AKS クラスタのライフサイクルの管理」を参照してください。

詳細については、『VMware Tanzu Kubernetes Grid v2.4 Release Notes』の「AWS および Azure での TKG 管理クラスタとワークロード クラスタの廃止」を参照してください。

Azure プライベート クラスタ

デフォルトでは、Azure 管理クラスタとワークロード クラスタはパブリックです。ただし、プライベートに構成することもできます。その場合、API サーバは Azure 内部ロード バランサ (ILB) を使用するため、クラスタ独自の VNet またはピアリングされた VNet 内からのみアクセスできます。

Azure クラスタをプライベートにするには、構成ファイルに次の設定を含めます。

• AZURE_ENABLE_PRIVATE_CLUSTER を true に設定します。

• （オプション）AZURE_FRONTEND_PRIVATE_IP をクラスタのロード バランサの内部アドレスに設定します。

  • このアドレスは制御プレーン サブネットの範囲内にする必要があり、別のコンポーネントで使用することはできません。
  • 設定しない場合、このアドレスはデフォルトで 10.0.0.100 になります。

• AZURE_VNET_NAME、AZURE_VNET_CIDR、AZURE_CONTROL_PLANE_SUBNET_NAME、AZURE_CONTROL_PLANE_SUBNET_CIDR、AZURE_NODE_SUBNET_NAME、および AZURE_NODE_SUBNET_CIDR を、他の Azure プライベート クラスタに使用する VNet とサブネットに設定します。

  • Azure プライベート クラスタは VNet の外部からアクセスできないため、管理クラスタと、それが管理するワークロードおよび共有サービス クラスタは、同じプライベート VNet に配置する必要があります。
  • Tanzu CLI を実行してプライベート クラスタを作成し、使用するブートストラップ マシンも、同じプライベート VNet 内にある必要があります。

• （オプション）制御プレーンとワーカー ノードが Azure インターネット接続を介してインターネットにアクセスできるようにする必要がある場合は、AZURE_ENABLE_CONTROL_PLANE_OUTBOUND_LB と AZURE_ENABLE_NODE_OUTBOUND_LB を true に設定します。

  • デフォルトでは、Azure プライベート クラスタはロード バランサ タイプの Kubernetes サービスごとにパブリック IP アドレスを作成します。代わりにプライベート IP アドレスを使用するようにロード バランサ サービスを構成するには、展開マニフェストに次の注釈を追加します。

    ---
    metadata:
    annotations:
      service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    

詳細については、クラスタ API プロバイダ Azure ドキュメントの「API Server Endpoint」を参照してください。

異なる Azure アカウント上のクラスタ

Tanzu Kubernetes Grid は、複数のターゲット プラットフォーム アカウントでワークロード クラスタを実行できます。たとえば、クラウド使用量を複数のチームに分割したり、本番、ステージング、開発の各ワークロードに異なるセキュリティ プロファイルを適用したりできます。

ワークロード クラスタを、管理クラスタの展開に使用されるアカウントとは異なる代替 Azure サービス プリンシパル アカウントに展開するには、次の手順を実行します。

1. 代替 Azure アカウントを作成します。このアカウントの詳細を使用して、後の手順で AzureClusterIdentity を作成します。Azure サービス プリンシパル アカウントの作成については、「How to: Use the portal to create an Azure AD application and service principal that can access resources」（Azure ドキュメント）を参照してください。

2. kubectl のコンテキストを管理クラスタに設定します。

   kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
   

   ここで、MY-MGMT-CLUSTER は管理クラスタの名前です。

3. 次の内容で secret.yaml ファイルを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: SECRET-NAME
   type: Opaque
   data:
     clientSecret: CLIENT-SECRET
   

   ここで、

   • SECRET-NAME はクライアント パスワードのシークレット名です。
   • CLIENT-SECRET はサービス プリンシパル ID のクライアント シークレットです。クライアント シークレットは base64 でエンコードされている必要があります。

4. このファイルを使用して Secret オブジェクトを作成します。

   kubectl apply -f secret.yaml
   

5. 次の内容で identity.yaml ファイルを作成します。

   apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
   kind: AzureClusterIdentity
   metadata:
     name: EXAMPLE-IDENTITY
     namespace: EXAMPLE-NAMESPACE
   spec:
     type: ManualServicePrincipal
     tenantID: AZURE-TENANT-ID
     clientID: CLIENT-ID
     clientSecret: {"name":"SECRET-NAME","namespace":"default"}
     allowedNamespaces:
       list:
       - CLUSTER-NAMESPACE-1
       - CLUSTER-NAMESPACE-1
   

   ここで、

   • EXAMPLE-IDENTITY は AzureClusterIdentity に使用する名前です。
   • EXAMPLE-NAMESPACE は AzureClusterIdentity の名前空間です。
   • AZURE-TENANT-ID は Azure テナント ID です。
   • CLIENT-ID は Azure AD アプリケーションのクライアント ID（AppID とも呼ばれます）です。
   • SECRET-NAME はクライアント パスワードのシークレット名です。
   • CLUSTER-NAMESPACE-1 および CLUSTER-NAMESPACE-2 は、クラスタで ID の使用が許可されている Kubernetes 名前空間です。これらの名前空間は、名前空間の配列を使用して選択できます。

6. このファイルを使用して AzureClusterIdentity オブジェクトを作成します。

   kubectl apply -f identity.yaml
   

新しい AzureClusterIdentity オブジェクトを使用して、管理クラスタが代替アカウントにワークロード クラスタを展開できるようになりました。

代替 Azure アカウントを使用するワークロード クラスタを作成するには、クラスタ構成ファイルに次の変数を含めます。

AZURE_IDENTITY_NAME: EXAMPLE-IDENTITY
AZURE_IDENTITY_NAMESPACE: EXAMPLE-NAMESPACE

ここで、

• EXAMPLE-IDENTITY は AzureClusterIdentity に使用する名前です。
• EXAMPLE-NAMESPACE は AzureClusterIdentity の名前空間です。

ワークロード クラスタを作成した後は、代替アカウントを使用して Azure ポータルにログインすると、クラスタが実行中であることが表示されます。

GPU 対応クラスタ

Azure に NVIDIA GPU 対応のワークロード クラスタを展開するには、次の 2 つの方法があります。

• GPU ワーカーを使用してワークロード クラスタを作成し、GPU ポリシーとオペレータをクラスタに手動でインストールします。
• （テクニカル プレビュー）ClusterResourceSet (CRS) を使用して管理クラスタを構成し、GPU 対応のワークロード クラスタを自動的に 1 つ以上作成します。

以降のサブセクションでは、これら 2 つの方法と、GPU 対応クラスタをテストする方法について説明します。

単一クラスタの展開と GPU 有効化

ワークロード クラスタを展開し、Azure で使用可能な NVIDIA GPU 仮想マシンを利用するように手動で構成するには、次の手順を実行します。

1. クラスタの構成ファイルで、ワーカー ノードの AZURE_NODE_MACHINE_TYPE を GPU 互換の仮想マシン タイプ（Standard_NC4as_T4_v3 など）に設定します。

   • Azure の GPU 仮想マシン タイプについては、Azure ドキュメントの「GPU optimized virtual machine sizes」を参照してください。

2. クラスタ構成ファイルを使用してクラスタを展開します。

   tanzu cluster create MY-GPU-CLUSTER -f MY-GPU-CONFIG
   

   ここで、MY-GPU-CLUSTER はクラスタに付ける名前です。

3. GPU クラスタ ポリシーと GPU オペレータをクラスタにインストールします。

   1. kubectl context が現在のコンテキストでない場合は、クラスタに設定します。

   2. クラスタ API プロバイダ Azure リポジトリから必要な NVIDIA GPU リソースをダウンロードし、現在のディレクトリに保存します。

      • GPU クラスタ ポリシーのリソース定義
      • GPU オペレータ コンポーネント

   3. クラスタ ポリシーを適用します。

      kubectl apply clusterpolicy-crd.yaml
      

   4. GPU オペレータを適用します。

      kubectl apply gpu-operator-components.yaml
      

4. kubectl get pods -A を実行します。default 名前空間内の gpu-operator- ポッドと、gpu-operator-resources 名前空間内の nvidia- ポッドのリストが表示されます。

GPU クラスタ展開用の管理クラスタの構成（テクニカル プレビュー）

注

この機能は、サポートされていない「テクニカル プレビュー」状態です。「TKG の機能状態」を参照してください。

クラスタ マニフェストのラベルに gpu: nvidia を追加するたびに、GPU 対応のワークロード クラスタを自動的に作成するように、管理クラスタを構成できます。これを行うには、ClusterResourceSet (CRS) をインストールし、次のように有効化します。

1. GPU クラスタを作成するように管理クラスタを構成するには、次の手順を実行します。

   1. VMware {code} Sample Exchange で GPU CRS for TKG を検索し、Tanzu Kubernetes Grid v1.4 用の gpu-crs.yaml ファイルをダウンロードします。

   2. kubectl のコンテキストを管理クラスタのコンテキストに設定します。

      kubectl config use-context my-management-cluster-admin@my-management-cluster
      

   3. --server-side オプションを使用して CRS ファイルを管理クラスタに適用し、大きなサイズの ConfigMap データを処理します。

      kubectl apply -f gpu-crs.yaml --server-side
      

2. GPU ワークロード クラスタを作成するには、次の手順を実行します。

   1. クラスタの構成ファイルで、ワーカー ノードの AZURE_NODE_MACHINE_TYPE を GPU 互換の仮想マシン タイプ（Standard_NC4as_T4_v3 など）に設定します。

      • Azure の GPU 仮想マシン タイプについては、Azure ドキュメントの「GPU optimized virtual machine sizes」を参照してください。

   2. tanzu cluster create を --dry-run オプションを指定して使用し、クラスタ構成ファイルから展開マニフェストを生成します。

      tanzu cluster create MY-GPU-CLUSTER -f MY-GPU-CONFIG --dry-run > MY-GPU-CLUSTER-MANIFEST
      

      ここで、MY-GPU-CLUSTER はクラスタに付ける名前です。

   3. kubectl apply に渡してクラスタを作成します。

      kubectl apply -f MY-GPU-CLUSTER-MANIFEST
      

   4. kubectl get pods -A を実行します。default 名前空間内の gpu-operator- ポッドと、gpu-operator-resources 名前空間内の nvidia- ポッドのリストが表示されます。

GPU 対応クラスタのテスト

GPU 対応クラスタをテストするには、次の手順を実行します。

1. NVIDIA ドキュメントの CUDA VectorAdd ベクター追加テストを実行して、GPU 処理をテストします。

2. GPU オペレータをテストします。

   1. ワークロード クラスタのワーカー ノード数をスケール アップします。

      tanzu cluster scale MY-GPU-CLUSTER -w 2
      

   2. kubectl get pods -A を再度実行します。追加のノード用に gpu-operator- および nvidia- ポッドが表示されます。