このドキュメントは 2021 年 11 月にリリースされた GKE on Azure の最新バージョンを対象としています。詳細については、リリースノートをご覧ください。

クラスタを作成する

このページでは、Kubernetes バージョン 1.28.7-gke.1700 上の GKE on Azure にクラスタとノードプールを作成する方法について説明します。

始める前に

このページの手順を完了するには、以下を実行します。

前提条件の構成の手順に沿って操作します。
コントロールプレーンを複数のゾーンで実行するか、単一のゾーンで実行するかを選択します。
クラスタに提供するクラスレスドメイン間ルーティング（CIDR）範囲を選択します。

コントロールプレーンのゾーン配置

デフォルトでは、GKE on Azure は、選択したリージョンの 3 つのゾーン間で同じサブネットに個別のコントロールプレーンレプリカを配置します。これらのゾーンとサブネットを選択できます。

デフォルトのコントロールプレーンレプリカプレースメントを使用する場合は、クラスタの CIDR 範囲の選択に進んでください。

Azure NAT ゲートウェイとクラスタコントロールプレーン

各コントロールプレーンレプリカでは、通常の状態で動作するために Google がホストする管理サービスへの接続も必要です。

Azure NAT ゲートウェイを使用して送信接続を実現する場合は、ゾーン障害がクラスタのコントロールプレーンに与える影響を考慮する必要があります。1 つの NAT ゲートウェイエンドポイントが単一のゾーンに分離されているか、リージョン/非ゾーンであり、これが単一障害点となります。

コントロールプレーンのレプリカを単一のゾーンに配置する場合は、単一のサブネットとゾーンを使用します。送信接続に NAT ゲートウェイを使用する場合は、エンドポイントが同じゾーンに配置されていることを確認してください。

2 つまたは 3 つのゾーンにレプリカを配置する場合は、クラスタの作成時にサブネットとゾーンのリストを渡すことが可能です。2 つのサブネットとゾーンを渡すと、GKE on Azure は最初に指定したゾーンに 2 つのレプリカを配置します。3 つのサブネットとゾーンを渡すと GKE on Azure は、各サブネットにレプリカを配置します。詳細については、レプリカを特定のサブネットに配置するをご覧ください。

高可用性向けの Azure サブネットとゾーンの構成の詳細については、Azure ドキュメントのゾーンスタックによるゾーン分離をご覧ください。

特定のサブネットにレプリカを配置する

このセクションはオプションです。

コントロールプレーンのレプリカが配置されるゾーンを制御するには、--replica-placements フラグを使用して、クラスタの作成時にサブネット ID とゾーンのリストを渡します。コントロールプレーンのレプリカを配置するサブネットとゾーンを最大 3 つ使用できます。

サブネットリストのフォーマットを実行するには、次の手順に従います。

az コマンドラインツールを使用して Azure サブネット ID を取得します。
```
az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name SUBNET_NAME --query "id" -otsv
```
次のように置き換えます。
- CLUSTER_RESOURCE_GROUP_NAME: クラスタを実行する既存のリソースグループ名。
- VNET_RESOURCE_GROUP_NAME: VNet を保持するリソースグループ名。
- VNET_NAME: VNet 名
- SUBNET_NAME: サブネット名
出力はサブネットの ID です。Azure サブネット ID は次のようになります。
```
/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME
```
コントロールプレーンレプリカを作成するサブネットごとに、このコマンドを繰り返します。次の手順で、サブネット ID をテキストエディタにコピーします。
サブネット ID と Azure アベイラビリティゾーンのカンマ区切りのリストを作成し、サブネットとゾーンをコロンで区切ります。たとえば、ゾーン 1 の subnet1、ゾーン 2 の subnet2、ゾーン 3 の subnet3 にコントロールプレーンのレプリカを作成するには、次の文字列を使用します。
```
/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet1:1,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet2:2,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet3:3
```
この文字列をコピーして、クラスタの作成時に --replica-placements フラグの値として使用します。

クラスタの CIDR 範囲の選択

GKE on Azure でクラスタを作成する場合は、Pod と Service に使用する IPv4 アドレス範囲を指定する必要があります。

これらの IP 範囲は、クラスレスドメイン間ルーティング（CIDR）表記を使用して指定されます（例: 100.64.0.0/16）。

推奨される範囲

Service と Pod には、次の CIDR 範囲をおすすめします。

Service: 100.64.0.0/16
Pod: 100.96.0.0/11

これらの範囲は、問題なくクラスタを拡張するのに十分な大きさです。

