このトピックでは、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 管理クラスタとワークロード クラスタはパブリックです。ただし、プライベートに構成することもできます。その場合、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 インターネット接続を介してインターネットにアクセスできるようにする必要がある場合は、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」を参照してください。
Tanzu Kubernetes Grid は、複数のターゲット プラットフォーム アカウントでワークロード クラスタを実行できます。たとえば、クラウド使用量を複数のチームに分割したり、本番、ステージング、開発の各ワークロードに異なるセキュリティ プロファイルを適用したりできます。
ワークロード クラスタを、管理クラスタの展開に使用されるアカウントとは異なる代替 Azure サービス プリンシパル アカウントに展開するには、次の手順を実行します。
代替 Azure アカウントを作成します。このアカウントの詳細を使用して、後の手順で AzureClusterIdentity を作成します。Azure サービス プリンシパル アカウントの作成については、「How to: Use the portal to create an Azure AD application and service principal that can access resources」(Azure ドキュメント)を参照してください。
kubectl
のコンテキストを管理クラスタに設定します。
kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
ここで、MY-MGMT-CLUSTER
は管理クラスタの名前です。
次の内容で secret.yaml
ファイルを作成します。
apiVersion: v1
kind: Secret
metadata:
name: SECRET-NAME
type: Opaque
data:
clientSecret: CLIENT-SECRET
ここで、
SECRET-NAME
はクライアント パスワードのシークレット名です。CLIENT-SECRET
はサービス プリンシパル ID のクライアント シークレットです。クライアント シークレットは base64 でエンコードされている必要があります。このファイルを使用して Secret
オブジェクトを作成します。
kubectl apply -f secret.yaml
次の内容で 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 名前空間です。これらの名前空間は、名前空間の配列を使用して選択できます。このファイルを使用して 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 ポータルにログインすると、クラスタが実行中であることが表示されます。
Azure に NVIDIA GPU 対応のワークロード クラスタを展開するには、次の 2 つの方法があります。
ClusterResourceSet
(CRS) を使用して管理クラスタを構成し、GPU 対応のワークロード クラスタを自動的に 1 つ以上作成します。以降のサブセクションでは、これら 2 つの方法と、GPU 対応クラスタをテストする方法について説明します。
ワークロード クラスタを展開し、Azure で使用可能な NVIDIA GPU 仮想マシンを利用するように手動で構成するには、次の手順を実行します。
クラスタの構成ファイルで、ワーカー ノードの AZURE_NODE_MACHINE_TYPE
を GPU 互換の仮想マシン タイプ(Standard_NC4as_T4_v3
など)に設定します。
クラスタ構成ファイルを使用してクラスタを展開します。
tanzu cluster create MY-GPU-CLUSTER -f MY-GPU-CONFIG
ここで、MY-GPU-CLUSTER
はクラスタに付ける名前です。
GPU クラスタ ポリシーと GPU オペレータをクラスタにインストールします。
kubectl context
が現在のコンテキストでない場合は、クラスタに設定します。
クラスタ API プロバイダ Azure リポジトリから必要な NVIDIA GPU リソースをダウンロードし、現在のディレクトリに保存します。
クラスタ ポリシーを適用します。
kubectl apply clusterpolicy-crd.yaml
GPU オペレータを適用します。
kubectl apply gpu-operator-components.yaml
kubectl get pods -A
を実行します。default
名前空間内の gpu-operator-
ポッドと、gpu-operator-resources
名前空間内の nvidia-
ポッドのリストが表示されます。
注この機能は、サポートされていない「テクニカル プレビュー」状態です。「TKG の機能状態」を参照してください。
クラスタ マニフェストのラベルに gpu: nvidia
を追加するたびに、GPU 対応のワークロード クラスタを自動的に作成するように、管理クラスタを構成できます。これを行うには、ClusterResourceSet
(CRS) をインストールし、次のように有効化します。
GPU クラスタを作成するように管理クラスタを構成するには、次の手順を実行します。
VMware {code} Sample Exchange で GPU CRS for TKG を検索し、Tanzu Kubernetes Grid v1.4 用の gpu-crs.yaml
ファイルをダウンロードします。
kubectl
のコンテキストを管理クラスタのコンテキストに設定します。
kubectl config use-context my-management-cluster-admin@my-management-cluster
--server-side
オプションを使用して CRS ファイルを管理クラスタに適用し、大きなサイズの ConfigMap
データを処理します。
kubectl apply -f gpu-crs.yaml --server-side
GPU ワークロード クラスタを作成するには、次の手順を実行します。
クラスタの構成ファイルで、ワーカー ノードの AZURE_NODE_MACHINE_TYPE
を GPU 互換の仮想マシン タイプ(Standard_NC4as_T4_v3
など)に設定します。
tanzu cluster create
を --dry-run
オプションを指定して使用し、クラスタ構成ファイルから展開マニフェストを生成します。
tanzu cluster create MY-GPU-CLUSTER -f MY-GPU-CONFIG --dry-run > MY-GPU-CLUSTER-MANIFEST
ここで、MY-GPU-CLUSTER
はクラスタに付ける名前です。
kubectl apply
に渡してクラスタを作成します。
kubectl apply -f MY-GPU-CLUSTER-MANIFEST
kubectl get pods -A
を実行します。default
名前空間内の gpu-operator-
ポッドと、gpu-operator-resources
名前空間内の nvidia-
ポッドのリストが表示されます。
GPU 対応クラスタをテストするには、次の手順を実行します。
NVIDIA ドキュメントの CUDA VectorAdd ベクター追加テストを実行して、GPU 処理をテストします。
GPU オペレータをテストします。
ワークロード クラスタのワーカー ノード数をスケール アップします。
tanzu cluster scale MY-GPU-CLUSTER -w 2
kubectl get pods -A
を再度実行します。追加のノード用に gpu-operator-
および nvidia-
ポッドが表示されます。