Quando uma zona fica indisponível, todas as cargas de trabalho concentradas nela saem do ar. As restrições de distribuição de topologia distribuem os Pods uniformemente entre as zonas de disponibilidade em um cluster ACS. Assim, uma falha em uma única zona afeta apenas os Pods dessa zona, enquanto o restante da carga de trabalho continua em execução.
Pré-requisitos
Antes de começar, verifique se você tem:
-
O componente kube-scheduler instalado, com uma versão que atenda aos seguintes requisitos:
Versão do cluster ACS
Versão do componente scheduler
1.31
v1.31.0-aliyun-1.2.0 e posterior
1.30
v1.30.3-aliyun-1.1.1 e posterior
1.28
v1.28.9-aliyun-1.1.0 e posterior
O componente acs-virtual-node instalado, versão v2.12.0-acs.4 ou posterior.
Limitações
As restrições a seguir se aplicam somente aos Pods que atendem a todas estas condições:
O Pod utiliza o tipo de computação GPU de Rede de Alto Desempenho (GPU-HPN).
O campo
schedulerNamedo Pod está definido comodefault-scheduler.A opção Enable Custom Tags And Scheduler For GPU-HPN Nodes não está selecionada na configuração do componente scheduler.
Novas versões do componente kube-scheduler ativam a opção Enable Custom Tags And Scheduler For GPU-HPN Nodes por padrão. Para mais detalhes, consulte kube-scheduler.
Para Pods que atendem às três condições acima, os seguintes campos de restrição de distribuição de topologia apresentam comportamento diferente do Kubernetes padrão:
|
Campo |
Descrição |
Restrição |
|
|
Seleciona os Pods incluídos na contagem por domínio de topologia. |
Exclui da contagem Pods de outros tipos de computação (uso geral, otimizado para computação e GPU). |
|
|
Lista de chaves de rótulo usada em conjunto com |
Sem restrição. |
|
|
Controla a aplicação de |
Não compatível. |
|
|
Define como os taints dos nós são considerados no cálculo da assimetria de distribuição de topologia. |
Não compatível. |
Para os tipos de computação de uso geral, otimizado para computação e GPU, aplica-se o comportamento padrão das restrições de distribuição de topologia do Kubernetes, sem essas limitações.
Distribuir Pods entre zonas
-
Visualize os nós virtuais no cluster.
kubectl get nodeA saída lista os nós organizados por zona. Por exemplo:
NAME STATUS ROLES AGE VERSION virtual-kubelet-cn-hangzhou-i Ready agent 5h42m v1.28.3-xx virtual-kubelet-cn-hangzhou-j Ready agent 5h42m v1.28.3-xx -
Crie o arquivo
dep-spread-demo.yamlcom o conteúdo abaixo.apiVersion: apps/v1 kind: Deployment metadata: name: dep-spread-demo labels: app: spread-demo spec: replicas: 4 selector: matchLabels: app: spread-demo template: metadata: labels: app: spread-demo spec: containers: - name: spread-demo image: registry-cn-beijing.ack.aliyuncs.com/acs/stress:v1.0.4 command: - "sleep" - "infinity" # Spread Pods evenly across zones. # maxSkew: 1 means no zone can have more than one extra Pod compared to any other zone. topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: spread-demo -
Implante a carga de trabalho.
kubectl apply -f dep-spread-demo.yaml -
Verifique a distribuição dos Pods entre as zonas.
kubectl get pod -o wideA saída mostra 4 Pods distribuídos em 2 zonas, com 2 Pods em cada uma:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES dep-spread-demo-7c656dbf5f-6twkc 1/1 Running 0 2m29s 192.168.xx.xxx virtual-kubelet-cn-hangzhou-i <none> <none> dep-spread-demo-7c656dbf5f-cgxr8 1/1 Running 0 2m29s 192.168.xx.xxx virtual-kubelet-cn-hangzhou-j <none> <none> dep-spread-demo-7c656dbf5f-f4fz9 1/1 Running 0 2m29s 192.168.xx.xxx virtual-kubelet-cn-hangzhou-j <none> <none> dep-spread-demo-7c656dbf5f-kc6xf 1/1 Running 0 2m29s 192.168.xx.xxx virtual-kubelet-cn-hangzhou-i <none> <none>