Clusters regionais

Esta página explica como funcionam os clusters regionais no Google Kubernetes Engine (GKE).

Os clusters regionais aumentam a disponibilidade de um cluster replicando o painel de controlo em várias zonas numa região.

Esta configuração oferece as seguintes vantagens:

  • Resiliência a falhas de uma única zona: os clusters regionais estão disponíveis numa região em vez de numa única zona de uma região. Se uma única zona ficar indisponível, o seu plano de controlo não é afetado.
  • Atualizações contínuas do painel de controlo, redimensionamentos do painel de controlo e redução do tempo de inatividade devido a falhas do painel de controlo. Com réplicas redundantes do plano de controlo, os clusters regionais oferecem uma maior disponibilidade da API Kubernetes, para que possa aceder ao seu plano de controlo mesmo durante as atualizações.

Além disso, por predefinição, os clusters regionais são criados como clusters multizonais, pelo que os nós de trabalho são distribuídos por várias zonas numa região. Isto aumenta a disponibilidade da sua carga de trabalho se executar réplicas suficientes da carga de trabalho.

Os clusters do GKE Autopilot são sempre regionais. Se usar o GKE Standard, pode optar por criar clusters regionais ou zonais. Para saber mais sobre os diferentes tipos de disponibilidade de clusters, consulte Disponibilidade de clusters.

Nos clusters regionais, incluindo os clusters do Autopilot, o plano de controlo é replicado em várias zonas de uma região. O GKE replica automaticamente os nós em várias zonas na mesma região. Nos clusters padrão e nos conjuntos de nós, pode especificar manualmente as zonas em que os nós são executados. Todas as zonas têm de estar na mesma região que o plano de controlo.

Depois de criar um cluster regional, não pode alterá-lo para um cluster zonal.

Como funcionam os clusters regionais

Os clusters regionais replicam o painel de controlo e os nós do cluster em várias zonas numa única região. Por exemplo, usando a configuração predefinida, um cluster regional na região us-east1 cria várias réplicas do plano de controlo em diferentes zonas us-east1 e aprovisiona nós em três zonas us-east1: us-east1-b, us-east1-c e us-east1-d. Em caso de uma indisponibilidade da infraestrutura, as cargas de trabalho do Autopilot continuam a ser executadas e o GKE reequilibra automaticamente os nós. Se usar clusters padrão, tem de reequilibrar os nós manualmente ou usando o escalador automático de clusters.

Limitações

  • O conjunto de nós predefinido criado para clusters padrão regionais consiste em nove nós (três por zona) distribuídos uniformemente por três zonas numa região. Isto consome nove endereços IP para clusters que usam nós públicos. Pode reduzir o número de nós para um por zona, se necessário. As contas de faturação do Google Cloud criadas recentemente só recebem oito endereços IP por região, pelo que pode ter de pedir um aumento das suas quotas para endereços IP regionais em utilização, consoante a dimensão do seu cluster regional. Se tiver um número demasiado baixo de endereços IP em utilização disponíveis, a criação do cluster falha.

  • Para executar GPUs no cluster regional, escolha uma região que tenha, pelo menos, uma zona onde as GPUs pedidas estejam disponíveis. Tem de usar a flag --node-locations ao criar o conjunto de nós para especificar a zona ou as zonas que contêm as GPUs pedidas.

    Se a região que escolher não tiver, pelo menos, uma zona onde as GPUs pedidas estejam disponíveis, pode ver um erro como o seguinte:

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

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

  • As zonas dos node pools do modo Standard têm de estar na mesma região que o plano de controlo do cluster. Se precisar, pode alterar as zonas de um cluster, o que faz com que todos os nós novos e existentes 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 requerem mais das quotas regionais do seu projeto do que um cluster zonal ou multizonal semelhante. Certifique-se de que compreende as suas quotas e os preços padrão antes de usar clusters regionais. Se encontrar um Insufficient regional quota to satisfy request for resource erro, o seu pedido excede a quota disponível na região atual.

Além disso, o tráfego de nó para nó entre zonas é cobrado. Por exemplo, se uma carga de trabalho executada numa zona precisar de comunicar com uma carga de trabalho numa zona diferente, o tráfego entre zonas incorre em 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 persistente em clusters regionais

Os discos persistentes zonais são recursos zonais e os discos persistentes regionais são recursos multizonais. Quando adiciona um armazenamento persistente, a menos que seja especificada uma zona, o GKE atribui o disco a uma zona única aleatória. Para saber como controlar as zonas, consulte o artigo Zonas em discos persistentes.

Escala automática de clusters regionais

Tenha em atenção as seguintes considerações quando usar o escalador automático de clusters para dimensionar automaticamente os node pools em clusters regionais no modo Standard.

Também pode saber mais acerca dos limites do redimensionamento automático para clusters regionais ou sobre como o redimensionador automático de clusters faz o equilíbrio entre zonas.

Estas considerações aplicam-se apenas a clusters no modo padrão com o escalador automático de clusters.

Limites de escalabilidade de aprovisionamento excessivo

Para manter a capacidade no caso improvável de falha zonal, pode permitir que o GKE faça o aprovisionamento excessivo dos seus limites de escalabilidade, para garantir um nível mínimo de disponibilidade mesmo quando algumas zonas estão indisponíveis.

Por exemplo, se aprovisionar em excesso um cluster de três zonas para 150% (50% de capacidade em excesso), pode garantir que 100% do tráfego é encaminhado para zonas disponíveis se perder um terço da capacidade do cluster. No exemplo anterior, faria isto especificando um máximo de seis nós por zona em vez de quatro. Se uma zona falhar, o cluster é dimensionado para 12 nós nas zonas restantes.

Da mesma forma, se aprovisionar em excesso um cluster de duas zonas para 200%, pode garantir que 100% do tráfego é reencaminhado se metade da capacidade do cluster for perdida.

Pode saber mais acerca do redimensionador automático de clusters ou ler as Perguntas frequentes sobre a escala automática na documentação do Kubernetes.

O que se segue?