Questa pagina fornisce una panoramica del funzionamento di GKE multi-cluster
Services (MCS). Per scoprire come utilizzare MCS, consulta
Configurazione dei servizi multi-cluster.
Panoramica di MCS
Il noto oggetto Service di Kubernetes
consente di scoprire e accedere a un servizio all'interno
dei limiti di un singolo cluster Kubernetes. Tuttavia, a volte potresti voler
dividere le applicazioni in più cluster per soddisfare i requisiti di gestione dello stato, privacy,
scalabilità, disponibilità e sovranità dei dati. Con MCS, puoi
creare applicazioni Kubernetes che si estendono su più cluster.
MCS è un meccanismo di individuazione e chiamata di servizi cross-cluster per Google Kubernetes Engine (GKE) che sfrutta l'oggetto Service esistente. I servizi abilitati con questa funzionalità sono rilevabili e accessibili
nei cluster con un IP virtuale, in linea con il comportamento di un
servizio ClusterIP
accessibile in un cluster. Come i tuoi servizi esistenti, MCS è
compatibile con API open source e basate sulla community, garantendo la portabilità dei tuoi carichi di lavoro.
MCS è una funzionalità di GKE. MCS configura zone e record Cloud DNS per ogni servizio esportato nei cluster del parco risorse. Un parco risorse ti consente di raggruppare e normalizzare logicamente i cluster GKE, semplificando l'amministrazione dell'infrastruttura e consentendo l'utilizzo di funzionalità multi-cluster come MCS. Puoi scoprire di più sui vantaggi dei parchi risorse e su come crearli nella documentazione sulla gestione dei parchi risorse.
I servizi esportati, indipendentemente dal tipo, hanno sempre un record Cloud DNS, mentre i servizi di tipo headless esportati hanno record per ogni pod di backend con un nome host, inclusi i pod in StatefulSet.
L'utilizzo di Cloud DNS comporta costi aggiuntivi. La fatturazione avviene in base ai
prezzi di Cloud DNS.
Per esportare un servizio con MCS, crea una risorsa personalizzata ServiceExport utilizzando lo stesso
spazio dei nomi e lo stesso nome del servizio. MCS importa automaticamente il servizio in ogni
cluster del parco. Quando MCS importa un servizio, crea:
Una risorsa personalizzata ServiceImport che utilizza lo stesso spazio dei nomi e lo stesso nome del servizio.
Un oggetto Endpoints che utilizza lo stesso spazio dei nomi del servizio e un nome casuale.
Vantaggi dell'utilizzo di MCS
L'utilizzo di MCS offre i seguenti vantaggi:
Alta disponibilità: l'esecuzione dello stesso servizio in più cluster in più regioni offre una migliore tolleranza agli errori. Se un servizio in un cluster non è disponibile, la richiesta può essere sottoposta a failover e gestita da altri cluster. Con MCS è possibile gestire la comunicazione tra i servizi nei cluster per migliorare la disponibilità delle applicazioni containerizzate.
Servizi stateful e stateless: i servizi stateful e stateless
hanno dipendenze e complessità operative diverse e presentano
compromessi operativi diversi. In genere, l'assenza di gestione dello stato
facilita lo scale, l'upgrade e la migrazione di un carico di lavoro con una disponibilità
maggiore. MCS ti consente di separare i cluster per i carichi di lavoro stateful e stateless e renderli indipendenti, isolati e più facili da gestire.
Servizi condivisi: è prassi comune creare cluster Kubernetes separati per ottenere una maggiore disponibilità, una migliore gestione dei servizi con stato e senza stato e una conformità più semplice ai requisiti di sovranità dei dati. Tuttavia, molti servizi come il
monitoraggio con Prometheus
o l'utilizzo della gestione dei secret con Vault
sono spesso condivisi tra tutti i cluster. Anziché richiedere a ogni cluster la propria replica del servizio locale, MCS semplifica la configurazione di servizi condivisi comuni in un cluster separato utilizzato da tutti i cluster funzionali.
Migrazione: la modernizzazione di un'applicazione esistente in un'architettura basata su microservizi containerizzati spesso richiede il deployment di servizi in più cluster Kubernetes. MCS ti offre un meccanismo per
aiutare a colmare la comunicazione tra questi servizi, semplificando la
migrazione delle applicazioni. Ciò è particolarmente utile perché puoi eseguire il deployment
dello stesso servizio in due cluster diversi e il traffico può spostarsi
da un cluster o un'applicazione all'altro.
Passaggi successivi
Scopri di più su Ingress multi-cluster, che fornisce servizi per le direzioni del traffico nord/sud ed est/ovest.
Scopri di più su Cloud Service Mesh, che ti offre un controllo più granulare sul routing e sul traffic shaping.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
