Clusters regionais

Nesta página, explicamos como os clusters regionais funcionam no Google Kubernetes Engine (GKE).

Os clusters regionais aumentam a disponibilidade de um cluster replicando o plano de controle e os nós em várias zonas em uma região.

Os clusters regionais oferecem todas as vantagens dos clusters multizonais com os seguintes benefícios adicionais:

  • 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.

Os clusters do Autopilot do GKE são sempre regionais. Se você usa o GKE Standard, é possível criar clusters regionais, zonais ou de várias zonas. Para saber mais sobre os diferentes tipos de disponibilidade de cluster, consulte Sobre opções de configuração de cluster.

Em clusters regionais, incluindo clusters do Autopilot, o plano de controle é replicado em três zonas de uma região. O GKE replica automaticamente os nós nas zonas da mesma região. Em clusters Standard e pools de nós, é possível especificar manualmente as zonas em que os nós são executados. Todas as zonas precisam estar na mesma região que o plano de controle.

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, as cargas de trabalho do Autopilot continuam em execução e o GKE reequilibra automaticamente os nós. Se você usa clusters Standard, reequilibre os nós manualmente ou usando o escalonador automático de clusters.

Limitações

  • O pool de nós padrão criado para clusters Standard regionais consiste em nove nós (três por zona) distribuídos uniformemente entre três zonas de uma região. Para clusters públicos, isso consome nove endereços IP. Você pode reduzir o número de nós para um por zona, se necessário. 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 que tenha pelo menos uma zona em que as GPUs solicitadas estejam disponíveis. Use a flag --node-locations ao criar o pool de nós para especificar as zonas que contêm as GPUs solicitadas.

    Se a região escolhida não tiver pelo menos uma zona em que as GPUs solicitadas estejam disponíveis, talvez você receba um erro como este:

    
ERROR: (gcloud.container.clusters.create) ResponseError: code=400, message=
    Accelerator type "nvidia-l4" does not exist in zone europe-west3-a.

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

  • As zonas dos pools de nós do modo Standard precisam estar na mesma região do 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

Todos os clusters do Autopilot são regionais e estão sujeitos ao modelo de preços do Autopilot.

No modo Standard, os clusters regionais exigem mais cotas regionais do seu projeto do que um cluster semelhante zonal ou multizonal. Entenda suas cotas e os preços do Standard 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 do modo Standard.

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.

Essas considerações se aplicam apenas aos clusters no modo Standard com o escalonador automático de cluster.

Como superprovisionar os limites de escalonamento

Para manter a capacidade no evento improvável de falha de zona, permita que o GKE superprovisione seus limites de escalonamento a fim de 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 para 150% (excesso de capacidade de 50%), é possível garantir que 100% do tráfego seja roteado para zonas disponíveis caso um terço da capacidade do cluster seja 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, ao superprovisionar um cluster de duas zonas para 200%, é possível garantir que 100% do tráfego seja redirecionado caso metade da capacidade do cluster seja perdida.

Saiba mais sobre o escalonador automático de cluster ou leia as perguntas frequentes sobre escalonamento automático na documentação do Kubernetes.

A seguir