Nesta página, fornecemos uma visão geral de como os serviços de vários clusters (MCS, na sigla em inglês) do GKE
funcionam. Para saber como usar o MCS, consulte
Como configurar serviços de vários clusters.
Visão geral dos MCS
O conhecido objeto Service
do Kubernetes permite que você descubra e acesse um serviço nas
extremidades de um único cluster do Kubernetes. No entanto, às vezes convém
dividir os aplicativos em vários clusters para atender aos requisitos de gerenciamento de estado, privacidade,
escalonabilidade, disponibilidade e soberania de
dados. Com o MCS, é possível
criar aplicativos do Kubernetes que abranjam vários clusters.
O MCS é um mecanismo de descoberta e invocação de serviço entre
clusters para o Google Kubernetes Engine (GKE) que aproveita o objeto Service
atual. Os serviços ativados com esse recurso são detectáveis e acessíveis
em clusters com um IP virtual, correspondendo ao comportamento de um
serviço ClusterIP
acessível em um cluster. Assim como os serviços atuais, o MCS é
compatível com APIs abertas e voltadas para a comunidade, garantindo que cargas de trabalho permaneçam
portáteis.
O MCS é um recurso do GKE. O MCS configura zonas e registros do Cloud DNS
para cada serviço exportado nos clusters de frota. Uma frota permite agrupar e normalizar logicamente os clusters do GKE, facilitando a administração da infraestrutura e permitindo o uso de recursos de vários clusters, como o MCS. Saiba mais sobre os benefícios dos frotas e como criá-los na documentação de gerenciamento de frota.
Os serviços exportados, independentemente do tipo, sempre têm um registro do Cloud DNS, e os serviços sem tipo exportados têm registros para cada pod de back-end com um nome do host, incluindo pods em StatefulSets.
O uso do Cloud DNS gera mais cobranças. A cobrança é feita de acordo com os
preços do Cloud DNS.
Para exportar um serviço com o MCS, crie um recurso personalizado ServiceExport usando o mesmo
namespace e o mesmo nome que o serviço. O MCS importa automaticamente o serviço para cada
cluster na frota. Quando o MCS importa um serviço, ele cria:
Um recurso personalizado ServiceImport que usa o mesmo namespace e o mesmo nome que o serviço.
Um objeto Endpoints que usa o mesmo namespace que o serviço e um nome aleatório.
Benefícios do uso do MCS
O uso do MCS oferece os seguintes benefícios:
Alta disponibilidade: a execução do mesmo serviço em clusters em
várias regiões proporciona melhor tolerância a falhas. Se um serviço em
um cluster não estiver disponível, a solicitação poderá falhar e ser veiculada de outros
clusters. Com o MCS, é possível gerenciar a comunicação
nos serviços entre clusters para melhorar a disponibilidade dos aplicativos em
contêineres.
Serviços com estado e sem estado: os serviços com estado e sem estado
têm diferentes dependências operacionais e complexidades, assim como apresentam
diferentes vantagens operacionais. Normalmente, a ausência do gerenciamento de estado
facilita o escalonamento, o upgrade e a migração de uma carga de trabalho com maior
disponibilidade. O MCS permite separar clusters para cargas de trabalho com estado e sem
estado e torná-los independentes, isolados e mais fáceis de gerenciar.
Serviços compartilhados: é comum criar clusters separados do
Kubernetes para ter maior disponibilidade, melhor gerenciamento de serviços com estado e
sem estado e conformidade mais fácil com os requisitos de soberania de
dados. No entanto, muitos serviços, como o
monitoramento com o Prometheus
ou o uso de gerenciamento de secrets com o Vault, geralmente são compartilhados entre todos os clusters. Em vez de cada cluster exigir uma
réplica de serviço local própria, o MCS facilita a configuração dos serviços compartilhados
comuns em um cluster separado para ser usado por todos os clusters funcionais.
Migração: a modernização de um aplicativo existente em uma arquitetura
baseada em microsserviço conteinerizado geralmente requer que você implante serviços
em vários clusters do Kubernetes. O MCS fornece um mecanismo para
ajudar a estabelecer a comunicação entre esses serviços, facilitando a
migração de aplicativos. Isso é especialmente útil, já que é possível implantar
o mesmo serviço em dois clusters e o tráfego tem permissão para alternar
de um cluster ou aplicativo para outro.
A seguir
Saiba mais sobre a Entrada de vários clusters,
que fornece serviços para rotas de tráfego norte-sul e leste-oeste.
Saiba mais sobre o Cloud Service Mesh, que oferece
um controle mais preciso sobre o roteamento e a modelagem de tráfego.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-09-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."]]
