クラスタを作成する

このページでは、GKE on AWS クラスタを作成する方法について説明します。Terraform を使用して VPC とクラスタを作成することもできます。

準備

クラスタを作成する前に、前提条件をすべて行う必要があります。特に、次のリソースを用意する必要があります。

  • クラスタが動作する AWS VPC。
  • 3 つのコントロール プレーン レプリカ用に最大 3 つの AWS サブネット。それぞれ異なる AWS アベイラビリティ ゾーンに作る必要があります。
  • クラスタを管理するときに GKE on AWS が想定する AWS IAM ロール。これには特定の IAM 権限が必要です。
  • クラスタデータ（etcd）と構成の安静時暗号化のための KMS 対称 CMK 鍵。
  • 各コントロール プレーン レプリカの AWS IAM インスタンス プロファイル。これには特定の IAM 権限が必要です。
  • 各コントロール プレーン レプリカを実行する EC2 インスタンスへの SSH アクセスが必要な場合の、EC2 SSH 認証鍵ペア（省略可）。

これらのリソースは、お客様の責任で作成して管理する必要があります。また、リソースはすべての GKE クラスタ間で共有できます。その他の基盤となるクラスタ スコープ AWS リソースは、GKE on AWS によって管理されます。

クラスタの CIDR 範囲の選択

GKE on AWS でクラスタを作成する場合は、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 AWS では、Pod と Service にオーバーレイ ネットワークを使用するため、これらのネットワークの IP 範囲は VPC 内でルーティングする必要はありません。使用する IP 範囲は、すべて使用可能であることが保証されている必要があります。詳細については、Dataplane V2 をご覧ください。

  • Pod と Service のどちらにもコントロール プレーンかノードプールのサブネット IP 範囲が含まれていない場合、Pod と Service の IP 範囲は VPC ネットワークと重複しても問題ありません。

  • 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 用に予約されており、VPC では使用されない可能性があります。

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

  • VPC ネットワーク: 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 ネットワークが VPC ネットワークと重複していても、コントロール プレーン レプリカとは重複しないため有効です。

  • VPC ネットワーク: 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 範囲がコントロール プレーン ネットワークと重複しているため、無効です。この重複により、ワークロードが VPC ネットワーク内のコントロール プレーン レプリカと通信できなくなる場合があります。

  • VPC ネットワーク: 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

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

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

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

プロジェクト間での登録

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

クラスタを作成する

GKE on AWS でクラスタを作成するには、次のコマンドを使用します。オプションのパラメータなど、このコマンドの詳細については、gcloud container aws のリファレンス ページをご覧ください。

gcloud container aws clusters create CLUSTER_NAME \
  --aws-region AWS_REGION \
  --location GOOGLE_CLOUD_LOCATION \
  --cluster-version CLUSTER_VERSION \
  --fleet-project FLEET_PROJECT \
  --vpc-id VPC_ID \
  --subnet-ids CONTROL_PLANE_SUBNET_1,CONTROL_PLANE_SUBNET_2,CONTROL_PLANE_SUBNET_3 \
  --pod-address-cidr-blocks POD_ADDRESS_CIDR_BLOCKS \
  --service-address-cidr-blocks SERVICE_ADDRESS_CIDR_BLOCKS \
  --role-arn API_ROLE_ARN \
  --database-encryption-kms-key-arn DB_KMS_KEY_ARN \
  --admin-users ADMIN_USERS_LIST \
  --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
  --iam-instance-profile CONTROL_PLANE_PROFILE \
  --tags "Name=CLUSTER_NAME-cp"

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

  • CLUSTER_NAME: 選択したクラスタ名
  • AWS_REGION: クラスタが作成される AWS リージョン。
  • GOOGLE_CLOUD_LOCATION: Google Cloud 管理リージョンで定義されている、このクラスタを管理する Google Cloud のロケーションの名前。
  • CLUSTER_VERSION: クラスタにインストールする Kubernetes のバージョン。
  • FLEET_PROJECT: クラスタを登録する フリート ホスト プロジェクト。別の Google Cloud プロジェクトからこのクラスタを管理する場合は、プロジェクトをまたぐ登録をご覧ください。
  • VPC_ID: このクラスタの AWS VPC の ID
  • CONTROL_PLANE_SUBNET_1、CONTROL_PLANE_SUBNET_2、CONTROL_PLANE_SUBNET_3: クラスタの 3 つのコントロール プレーン インスタンスのサブネット ID
  • POD_ADDRESS_CIDR_BLOCKS: クラスタの Pod の CIDR アドレス範囲に置き換えます。
  • SERVICE_ADDRESS_CIDR_BLOCKS: クラスタの Service の CIDR アドレス範囲に置き換えます。
  • API_ROLE_ARN: GKE Multi-Cloud API ロールの ARN
  • CONTROL_PLANE_PROFILE: クラスタに関連付けられた IAM インスタンスのプロファイル。IAM インスタンス プロファイルを更新する方法について詳しくは、AWS IAM インスタンス プロファイルの更新をご覧ください。
  • DB_KMS_KEY_ARN: クラスタのシークレットを暗号化するための AWS KMS 鍵の Amazon リソース名（ARN）
  • CONFIG_KMS_KEY_ARN: ユーザーデータを暗号化するための AWS KMS 鍵の Amazon リソース名（ARN）に置き換えます
  • ADMIN_USERS_LIST（省略可）: 管理者権限を付与するユーザーのメールアドレスのカンマ区切りリスト。例: kai@example.com,hao@example.com,kalani@example.com」デフォルトは、クラスタを作成するユーザーです。

存在する場合、--tags パラメータは、指定された AWS タグを GKE on AWS によって管理されるすべての基盤となる AWS リソースに適用します。この例では、コントロール プレーン ノードに、そのクラスタが属するクラスタの名前でタグを付けます。

--ssh-ec2-key-pair フラグを使用して SSH 認証鍵ペアを指定しない限り、これらのコントロール プレーン ノードに SSH 接続することはできません。

特定の Google Cloud ロケーションでサポートされている Kubernetes バージョンをすべて表示するには、次のコマンドを実行します。

gcloud container aws get-server-config --location GCP_LOCATION

Cloud Logging / Cloud Monitoring を認可する

GKE on AWS でシステムログと指標を作成して 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）が、クラスタが作成されるまでプロビジョニングされないためです。

次のステップ