Escolher tamanho e escopo dos clusters do Google Kubernetes Engine

Neste artigo, apresentamos os critérios para decidir quais cargas de trabalho precisam ser executadas em um cluster compartilhado do Google Kubernetes Engine e para determinar o tamanho correto de um cluster.

Com o uso de contêineres em vez de máquinas virtuais, é possível empacotar mais cargas de trabalho na mesma infraestrutura e oferecer isolamento entre elas.

Os aplicativos e os contêineres em que eles são executados têm diferentes requisitos de CPU e memória. Como uma plataforma de orquestração de contêineres, o Kubernetes agenda contêineres entre máquinas para acomodar as necessidades de CPU e memória. O tipo de otimização do seu uso de máquinas depende das cargas de trabalho e das máquinas disponíveis para agendar cargas de trabalho.

Você pode pensar que clusters maiores que executam uma grande quantidade de cargas de trabalho ofereceriam melhor utilização do que os clusters menores que executam apenas algumas cargas de trabalho. No entanto, o compartilhamento de clusters entre cargas de trabalho diferentes pode introduzir complexidade e outras restrições, que podem superar os possíveis benefícios.

O Google Kubernetes Engine foi criado para aceitar uma ampla variedade de tamanhos de cluster. O tamanho mínimo de um cluster é definido pelo número de zonas que ele abrange: uma para um cluster por zona e três para um cluster regional. O tamanho máximo de um cluster do Google Kubernetes Engine é definido como:

  • 50 clusters por zona;
  • 5000 nodes por cluster;
  • 100 pods por node;
  • 300.000 contêineres.

Dentro desses limites, você decide qual é o tamanho ideal para o cluster. Nas próximas seções, você encontra uma visão geral dos critérios e das vantagens e desvantagens a serem consideradas.

Como dimensionar um cluster do Google Kubernetes Engine

Mobilidade da carga de trabalho

O Kubernetes tenta programar pods nos nodes de uma maneira que faça melhor uso dos recursos disponíveis. A programação não inclui apenas a escolha de máquinas para executar um pod pela primeira vez, mas também a atenção aos orçamentos de interrupção do pod. O Kubernetes também pode reprogramar os pods em execução para otimizar a utilização. No entanto, a otimização será restrita se as cargas de trabalho usarem determinados recursos:

Se muitas de suas cargas de trabalho estiverem restritas de qualquer uma dessas maneiras, a alocação de pods nos nodes será amplamente estática. A incapacidade de programar pods livremente não significa apenas que a utilização pode ficar abaixo da ideal, mas também torna o escalonamento automático de cluster menos eficaz. Na pior das hipóteses, no caso de uma falha no node, o Kubernetes talvez não consiga reprogramar os pods, mesmo que a capacidade de computação esteja disponível.

Para ter alta utilização, permita que o Kubernetes programe os pods livremente. Se isso não for possível, pense em usar clusters menores, específicos da carga de trabalho. Se for possível antecipar como os pods serão alocados nos nodes de acordo com suas restrições, você poderá escolher tamanhos de máquinas que correspondam aos requisitos de CPU e tamanho de memória de seus contêineres. Para garantir a redundância, em caso de falha de node ou zona, configure os pools de nós para que as cargas de trabalho possam ser migradas para outros nodes sem violar qualquer restrição.

Uniformidade de carga de trabalho

Quando suas cargas de trabalho estão perfeitamente uniformes e todos os contêineres exigem a mesma quantidade de CPU e memória, o Kubernetes pode programar tranquilamente as cargas de trabalho nos nodes. Quanto mais diversificada for a carga de trabalho, mais difícil será encontrar uma alocação que não desperdice recursos devido à fragmentação. Para diversas cargas de trabalho, os clusters maiores tendem a exibir melhor utilização de recursos.

Elasticidade de carga de trabalho

Na maioria dos casos, a carga de trabalho do cluster não é estática. As implantações podem ser adicionadas ou removidas e, mais importante, o número de pods em execução pode mudar devido ao uso do escalonamento automático de pod horizontal.

Se as cargas de trabalho variarem, ative o autoescalador do cluster. Quando esse recurso está ativado, o Google Kubernetes Engine tenta aproximar a capacidade necessária, adicionando ou removendo dinamicamente o pool de nós subjacente. Quando a capacidade de uma máquina é muito maior do que a capacidade extra necessária, inicialmente uma máquina adicionada ao pool de nós pode exibir má utilização. Em clusters maiores, esse efeito pode ser insignificante, mas em clusters menores, a sobrecarga pode ser significativa. Para minimizar a sobrecarga e os custos, use clusters maiores ou máquinas menores.

Como definir o escopo de um cluster do Google Kubernetes Engine

Regionalidade da carga de trabalho

