マルチクラスタ Service の構成

このページでは、マルチクラスタ Service（MCS）を有効にして使用する方法を説明します。MCS の仕組みとその利点の詳細については、マルチクラスタ Service をご覧ください。

Google Kubernetes Engine（GKE）MCS 機能は、クラスタ境界を超えて Kubernetes Service の範囲を拡張し、複数の GKE クラスタ間で Service を検出して呼び出せるようにします。既存の Service のサブセットまたは新しい Service をエクスポートできます。

MCS を使用して Service をエクスポートすると、その Service はフリート内のすべてのクラスタで使用可能になります。

このページでは、単一プロジェクトで MCS を構成する方法について説明します。共有 VPC を使用するマルチプロジェクトの設定については、共有 VPC を使用したマルチクラスタ Service の設定をご覧ください。

MCS によって管理されるGoogle Cloud リソース

MCS は、 Google Cloudの次のコンポーネントを管理します。

  • Cloud DNS: MCS は、フリート クラスタ内のエクスポートされた Service ごとに Cloud DNS ゾーンとレコードを構成します。これにより、他のクラスタで実行されている Service に接続できます。これらのゾーンとレコードは、複数のクラスタにエクスポートする Service に基づいて作成、読み取り、更新、削除されます。

  • ファイアウォール ルール: MCS は、フリート内のクラスタ間での Pod の相互通信を可能にするファイアウォール ルールを構成します。ファイアウォール ルールの作成、読み取り、更新、削除は、フリートに追加するクラスタに応じて行われます。これらのルールは、GKE クラスタ内の Pod 間の通信を有効にするために GKE が作成するルールと類似しています。

  • Cloud Service Mesh: MCS は、Cloud Service Mesh をコントロール プレーンとして使用して、クラスタ間でエンドポイントとその健全性を追跡します。

要件

MCS の要件は次のとおりです。

  • MCS では、 Google Cloud上の VPC ネイティブ GKE クラスタからの Service のエクスポートのみがサポートされています。詳細については、VPC ネイティブ クラスタを作成するをご覧ください。VPC ネイティブ以外の GKE Standard クラスタは使用できません。

  • クラスタ間の接続が可能かどうかは、それらのクラスタが同じ VPC ネットワーク内、ピアリングした VPC ネットワーク内、または共有 VPC ネットワーク内で稼働しているかどうかに依存します。接続されていない別のネットワークにクラスタがある場合、外部サービスへの呼び出しはブロックされます。クラスタが同じ VPC ネットワーク内にあるプロジェクトで MCS を有効にすることをおすすめします。

    共有 VPC を使用してプロジェクト間のフリートに MCS を設定するには、共有 VPC を使用したマルチクラスタ Service の設定をご覧ください。

  • フリートが複数の Google Cloud プロジェクトと VPC ネットワークにまたがることがありますが、単一のマルチクラスタ Service を単一のプロジェクトと単一の VPC ネットワークからエクスポートする必要があります。

  • MCS はネットワーク ポリシーではサポートされていません。

  • クラスタで HttpLoadBalancing アドオンを有効にする必要があります。HttpLoadBalancing アドオンが有効になっていることを確認します。HttpLoadBalancing アドオンはデフォルトで有効になっています。無効にしないでください。

料金

マルチクラスタ Service は GKE クラスタの管理料金に含まれており、追加料金なしで使用できます。Traffic Director API を有効にする必要がありますが、MCS では Cloud Service Mesh エンドポイントの料金は発生しません。MCS の使用に GKE Enterprise ライセンスは必要ありません。

始める前に

作業を始める前に、次のことを確認してください。

  1. Google Cloud SDK をインストールします。

  2. Google Kubernetes Engine API を有効にします。

    Google Kubernetes Engine API を有効にする

  3. VPC ネットワーク ピアリング、Cloud Interconnect、または Cloud VPN を使用して VPC ネットワークを接続します。

  4. MCS、フリート（ハブ）、Resource Manager、Cloud Service Mesh、Cloud DNS の API を有効にします。

    gcloud services enable \
    multiclusterservicediscovery.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com \
    trafficdirector.googleapis.com \
    dns.googleapis.com \
    --project=PROJECT_ID

    PROJECT_ID は、クラスタをフリートに登録する予定のプロジェクトのプロジェクト ID に置き換えます。

