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 componentes e recursos compatíveis com elas, ambos do Google Cloud, se esforçam para facilitar ao máximo o gerenciamento de vários clusters, mas sempre há 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.