マルチクラスタ Ingress の設定


このページでは、マルチクラスタ 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 アドレスではサポートされていません。

概要

この演習では、次の手順を行います。

  1. 使用する料金を選択する。
  2. クラスタをデプロイする。
  3. クラスタ認証情報を構成する。
  4. クラスタをフリートに登録します。
  5. 構成クラスタを指定する。このクラスタは、専用のコントロール プレーンにすることも、他のワークロードを実行することもできます。

次の図は、演習を完了した際の環境の様子を示しています。

リージョン、フリート、プロジェクトの関係を示すクラスタ トポロジ。

この図では、リージョン europe-west1us-central1 に、gke-usgke-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 のリソースやトラフィックには影響しないため、いつでも変更できます。

スタンドアロン版の料金

スタンドアロン版の料金を有効にするには、次の手順を行います。

  1. プロジェクトで GKE Enterprise API が無効になっていることを確認します。

    gcloud services list --project=PROJECT_ID | grep anthos.googleapis.com
    

    PROJECT_ID は、GKE クラスタが実行されているプロジェクト ID に置き換えます。

    出力が空のレスポンスの場合、GKE Enterprise API はプロジェクトで無効になり、マルチクラスタ Ingress リソースはスタンドアロン版の料金を使用して課金されます。

  2. プロジェクトで必要な 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-usgke-eu という名前の 2 つの GKE クラスタを作成します。

Autopilot

  1. 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 に置き換えます。

  2. 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 つのクラスタを作成します。

  1. 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 に置き換えます。

  2. 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
    

クラスタ認証情報を構成する

クラスタの認証情報を構成し、クラスタ コンテキストの名前を変更して、リソースをデプロイするときにクラスタを簡単に切り替えられるようにします。

  1. クラスタの認証情報を取得します。

    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 サーバーにアクセスできるようになります。デフォルトでは、認証情報に自動生成された名前が使用されます。

  2. クラスタ コンテキストの名前を変更します。

    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
    

クラスタをフリートに登録する

次のようにして、クラスタをプロジェクトのフリートに登録します。

  1. クラスタを登録します。

    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
    
  2. クラスタがフリートに正常に登録されたことを確認します。

    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"}}]'

次のステップ