プロジェクトで MCS を有効にする

MCS では、参加する GKE クラスタが同じフリートに登録されている必要があります。フリートで MCS 機能が有効になると、すべてのクラスタがフリート内のクラスタ間で Service をエクスポートできます。

MCS ではフリートへの登録が必要ですが、GKE Enterprise プラットフォームを有効にする必要はありません。

GKE Enterprise

他の GKE Enterprise コンポーネントを使用するための前提条件として、フリート ホスト プロジェクトで GKE Enterprise API が有効になっている場合、プロジェクトのフリートに登録されているクラスタは、GKE Enterprise の料金に従って課金されます。この料金モデルでは、登録済みクラスタ上で GKE Enterprise のすべての機能を 1 vCPU あたりの料金で利用できます。GKE Enterprise API が有効になっているかどうかを確認するには、次のコマンドを使用します。

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

出力が次のような場合は、完全な GKE Enterprise プラットフォームが有効になっており、フリートに登録されているすべてのクラスタで GKE Enterprise の料金が発生します。

anthos.googleapis.com                        Anthos API

これが想定外である場合は、プロジェクト管理者にお問い合わせください。

空の出力は、GKE Enterprise が有効になっていないことを示します。

GKE クラスタで MCS を有効にする

  1. プロジェクトのフリートで MCS 機能を有効にします。

    gcloud container fleet multi-cluster-services enable \
    --project PROJECT_ID

    PROJECT_ID は、クラスタをフリートに登録する予定のプロジェクトのプロジェクト ID に置き換えます。これはフリート ホスト プロジェクトです。

    フリート ホスト プロジェクトでマルチクラスタ Service を有効にすると、サービス アカウント service-PROJECT_NUMBER@gcp-sa-mcsd.iam.gserviceaccount.com が作成されます。

  2. GKE クラスタをフリートに登録します。Workload Identity Federation for GKE を有効にしてクラスタを登録することを強くおすすめします。Workload Identity Federation for GKE を有効にしない場合は、認証用の Google Cloud サービス アカウントを使用してクラスタを登録し、サービス アカウントの認証の追加手順を完了する必要があります。

    Workload Identity Federation for GKE を使用してクラスタを登録するには、次のコマンドを実行します。

    gcloud container fleet memberships register MEMBERSHIP_NAME \
   --gke-cluster CLUSTER_LOCATION/CLUSTER_NAME \
   --enable-workload-identity \
   --project PROJECT_ID

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

    • MEMBERSHIP_NAME: フリート内のクラスタを一意に表すように選択したメンバーシップ名。通常、クラスタのフリート メンバーシップ名はクラスタ名ですが、フリート内に元の名前の別のクラスタがすでに存在している場合は、新しい名前を指定する必要があります。
    • CLUSTER_LOCATION: クラスタが配置されているゾーンまたはリージョン。
    • CLUSTER_NAME: クラスタの名前。

  3. MCS インポータに必要な Identity and Access Management（IAM）権限を付与します。

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/gke-mcs/sa/gke-mcs-importer" \
    --role "roles/compute.networkViewer"

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

    • PROJECT_ID: フリート ホスト プロジェクトのプロジェクト ID。
    • PROJECT_NUMBER: フリート ホスト プロジェクトのプロジェクト番号。

  4. フリート内の各クラスタに、Service を共有する Namespace があることを確認します。必要に応じて、次のコマンドを使用して Namespace を作成します。

    kubectl create ns NAMESPACE

    NAMESPACE は Namespace の名前に置き換えます。

  5. MCS が有効になっていることを確認するには、次のコマンドを実行します。

    gcloud container fleet multi-cluster-services describe \
    --project PROJECT_ID

    出力は次のようになります。

    createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
  projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
    state:
      code: OK
      description: Firewall successfully updated
      updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
  state: ACTIVE
