クラスタを作成する
このページでは、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 コンソールの [サービス アカウント] ページで確認できます。プロジェクト番号を検索する方法については、プロジェクトの識別をご覧ください。
クラスタを作成する
クラスタを作成するには、次のコマンドを実行します。
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.29.4-gke.200 \ --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.29.4-gke.200 \ --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 名
クラスタのステータスを確認します。
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 Workload Identity 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.29.4-gke.200 \ --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
のリファレンス ドキュメントを読む。- クラスタの作成で問題が発生した場合について、トラブルシューティングで詳細を確認する。