Clusters regionais

Nesta página, explicamos como os clusters regionais funcionam no Google Kubernetes Engine (GKE). Crie um cluster regional ou saiba 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 extras:

  • Se uma ou mais zonas, mas não todas, em uma região passarem por uma interrupção, o plano de controle do cluster continuará acessível enquanto uma réplica do plano de controle permanecer 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 de cluster em várias zonas de uma 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 sendo executadas, e os nós podem ser rebalanceados manualmente ou usando o escalonador automático de cluster.

Veja os benefícios do uso de clusters regionais:

  • 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.
  • Upgrades de mestre contínuo, redimensionamento de mestre e inatividade reduzida em falhas de mestres. Com réplicas redundantes do plano de controle, os clusters regionais proporcionam maior disponibilidade da API Kubernetes, para que seja possível acessar seu plano de controle mesmo durante os upgrades.

Limitações

  • Por padrão, os clusters regionais consistem em nove nós (três por zona) distribuídos uniformemente em três zonas de uma região. Isso consome nove endereços IP. É possível 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 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ço

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

Além disso, você é cobrado pelo tráfego entre os nós nas zonas. 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 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

Discos permanentes zonais são recursos por zona e discos permanentes regionais são recursos multizonais. Quando você adiciona armazenamento permanente, o GKE atribui o disco a uma única zona aleatória, a menos que ela seja especificada. Para saber como controlar as zonas, consulte Zonas em discos permanentes.

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, permita 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, se você superprovisionar um cluster de três zonas para 150% (excesso de capacidade de 50%), garanta que 100% do tráfego seja roteado para zonas disponíveis se um terço da capacidade do cluster for perdido. No exemplo anterior, você faria isso ao especificar no máximo seis nós por zona em vez de quatro. Se uma zona falhar, o cluster será escalonado para 12 nós nas zonas restantes.

Da mesma forma, se você superprovisionar um cluster de duas zonas para 200%, garanta que 100% do tráfego seja redirecionado se metade da capacidade do cluster 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