spec: {}

    state の値が ACTIVE でない場合は、トラブルシューティング セクションをご覧ください。

サービス アカウントの認証

サービス アカウントを使用して GKE クラスタをフリートに登録した場合は、サービス アカウントを認証するための追加手順を行う必要があります。MCS は、gke-mcs-importer というコンポーネントをデプロイします。このコンポーネントは Cloud Service Mesh からエンドポイントの更新を受信するため、MCS の有効化の一環として、サービス アカウントに Cloud Service Mesh から情報を読み取るための権限を付与する必要があります。

サービス アカウントを使用する場合、Compute Engine のデフォルトのサービス アカウントまたは独自のノード サービス アカウントを使用できます。

MCS の使用

以下のセクションでは、MCS の使用方法を説明します。MCS は Kubernetes マルチクラスタ サービス API を使用します。

エクスポートする Service の登録

エクスポートする Service をフリート内の他のクラスタに登録するには、次の手順を行います。

  1. export.yaml という名前の ServiceExport オブジェクトを作成します。

    # export.yaml
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
 namespace: NAMESPACE
 name: SERVICE_EXPORT_NAME

    以下を置き換えます。

    • NAMESPACE: ServiceExport オブジェクトの Namespace。この Namespace は、エクスポートする Service の Namespace と一致する必要があります。
    • SERVICE_EXPORT_NAME: クラスタで、フリート内の他のクラスタにエクスポートする Service の名前。

  2. 次のコマンドを実行して ServiceExport リソースを作成します。

    kubectl apply -f export.yaml

Service の最初のエクスポートでは、フリートに登録されているクラスタと同期するまでに約 5 分を要します。Service がエクスポートされると、それに続いてエンドポイントの同期が直ちに行われます。

複数のクラスタから同じ Service をエクスポートして、クラスタ間でトラフィック分配を行う単一の高可用性マルチクラスタ Service エンドポイントを作成できます。同じ名前と Namespace を持つ Service をエクスポートする前に、この方法でグループ化するかを確認してください。default と kube-system の Namespace に Service をエクスポートすることはおすすめしません。なぜなら、意図しない名前の競合が高確率で発生して、意図しないグループ化が行われるからです。同じ名前と Namespace の 6 つ以上の Service をエクスポートすると、インポートされた Service のトラフィック分配が、5 つのエクスポートされた Service に限定される場合があります。

クラスタ間の Service を使用する

MCS は ClusterSetIP とヘッドレス Service のみをサポートしています。DNS「A」レコードのみを使用できます。

ServiceExport オブジェクトを作成すると、次のドメイン名は、フリート クラスタ内の任意の Pod からエクスポートされた Service に解決されます。

 SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

出力には次の値が含まれます。

  • SERVICE_EXPORT_NAME、NAMESPACE: ServiceExport オブジェクトで定義した値。

ClusterSetIP Service では、ドメインが ClusterSetIP に解決されます。この値は、ServiceExport オブジェクトが作成された Namespace 内のクラスタに含まれる ServiceImport オブジェクトで確認できます。ServiceImport オブジェクトは自動的に作成されます。

次に例を示します。

kind: ServiceImport
apiVersion: net.gke.io/v1
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: SERVICE-EXPORT-TARGET
status:
 ports:
 - name: https
   port: 443
   protocol: TCP
   targetPort: 443
 ips: CLUSTER_SET_IP

MCS は、クラスタへの Service のインポートの一部として、Endpoints オブジェクトを作成します。このオブジェクトを調べることで、Service のインポートの進行状況をモニタリングできます。Endpoints オブジェクトの名前を調べるには、インポートした Service に対応する ServiceImport オブジェクトでアノテーション net.gke.io/derived-service の値を探します。次に例を示します。

kind: ServiceImport
apiVersion: net.gke.io/v1
annotations: net.gke.io/derived-service: DERIVED_SERVICE_NAME
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: SERVICE-EXPORT-TARGET

次に、Endpoints オブジェクトを探して、MCS がインポートするクラスタにエンドポイントをすでに伝播しているかどうかを確認します。Endpoints オブジェクトは、ServiceImport オブジェクトと同じ Namespace に、net.gke.io/derived-service アノテーションに格納されている名前で作成されます。次に例を示します。

