Clusters regionais

Esta página explica como os clusters regionais funcionam no Google Kubernetes Engine. Você pode criar um cluster regional ou saber mais sobre os diferentes tipos de clusters.

Visão geral

Por padrão, o plano de controle do cluster (mestre) e os nós são executados em uma única zona do Compute que você especifica ao criar o cluster. Os clusters regionais aumentam a disponibilidade do plano de controle de um cluster (mestre) e de seus nós replicando-os em várias zonas de uma região. Isso fornece as vantagens dos clusters com várias zonas, com os seguintes benefícios adicionais:

  • Se uma ou mais zonas, mas não todas, em uma região sofrerem uma interrupção, o plano de controle do cluster permanecerá acessível enquanto houver uma réplica do plano de controle disponível.
  • Durante a manutenção do cluster, como um upgrade de cluster, apenas uma réplica do plano de controle fica indisponível por vez e o cluster ainda está operacional.

Por padrão, o plano de controle e cada pool de nós são replicados em três zonas de uma região, mas é possível personalizar o número de réplicas.

Depois da criação do cluster, não é possível modificar se ele é zonal, de várias zonas ou regional.

Como os clusters regionais funcionam

Os clusters regionais replicam os mestres e nós em várias zonas dentro de uma única região. Por exemplo, um cluster regional na região us-east1 cria réplicas do plano de controle e nós em três zonas de us-east1: us-east1-b, us-east1-c e us-east1-d. No caso de uma interrupção da infraestrutura, suas cargas de trabalho continuam em execução e os nós podem ser rebalanceados manualmente ou usando o escalonador automático de cluster.

Os benefícios do uso de clusters regionais incluem:

  • Resiliência a falha em zona única. Os clusters regionais estão disponíveis em uma região e não em uma única zona de uma região. Se uma única zona ficar indisponível, o plano de controle do Kubernetes e os recursos não serão afetados.
  • Inatividade zero nos upgrades do mestre, redimensionamento e tempo de inatividade reduzido nas falhas dele. Os clusters regionais fornecem um plano de controle de alta disponibilidade para que seja possível acessá-lo mesmo durante upgrades.

Limitações

  • Por padrão, os clusters regionais consistem em nove nós espalhados uniformemente em três zonas de uma região. Isso consome nove endereços IP. Você pode reduzir o número de nós para um por zona, se quiser. As contas recém-criadas do Google Cloud recebem apenas oito endereços IP por região. Por isso, talvez seja necessário solicitar um aumento nas suas cotas para endereços IP regionais em uso, dependendo do tamanho do seu cluster regional. Se você tiver poucos endereços IP disponíveis em uso, a criação do cluster falhará.

  • Para clusters regionais que executam GPUs, é necessário escolher uma região que tenha GPUs em três zonas ou especificar zonas usando a sinalização --node-locations. Caso contrário, você poderá ver um erro como o seguinte:

    ERROR: (gcloud.container.clusters.create) ResponseError: code=400, message=
      (1) accelerator type "nvidia-tesla-k80" does not exist in zone us-west1-c.
      (2) accelerator type "nvidia-tesla-k80" does not exist in zone us-west1-a.
    

    Para ver uma lista completa das regiões e zonas em que as GPUs estão disponíveis, consulte GPUs no Compute Engine.

  • Não é possível criar pools de nós em zonas fora das zonas do cluster. No entanto, é possível alterar as zonas de um cluster, o que faz com que todos os nós novos e atuais abranjam essas zonas.

Preços

Os clusters regionais são oferecidos sem custo extra.

A utilização de clusters regionais requer mais cotas regionais do seu projeto do que um cluster semelhante zonal ou com várias zonas. Veja se você entendeu suas cotas e os preços do Google Kubernetes Engine antes de usar os clusters regionais. Se você encontrar o erro Insufficient regional quota to satisfy request for resource, a solicitação terá excedido a cota disponível na região atual.

Além disso, o tráfego entre nós nas zonas é cobrado. Por exemplo, se uma carga de trabalho em execução em uma zona precisar se comunicar com uma carga de trabalho em uma zona diferente, o tráfego entre zonas irá gerar custos. Para mais informações, consulte Saída entre zonas na mesma região (por GB) na página de preços do Compute Engine.

Armazenamento permanente em clusters regionais

Os discos de armazenamento permanente são recursos de zona. Quando você adiciona armazenamento permanente ao cluster, o GKE atribui o disco a uma única zona, a menos que ela seja especificada. O GKE escolhe a zona aleatoriamente. Com o uso de um StatefulSet, os discos permanentes provisionados de cada réplica são distribuídos entre as zonas.

Após o provisionamento de um disco permanente, quaisquer pods que façam referência a ele são programados para a mesma zona dele.

Não é possível anexar um disco permanente de leitura e gravação a vários nós.

Clusters regionais de escalonamento automático

Tenha as seguintes considerações em mente ao usar o escalonador automático de cluster para fazer o escalonamento automático dos pools de nós em clusters regionais.

Você também pode saber mais sobre Limites de escalonamento automático para clusters regionais ou sobre como o escalonador automático de clusters se equilibra entre zonas.

Como superprovisionar os limites de escalonamento

Para manter a capacidade no evento improvável de falha de zona, você pode permitir que o GKE superestime seus limites de escalonamento para garantir um nível mínimo de disponibilidade mesmo quando algumas zonas estiverem indisponíveis.

Por exemplo, ao superprovisionar um cluster de três zonas em 150%, você garante que 100% do tráfego seja roteado para as zonas disponíveis se um terço da capacidade for perdida. Para fazer isso, basta especificar o máximo de seis nodes por zona em vez de quatro. Se uma zona falhar, o cluster fará o escalonamento para 12 nodes nas zonas restantes.

Da mesma forma, ao superprovisionar um cluster de duas zonas em 200%, você garante que 100% do tráfego seja roteado novamente se a metade da capacidade for perdida.

Você pode saber mais sobre o escalonador automático de cluster ou ler as perguntas frequentes sobre escalonamento automático na documentação do Kubernetes.

A seguir