以降のセクションでさらに詳しく説明します。

範囲の選択に関する詳細

GKE on Azure では、Pod と Service にオーバーレイネットワークを使用するため、これらのネットワークの IP 範囲は VNet 内でルーティング可能である必要はありません。使用する IP 範囲は、すべて使用可能であることが保証されている必要があります。詳細については、Dataplane V2 をご覧ください。

Pod と Service のどちらにもコントロールプレーンかノードプールのサブネット IP 範囲が含まれていない場合、Pod と Service の IP 範囲は VNet ネットワークと重複しても問題ありません。
Pod とサービスの IP 範囲は、次のいずれかのプライベート IP 範囲内にある必要があります。
- 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16: プライベート IP アドレス（RFC 1918）
- 100.64.0.0/10: 共有アドレス空間（RFC 6598）
- 192.0.0.0/24: IETF プロトコル割り当て（RFC 6890）
- 192.0.2.0/24、198.51.100.0/24、203.0.113.0/24: ドキュメント（RFC 5737）
- 192.88.99.0/24: IPv6 から IPv4 へのリレー（サポート終了）（RFC 7526）
- 198.18.0.0/15: ベンチマークテスト（RFC 2544）

100.64.0.0/10（RFC 6598）内の IP 範囲をおすすめします。この範囲はキャリアグレードの NAT 用に予約されており、VNet では使用されない可能性があります。

たとえば、次の構成は、Pod、Service、Node のネットワークが重複しないため有効です（VNet は RFC 1918 のプライベート IP アドレスを使用しており、Pod と Service のネットワークは RFC 6598 のプライベート IP にオーバーレイされます）。

VNet ネットワーク: 10.0.0.0/16、172.16.1.0/24、172.16.2.0/24
Pod ネットワーク: 100.65.0.0/16
Service ネットワーク: 100.66.0.0/16

次の構成も、Pod ネットワークと Service ネットワークが VNet ネットワークと重複していても、コントロールプレーンレプリカとは重複しないため有効です。

VNet ネットワーク: 10.0.0.0/16
Pod ネットワーク: 10.0.1.0/24
Service ネットワーク: 10.0.2.0/24
コントロールプレーンのレプリカのサブネット: 10.0.3.0/24、10.0.4.0/24、10.0.5.0/24

次の構成は、Pod の IP 範囲がコントロールプレーンネットワークと重複しているため、無効です。この重複により、ワークロードが VNet ネットワークのコントロールプレーンレプリカと通信できなくなる可能性があります。

VNet ネットワーク: 10.0.0.0/16
Pod ネットワーク: 10.0.1.0/24
Service ネットワーク: 10.1.0.0/24
コントロールプレーンのレプリカのサブネット: 10.0.1.0/24、10.0.2.0/24、10.0.3.0/24

Pod のアドレス範囲の詳細

Kubernetes は、Pod のアドレス範囲から Pod オブジェクトにアドレスを割り当てます。クラスタの Pod 範囲は、ノードごとにより小さな範囲に分割されます。Pod が特定のノードでスケジュールされると、Kubernetes はノードの範囲から Pod IP を割り当てます。

Pod のアドレス範囲のサイズを計算するには、クラスタに含めるノードの数と、各ノードで実行する Pod の数を見積もる必要があります。

次の表は、実行するノードと Pod の数に基づいた Pod の CIDR 範囲のサイズの推奨値を示しています。

Pod のアドレス範囲のテーブル

ポッドのアドレス範囲	最大 Pod IP アドレス数	最大ノード数	最大 Pod 数
/24 可能な限り最も小さい Pod アドレス範囲	256 個のアドレス	1 個のノード	110 個の Pod
/23	512 個のアドレス	2 個のノード	220 個の Pod
/22	1,024 個のアドレス	4 個のノード	440 個の Pod
/21	2,048 個のアドレス	8 個のノード	880 個の Pod
/20	4,096 個のアドレス	16 個のノード	1,760 個の Pod
/19	8,192 個のアドレス	32 個のノード	3,520 個の Pod
/18	16,384 個のアドレス	64 個のノード	7,040 個の Pod
/17	32,768 個のアドレス	128 個のノード	14,080 個の Pod
/16	65,536 個のアドレス	256 個のノード	28,160 個の Pod
/15	131,072 個のアドレス	512 個のノード	56,320 個の Pod
/14	262,144 個のアドレス	1,024 個のノード	112,640 個の Pod

サービスアドレス範囲の詳細

