このページでは、マルチクラスタ Ingress を使用して、異なるリージョンの複数の Google Kubernetes Engine(GKE)クラスタ間でトラフィックをルーティングする方法と、2 つのクラスタを使用する例を紹介します。
マルチクラスタ Ingress(MCI)、マルチクラスタ ゲートウェイ(MCG)、スタンドアロン ネットワーク エンドポイント グループを持つロードバランサ(LB とスタンドアロン NEG)の詳細な比較については、GKE のマルチクラスタ ロード バランシング API を選択するをご覧ください。
マルチクラスタ Ingress のデプロイの詳細については、クラスタ間での Ingress のデプロイをご覧ください。
以下の手順を行うには高い権限が必要で、GKE 管理者により実施される必要があります。
始める前に
作業を始める前に、次のことを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components update
を実行して最新のバージョンを取得する。
要件と制限事項
マルチクラスタ Ingress には次の要件があります。
- Google Cloud CLI バージョン 290.0.0 以降が必要です。
Standard モードのクラスタを使用する場合は、次の要件を満たしていることを確認してください。Autopilot クラスタはすでにこれらの要件を満たしています。
- クラスタで
HttpLoadBalancing
アドオンを有効にする必要があります。このアドオンはデフォルトで有効になっています。無効にしないでください。 - クラスタは VPC ネイティブである必要があります。
- クラスタで GKE 用 Workload Identity 連携を有効にする必要があります。
マルチクラスタ Ingress には次の制限があります。
- 外部アプリケーション ロードバランサでのみサポートされます。
- マルチクラスタ Ingress で管理されていない Compute Engine ロードバランサを、同じプロジェクトで
mci-
という接頭辞を使用して作成しないでください。作成すると削除されます。Google Cloud では、接頭辞mci-[6 char hash]
を使用して、マルチクラスタ Ingress がデプロイする Compute Engine リソースを管理しています。 - HTTPS を構成するには、事前に割り振られた静的 IP アドレスが必要です。HTTPS は、エフェメラル IP アドレスではサポートされていません。
概要
この演習では、次の手順を行います。
- 使用する料金を選択する。
- クラスタをデプロイする。
- クラスタ認証情報を構成する。
- クラスタをフリートに登録します。
- 構成クラスタを指定する。このクラスタは、専用のコントロール プレーンにすることも、他のワークロードを実行することもできます。
次の図は、演習を完了した際の環境の様子を示しています。
この図では、リージョン europe-west1
と us-central1
に、gke-us
と gke-eu
という名前の 2 つの GKE クラスタがあります。クラスタは、マルチクラスタ Ingress コントローラで認識されるようにフリートに登録されます。 フリートを使用すると、GKE クラスタを論理的にグループ化して正規化できるため、インフラストラクチャの管理が容易になり、マルチクラスタ Ingress をはじめとするマルチクラスタ機能を利用できるようになります。フリートの利点と作成方法について詳しくは、フリート管理のドキュメントをご覧ください。
料金を選択する
マルチクラスタ Ingress が、使用する GKE Enterprise の唯一の機能である場合は、スタンドアロン料金を使用することをおすすめします。プロジェクトで他の GKE Enterprise on Google Cloud のコンポーネントまたは機能を使用している場合は、GKE Enterprise プラットフォーム全体を有効にする必要があります。これにより、vCPU ごとに 1 回の課金ですべての GKE Enterprise 機能を使用できるようになります。
有効にする必要がある API は、使用するマルチクラスタ Ingress の料金によって異なります。
- GKE Enterprise API(
anthos.googleapis.com
)が有効になっている場合、クラスタ vCPU の数と GKE Enterprise の料金に応じてプロジェクトに課金されます。 - GKE Enterprise が無効になっている場合は、プロジェクト内のバックエンド マルチクラスタ Ingress Pod の数に基づいて課金されます。
マルチクラスタ Ingress 課金モデルをスタンドアロンから GKE Enterprise に(または GKE Enterprise からスタンドアロンに)変更しても、マルチクラスタ Ingress のリソースやトラフィックには影響しないため、いつでも変更できます。
スタンドアロン版の料金
スタンドアロン版の料金を有効にするには、次の手順を行います。
プロジェクトで GKE Enterprise API が無効になっていることを確認します。
gcloud services list --project=PROJECT_ID | grep anthos.googleapis.com
PROJECT_ID
は、GKE クラスタが実行されているプロジェクト ID に置き換えます。出力が空のレスポンスの場合、GKE Enterprise API はプロジェクトで無効になり、マルチクラスタ Ingress リソースはスタンドアロン版の料金を使用して課金されます。
プロジェクトで必要な API を有効にします。
gcloud services enable \ multiclusteringress.googleapis.com \ gkehub.googleapis.com \ container.googleapis.com \ multiclusterservicediscovery.googleapis.com \ --project=PROJECT_ID
GKE Enterprise の料金
GKE Enterprise の料金を有効にするには、プロジェクトで必要な API を有効にします。
gcloud services enable \
anthos.googleapis.com \
multiclusteringress.googleapis.com \
gkehub.googleapis.com \
container.googleapis.com \
multiclusterservicediscovery.googleapis.com \
--project=PROJECT_ID
プロジェクトで anthos.googleapis.com
が有効になると、Connect に登録されたクラスタは GKE Enterprise の料金に応じて課金されます。
クラスタをデプロイする
europe-west1
リージョンと us-central1
リージョンに、gke-us
と gke-eu
という名前の 2 つの GKE クラスタを作成します。
Autopilot
us-central1
リージョンにgke-us
クラスタを作成します。gcloud container clusters create-auto gke-us \ --region=us-central1 \ --release-channel=stable \ --project=PROJECT_ID
PROJECT_ID
は、実際の Google Cloud プロジェクト ID に置き換えます。europe-west1
リージョンにgke-eu
クラスタを作成します。gcloud container clusters create-auto gke-eu \ --region=europe-west1 \ --release-channel=stable \ --project=PROJECT_ID
Standard
GKE 用 Workload Identity 連携を有効にして 2 つのクラスタを作成します。
us-central1
リージョンにgke-us
クラスタを作成します。gcloud container clusters create gke-us \ --region=us-central1 \ --enable-ip-alias \ --workload-pool=PROJECT_ID.svc.id.goog \ --release-channel=stable \ --project=PROJECT_ID
PROJECT_ID
は、実際の Google Cloud プロジェクト ID に置き換えます。europe-west1
リージョンにgke-eu
クラスタを作成します。gcloud container clusters create gke-eu \ --region=europe-west1 \ --enable-ip-alias \ --workload-pool=PROJECT_ID.svc.id.goog \ --release-channel=stable \ --project=PROJECT_ID
クラスタ認証情報を構成する
クラスタの認証情報を構成し、クラスタ コンテキストの名前を変更して、リソースをデプロイするときにクラスタを簡単に切り替えられるようにします。
クラスタの認証情報を取得します。
gcloud container clusters get-credentials gke-us \ --region=us-central1 \ --project=PROJECT_ID gcloud container clusters get-credentials gke-eu \ --region=europe-west1 \ --project=PROJECT_ID
認証情報はローカルに保存され、kubectl クライアントを使用してクラスタ API サーバーにアクセスできるようになります。デフォルトでは、認証情報に自動生成された名前が使用されます。
クラスタ コンテキストの名前を変更します。
kubectl config rename-context gke_PROJECT_ID_us-central1_gke-us gke-us kubectl config rename-context gke_PROJECT_ID_europe-west1_gke-eu gke-eu
クラスタをフリートに登録する
次のようにして、クラスタをプロジェクトのフリートに登録します。
クラスタを登録します。
gcloud container fleet memberships register gke-us \ --gke-cluster us-central1/gke-us \ --enable-workload-identity \ --project=PROJECT_ID gcloud container fleet memberships register gke-eu \ --gke-cluster europe-west1/gke-eu \ --enable-workload-identity \ --project=PROJECT_ID
クラスタがフリートに正常に登録されたことを確認します。
gcloud container fleet memberships list --project=PROJECT_ID
出力は次のようになります。
NAME EXTERNAL_ID gke-us 0375c958-38af-11ea-abe9-42010a800191 gke-eu d3278b78-38ad-11ea-a846-42010a840114
クラスタを登録すると、GKE によって gke-mcs-importer
Pod がクラスタにデプロイされます。
クラスタの登録の詳細については、GKE クラスタをフリートに登録するをご覧ください。
構成クラスタを指定する
構成クラスタは、メンバー クラスタ間で Ingress を制御する中心となる GKE クラスタです。このクラスタはフリートに登録済みである必要があります。詳細については、構成クラスタの設計をご覧ください。
マルチクラスタ Ingress を有効にして、構成クラスタとして gke-us
を選択します。
gcloud container fleet ingress enable \
--config-membership=gke-us \
--location=us-central1 \
--project=PROJECT_ID
構成クラスタの登録には最大で 15 分ほどかかります。正常な出力は次のようになります。
Waiting for Feature to be created...done.
Waiting for controller to start...done.
失敗した出力は次のようになります。
Waiting for controller to start...failed.
ERROR: (gcloud.container.fleet.ingress.enable) Controller did not start in 2 minutes. Please use the `describe` command to check Feature state for debugging information.
前の手順でエラーが発生した場合は、機能の状態を確認します。
gcloud container fleet ingress describe \
--project=PROJECT_ID
正常な出力は次のようになります。
createTime: '2021-02-04T14:10:25.102919191Z'
membershipStates:
projects/PROJECT_ID/locations/global/memberships/CLUSTER_NAME:
state:
code: ERROR
description: '...is not a VPC-native GKE Cluster.'
updateTime: '2021-08-10T13:58:50.298191306Z'
projects/PROJECT_ID/locations/global/memberships/CLUSTER_NAME:
state:
code: OK
updateTime: '2021-08-10T13:58:08.499505813Z'
マルチクラスタ Ingress のエラーのトラブルシューティングの詳細については、トラブルシューティングとオペレーションをご覧ください。
ライブクラスタへの影響
gcloud container fleet ingress enable
を使用すると、ライブクラスタでマルチクラスタ Ingress の有効化を安全に行うことができます。ダウンタイムが発生したり、クラスタ上のトラフィックに影響することはありません。
共有 VPC
MultiClusterIngress
リソースは、共有 VPC ネットワークのクラスタにデプロイできますが、参加するバックエンド GKE クラスタはすべて同じプロジェクト内に存在する必要があります。異なるプロジェクトの GKE クラスタで同じ Cloud Load Balancing VIP を使用することはサポートされていません。
非共有 VPC ネットワークでは、マルチクラスタ Ingress コントローラがファイアウォール ルールを管理し、ロードバランサからコンテナ ワークロードにヘルスチェックを許可できます。
共有 VPC ネットワークでは、ホスト プロジェクト管理者が、マルチクラスタ Ingress コントローラの代わりにロードバランサ トラフィックのファイアウォール ルールを手動で作成する必要があります。
次のコマンドは、クラスタが共有 VPC ネットワーク上にある場合に作成する必要のあるファイアウォール ルールを示しています。ソース範囲は、ロードバランサがバックエンドにトラフィックを送信するために使用する範囲です。このルールは、MultiClusterIngress
リソースの運用期間中には存在する必要があります。
共有 VPC ネットワーク上にクラスタがある場合は、次のファイアウォール ルールを作成します。
gcloud compute firewall-rules create FIREWALL_RULE_NAME \
--project=HOST_PROJECT \
--network=SHARED_VPC \
--direction=INGRESS \
--allow=tcp:0-65535 \
--source-ranges=130.211.0.0/22,35.191.0.0/16
次のように置き換えます。
FIREWALL_RULE_NAME
: 新しいファイアウォール ルールに付ける任意の名前。HOST_PROJECT
: 共有 VPC ホスト プロジェクトの ID。SHARED_VPC
: 共有 VPC ネットワークの名前。
既知の問題
このセクションでは、マルチクラスタ Ingress の既知の問題について説明します。
config_membership フィールドの InvalidValueError
既知の問題により、Google Cloud CLI からマルチクラスタ Ingress を操作できなくなります。この問題は、バージョン 346.0.0 で発生し、バージョン 348.0.0 で修正されました。gcloud CLI のバージョン 346.0.0 と 347.0.0 をマルチクラスタ Ingress で使用することはおすすめしません。
resource フィールドの値が無効
Google Cloud Armor は、次の GKE バージョンで実行されているマルチクラスタ Ingress 構成クラスタと通信できません。
- 1.18.19-gke.1400 以降
- 1.19.10-gke.700 以降
- 1.20.6-gke.700 以降
Google Cloud Armor セキュリティ ポリシーを構成すると、次のメッセージが表示されます。
Invalid value for field 'resource': '{"securityPolicy": "global/securityPolicies/"}': The given policy does not exist
この問題を回避するには、構成クラスタをバージョン 1.21 以降にアップグレードするか、次のコマンドを使用して BackendConfig CustomResourceDefinition
を更新します。
kubectl patch crd backendconfigs.cloud.google.com --type='json' -p='[{"op": "replace", "path": "/spec/versions/1/schema/openAPIV3Schema/properties/spec/properties/securityPolicy", "value":{"properties": {"name": {"type": "string"}}, "required": ["name" ],"type": "object"}}]'