Schedule multi-cluster PyTorchJobs with gang scheduling and Kube Queue - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

O PyTorch é um framework de machine learning amplamente utilizado que auxilia desenvolvedores de modelos a executar treinamentos distribuídos com múltiplos nós e GPUs. No Kubernetes, os jobs do PyTorch são enviados como PyTorchJobs. Utilize o ACK Kube Queue para gerenciar jobs em uma instância de fleet e declare requisitos de Gang scheduling para garantir que todos os pods sejam executados em um único cluster associado.

Arquitetura

Em treinamentos distribuídos com múltiplos nós e GPUs, a carga de trabalho geralmente precisa atender à semântica de Gang scheduling no momento do agendamento para assegurar a execução correta dos pods. A semântica de Gang scheduling exige que todas as cargas de trabalho de um job sejam executadas simultaneamente ou nenhuma delas seja iniciada. A fleet utiliza o ACK Kube Queue e o ACK Scheduler para agendar PyTorchJobs em vários clusters, respeitando a semântica de Gang declarada nas cargas de trabalho do PyTorchJob durante o agendamento.

Pré-requisitos

As operações descritas em Deploy the cloud-native AI suite foram concluídas nos clusters associados (implante apenas o add-on Arena).
A permissão AliyunAdcpFullAccess foi concedida ao usuário do Resource Access Management (RAM). Para mais informações, consulte Manage RAM user permissions.
A ferramenta de linha de comando AMC está instalada. Para mais informações, consulte AMC command-line help.
(Opcional) Quando a reserva de recursos está ativada em um cluster, a fleet utiliza essa reserva para alinhar seu resultado de agendamento com o resultado no cluster associado. Caso a reserva de recursos não esteja ativada, a fleet avalia os recursos e agenda jobs comparando dois totais: o total de recursos restantes de todos os nós nos clusters associados e o total de recursos solicitados pelo job. Ative a reserva de recursos conforme descrito abaixo.

Nota
A ativação da reserva de recursos requer versão 1.28 ou superior do cluster e versão 6.8.0 ou superior do ACK Scheduler.
1. Faça login no ACK console. No painel de navegação à esquerda, clique em Clusters.
2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Components and Add-ons .
3. Na página Add-ons, localize o add-on Kube Scheduler e clique em Configuration para acessar a página Parameters. Defina enableReservation como true e clique em OK.

Etapa 1: Use o Kube Queue para enfileiramento de jobs e gerenciamento de cotas (opcional)

Em uma fleet de múltiplos clusters, o ElasticQuotaTree gerencia cotas e configura filas, resolvendo o problema de enfileiramento de muitos jobs em ambientes multiusuário. O gerenciamento de filas é opcional. Se você pular esta etapa, utilize a aba Gang scheduling policy only na Etapa 2. A aba ElasticQuotaTree and Gang scheduling policies na Etapa 2 requer o ElasticQuotaTree enviado nesta etapa.

Utilize o conteúdo de exemplo a seguir para enviar um ElasticQuotaTree.

Importante
Os valores max e min no exemplo são espaços reservados. Configure-os com os recursos que seus clusters associados podem realmente fornecer. O parâmetro max especifica o limite superior de recursos que um nó de cota pode utilizar. O parâmetro min define os recursos mínimos garantidos a um nó de cota.

Para o nó raiz, os valores max e min devem ser iguais, e o valor max não pode ser menor que a soma dos valores max de seus filhos. Se uma cota exceder a capacidade dos clusters associados, os jobs sairão da fila, mas seus pods permanecerão no status Pending.

Um administrador de cluster pode enviar um ElasticQuotaTree na instância de fleet para configurar filas de jobs. Este exemplo define uma cota no namespace default com um total de 10.000 CPUs, 10.000 GiB de memória, 10.000 GPUs e um job simultâneo.
```
apiVersion: scheduling.sigs.k8s.io/v1beta1
kind: ElasticQuotaTree
metadata:
  name: elasticquotatree # Only one ElasticQuotaTree is supported.
  namespace: kube-system # Takes effect only in the kube-system namespace.
spec:
  root:
    name: root # Root node: Max must equal Min.
    max:
      cpu: 999900
      memory: 400000Gi
      kube-queue/max-jobs: 10000000000
      nvidia.com/gpu: 100000
    min:
      cpu: 999900
      memory: 400000Gi
      kube-queue/max-jobs: 10000000000
      nvidia.com/gpu: 100000
    children:
    - name: child-2
      max:
        # Only one job can be dequeued at a time.
        kube-queue/max-jobs: 1
        cpu: 10000
        nvidia.com/gpu: 10000
        memory: 10000Gi
      namespaces: # Configure the namespaces.
        - default
```
Execute o seguinte comando kubectl na instância de fleet para visualizar as filas criadas pelo ElasticQuotaTree e pelo Kube Queue.
```
kubectl get queue -n kube-queue
```
Saída esperada:
```
NAME                 AGE
root-child-2-v5zxz   15d
root-kdzw7           15d
```

Etapa 2: Envie um PyTorchJob para agendamento em múltiplos clusters

Envie uma PropagationPolicy na instância de fleet e especifique Gang como a política de agendamento personalizada.

Importante
O parâmetro tolerationSeconds define por quanto tempo a fleet tolera um job não saudável antes de reagendá-lo. Valor padrão: 300 segundos. Defina este valor com uma duração maior que o tempo necessário para o job reiniciar. Caso contrário, o job poderá ser reagendado antes que todos os seus pods tenham reiniciado.