Kubernetes は、このアドレス範囲からの Service オブジェクト（ロードバランサなど）に仮想 IP アドレスを割り当てます。

サービスアドレス範囲のサイズを計算するには、クラスタに必要なサービスの数を見積もる必要があります。

次の表は、実行する Sercice の数に基づいた Service CIDR 範囲のサイズの推奨を示しています。

サービスアドレス範囲の表

サービスアドレスの範囲	Service の最大数
/27 可能な限り最も小さい Service アドレス範囲	32 個の Service
/26	64 個の Service
/25	128 個の Service
/24	256 個の Service
/23	512 個の Service
/22	1,024 個の Service
/21	2,048 個の Service
/20	4,096 個の Service
/19	8,192 個の Service
/18	16,384 個の Service
/17	32,768 個の Service
/16 可能な限り最も大きい Service アドレス範囲	65,536 個の Service

Azure に対する認証

GKE on Azure には、Workload Identity 連携とクライアント証明書の作成という 2 つの Azure に対する認証方法が用意されています。Workload Identity 連携認証が、よりシンプルで安全なため、おすすめの方法です。

Workload Identity 連携

Workload Identity 連携を使用すると、GKE on Azure が Google サービスアカウントを使用して Azure に対する認証を行い、Azure AD アプリケーションのリソースを管理できます。AzureClient とは異なり、証明書を管理して Azure AD に手動でアップロードする必要はありません。

Azure AD アプリケーションで連携 ID 認証情報を構成するには、次のコマンドを実行します。Azure AD アプリケーションごとに最大 20 個の認証情報を追加できます。

Azure アプリケーション ID を環境変数に保存します。

APPLICATION_ID=$(az ad app list --all \
  --query "[?displayName=='APPLICATION_NAME'].appId" --output tsv)
PROJECT_ID="$(gcloud config get-value project)"
PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" \
--format "value(projectNumber)")

APPLICATION_NAME: Azure Active Directory アプリケーションを作成するときに使用した Azure AD アプリケーション名。

credential.json という名前の JSON ファイルを作成します。

{
  "name": "CREDENTIAL_NAME",
  "issuer": "https://accounts.google.com",
  "subject": "service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com",
  "audiences": ["api://AzureADTokenExchange"],
  "description": "Allow GKE on Azure to authenticate to the Azure AD application using a Google service account."
}

CREDENTIAL_NAME: 認証情報名。
PROJECT_NUMBER: クラスタをホストする Google Cloud プロジェクトの数。

Azure AD アプリケーションで連携 ID 認証情報を作成します。

az ad app federated-credential create --id "${APPLICATION_ID}" --parameters credential.json

詳細については、Azure のドキュメント Azure AD workload identity federation with Google Cloud をご覧ください。

Terraform を使用して Azure 連携 ID 認証情報をプロビジョニングすることもできます。詳しくは、azuread_application_legacyed_identity_credential をご覧ください。

認証情報を構成したら、クラスタの SSH 認証鍵ペアを作成または選択します。

SSH 認証鍵ペアを作成する

クラスタを作成するときに、SSH 認証鍵ペアを指定する必要があります。使用する鍵ペアがすでにある場合は、このステップをスキップします。

新しい鍵ペアを作成するには、ssh-keygen コマンドラインツールを使用します。
```
ssh-keygen -m PEM -t rsa -b 4096 -f KEY_PATH
```
KEY_PATH は、新しい秘密鍵のパスに置き換えます。
鍵を環境変数に保存します。
```
SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)
```
たとえば、~/.ssh/anthos-multicloud-key.pub で新しい鍵ペアを作成し、公開鍵を環境変数に格納するには、次のコマンドを実行します。
```
ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/anthos-multicloud-key
SSH_PUBLIC_KEY=$(cat ~/.ssh/anthos-multicloud-key.pub)
```

公開鍵を環境変数に保存したら、クラスタを作成できます。

フリートホストプロジェクトを選択する

フリートは、クラスタをより大きなグループに整理するための Google Cloud のコンセプトです。フリートを使用すると、複数のクラウドにわたって複数のクラスタを管理し、それらのクラスタに一貫したポリシーを適用できます。GKE Multi-Cloud API では、クラスタの作成時に、クラスタが自動的にフリートに登録されます。

クラスタを作成する際には、クラスタを管理するフリートのホストプロジェクトを指定します。GKE on Azure はフリートメンバーシップ名としてクラスタ名を使用するため、クラスタ名がフリート全体で一意になるようにする必要があります。