kubectl get endpoints DERIVED_SERVICE_NAME -n NAMESPACE

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

  • DERIVED_SERVICE_NAME: ServiceImport オブジェクトのアノテーション net.gke.io/derived-service の値。
  • NAMESPACE: ServiceExport オブジェクトの Namespace。

エンドポイントのヘルス ステータスの詳細は、 Google Cloud コンソールの Cloud Service Mesh ダッシュボードで確認できます。

ヘッドレス Service の場合、ドメインはエクスポート側クラスタ内のエンドポイントの IP アドレスリストに解決されます。ホスト名を持つ各バックエンド Pod は、次の形式のドメイン名を使用して個別にアドレス指定することもできます。

 HOSTNAME.MEMBERSHIP_NAME.LOCATION.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

出力には次の値が含まれます。

  • SERVICE_EXPORT_NAME、NAMESPACE: ServiceExport オブジェクトで定義した値。
  • MEMBERSHIP_NAME: Pod が配置されているクラスタのフリート内にある一意の識別子。
  • LOCATION: メンバーシップのロケーション。メンバーシップが global であるか、またはそのロケーションが、Pod が配置されているリージョンまたはゾーンのいずれか（us-central1 など）です。
  • HOSTNAME: Pod のホスト名。

次の形式のドメイン名を使用して、グローバル メンバーシップに登録されたクラスタからエクスポートされたホスト名でバックエンド Pod をアドレス指定することもできます。

HOSTNAME.MEMBERSHIP_NAME.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

MCS の無効化

MCS を無効にするには、次の手順を行います。

  1. フリート内の各クラスタから、作成した各 ServiceExport オブジェクトを削除します。

    kubectl delete serviceexport SERVICE_EXPORT_NAME \
    -n NAMESPACE

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

    • SERVICE_EXPORT_NAME: ServiceExport オブジェクトの名前。
    • NAMESPACE: ServiceExport オブジェクトの Namespace。

  2. 30 分後に ServiceExport がリストから消えていることを確認します。

  3. 他の目的で登録する必要がない場合は、フリートからクラスタの登録を解除します。

  4. multiclusterservicediscovery 機能を無効にします。

    gcloud container fleet multi-cluster-services disable \
    --project PROJECT_ID

    PROJECT_ID は、クラスタを登録したプロジェクトのプロジェクト ID に置き換えます。

  5. MCS の API を無効にします。

    gcloud services disable multiclusterservicediscovery.googleapis.com \
    --project PROJECT_ID

    PROJECT_ID は、クラスタを登録したプロジェクトのプロジェクト ID に置き換えます。

制限事項

クラスタ、Pod、Service ポートの数

以下の上限は適用されません。クラスタやプロジェクトの負荷およびエンドポイントのチャーンレートによっては、これらの上限を超える場合もあります。これらの上限を超えると、パフォーマンスの問題が発生する可能性があります。

Kubernetes では、Service はその名前と所属する Namespace によって一意に識別されます。この名前と Namespace のペアは、名前空間名と呼ばれます。

  • クラスタのエクスポート: 名前空間名で識別される単一の Service を最大 5 つのクラスタから同時に安全にエクスポートできます。この上限を超えると、使用するクラスタにエンドポイントのサブセットのみがインポートされる可能性があります。クラスタの異なるサブセットから、それぞれ異なる Service をエクスポートできます。

  • 単一の Service の背後の Pod 数: 単一の Service の背後の Pod 数を 250 未満に抑えていれば安全です。比較的静的なワークロードと少数のマルチクラスタ Service では、この数を大幅に上回って Service ごとのエンドポイント数が何千にもなる可能性があります。単一クラスタ Service と同様に、すべてのエンドポイントは各ノードの kube-proxy で監視されます。特に複数のクラスタから同時にエクスポートする場合、この上限を超えると、より大きいノードが必要になる場合があります。

  • 同時にエクスポートするマルチクラスタ Service の数: Service を同時にエクスポートする場合、一意の Service ポートが 250 個を超えないようにすることをおすすめします。

    一意の Service ポートは、名前空間名とポート番号（（名前、Namespace、ポート番号）タプル）で識別されます。これは次のことを意味します。

    • 複数のクラスタからエクスポートされた、同じ名前空間名とポートを持つ Service は、単一の一意の Service ポートとしてカウントされます。

    • 名前とポートは同じだが、Namespace が異なる 2 つの Service（（name、ns1、port-80）と（name、ns2、port-80）など）は、2 つの異なる Service ポートとなり、250 個の一意の Service ポート上限のうちの 2 つとカウントされます。

    • 80 と 443 の 2 つのポートを公開するエクスポートされた Service は、この Service を同時にエクスポートするフリート内のクラスタの数に関係なく、250 個の一意の Service ポート上限のうちの 2 つとカウントされます。

    各マルチクラスタ Service はバックエンド サービスの割り当てに計上され、各エクスポート側クラスタの各ゾーンがネットワーク エンドポイント グループ（NEG）を作成します。これらの割り当てを増やしても、一意の Service ポートの合計数の上限は変更されません。

