Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Embora geralmente seja uma prática recomendada usar o menor número possível de clusters,
as organizações optam por implantar vários clusters para atingir os objetivos técnicos e
comerciais por vários motivos. No mínimo, a maioria das organizações
separa a não produção dos serviços de produção, colocando-os em
clusters diferentes. Em cenários mais complexos, as organizações podem escolher
vários clusters para separar os serviços por níveis, localidades, equipes ou
provedores de infraestrutura.
A maioria dos motivos para a adoção de vários clusters se enquadra em três categorias
de requisitos:
Isolamento: separação do plano de controle e do plano de dados,
principalmente para melhorar a confiabilidade ou atender às necessidades de segurança
Localização: colocar serviços em locais específicos para atender às necessidades de disponibilidade,
latência e localidade.
Escalonamento: especialmente no contexto dos clusters do Kubernetes, escalonando os
serviços além dos limites práticos impostos por um único cluster
Vamos analisar isso mais detalhadamente nas seções a seguir.
Em muitos casos, as organizações precisam equilibrar vários desses requisitos
simultaneamente. Ao considerar sua própria organização, lembre-se de que nossa
recomendação geral é usar a menor quantidade possível de clusters. Determine quais
necessidades de vários clusters são a prioridade mais alta para sua organização e
não podem ser comprometidas e, em seguida, faça as contrapartidas adequadas para criar uma
arquitetura de vários clusters.
Se você acha que sua organização está considerando um cluster por serviço-modelo ou um
modo cluster por equipe, convém considerar a carga de gerenciamento
imposta aos operadores desse sistema.
As frotas e os Google Cloud
componentes e recursos compatíveis com elas
são úteis para facilitar o gerenciamento de vários clusters, mas há
sempre uma certa complexidade de gerenciamento adicional com mais clusters.
Isolamento
Nesse contexto, isolamento refere-se à separação do plano de controle e/ou
plano de dados, que podem ser conseguidos com a execução de vários clusters. No entanto,
dependendo da implementação, essa separação também se estende ao isolamento do plano
de dados. O isolamento geralmente surge ao considerar o seguinte:
Ambiente
Com mais frequência, as organizações executam seus serviços de desenvolvimento, preparação/teste e produção
em clusters separados, geralmente em diferentes redes e projetos na nuvem
para criar um anexo da VLAN de monitoramento. Essa separação é feita para evitar a interrupção acidental dos serviços de produção
e o acesso a dados confidenciais durante o desenvolvimento ou teste.
Nível de carga de trabalho
Muitas vezes, nas organizações com muitos aplicativos complexos, opta-se por executar os serviços mais importantes em clusters separados dos menos importantes. Nesse ambiente, esses serviços mais críticos
e os respectivos clusters são tratados com considerações especiais sobre acesso,
segurança, upgrades, política e muito mais. Um exemplo dessa hierarquia é separar
os serviços sem estado e com estado colocando-os em clusters separados.
Redução de impacto da falha
Quando as organizações querem limitar os impactos de um erro de operador, falha de
cluster ou falha de infraestrutura relacionada, elas pode dividir os serviços
entre vários clusters.
Upgrades
Quando as organizações estão preocupadas com possíveis problemas com o upgrade no local
(ou seja, falha no upgrade da automação, lentidão no aplicativo ou na capacidade
de reversão), poderão implantar uma cópia dos próprios serviços em um novo cluster.
O upgrade dessa maneira exige um planejamento ou automação para possibilitar o trabalho,
abordando o gerenciamento de tráfego e a replicação de estado durante o
processo de upgrade.
Separação de segurança/regulamentação
As organizações podem escolher isolar serviços por vários motivos, como para manter cargas de trabalho
sujeitas a requisitos regulamentares separadas de outras menos confidenciais ou executar serviços de
terceiros (menos confiáveis) em uma infraestrutura separada
dos serviços primários (confiáveis) (clusters).
Separação de locatários
A separação de locatários em vários clusters geralmente é feita por vários motivos,
incluindo isolamento de segurança, isolamento de desempenho, contabilidade de custos e
até mesmo propriedade.
Location
Latência
Alguns serviços têm requisitos de latência que precisam ser fisicamente
posicionando a carga de trabalho em um local (ou região) específico. Isso pode ocorrer
se os serviços upstream ou os usuários finais forem sensíveis à latência, mas também
poderá ocorrer facilmente se a carga de trabalho for sensível à latência do serviço downstream.
Disponibilidade
Executar o mesmo serviço em várias zonas de disponibilidade em um único provedor
de nuvem ou em vários provedores pode fornecer uma disponibilidade geral maior.
Jurisdição
Os requisitos de residência e processamento de dados podem exigir que a computação
e o armazenamento estejam em uma região específica, exigindo que a infraestrutura seja
implantada em vários data centers ou provedores de nuvem.
Gravidade dos dados
Pode ser difícil, impossível ou mesmo desaconselhável consolidar em um único provedor
de nuvem ou região um grande corpus de dados, ou mesmo determinadas instâncias
de banco de dados. Dependendo dos requisitos de processamento e exibição, um aplicativo
pode ser implantado próximo aos dados.
Infraestrutura/serviços legados
Como os dados podem ser difíceis de migrar para a nuvem,
também é difícil mover algumas infraestruturas legadas. Embora esses serviços legados não possam ser movidos, a implantação de clusters adicionais para o desenvolvimento de novos serviços permite que as organizações aumentem a velocidade de desenvolvimento.
Escolha do desenvolvedor
As organizações costumam se beneficiar da possibilidade de oferecer aos desenvolvedores
os serviços gerenciados na nuvem que consomem. Geralmente, a escolha permite que as equipes trabalhem
mais rapidamente com as ferramentas mais adequadas às suas necessidades,
às custas da necessidade de gerenciar recursos adicionais alocados em cada provedor.
Necessidades de edge computing/computação local
Por fim, como as organizações querem adotar práticas de modernização de aplicativos em
ambientes de trabalho mais tradicionais, como depósitos, fábricas e lojas de varejo,
entre outros, isso requer o gerenciamento de muito mais cargas de trabalho em muito mais
partes da infraestrutura.
Escala
Como o GKE pode escalonar clusters para mais de
5.000 nós,
esses limites raramente se tornam um motivo para operar vários clusters. Antes de um
cluster atingir os limites de escalonabilidade, as organizações costumam decidir distribuir os serviços
em vários deles. Para clusters que atingem os limites de escalonabilidade, a execução
de um aplicativo em vários clusters pode facilitar alguns desafios, mas apresenta a
complexidade de gerenciar vários clusters.
[[["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 2025-07-31 UTC."],[],[],null,["# Multi-cluster use cases\n\nWhile it is generally a best practice to use as few clusters as possible,\norganizations choose to deploy multiple clusters to achieve their technical and\nbusiness objectives for a variety of reasons. At a minimum, most organizations\nseparate their non-production from their production services by placing them in\ndifferent clusters. In more complex scenarios, organizations might choose\nmultiple clusters to separate services across tiers, locales, teams, or\ninfrastructure providers.\n\nMost reasons for adopting multiple clusters fall into three categories\nof requirements:\n\n- **Isolation:** separating the control plane and data plane of services, primarily to improve reliability or address security needs\n- **Location:** placing services in specific locations to address availability, latency, and locality needs\n- **Scale:** especially in the context of Kubernetes clusters, scaling services beyond the practical limits imposed by a single cluster\n\nWe look at these in more detail in the following sections.\n\nIn many cases, organizations need to balance several of these requirements\nsimultaneously. As you think about your own organization, remember that our\ngeneral recommendation is to use as few clusters as possible. Determine which\nof the multi-cluster needs are the highest priority for your organization and\ncannot be compromised, and then make appropriate tradeoffs to create a\nmulti-cluster architecture.\n\nIf you find your organization considering a *cluster per service-model* or a\n*cluster-per-team* mode, you might want to consider the management burden\nimposed on the operators of such a system.\n[Fleets](/kubernetes-engine/fleet-management/docs/fleet-concepts) and the Google Cloud\n[components and features that support them](/kubernetes-engine/fleet-management/docs)\nstrive to make managing multiple clusters as easy as possible, but there is\nalways some additional management complexity with more clusters.\n\nIsolation\n---------\n\nIn this context, *isolation* refers to separation of the control plane and/or\ndata plane, both of which can be achieved by running multiple clusters. However,\ndepending on implementation, this separation likely also extends to data plane\nisolation. Isolation usually comes up when considering the following:\n\n- **Environment** \n\n More often than not, organizations run their development, staging/test, and production\n services across separate clusters, often running on different networks and cloud\n projects. This separation is done to avoid accidental disruption of production\n services and prevent access to sensitive data during development or testing.\n\n- **Workload tiering** \n\n Often organizations that have many complex applications tier their\n services, choosing to run their more critical services on separate clusters from\n their less critical ones. In such an environment, these more critical services\n and their clusters are treated with special consideration around access,\n security, upgrades, policy, and more. An example of this tiering is separating\n *stateless* and *stateful* services by placing them on separate clusters.\n\n- **Reduced impact from failure** \n\n When organizations want to limit the impacts of an operator mistake, cluster\n failure, or related infrastructure failure, they can split their services\n across multiple clusters.\n\n- **Upgrades** \n\n When organizations are concerned about potential issues with upgrading in-place\n (that is, upgrading automation failure, application flakiness, or the ability to\n roll back), they can choose to deploy a copy of their services in a new cluster.\n Upgrading in this fashion requires planning or automation to make it possible,\n being sure to address traffic management and state replication during the\n upgrade process.\n\n- **Security/regulatory separation** \n\n Organizations can choose to isolate services for many reasons, including keeping\n workloads subject to regulatory requirements separate from less-sensitive ones,\n or running third-party (less-trusted) services on separate infrastructure from\n first-party (trusted) services (clusters).\n\n- **Tenant separation** \n\n Separating tenants into multiple clusters is often done for a variety of reasons,\n including security isolation, performance isolation, cost accounting, and\n even ownership.\n\nLocation\n--------\n\n- **Latency** \n\n Certain services have latency requirements that must be met by physically\n locating that workload in a specific location (or geography). This need can\n occur if upstream services or end-users are sensitive to latency, but can also\n easily occur if the workload itself is sensitive to downstream service latency.\n\n- **Availability** \n\n Running the same service across multiple availability zones in a single-cloud\n provider (or across multiple providers) can provide higher overall availability.\n\n- **Jurisdiction** \n\n Data residency and other jurisdictional processing requirements can require\n compute and storage to live within a specific region, requiring infrastructure\n to be deployed in multiple data centers or cloud providers.\n\n- **Data gravity** \n\n A large corpus of data, or even certain database instances, can be difficult,\n impossible, or even inadvisable to consolidate in a single cloud provider or\n region. Depending on the processing and serving requirements, an application\n might need to be deployed close to its data.\n\n- **Legacy infrastructure/services** \n\n Just as data can be difficult to move to the cloud, some legacy infrastructure\n is similarly difficult to move. Although these legacy services are immobile, deploying additional clusters for the development of new services allows organizations to increase development velocity.\n\n- **Developer choice** \n\n Organizations often benefit from being able to provide developers choice in\n the cloud-managed services that they consume. Generally, choice lets teams move\n more quickly with tools that are best-suited to their needs at the expense of\n needing to manage additional resources allocated in each provider.\n\n- **Local/edge compute needs** \n\n Finally, as organizations want to adopt application modernization practices in\n more traditional work environments, like warehouses, factory floors, retail\n stores, and so on, this necessitates managing many more workloads on many more\n pieces of infrastructure.\n\nScale\n-----\n\nBecause GKE can scale clusters to more than\n[5000 nodes](/kubernetes-engine/docs/concepts/planning-large-workloads#above-5000),\nthese limits rarely become a reason to operate multiple clusters. Before a\ncluster reaches scalability limits, organizations often decide to distribute\nservices across multiple clusters. For clusters that do reach scalability\nlimits, running an application across multiple clusters can ease some\nchallenges, but with the added complexity of managing multiple clusters."]]
