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

Ao contrário dos clusters zonais que têm um único plano de controle em uma única zona, os clusters regionais aumentam a disponibilidade do plano de controle de um cluster e seus nós, replicando-os em várias zonas em uma região. Isso fornece as vantagens dos clusters com várias zonas, com os seguintes benefícios extras:

  • Se uma zona em uma região sofrer uma interrupção, o plano de controle do cluster continuará acessível enquanto duas réplicas do plano de controle permanecerem disponíveis.
  • 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.

O plano de controle é replicado em três zonas de uma região. Para pools de nós, é possível especificar manualmente as zonas em que os pools de nós do cluster são executados. Também é possível usar a configuração padrão, que replica cada pool de nós em três zonas da região do plano de controle. Todas as zonas precisam estar na mesma região do plano de controle do cluster.

Use clusters regionais para executar cargas de trabalho de produção, porque eles oferecem maior disponibilidade do que os clusters zonais.

Depois de criar um cluster regional, não será possível alterá-lo para um cluster zonal.

Como os clusters regionais funcionam

Os clusters regionais replicam o plano de controle e os nós do cluster em várias zonas em uma única região. Por exemplo, usando a configuração padrão, 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 falhas em zona única: 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 do plano de controle contínuo, redimensionamentos do plano de controle e inatividade reduzida com falhas do plano de controle. 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. Você pode reduzir o número de nós para um por zona, se quiser. As contas recém-criadas do Google Billing 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 executar GPUs no cluster regional, escolha uma região com três zonas em que as GPUs estejam disponíveis. Também é possível especificar zonas usando a sinalização --node-locations ao criar o cluster.

    Se a região escolhida não tiver três zonas em que as GPUs estejam disponíveis, 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.

  • As zonas dos pools de nós precisam estar na mesma região que o plano de controle do cluster. Se for necessário, altere as zonas de um cluster, o que faz com que todos os nós novos e atuais abranjam essas zonas.

Preços

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