Configurar domínios de topologia

Esta página apresenta uma visão geral dos domínios de topologia e diretrizes para configurá-los.

Para configurar um domínio de topologia, é necessário ativar o cluster avançado. Observe as seguintes limitações com a visualização avançada de clusters:

  • É possível ativar o cluster avançado no momento da criação apenas para novos clusters da versão 1.31.
  • Depois que o cluster avançado for ativado, não será possível fazer upgrade dele para a versão 1.32. Ative o cluster avançado apenas em um ambiente de teste.

Esta página é destinada a administradores e arquitetos que definem soluções de TI e arquitetura de sistemas de acordo com estratégias corporativas e criam e gerenciam políticas relacionadas a permissões dos usuários. Para saber mais sobre papéis comuns e exemplos de tarefas referenciados no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE Enterprise.

Visão geral

Um domínio de topologia é um grupo de nós de cluster que são considerados parte do mesmo agrupamento lógico ou físico, como um campus ou data center. Um domínio de topologia precisa corresponder a algum hardware ou software que tenha alguma possibilidade de falha correlacionada. Exemplo:

  • Falhas de software, como diferentes servidores vCenter
  • Falha de hardware, como racks, fontes de energia e edifícios diferentes

No Google Distributed Cloud (somente software) para VMware, como parte da configuração de um domínio de topologia ao criar um cluster, você define um rótulo de topologia. Após a criação do cluster, o rótulo da topologia é preenchido com rótulos de nós no domínio da topologia.

Para usar um domínio de topologia durante a visualização, você tem as seguintes opções:

  • Use a restrição padrão no nível do cluster do Kubernetes, "topology.kubernetes.io/zone", como a chave no rótulo da topologia. Para mais informações, consulte Restrições padrão integradas.

  • Configure o PodTemplate na implantação, no StatefulSet ou no ReplicaSet, conforme aplicável, com a chave de rótulo de topologia. Na especificação do pod, use a chave no rótulo de topologia como o valor do campo topologySpreadConstraints.topologyKey. Essa chave permite que o agendador do Kubernetes distribua pods no domínio de topologia para garantir alta disponibilidade e evitar a concentração excessiva em qualquer área no caso de falha. Para mais informações sobre como configurar topologySpreadConstraints na especificação do pod, consulte Restrições de propagação da topologia de pod na documentação do Kubernetes.

Exemplos de rótulos de domínio de topologia

Suponha que você crie os três domínios de topologia a seguir ao criar um cluster de usuários:

...
topologyDomains:
- name: "topology-domain-1"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-1"
...

...
topologyDomains:
- name: "topology-domain-2"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-2"
...

...
topologyDomains:
- name: "topology-domain-3"
  topologyLabels:
    "topology.examplepetstore.com/zone": "zone-3"
...

Depois que o cluster é criado, você atualiza a especificação do pod, por exemplo:

...
topologySpreadConstraints:
  topologyKey: "topology.examplepetstore.com/zone"
...

De modo geral, o programador do Kubernetes usa topology.examplepetstore.com/zone para separar os nós do cluster em grupos diferentes, zone-1, zone-2 e zone-3. Em seguida, o programador distribui os pods entre esses três grupos de nós.

Diretrizes para a configuração de domínios de topologia

Para garantir o uso eficaz de todos os recursos de clusters pelo agendador do Kubernetes, recomendamos as seguintes diretrizes:

  • Os domínios da topologia precisam estar equilibrados. É necessário fornecer quantidades quase iguais de capacidade de CPU e RAM em cada domínio da topologia.
  • Forneça pelo menos dois e, de preferência, três domínios de topologia.
  • Não se espalhe por mais de uma chave de topologia.
  • Os nós precisam ter um tamanho semelhante em cada domínio da topologia.
  • Se você usar taints e tolerâncias para separar cargas de trabalho em um cluster, cada grupo de nós precisará atender aos requisitos anteriores.

Se essas diretrizes não forem atendidas, o programador ainda tentará usar a capacidade total do cluster, mas pode levar mais tempo para programar pods, e nem todos os pods vão ter o comportamento de propagação esperado.

A seguir