サービスタイプ

MCS は ClusterSetIP とヘッドレス Service のみをサポートしています。NodePort と LoadBalancer Service はサポートされておらず、予期しない動作が発生する可能性があります。

MCS での IPmasq エージェントの使用

デフォルトまたはその他のマスカレードされていない Pod IP 範囲を使用すると、MCS は期待どおりに動作します。

カスタム Pod IP 範囲またはカスタム IPmasq エージェント ConfigMap を使用すると、MCS トラフィックがマスカレードされる可能性があります。ファイアウォール ルールで Pod IP からのトラフィックのみが許可されるため、MCS は機能しません。

この問題を回避するには、デフォルトの Pod IP 範囲を使用するか、IPmasq エージェント ConfigMap の nonMasqueradeCIDRs フィールドにすべての Pod IP 範囲を指定します。Autopilot を使用しているか、デフォルト以外の Pod IP 範囲を使用する必要があるときに、ConfigMap ですべての Pod IP 範囲を指定できない場合は、Egress NAT ポリシーを使用して IP マスカレードを構成する必要があります。

MCS サービス内でのポート番号の再利用

プロトコルが異なる場合でも、1 つの MCS サービス内で同じポート番号を再利用することはできません。

これは、1 つの Kubernetes Service 内と、1 つの MCS Service のすべての Kubernetes Service の両方に適用されます。

複数のプロジェクトでクラスタを持つ MCS

同じ名前と Namespace のフリート内にある別のプロジェクトで、他のクラスタによってすでにその Service がエクスポートされている場合、その Service のエクスポートはできません。他のプロジェクト内のフリートにある他のクラスタの Service にはアクセスできますが、それらのクラスタが同じ Namespace 内の同じ Service をエクスポートすることはできません。

トラブルシューティング

以降のセクションでは、MCS のトラブルシューティングのヒントを紹介します。

MCS 機能のステータスを表示する

Feature リソースのステータスを表示すると、MCS が正常に構成されているかどうかを確認するのに役立ちます。次のコマンドを使用してステータスを表示できます。

gcloud container fleet multi-cluster-services describe

出力は次のようになります。

createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
 projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
   state:
     code: OK
     description: Firewall successfully updated
     updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
 state: ACTIVE
spec: {}

これには、resourceState の Feature 全体のステータスや、membershipStates の個々のメンバーシップのステータスなどの情報が含まれます。

GKE クラスタで MCS を有効にするの手順に沿って MCS 機能を有効にしたにもかかわらず、resourceState.state の値が ACTIVE でない場合は、サポートにお問い合わせください。

各メンバーシップのステータスは、パスと state フィールドで構成されます。後者には、トラブルシューティングに役立つ code と description が含まれています。

メンバーシップの状態のコード