プロジェクト間での登録

クラスタが配置されている Google Cloud プロジェクト以外のフリートホストプロジェクトを使用する場合は、追加の IAM ポリシーバインディングをマルチクラウドサービスエージェントサービスアカウントに適用する必要があります。これにより、サービスアカウントはフリートホストプロジェクトでフリートを管理できます。

プロジェクトにサービスエージェントを追加するには、次のコマンドを実行します。
```
gcloud beta services identity create --service=gkemulticloud.googleapis.com \
  --project=CLUSTER_PROJECT_NUMBER
```
CLUSTER_PROJECT_NUMBER は、実際の Google Cloud プロジェクトの番号に置き換えます。
次のコマンドを使用して、このバインディングを割り当てます。
```
gcloud projects add-iam-policy-binding FLEET_PROJECT_ID \
  --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com" \
  --role="roles/gkemulticloud.serviceAgent"
```
次のように置き換えます。
- FLEET_PROJECT_ID: フリートホストプロジェクトの Google Cloud プロジェクト
- CLUSTER_PROJECT_NUMBER: Google Cloud プロジェクト番号。

マルチクラウドサービスエージェントのアカウント名は「service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com」の形式です。

サービスアカウントは、Google Cloud Console の [サービスアカウント] ページで確認できます。プロジェクト番号を検索する方法については、プロジェクトの識別をご覧ください。

クラスタの作成

クラスタを作成するには、次のコマンドを実行します。

Azure リソースグループ、VNet、サブネット ID を環境変数に保存します。

SUBSCRIPTION_ID=$(az account show --query "id" --output tsv)
TENANT_ID=$(az account list \
  --query "[?id=='${SUBSCRIPTION_ID}'].{tenantId:tenantId}" --output tsv)
CLUSTER_RG_ID=$(az group show --resource-group=CLUSTER_RESOURCE_GROUP_NAME \
  --query "id" -otsv)
VNET_ID=$(az network vnet show --resource-group=VNET_RESOURCE_GROUP_NAME \
  --name=VNET_NAME --query "id" -otsv)
SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)

次のように置き換えます。

CLUSTER_RESOURCE_GROUP_NAME: クラスタを実行する既存のリソースグループ名。
VNET_RESOURCE_GROUP_NAME: VNet を保持するリソースグループ名。
VNET_NAME: VNet の名前

Google Cloud CLI を使用してクラスタを作成します。
Workload Identity 連携
```
gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --azure-tenant-id "${TENANT_ID}" \
    --azure-application-id "${APPLICATION_ID}" \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.28.7-gke.1700 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST
```
Azure クライアント
```
gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --client CLIENT_NAME \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.28.7-gke.1700 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST
```
以下を置き換えます。
- CLUSTER_NAME: クラスタの名前。
- GOOGLE_CLOUD_LOCATION: クラスタを管理する Google Cloud のロケーション
- FLEET_PROJECT は、クラスタを登録するフリートホストプロジェクトに置き換えます。別の Google Cloud プロジェクトからこのクラスタを管理する場合は、プロジェクトをまたぐ登録をご覧ください。
- AZURE_REGION: Google Cloud リージョンに関連付けられたサポート対象の Azure リージョン。
- POD_CIDR: クラスタのPod アドレス範囲（例: 10.0.1.0/18）
- SERVICE_CIDR: クラスタのサービスアドレス範囲。
- VM_SIZE: サポートされている Azure VM サイズ
- ADMIN_USERS_LIST（省略可）: 管理者権限を付与するユーザーのメールアドレスのカンマ区切りリスト。例: kai@example.com,hao@example.com,kalani@example.com」デフォルトは、クラスタを作成するユーザーです。
- CLIENT_NAME: AzureClient 名
注: クラスタの作成時に、「--subnet-id」フィールドの代わりに次の 3 つのオプションフィールドを渡すことができます。
- --endpoint-subnet-id: GKE on Azure がコントロールプレーンロードバランサのエンドポイントをデプロイするサブネット。値を指定しない場合、デフォルトは「subnet-id」です。
- --service-load-balancer-subnet-id: Kubernetes プライベート Service タイプのロードバランサがデプロイされるサブネット。値を指定しない場合、デフォルトは「subnet-id」です。
- --replica-placements
クラスタのステータスを確認します。
```
gcloud container azure clusters describe CLUSTER_NAME  --location GOOGLE_CLOUD_LOCATION
```
次のように置き換えます。
- CLUSTER_NAME
- GOOGLE_CLOUD_LOCATION
出力には、クラスタのステータスと構成に関する情報が含まれます。

