Embora seja geralmente uma prática recomendada usar o menor número possível de clusters, as organizações optam por implementar vários clusters para alcançar os respetivos objetivos técnicos e empresariais por vários motivos. No mínimo, a maioria das organizações separa os serviços de 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 em vários níveis, localizações, equipas ou fornecedores de infraestrutura.
A maioria dos motivos para adotar vários clusters enquadra-se em três categorias de requisitos:
- Isolamento: separar o plano de controlo e o plano de dados dos serviços, principalmente para melhorar a fiabilidade ou responder às necessidades de segurança
- Localização: posicionar serviços em localizações específicas para responder às necessidades de disponibilidade, latência e localidade
- Escala: especialmente no contexto de clusters do Kubernetes, serviços de escalamento para além dos limites práticos impostos por um único cluster
Vamos analisá-las mais detalhadamente nas secções seguintes.
Em muitos casos, as organizações têm de equilibrar vários destes requisitos em simultâneo. Ao pensar na sua própria organização, lembre-se de que a nossa recomendação geral é usar o menor número possível de clusters. Determine quais das necessidades de vários clusters são a prioridade mais elevada para a sua organização e não podem ser comprometidas. Em seguida, faça as concessões adequadas para criar uma arquitetura de vários clusters.
Se a sua organização estiver a considerar um cluster por modelo de serviço ou um modo de cluster por equipa, é recomendável considerar o encargo de gestão imposto aos operadores de tal sistema. As frotas e os Google Cloud componentes e funcionalidades que as suportam esforçam-se por tornar a gestão de vários clusters o mais fácil possível, mas existe sempre alguma complexidade de gestão adicional com mais clusters.
Isolamento
Neste contexto, o isolamento refere-se à separação do plano de controlo e/ou do plano de dados, que podem ser alcançados através da execução de vários clusters. No entanto, dependendo da implementação, esta separação também se estende provavelmente ao isolamento do plano de dados. Normalmente, o isolamento surge quando considera o seguinte:
Ambiente
Normalmente, as organizações executam os respetivos serviços de desenvolvimento, preparação/teste e produção em clusters separados, muitas vezes, em diferentes redes e projetos na nuvem. Esta separação é feita para evitar a interrupção acidental dos serviços de produção e impedir o acesso a dados confidenciais durante o desenvolvimento ou os testes.Níveis de carga de trabalho
Muitas vezes, as organizações que têm muitas aplicações complexas dividem os respetivos serviços em níveis, optando por executar os serviços mais críticos em clusters separados dos menos críticos. Num ambiente deste tipo, estes serviços mais críticos e os respetivos clusters são tratados com especial consideração relativamente ao acesso, à segurança, às atualizações, às políticas e muito mais. Um exemplo desta hierarquização é a separação dos serviços sem estado e com estado, colocando-os em clusters separados.Impacto reduzido da falha
Quando as organizações querem limitar os impactos de um erro do operador, de uma falha do cluster ou de uma falha de infraestrutura relacionada, podem dividir os respetivos serviços em vários clusters.Atualizações
Quando as organizações estão preocupadas com potenciais problemas com a atualização no local (ou seja, falha na atualização da automatização, instabilidade da aplicação ou capacidade de reverter), podem optar por implementar uma cópia dos respetivos serviços num novo cluster. A atualização desta forma requer planeamento ou automatização para a tornar possível, certificando-se de que aborda a gestão do tráfego e a replicação do estado durante o processo de atualização.Separação regulamentar/de segurança
As organizações podem optar por isolar os serviços por vários motivos, incluindo manter as cargas de trabalho sujeitas a requisitos regulamentares separadas das menos sensíveis ou executar serviços de terceiros (menos fidedignos) numa infraestrutura separada dos serviços (clusters) originais (fidedignos).Separação de inquilinos
A separação de inquilinos em vários clusters é frequentemente feita por vários motivos, incluindo isolamento de segurança, isolamento de desempenho, contabilidade de custos e até mesmo propriedade.
Localização
Latência
Determinados serviços têm requisitos de latência que têm de ser cumpridos através da localização física dessa carga de trabalho numa localização (ou geografia) específica. Esta necessidade pode ocorrer se os serviços a montante ou os utilizadores finais forem sensíveis à latência, mas também pode ocorrer facilmente se a carga de trabalho em si for sensível à latência do serviço a jusante.Disponibilidade
A execução do mesmo serviço em várias zonas de disponibilidade num fornecedor de nuvem único (ou em vários fornecedores) pode oferecer uma disponibilidade geral mais elevada.Jurisdição
A residência dos dados e outros requisitos de processamento jurisdicional podem exigir que a computação e o armazenamento residam numa região específica, o que requer que a infraestrutura seja implementada em vários centros de dados ou fornecedores de nuvem.Gravidade dos dados
Pode ser difícil, impossível ou até desaconselhável consolidar um grande conjunto de dados, ou mesmo determinadas instâncias de bases de dados, num único fornecedor de nuvem ou região. Consoante os requisitos de processamento e publicação, pode ser necessário implementar uma aplicação perto dos respetivos dados.Infraestrutura/serviços antigos
Tal como os dados podem ser difíceis de mover para a nuvem, alguma infraestrutura antiga é igualmente difícil de mover. Embora estes serviços antigos sejam imóveis, a implementação de clusters adicionais para o desenvolvimento de novos serviços permite às organizações aumentar a velocidade de desenvolvimento.Escolha do programador
As organizações beneficiam frequentemente da capacidade de oferecer aos programadores a escolha dos serviços geridos na nuvem que consomem. Geralmente, a escolha permite que as equipas avancem mais rapidamente com ferramentas mais adequadas às suas necessidades, à custa da necessidade de gerir recursos adicionais atribuídos em cada fornecedor.Necessidades de computação local/na periferia
Por último, à medida que as organizações querem adotar práticas de modernização de aplicações em ambientes de trabalho mais tradicionais, como armazéns, fábricas, lojas de retalho, etc., isto exige a gestão de muito mais cargas de trabalho em muito mais elementos de infraestrutura.
Evolua
Uma vez que o GKE pode dimensionar clusters para mais de 5000 nós, estes limites raramente se tornam um motivo para operar vários clusters. Antes de um cluster atingir os limites de escalabilidade, as organizações decidem frequentemente distribuir os serviços por vários clusters. Para clusters que atingem os limites de escalabilidade, a execução de uma aplicação em vários clusters pode facilitar alguns desafios, mas com a complexidade adicional da gestão de vários clusters.