state.code フィールドで表されるコードは、MCS に関するメンバーの全般的な状態を示します。次の 4 つの値があります。

  • OK: メンバーシップは MCS に正常に追加され、使用できる状態です。

  • WARNING: MCS は、メンバーシップ設定の調整中です。説明フィールドで、このコードの原因に関する詳細情報を確認できます。

  • FAILED: このメンバーシップは MCS に追加されませんでした。OK コードを使用したフリート内の他のメンバーは、この FAILED メンバーシップの影響を受けません。説明フィールドで、このコードの原因に関する詳細情報を確認できます。

  • ERROR: このメンバーシップにはリソースがありません。OK コードを使用したフリート内の他のメンバーは、この ERROR メンバーシップの影響を受けません。説明フィールドで、このコードの原因に関する詳細情報を確認できます。

メンバーシップの状態の説明

MCS のメンバーシップの状態に関する情報を確認するには、state.description フィールドを確認します。このフィールドには、プロジェクトとハブの構成、フリートとメンバーシップの健全性ステータスに関する情報が表示されます。個々の Service とその構成に関する情報を確認するには、ServiceExport オブジェクトの Status.Conditions フィールドを参照してください。ServiceExport の確認をご覧ください。

state.description フィールドには次の情報が含まれます。

  • Firewall successfully created: このメッセージは、メンバーシップのファイアウォール ルールが正常に作成または更新されたことを示します。メンバーシップのコードは OK です。

  • Firewall creation pending: このメッセージは、メンバーシップのファイアウォール ルールの作成または更新が保留中であることを示します。メンバーシップのコードは WARNING です。このメンバーシップでは、ファイアウォール ルールが保留中の間、新しいマルチクラスタ Service と追加したメンバーシップに対する更新と接続に関する問題が発生する可能性があります。

  • GKE Cluster missing: このメッセージは、登録された GKE クラスタが使用できないか、削除されていることを示します。このメンバーシップのコードは ERROR です。GKE クラスタを削除した後、手動でこのメンバーシップのフリートへの登録を解除する必要があります。

  • Project that member lives in is missing required permissions and/or has not enabled all required APIs - additional setup steps are required: このメッセージは、内部 StatusForbidden（403）エラーが発生したことを示します。メンバーシップのコードは FAILED です。このエラーは、次のような状況で発生します。

    • メンバーのプロジェクトで必要な API が有効にされていない。

      メンバーのクラスタがフリートとは別のプロジェクトに存在する場合は、プロジェクト間の設定を参照して、必要なすべての手順が完了していることを確認してください。すべての手順が完了したら、次のコマンドを使用して、登録プロジェクトで次の API が有効であることを確認します。

      gcloud services enable multiclusterservicediscovery.googleapis.com --project PROJECT_ID
gcloud services enable dns.googleapis.com --project PROJECT_ID
gcloud services enable trafficdirector.googleapis.com --project PROJECT_ID
gcloud services enable cloudresourcemanager.googleapis.com --project PROJECT_ID

      PROJECT_ID は、クラスタを登録したプロジェクトのプロジェクト ID に置き換えます。

    • mcsd または gkehub のサービス アカウントには、メンバーのプロジェクトで追加の権限が必要です。

      mcsd および gkehub サービス アカウントはフリートホスト プロジェクト内に自動的に作成され、必要なすべての権限が付与されているはずです。サービス アカウントが存在することを確認するには、次のコマンドを実行します。

      gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-mcsd
gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-gkehub

      PROJECT_ID は、フリートホスト プロジェクトのプロジェクト ID に置き換えます。

    これらのコマンドにより、mcsd および gkehub サービス アカウントの完全な名前が表示されます。

  • Multiple VPCs detected in the hub - VPC must be peered with other VPCs for successful connectivity: このメッセージは、複数の異なる VPC でホストされているクラスタが同じフリートに登録されたことを示します。メンバーシップ ステータスは OK です。クラスタの VPC ネットワークは、その NetworkConfig のネットワークにより定義されます。マルチクラスタ Service にはフラット ネットワークが必要であり、マルチクラスタ Service が正常に相互接続するためには、これらの VPC がアクティブにピアリングされる必要があります。詳細については、2 つのネットワークをピアリングするをご覧ください。

  • Member does not exist in the same project as hub - additional setup steps are required, errors may occur if not completed.: このメッセージは、プロジェクト間クラスタに追加の設定手順が必要であることを示します。メンバーシップ ステータスは OK です。プロジェクト間のメンバーシップが、フリートと同じプロジェクトに存在していない、メンバー クラスタとして定義されています。詳しくは、プロジェクト間の設定をご覧ください。

  • Non-GKE clusters are currently not supported: このメッセージは、MCS では GKE クラスタのみがサポートされることをお知らせするものです。GKE 以外のクラスタを MCS に追加することはできません。メンバーシップ ステータスは FAILED です。

