Spread workloads across zones - Container Compute Service: Central de Documentação do Alibaba Cloud

A alta disponibilidade é um requisito crítico para aplicações distribuídas. Em um cluster do Alibaba Cloud Container Compute Service (ACS), use a semântica de agendamento nativa do Kubernetes para distribuir cargas de trabalho entre zonas e garantir alta disponibilidade. Para ativar essa distribuição entre zonas, especifique um rótulo de topologia no campo topologyKey de uma restrição de distribuição de topologia. Este tópico descreve as condições e o uso de restrições de distribuição de topologia no ACS.

Pré-requisitos

Antes de começar, verifique se você tem:

kube-scheduler instalado em uma versão que atenda aos seguintes requisitos:

Versão do cluster ACS	Versão mínima do scheduler
1.31	v1.31.0-aliyun-1.2.0
1.30	v1.30.3-aliyun-1.1.1
1.28	v1.28.9-aliyun-1.1.0

acs-virtual-node instalado na versão v2.12.0-acs.4 ou posterior

Observações de uso

Nota

A configuração Enable custom labels and scheduler for GPU-HPN nodes no componente scheduler do ACS vem ativada por padrão nas versões recentes. Para mais informações, consulte kube-scheduler.

Ao usar restrições de distribuição de topologia em um cluster ACS, alguns campos apresentam limitações para Pods que atendem a todas as condições abaixo:

O tipo de computação do Pod é GPU-HPN.
O campo schedulerName do Pod está definido como default-scheduler.
A opção Enable Custom Tags And Scheduler For GPU-HPN Nodes não está selecionada na configuração do componente scheduler.

Parâmetro	Descrição	Restrição
labelSelector	Localiza os Pods correspondentes e os contabiliza para determinar a quantidade de Pods no domínio de topologia associado.	Pods de outros tipos de computação, como uso geral, desempenho aprimorado e aceleração por GPU, não entram na contagem.
matchLabelKeys	Lista de chaves de rótulo do Pod que, combinadas com `labelSelector`, definem o grupo de Pods usado no cálculo da distribuição.
nodeAffinityPolicy	Determina como o nodeAffinity/nodeSelector do Pod é tratado durante o cálculo da assimetria de distribuição de topologia.	Não suportado.
nodeTaintsPolicy	Define o tratamento dos taints do nó no cálculo da assimetria de distribuição de topologia.	Não suportado.

As restrições de distribuição de topologia descritas acima não se aplicam a instâncias de uso geral, desempenho aprimorado ou aceleração por GPU. Para detalhes sobre cada campo, consulte Pod Topology Spread Constraints.

Procedimento

Execute o comando abaixo para visualizar os nós do cluster:

kubectl get node

Saída esperada:

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 um arquivo chamado dep-spread-demo.yaml e adicione o seguinte conteúdo:

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"
      # Specifies the zone spread constraint. maxSkew=1 means the number of Pods can differ by at most one across zones.
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: spread-demo

Execute o comando a seguir para implantar o dep-spread-demo no cluster:
```
kubectl apply -f dep-spread-demo.yaml
```

Verifique a distribuição dos pods executando este comando:

kubectl get pod -o wide

Saída esperada:

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>

A saída confirma que quatro pods foram distribuídos em duas zonas.