Cette page vous offre un aperçu du fonctionnement des services multiclusters GKE (MCS). Pour apprendre à utiliser MCS, consultez la page Configurer les services multiclusters (MCS).
Présentation de MCS
L'objet Service de Kubernetes vous permet de découvrir un service et d'y accéder au sein d'un même cluster Kubernetes. Toutefois, il peut parfois être nécessaire de répartir les applications sur plusieurs clusters afin de répondre aux exigences de gestion d'état, de confidentialité, d'évolutivité, de disponibilité et de souveraineté des données. Avec MCS, vous pouvez créer des applications Kubernetes couvrant plusieurs clusters.
MCS est un mécanisme de découverte des services et d'appel interclusters de Google Kubernetes Engine (GKE) qui exploite l'objet Service existant. Les services activés avec cette fonctionnalité sont détectables et accessibles sur tous les clusters dotés d'une adresse IP virtuelle (semblable au comportement d'un service ClusterIP accessible dans un cluster). À l'instar de vos services existants, MCS est compatible avec les API Open Source impulsées par la communauté, garantissant ainsi la portabilité de vos charges de travail.
MCS est une fonctionnalité de GKE. MCS configure les zones et les enregistrements Cloud DNS pour chaque service exporté dans vos clusters de Fleet. Un parc vous permet de regrouper et de normaliser logiquement des clusters GKE, ce qui facilite l'administration de l'infrastructure et permet d'utiliser des fonctionnalités multicluster telles que MCS. Pour en savoir plus sur les avantages des parcs et leur création, consultez la documentation sur la gestion des parcs.
Les services exportés, quel que soit leur type, disposent toujours d'un enregistrement Cloud DNS. Les services de type "sans interface graphique" disposent d'enregistrements pour chaque pod de backend avec un nom d'hôte, y compris les pods des StatefulSets.
L'utilisation de Cloud DNS entraîne des frais supplémentaires. Vous êtes facturé selon les tarifs Cloud DNS.
Pour exporter un service avec MCS, créez une ressource personnalisée ServiceExport utilisant le même espace de noms et le même nom que le service. MCS importe automatiquement le service dans chaque cluster du parc. Lorsque MCS importe un service, il crée:
Une ressource personnalisée ServiceImport utilisant le même espace de noms et le même nom que le service.
Un objet Endpoints utilisant le même espace de noms que l'objet Service et un nom aléatoire.
Avantages de l'utilisation de MCS
L'utilisation de MCS vous offre les avantages suivants :
Haute disponibilité : l'exécution du même service sur des clusters situés dans plusieurs régions vous offre une tolérance aux pannes supérieure. Si un service d'un cluster n'est pas disponible, la requête peut basculer et être desservie par d'autres clusters. Avec MCS, il est possible de gérer la communication entre les services des clusters afin d'améliorer la disponibilité de vos applications en conteneur.
Services avec état et sans état : les services avec état et sans état présentent des complexités et dépendances opérationnelles différentes, ainsi que des compromis opérationnels différents. Généralement, l'absence de gestion d'état facilite le scaling, la mise à niveau et la migration d'une charge de travail avec une plus haute disponibilité. MCS vous permet de séparer les clusters pour les charges de travail avec état et sans état, afin qu'ils soient indépendants, isolés et plus faciles à gérer.
Services partagés : il est courant de créer des clusters Kubernetes séparés pour obtenir une plus haute disponibilité, une meilleure gestion des services avec état et sans état et une conformité plus facile avec les exigences de souveraineté des données. Cependant, de nombreux services tels que la surveillance via Prometheus ou l'utilisation de la gestion des secrets avec Vault sont souvent partagés entre tous les clusters. MCS facilite la configuration des services partagés communs dans un cluster distinct utilisé par tous les clusters fonctionnels. Cela permet ainsi d'éviter que chaque cluster nécessite sa propre instance dupliquée de service locale.
Migration : la modernisation d'une application existante vers une architecture basée sur des microservices conteneurisés nécessite souvent de déployer des services sur plusieurs clusters Kubernetes. MCS fournit un mécanisme permettant à ces services de communiquer, facilitant ainsi la migration de vos applications. Ceci est particulièrement utile car vous pouvez déployer le même service sur deux clusters différents et le trafic est autorisé à passer d'un cluster ou d'une application à l'autre.
Étape suivante
Apprenez-en plus sur Multi Cluster Ingress, qui fournit des services pour les sens de trafic nord-sud et est-ouest.
Apprenez-en plus sur Cloud Service Mesh, qui vous permet de contrôler avec précision le routage et le lissage du trafic.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]