ServiceExport の確認

個々の Service のステータスと潜在的なエラーを表示するには、その Service の ServiceExport リソースの Status.Conditions フィールドを確認します。

kubectl describe serviceexports PROJECT_ID -n NAMESPACE

出力は次のようになります。

Name:         SERVICE_NAME
Namespace:    NAMESPACE
Labels:       <none>
Annotations:  <none>
API Version:  net.gke.io/v1
Kind:         ServiceExport
Metadata:
  Creation Timestamp:  2024-09-06T15:57:40Z
  Finalizers:
    serviceexport.net.gke.io
  Generation:        2
  Resource Version:  856599
  UID:               8ac44d88-4c08-4b3d-8524-976efc455e4e
Status:
  Conditions:
    Last Transition Time:  2024-09-06T16:01:53Z
    Status:                True
    Type:                  Initialized
    Last Transition Time:  2024-09-06T16:02:48Z
    Status:                True
    Type:                  Exported
Events:                    <none>

MCS コントローラは、ServiceExport リソースを検出すると Status.Conditions フィールドに次の条件を追加します。

  • Initialized: ServiceExport で表される Service を MCS コントローラが取得して調整を試みた場合は true。

  • Exported: ServiceExport で表される Service が正常に検証された場合は true。

各条件には、必須の Type、Status、LastTransitionTime フィールドが含まれています。MCS コントローラが Service を調整して検証すると、対応する条件の Status フィールドが False から True に変わります。

エラー

検証でエラーが発生した場合、コントローラは Exported 条件の Status フィールドを False に設定し、エラーに関する詳細情報を含む Reason フィールドと Message フィールドを追加します。Reason フィールドは次のいずれかの値になります。

  • NoMatchingService: 指定されたクラスタで、ServiceExport の名前と Namespace に一致する Service が見つかりませんでした。
    エクスポートする Kubernetes Service が同じクラスタに存在するかどうかを確認します。両方のリソース（Service と ServiceExport）の名前と Namespace が完全に一致しているかどうかを確認します。

  • Conflict: 同じ名前と Namespace でエクスポートされた Service がすでに存在し、その Service が、この ServiceExport によってエクスポートされる Service と一致しないか、許可されていない別のネットワークまたはプロジェクトからエクスポートされています。制限事項をご覧ください。
    Message フィールドで詳細を確認し、必要に応じて制限事項のセクションを参照してください。Service と ServiceExport の名前と Namespace が一致し、すべてのリソースが同じネットワークまたはプロジェクトに作成されていることを確認します。

  • ReadinessProbeError: Service の背後にある Pod 内のコンテナに readinessProbe が構成されています。Kubernetes ReadinessProbes は Google cloud HealthChecks に変換されるため、同じ制限に従う必要があります。

    readiness チェック フィールドとヘルスチェック パラメータの対応関係は次のとおりです。

    • PeriodSeconds は CheckInterval に対応
    • TimeoutSeconds は Timeout に対応
    • SuccessThreshold は HealthyThreshold に対応
    • FailureThreshold は UnhealthyThreshold に対応

    ReadinessProbes を HealthCheck の制約に合わせるため、MCS は次の処理を実装します。

    • PeriodSeconds と TimeoutSeconds は 300 秒に制限されます。この上限を超える値はエラーをトリガーします。
    • SuccessThreshold と FailureThreshold は 10 秒に制限されます。この上限を超える値はエラーをトリガーします。
    • TimeoutSeconds が PeriodSeconds より大きい場合はエラーが報告され、リソースの作成（場合によってはすべてのリソース）が失敗します。

    このような制限が適用されるのは、スケーラビリティの問題、後続のプローブの重複、ヘルスチェック / readiness の遅延などを防ぐためです。上記の検証に従って、readinessProbe のパラメータを調整します。フリートのすべての Service でこのようなエラーを修正することが重要です。詳細については、既知の問題をご覧ください。

  • ServiceError: 対応する Service の取得中にエラーが発生しました。
    通常、このエラーは Google Cloud インフラストラクチャの問題に関連しています。問題が解決しない場合は、Google Cloud サポートにお問い合わせください。

  • PodsError: バックエンド Pod の取得中にエラーが発生しました。
    通常、このエラーは Google Cloud インフラストラクチャの問題に関連しています。問題が解決しない場合は、Google Cloud サポートにお問い合わせください。

  • EndpointsError: ヘッドレス Service のエンドポイントの集約中にエラーが発生しました。
    通常、このエラーは Google Cloud インフラストラクチャの問題に関連しています。問題が解決しない場合は、Google Cloud サポートにお問い合わせください。

