クラスタを作成する

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

始める前に

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

  1. 前提条件を構成するの手順に沿って操作します。

  2. コントロール プレーンを複数のゾーンで実行するか、単一のゾーンで実行するかを選択します。

  3. クラスタに対して指定するクラスレス ドメイン間ルーティング(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 つ使用できます。

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

  1. 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 をテキスト エディタにコピーします。

  2. サブネット 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/8172.16.0.0/12192.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/24198.51.100.0/24203.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/16172.16.1.0/24172.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/2410.0.4.0/2410.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/2410.0.2.0/2410.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 個の認証情報を追加できます。

  1. 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)")
    
  2. 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 プロジェクトの番号。
  3. 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 認証鍵ペアを指定する必要があります。使用する鍵ペアがすでにある場合は、このステップをスキップします。

  1. 新しい鍵ペアを作成するには、ssh-keygen コマンドライン ツールを使用します。

    ssh-keygen -m PEM -t rsa -b 4096 -f KEY_PATH
    

    KEY_PATH は、新しい秘密鍵のパスに置き換えます。

  2. 鍵を環境変数に保存します。

    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 ポリシー バインディングをマルチクラウド サービス エージェント サービス アカウントに適用する必要があります。これにより、サービス アカウントはフリート ホスト プロジェクトでフリートを管理できます。

  1. プロジェクトにサービス エージェントを追加するには、次のコマンドを実行します。

    gcloud beta services identity create --service=gkemulticloud.googleapis.com \
      --project=CLUSTER_PROJECT_NUMBER
    

    CLUSTER_PROJECT_NUMBER は、実際の Google Cloud プロジェクトの番号に置き換えます。

  2. 次のコマンドを使用して、このバインディングを割り当てます。

    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 コンソールの [サービス アカウント] ページで確認できます。プロジェクト番号を検索する方法については、プロジェクトの識別をご覧ください。

クラスタを作成する

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

  1. 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 の名前
  2. 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
    

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

  3. クラスタのステータスを確認します。

    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 公開鍵へのアクセス権。

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

  1. 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: 鍵ペアのパス
  2. 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}"
    

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

  3. ノードプールのステータスを確認します。

    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 であるかどうか、など)が含まれます。

次のステップ