O parâmetro purgeMode especifica como os pods de um job com falha são tratados. Valores válidos: Immediately (os pods são excluídos e o job é recriado), Graciously (os pods são excluídos de forma graceful e o reagendamento termina se o job voltar a ficar saudável dentro do período definido em gracePeriodSeconds) e Never (os pods não saudáveis não são excluídos). Se você definir purgeMode como Immediately, o progresso de treinamento não salvo em um checkpoint será perdido quando o job falhar. Para jobs de treinamento de longa duração, configure checkpoints periódicos.
Apenas política de Gang scheduling

Ao utilizar o Gang scheduling, a PropagationPolicy enviada deve usar a política de agendamento personalizada customSchedulingType=Gang.
```
apiVersion: policy.one.alibabacloud.com/v1alpha1
kind: PropagationPolicy
metadata:
  name: example-policy # The default namespace is `default`.
spec:
  propagateDeps: true
  # Reschedule the job when it fails to run.
  failover:
    application:
      decisionConditions:
        tolerationSeconds: 30
      purgeMode: Immediately
  placement:
    replicaScheduling:
      replicaSchedulingType: Divided
      # Declare the use of Gang scheduling.
      customSchedulingType: Gang
  resourceSelectors:
    - apiVersion: kubeflow.org/v1
      kind: PyTorchJob
```
Políticas de ElasticQuotaTree e Gang scheduling

A PropagationPolicy enviada deve utilizar a política de agendamento personalizada customSchedulingType=Gang. Além disso, defina .spec.suspension.scheduling como true para indicar que o job deve entrar na fila.
```
apiVersion: policy.one.alibabacloud.com/v1alpha1
kind: PropagationPolicy
metadata:
  name: example-policy # The default namespace is `default`.
spec:  
  suspension:
    scheduling: true
  propagateDeps: true
  # Reschedule the job when it fails to run.
  failover:
    application:
      decisionConditions:
        tolerationSeconds: 30
      purgeMode: Immediately
  placement:
    replicaScheduling:
      replicaSchedulingType: Divided
      # Declare the use of Gang scheduling.
      customSchedulingType: Gang
  resourceSelectors:
    - apiVersion: kubeflow.org/v1
      kind: PyTorchJob
```

Utilize o conteúdo de exemplo a seguir para enviar um PyTorchJob na instância de fleet.

O exemplo envia uma carga de trabalho de espaço reservado que não solicita recursos de GPU. Ele verifica apenas se o pod Master e os dois pods Worker são agendados simultaneamente em um único cluster associado. Para executar um treinamento distribuído real, substitua a imagem por uma imagem de treinamento PyTorch e solicite recursos nvidia.com/gpu nos modelos Master e Worker.

Expanda para visualizar o YAML de exemplo do PyTorchJob

apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  labels:
    app: pytorchjob
  name: pytorch-test
  namespace: default
spec:
  cleanPodPolicy: None
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      restartPolicy: Never
      template:
        metadata:
          labels:
            app: pytorchjob
          name: pytorch-test
        spec:
          schedulerName: default-scheduler
          containers:
          - command:
            - sh
            - -c
            - sleep 1h
            env:
            - name: NVIDIA_VISIBLE_DEVICES
              value: void
            - name: gpus
              value: "0"
            - name: workers
              value: "8"
            image: registry-cn-hangzhou.ack.aliyuncs.com/acs/nginx
            imagePullPolicy: Always
            name: pytorch
            resources:
              limits:
                cpu: "3"
              requests:
                cpu: "10m"
            volumeMounts:
            - mountPath: /dev/shm
              name: dshm
            workingDir: /root
          volumes:
          - emptyDir:
              medium: Memory
              sizeLimit: 2Gi
            name: dshm
    Worker:
      replicas: 2
      restartPolicy: OnFailure
      # restartPolicy: Never
      template:
        metadata:
          labels:
            app: pytorchjob
          name: pytorch-test
        spec:
          containers:
          - command:
            - bash
            - -c
            - |
              #!/bin/bash
              #sleep 180
              echo "$WORKER_INDEX"
              #if [[ "$WORKER_INDEX" == "0" ]]
              #then
              #  exit -1
              #fi
              sleep 1h
            env:
            - name: WORKER_INDEX
              valueFrom:
                fieldRef:
                  fieldPath: metadata.labels['pytorch-replica-index']
            - name: NVIDIA_VISIBLE_DEVICES
              value: void
            - name: gpus
              value: "0"
            - name: workers
              value: "8"
            image: registry-cn-hangzhou.ack.aliyuncs.com/acs/nginx
            imagePullPolicy: Always
            name: pytorch
            resources:
              limits:
                cpu: "2"
              requests:
                cpu: "2"
                memory: "2Gi"
            volumeMounts:
            - mountPath: /dev/shm
              name: dshm
            workingDir: /root
          volumes:
          - emptyDir:
              medium: Memory
              sizeLimit: 2Gi
            name: dshm

Etapa 3: Visualize o status do job

Execute o seguinte comando kubectl na instância de fleet para verificar o status do PyTorchJob.
```
kubectl get pytorchjob
```
Saída esperada:
```
NAME           STATE     AGE
pytorch-test   Created   3m44s
```

Execute o comando kubectl abaixo na instância de fleet para visualizar os eventos e identificar o cluster associado onde o PyTorchJob foi agendado.

kubectl describe pytorchjob pytorch-test

Saída esperada:

 Normal   ScheduleBindingSucceed  4m59s                   default-scheduler                   Binding has been scheduled successfully. Result: {cfxxxxxx:0,[{master 1} {worker 2}]}

Utilize o seguinte comando kubectl na instância de fleet para consultar o status do PyTorchJob no cluster associado.
```
kubectl amc get pytorchjob -M
```
Saída esperada:
```
NAME           CLUSTER    STATE     AGE     ADOPTION
pytorch-test   cfxxxxxx   Running   6m23s   Y
```

Verifique o status dos pods executando o comando kubectl a seguir na instância de fleet.

kubectl amc get pod -M