En esta página, se proporciona una descripción general de cómo funciona Service de varios clústeres (MCS). Si deseas obtener información sobre cómo usar MCS, consulta Configura Service de varios clústeres.
Descripción general de MCS
El objeto Service conocido de Kubernetes te permite descubrir y acceder a un servicio dentro de las combinaciones de un solo clúster de Kubernetes. Sin embargo, a veces es posible que quieras dividir las aplicaciones en varios clústeres para abordar los requisitos de administración de estado, privacidad, escalabilidad, disponibilidad y soberanía de los datos. Con MCS, puedes compilar aplicaciones de Kubernetes que abarquen varios clústeres.
MCS es un mecanismo de invocación y detección de Service de varios clústeres para Google Kubernetes Engine (GKE) que aprovecha el objeto de Service existente. Los Service habilitados con esta característica pueden detectarse y acceder a través de clústeres con una IP virtual, lo que coincide con el comportamiento de un Service de ClusterIP al que se puede acceder en un clúster. Al igual que tus Service existentes, el MCS es compatible con las API abiertas e impulsadas por la comunidad, lo que garantiza que las cargas de trabajo sean portátiles.
MCS es una función de GKE. MCS configura las zonas y los registros de Cloud DNS para cada servicio exportado en tus clústeres de flota. Una flota te permite agrupar y normalizar de forma lógica tus clústeres de GKE, lo que facilita la administración de la infraestructura y habilita el uso de funciones de varios clústeres, como MCS. Puedes obtener más información sobre los beneficios de las flotas y cómo crearlas en la documentación de administración de flotas.
Los servicios exportados sin importar el tipo siempre tienen un registro de Cloud DNS, y los servicios de tipo sin interfaz gráfica exportados tienen registros para cada pod de backend con un nombre de host, incluidos los pods en StatefulSets.
El uso de Cloud DNS genera cargos adicionales. Se te facturará según los precios de Cloud DNS.
Para exportar un servicio con MCS, crea un recurso personalizado ServiceExport con el mismo espacio de nombres y nombre que el Service. MCS importa automáticamente el Service a cada clúster de la flota. Cuando MCS importa un Service, crea lo siguiente:
Un recurso personalizado ServiceImport con el mismo espacio de nombres y nombre que el Service.
Un objeto de Endpoints que usa el mismo espacio de nombres que el Service y un nombre aleatorio.
Beneficios de usar MCS
El uso de MCS te brinda los siguientes beneficios:
Alta disponibilidad: ejecutar el mismo Service en todos los clústeres en varias regiones te proporciona una tolerancia a errores mejorada. Si un Service en un clúster no está disponible, la solicitud puede conmutar por error y entregarse desde otros clústeres. Con MCS, es posible administrar la comunicación entre Service en clústeres para mejorar la disponibilidad de tus aplicaciones en contenedores.
Servicios con y sin estado: Los servicios con y sin estado tienen diferentes dependencias operativas y complejidades, y presentan diferentes compensaciones operativas. Por lo general, la ausencia de la administración de estados facilita el escalamiento, la actualización y la migración de una carga de trabajo con una mayor disponibilidad. MCS te permite separar los clústeres para cargas de trabajo con estado y sin estado, y hacerlos independientes, aislados y más fáciles de administrar.
Service compartidos: Es común crear clústeres de Kubernetes separados para obtener una mayor disponibilidad, una mejor administración de los Service con estado y sin estado, y un cumplimiento más sencillo de los requisitos de soberanía de los datos. Sin embargo, muchos Service, como la supervisión con Prometheus o el uso de la administración de secretos con Vault, a menudo, se comparten entre todos los clústeres. En lugar de que cada clúster requiera su propia réplica de Service local, MCS facilita la configuración de Service compartidos comunes en un clúster separado que usan todos los clústeres funcionales.
Migración: Modernizar una aplicación existente en una arquitectura basada en microservicio en contenedores a menudo requiere que implementes Service en varios clústeres de Kubernetes. MCS te proporciona un mecanismo para ayudar a conectar la comunicación entre esos Service, lo que facilita la migración de tus aplicaciones. Esto es muy útil, ya que puedes implementar el mismo Service en dos clústeres diferentes y el tráfico puede cambiar de un clúster o una aplicación a otro.
¿Qué sigue?
Obtén más información sobre Ingress de varios clústeres, que proporciona Services para las direcciones de tráfico norte-sur y este-oeste.
Obtén más información sobre la Cloud Service Mesh, que te brinda un control más preciso sobre el enrutamiento y la forma de tráfico.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-05-01 (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."]]