Para minimizar a latência, melhorar a disponibilidade ou obedecer aos regulamentos, talvez seja necessário executar cargas de trabalho em uma região específica ou em várias regiões. Os clusters do Google Kubernetes Engine são executados em uma única região ou em uma única zona. Portanto, o número de regiões necessárias para executar as cargas de trabalho determina a quantidade mínima de clusters do Google Kubernetes Engine de que você precisa.

Criticidade da carga de trabalho

Sempre que algum incidente afeta uma carga de trabalho crítica, a equipe de operações precisa ser notificada para começar a solucionar o problema. E se um cluster executar cargas de trabalho críticas e não críticas? No caso de incidentes, pode não ficar claro de imediato se apenas as cargas de trabalho críticas ou não críticas serão afetadas. O Kubernetes permita que você classifique cargas de trabalho por prioridade, mas é melhor executar somente cargas de trabalho com criticidade semelhante no mesmo cluster.

Descoberta e comunicação de serviços

As cargas de trabalho que são executadas no mesmo cluster podem depender dos recursos de descoberta de serviço e balanceamento de carga do Kubernetes. No entanto, caso cargas de trabalho precisem se comunicar entre clusters, talvez seja necessário usar registros de serviços externos ou usar registros de serviço externos ou balanceadores de carga para garantir que essas cargas de trabalho possam ser descobertas e alcançar umas às outras.

Pela perspectiva de descoberta e comunicação de serviços, geralmente é mais fácil gerenciar cargas de trabalho dependentes (por exemplo, aplicativos de front-end e back-end) em um único cluster maior, em vez de clusters dedicados e menores.

Gerenciamento de identidade e acesso

No Google Cloud Platform (GCP), o gerenciamento de acesso é processado no escopo de um projeto. Portanto, é uma prática comum e recomendada modelar projetos após a estrutura de equipe de uma organização.

Os clusters do Google Kubernetes Engine fazem parte de um projeto. Ou seja, não é possível compartilhá-los em vários projetos. Assim, um cluster do Google Kubernetes Engine também está sujeito à configuração do Cloud Identity and Access Management (IAM) do projeto.

O alinhamento de clusters, equipes e projetos simplifica o gerenciamento de papéis e permissões. Na maioria dos casos, o Cloud IAM oferece a granularidade necessária para gerenciar o acesso ao Kubernetes, e não é necessário configurar o controle de acesso baseado em papel (RBAC, na sigla em inglês) adicional no próprio Kubernetes.

No entanto, se for necessário compartilhar um cluster entre as equipes, o projeto pai do GCP do cluster também precisará abranger várias equipes. Nesse caso, os papéis que o Cloud IAM oferece para gerenciar o acesso ao Google Kubernetes Engine podem não ser específicos o suficiente, exigindo configuração adicional do RBAC (no nível do namespace) gerenciada no próprio Kubernetes. O gerenciamento da configuração do RBAC em dois locais, Cloud IAM e Kubernetes, aumenta a complexidade administrativa. Por isso, é melhor escolher o escopo do cluster para que você possa gerenciar todo o controle de acesso no Cloud IAM.

Manutenção

O Google Kubernetes Engine é um serviço totalmente gerenciado, mas você precisa pensar em algumas atividades de manutenção:

  • Escolher uma versão do Kubernetes.
  • Escolher um modelo de atualização (manual ou programado) e janelas de manutenção.
  • Iniciar atualizações.
  • Alterar as configurações do pool de nós.

Todas essas atividades podem afetar as cargas de trabalho em execução no cluster. Se algum cluster for compartilhado entre várias equipes, talvez seja um desafio elas concordarem sobre quando executar essas tarefas. Para evitar problemas no agendamento, limite o número de equipes que participam das atividades de manutenção de clusters.

Rede

Um cluster do Google Kubernetes Engine pertence a uma única nuvem privada virtual (VPC, na sigla em inglês) e sub-rede, independentemente de quantos pools de nós são usados. Se os requisitos de conectividade exigirem que as cargas de trabalho sejam executadas em diferentes VPCs ou sub-redes, será necessário criar clusters separados, pelo menos um por VPC ou sub-rede.

Como monitorar e gerar registros

Como a configuração de monitoramento e registro é global em um cluster do Google Kubernetes Engine, execute várias cargas de trabalho em um único cluster em caso de correspondência dos requisitos de registro e monitoramento.

Faturamento

O GCP trata o faturamento por projeto. Para cargas de trabalho que compartilham um único cluster e, portanto, um único projeto do GCP, é difícil determinar para quais contas de carga de trabalho é preciso compartilhar o custo geral. Se precisar de faturamento por carga de trabalho, use clusters dedicados do Google Kubernetes Engine e projetos do GCP.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…