Cloud Logging / Cloud Monitoring を認可する

GKE on Azure でシステムログと指標を作成して Google Cloud にアップロードするには、承認が必要です。

Kubernetes ワークロード ID gke-system/gke-telemetry-agent が Google Cloud Logging にログを、Google Cloud Monitoring に指標を書き込むことを承認するには、次のコマンドを実行します。

gcloud projects add-iam-policy-binding GOOGLE_PROJECT_ID \
  --member="serviceAccount:GOOGLE_PROJECT_ID.svc.id.goog[gke-system/gke-telemetry-agent]" \
  --role=roles/gkemulticloud.telemetryWriter

GOOGLE_PROJECT_ID をクラスタの Google Cloud プロジェクト ID に置き換えます。

この IAM バインディングは、ログと指標をアップロードするための Google Cloud プロジェクトのプロジェクトにあるすべてのクラスタへのアクセスを許可します。プロジェクトに対して最初のクラスタを作成した後にのみ実行する必要があります。

Google Cloud プロジェクトに 1 つ以上のクラスタを作成しない限り、この IAM バインディングの追加は失敗します。これは、参照する Workload Identity プール（GOOGLE_PROJECT_ID.svc.id.goog）が、クラスタが作成されるまでプロビジョニングされないためです。

ノードプールを作成

ノードプールの作成にあたり、次のものが必要です。

az コマンドラインツールを使用して Azure サブネット ID を取得する権限。
クラスタの SSH 公開鍵へのアクセス権。

ノードプールを作成するには、次のコマンドを実行します。

Azure VNet サブネット ID と SSH 公開鍵を環境変数に保存します。
```
SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)
SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)
```
次のように置き換えます。
- VNET_RESOURCE_GROUP_NAME: VNet を保持するリソースグループ名
- VNET_NAME: VNet の名前
- KEY_PATH: 鍵ペアのパス
Google Cloud CLI を使用してノードプールを作成します。
```
gcloud container azure node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --node-version 1.28.7-gke.1700 \
    --vm-size VM_SIZE \
    --max-pods-per-node 110 \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --ssh-public-key "${SSH_PUBLIC_KEY}" \
    --subnet-id "${SUBNET_ID}"
```
次のように置き換えます。
- NODE_POOL_NAME: ノードプールの一意の名前（node-pool-1 など）
- CLUSTER_NAME: GKE on Azure クラスタの名前
- GOOGLE_CLOUD_LOCATION: クラスタを管理する Google Cloud のロケーション
- VM_SIZE: サポートされている Azure VM サイズ
- MIN_NODES: ノードプール内の最小ノード数。詳細については、クラスタオートスケーラーをご覧ください。
- MAX_NODES: ノードプール内のノードの最大数
ノードプールのステータスを確認します。
```
gcloud container azure node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION
```
次のように置き換えます。
- NODE_POOL_NAME: ノードプールの一意の名前（node-pool-1 など）
- CLUSTER_NAME: GKE on Azure クラスタの名前
- GOOGLE_CLOUD_LOCATION: クラスタを管理する Google Cloud のロケーション
出力には、ノードプールのステータス（PROVISIONING や RUNNING かどうか、など）が含まれます。

次のステップ

kubectl のクラスタアクセスを構成する。
ノードプールを作成します。
クイックスタートを試して最初のワークロードを立ち上げます。
gcloud container clusters create のリファレンスドキュメントを読む。
クラスタの作成で問題が発生した場合、トラブルシューティングで詳細を確認してください。

クラスタを作成する

始める前に

コントロール プレーンのゾーン配置

Azure NAT ゲートウェイとクラスタ コントロール プレーン

特定のサブネットにレプリカを配置する

クラスタの CIDR 範囲の選択

推奨される範囲

範囲の選択に関する詳細

Pod のアドレス範囲の詳細

サービス アドレス範囲の詳細

Azure に対する認証

Workload Identity 連携

SSH 認証鍵ペアを作成する

フリート ホスト プロジェクトを選択する

プロジェクト間での登録

クラスタの作成

Workload Identity 連携

Azure クライアント

Cloud Logging / Cloud Monitoring を認可する

ノードプールを作成

次のステップ

コントロールプレーンのゾーン配置

Azure NAT ゲートウェイとクラスタコントロールプレーン

サービスアドレス範囲の詳細

フリートホストプロジェクトを選択する