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

このページは Cloud Translation API によって翻訳されました。

クラスタを作成する

このページでは、Kubernetes バージョン 1.29.4-gke.200 上の 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 範囲をおすすめします。

サービス: 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
サービスネットワーク: 100.66.0.0/16

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

VNet ネットワーク: 10.0.0.0/16
Pod ネットワーク: 10.0.1.0/24
サービスネットワーク: 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
サービスネットワーク: 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 のアドレス範囲	最大 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 のアドレス範囲	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_federated_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 コンソールの [サービスアカウント] ページで確認できます。プロジェクト番号を検索する方法については、プロジェクトの識別をご覧ください。