Message フィールドには、エラーに関する追加のコンテキストが示されます。

権限に関する一般的な問題

  • プロジェクトで必要な API が有効になっていない。

    始める前にの指示に従って、必要な API を有効にしてください。

    プロジェクト間のフリートの場合は、共有 VPC を使用したマルチクラスタ Service の設定の適切な必要な API を有効にするセクションの手順に沿って操作します。

  • mcsd または gkehub サービス アカウントに十分な権限がない

    単一プロジェクト設定では、GKE Hub と MCS によって自動作成されるサービス アカウントに、必要な権限がすべて自動的に付与されます。

    プロジェクト間のフリートの場合は、追加の IAM バインディングを作成する必要があります。共有 VPC を使用したマルチクラスタ Service の設定の適切な IAM バインディングを作成するセクションの手順に沿って操作します。

既知の問題

複数のポートを持つ MCS サービス

GKE Dataplane V2 に複数の（TCP/UDP）ポートがあるマルチクラスタ Service には、一部のエンドポイントがデータプレーンでプログラムされないという既知の問題があります。この問題は、1.26.3-gke.400 より前の GKE バージョンに影響します。

回避策として、GKE Dataplane V2 を使用する場合は、複数のポートを持つ 1 つの MCS ではなく、単一のポートを持つ複数の MCS を使用します。

1 つの MCS サービス内で再利用されるポート番号

プロトコルが異なる場合でも、MCS サービス内で同じポート番号を再利用することはできません。

これは、1 つの Kubernetes Service 内と、1 つの MCS Service のすべての Kubernetes Service の両方に適用されます。

共有 VPC を持つ MCS

MCS の現在の実装では、同じ共有 VPC に複数のフリートをデプロイすると、フリート間でメタデータが共有されます。1 つのフリートで Service が作成されると、同じ共有 VPC に属する他のすべてのフリートで、Service のメタデータがエクスポートまたはインポートされて、ユーザーに表示されます。

ヘルスチェックで containerPort の代わりに使用されるデフォルト ポート

Deployment の名前付きポートを参照する targetPort フィールドを使用して Service をデプロイすると、MCS は指定された containerPort ではなく、ヘルスチェックのデフォルト ポートを構成します。

この問題を回避するには、Service フィールド ports.targetPort と Deployment フィールド readinessProbe.httpGet.port で、名前付きの値ではなく数値を使用します。

単一の Service の無効な readinessProbe が他の Service を中断する

ServiceExports の確認で説明されているように、readinessProbe 構成エラーが発生する可能性があります。現在の MCS の実装では、エクスポートされた 1 つの Service でこのエラーが発生すると、フリート内の他の Service の一部またはすべてが同期されなくなる可能性があります。

すべての Service の構成を健全に保つことが重要です。MCS Service が更新されない場合は、いずれの Namespace のいずれのクラスタの ServiceExport も、ステータス条件 Exported が False である理由として ReadinessProbeError を報告していないことを確認します。条件を確認する方法については、ServiceExports の確認をご覧ください。

次のステップ