Kubernetes の一般的な Service オブジェクトを使用すると、単一の Kubernetes クラスタ内で Service を検出し、アクセスできます。しかし、状態管理、プライバシー、スケーラビリティ、可用性、データ主権の要件に対応するために、アプリケーションを複数のクラスタに分割したい場合もあるかもしれません。MCS を使用すると、複数のクラスタにまたがる Kubernetes アプリケーションをビルドできます。
MCS は、既存の Service オブジェクトを利用する Google Kubernetes Engine（GKE）のクラスタ間サービス ディスカバリおよび呼び出しのメカニズムです。この機能を有効にしたサービスは、仮想 IP を使用してクラスタ全体で検出とアクセスが可能になり、クラスタ内の ClusterIP Service の動作と一致します。既存の Service と同様に、MCS はコミュニティ主導のオープン API と互換性があり、ワークロードの移植性を維持できます。
MCS は GKE の機能です。MCS では、fleet クラスタ内のエクスポートされた Service ごとに Cloud DNS ゾーンとレコードが構成されます。フリートを使用すると、GKE クラスタを論理的にグループ化して正規化できるため、インフラストラクチャの管理が容易になり、MCS をはじめとするマルチクラスタ機能を利用できるようになります。フリートの利点と作成方法について詳しくは、フリート管理のドキュメントをご覧ください。
タイプに関係なく、エクスポートされた Service には必ず 1 つの Cloud DNS レコードがあり、エクスポートされたヘッドレス タイプの Service には、StatefulSet の Pod を含むホスト名を持つ各バックエンド Pod のレコードがあります。Cloud DNS を使用すると、追加料金が発生します。Cloud DNS の料金に従って課金されます。
MCS を使用して Service をエクスポートするには、Service と同じ名前空間と名前を使用して ServiceExport カスタム リソースを作成します。MCS は、フリート内の各クラスタに Service を自動的にインポートします。MCS が Service をインポートすると、次のものが作成されます。
Service と同じ名前空間と名前を使用する ServiceImport カスタム リソース。
Service と同じ名前空間とランダムな名前を使用する Endpoints オブジェクト。
MCS を使用するメリット
MCS を使用すると、次のメリットがあります。
高可用性: 複数のリージョンのクラスタで同じサービスを実行することで、フォールト トレランスが向上します。クラスタ内の Service が使用不能である場合、リクエストをフェイルオーバーして、他のクラスタから提供できます。MCS を使用すると、クラスタをまたいで Service 間の通信を管理することで、コンテナ化されたアプリケーションの可用性を向上させることができます。
共有サービス: 高可用性の確保、ステートフル サービスとステートレス サービスの高度な管理、データ主権要件の遵守のしやすさのため、Kubernetes クラスタを個別に作成するのが一般的な手法です。ただし、Prometheus によるモニタリングや Vault での Secret 管理の使用など、多くの Service はクラスタ全体で共有することが少なくありません。MCS では、各クラスタが Service の独自のローカル レプリカを必要とせずに、すべての機能クラスタで使用される個別のクラスタに共通の共有 Service を簡単に設定できます。
移行: 既存のアプリケーションをマイクロサービスベースのコンテナ化アーキテクチャにモダナイズするには、たいてい複数の Kubernetes クラスタに Service をデプロイする必要があります。MCS は、こうした Service の間の通信をブリッジできるメカニズムを提供することで、アプリケーションの移行を容易にします。特に、同じ Service を 2 つの異なるクラスタにデプロイでき、1 つのクラスタやアプリケーションから他へのトラフィックのシフトが許可されている場合に役立ちます。
次のステップ
マルチクラスタ Ingress について確認する。これにより、North-South および East-West トラフィックで Service を提供できます。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[],[],null,["# Multi-cluster Services\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page provides you with an overview of how GKE multi-cluster\nServices (MCS) works. To learn how to use MCS, see\n[Configuring multi-cluster Services](/kubernetes-engine/docs/how-to/multi-cluster-services).\n\nOverview of MCS\n---------------\n\nKubernetes' familiar [Service](/kubernetes-engine/docs/concepts/service)\nobject lets you discover and access a Service within the\nconfines of a single Kubernetes cluster. However, sometimes you might want to\nsplit applications into multiple clusters, to address state management, privacy,\nscalability, availability, and data sovereignty requirements. With MCS, you can\nbuild Kubernetes applications that span multiple clusters.\n\nMCS is a cross-cluster Service discovery and invocation\nmechanism for Google Kubernetes Engine (GKE) that leverages the existing Service\nobject. Services enabled with this feature are discoverable and accessible\nacross clusters with a virtual IP, matching the behavior of a\n[ClusterIP Service](/kubernetes-engine/docs/concepts/service#services_of_type_clusterip)\naccessible in a cluster. Just like your existing Services, MCS is\ncompatible with community-driven and open APIs, ensuring your workloads remain\nportable.\n\nMCS is a feature of GKE. MCS configures Cloud DNS zones and\nrecords for each exported Service in your [fleet clusters](/kubernetes-engine/fleet-management/docs). A fleet lets you logically group and normalize your GKE clusters, making administration of infrastructure easier and enabling the use of multi-cluster features such as MCS. You can learn more about the benefits of fleets and how to create them in the [fleet management documentation](/kubernetes-engine/fleet-management/docs).\n\nExported Services regardless of type always have one Cloud DNS record, and exported Headless type services have records for each backend Pod with a hostname, including Pods in StatefulSets.\nUsing Cloud DNS incurs additional charges. You are billed according to\n[Cloud DNS pricing](https://cloud.google.com/dns/pricing).\n\nTo export a Service with MCS, create a ServiceExport custom resource using the same\nnamespace and name as the Service. MCS automatically imports the Service to each\ncluster in the fleet. When MCS imports a Service, it creates:\n\n- A ServiceImport custom resource using the same namespace and name as the Service.\n- An Endpoints object using the same namespace as the Service and a random name.\n\nBenefits of using MCS\n---------------------\n\nUsing MCS provides you with the following benefits:\n\n- **High availability**: Running the same Service across clusters in multiple regions provides you with improved fault tolerance. If a Service in a cluster is unavailable, the request can fail over and be served from other clusters. With MCS, it's possible to manage the communication between Services across clusters, to improve the availability of your containerized applications.\n- **Stateful and stateless Services**: Stateful and stateless Services have different operational dependencies and complexities and present different operational tradeoffs. Typically, the absence of state management makes it easier to scale, upgrade, and migrate a workload with higher availability. MCS lets you separate clusters for stateful and stateless workloads and make them independent, isolated, and easier to manage.\n- **Shared Services** : It's common to create separate Kubernetes clusters to get higher availability, better management of stateful and stateless Services, and easier compliance with data sovereignty requirements. However, many Services such as [monitoring with Prometheus](/stackdriver/docs/managed-prometheus) or [using secrets management with Vault](https://www.cloudskillsboost.google/focuses/1210?parent=catalog) are often shared among all clusters. Instead of each cluster requiring its own local Service replica, MCS makes it easier to set up common shared Services in a separate cluster that all functional clusters use.\n- **Migration**: Modernizing an existing application into a containerized microservice-based architecture often requires you to deploy Services across multiple Kubernetes clusters. MCS provides you with a mechanism to help bridge the communication between those Services, making it easier to migrate your applications. This is especially helpful as you can deploy the same Service to two different clusters and traffic is allowed to shift from one cluster or application to another.\n\nWhat's next\n-----------\n\n- Learn more about [Multi Cluster Ingress](/kubernetes-engine/docs/concepts/multi-cluster-ingress), which provides Services for north-south and east-west traffic directions.\n- Learn more about [Cloud Service Mesh](/anthos/service-mesh), which provides you with finer-grained control over routing and traffic shaping."]]
