マルチクラスタ Service の構成

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

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

MCS を使用して Service をエクスポートすると、その 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 ネットワーク内で稼働しているかどうかに依存します。そうしないと、外部サービスの呼び出しはネットワーク境界を越えることができません。

  • フリートが複数の 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. 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 に置き換えます。これはフリート ホスト プロジェクトです。

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

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

    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 "serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer]" \
    --role "roles/compute.networkViewer"

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

  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 をエクスポートする前に、この方法でグループ化するかを確認してください。default と kube-system の名前空間にサービスをエクスポートすることはおすすめしません。なぜなら、意図しない名前の競合が高確率で発生して、意図しないグループ化が行われるからです。同じ名前と名前空間の 5 つ以上のサービスをエクスポートすると、インポートされたサービスのトラフィック分配が、5 つのエクスポートされたサービスに限定される場合があります。

クラスタ間の 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: external-svc-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: external-svc-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 によって一意に識別されます。この名前と名前空間のペアは、名前空間方式の名前と呼ばれます。

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

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

  • 同時にエクスポートするマルチクラスタ Service の数: 同時にエクスポートする Service ポートは 250 個までにすることをおすすめします。

    一意の Service ポートは、名前空間方式の名前とポート番号（（名前、名前空間、ポート番号）タプル）で識別されます。具体的には、次のようになります。

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

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

    • 2 つのポート（80 と 443）を公開するエクスポートされた 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

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

トラブルシューティング

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

featureState の表示

機能の状態を表示すると、MCS が正常に構成されているかどうかを確認するのに役立ちます。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: {}

トラブルシューティングに最も役立つフィールドは code と description です。

featureState 内のコード

コードは、MCS に関するメンバーの全般的な状態を示します。これらのフィールドは state.code フィールドで確認できます。次の 3 つのコードがあります。

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

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

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

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

featureState 内の説明

この説明は MCS のメンバーシップの状態に関する詳細情報を提供します。これらの説明は 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 です。

既知の問題

複数のポートを持つ 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 の両方に適用されます。

この動作は、今後の MCS リリースで修正される予定です。

共有 VPC を持つ MCS

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

この動作は、今後の MCS リリースで修正される予定です。

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

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

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

この動作は、今後の MCS リリースで修正される予定です。

次のステップ