Todos os produtos
Search

Este produto

    :Enable co-scheduling with ack-co-scheduler

    Central de documentação

    :Enable co-scheduling with ack-co-scheduler

    Última atualização: Jun 27, 2026

    Em comparação com o agendador nativo do Kubernetes, o ACK estende o agendamento com recursos como Gang Scheduling, agendamento ciente de topologia de CPU e agendamento elástico de ECI. Instale o complemento ack-co-scheduler em um cluster registrado para usar os recursos de agendamento do ACK no seu cluster local e aumentar a eficiência de workloads intensivos em computação, como big data e IA.

    Pré-requisitos

    Certifique-se de que:

    • Seu cluster Kubernetes autogerenciado esteja conectado a um cluster registrado do ACK One.

    • Os componentes do sistema estejam nas seguintes versões:

      Componente

      Versão

      Kubernetes

      1.18.8 ou posterior

      Helm

      3.0 ou posterior

      Docker

      19.03.5

      Sistema operacional

      CentOS 7.6, CentOS 7.7, Ubuntu 16.04, Ubuntu 18.04, Alibaba Cloud Linux

    Observações de uso

    Defina .template.spec.schedulerName como ack-co-scheduler na especificação do job para rotear os pods pelo co-scheduler do ACK em vez do agendador padrão.

    Instale o componente ack-co-scheduler

    Use o onectl para ambientes automatizados por script. Para uma abordagem baseada em interface gráfica, use o console.

    Instalação via onectl

    1. Instale o onectl na sua máquina.

    2. Instale o ack-co-scheduler:

      onectl addon install ack-co-scheduler

      Saída esperada:

      Addon ack-co-scheduler, version **** installed.

    Instalação via console

    1. Faça login no Console de Gerenciamento do Container Service. No painel de navegação à esquerda, clique em Clusters.

    2. Clique no nome do cluster. No painel de navegação à esquerda, clique em Add-ons.

    3. Na página Add-ons, clique na aba Others. Localize o ack-co-scheduler e clique em Install.

    4. Na caixa de diálogo, clique em OK.

    Gang scheduling

    O Gang scheduling impõe uma política de alocação "tudo ou nada": todos os pods de um grupo são agendados juntos ou nenhum deles é agendado. Isso evita deadlocks de recursos em jobs distribuídos, como treinamento de IA e MPI, nos quais todos os workers precisam ser executados simultaneamente.

    Envie um job distribuído do TensorFlow

    Este exemplo envia um job de treinamento distribuído do TensorFlow com Gang Scheduling. Os pods PS e Worker usam rótulos pod-group.scheduling.sigs.k8s.io para formar um grupo de pods.

    apiVersion: "kubeflow.org/v1"
kind: "TFJob"
metadata:
  name: "tf-smoke-gpu"
spec:
  tfReplicaSpecs:
    PS:
      replicas: 1
      template:
        metadata:
          creationTimestamp: null
          labels:
            pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpu
            pod-group.scheduling.sigs.k8s.io/min-available: "2"
        spec:
          schedulerName: ack-co-scheduler   # Route pods through the ACK co-scheduler.
          containers:
          - args:
            - python
            - tf_cnn_benchmarks.py
            - --batch_size=32
            - --model=resnet50
            - --variable_update=parameter_server
            - --flush_stdout=true
            - --num_gpus=1
            - --local_parameter_device=cpu
            - --device=cpu
            - --data_format=NHWC
            image: registry.cn-hangzhou.aliyuncs.com/kubeflow-images-public/tf-benchmarks-cpu:v20171202-bdab599-dirty-284af3
            name: tensorflow
            ports:
            - containerPort: 2222
              name: tfjob-port
            resources:
              limits:
                cpu: '10'
            workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks
          restartPolicy: OnFailure
    Worker:
      replicas: 4
      template:
        metadata:
          creationTimestamp: null
          labels:
            pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpu
            pod-group.scheduling.sigs.k8s.io/min-available: "2"
        spec:
          schedulerName: ack-co-scheduler
          containers:
          - args:
            - python
            - tf_cnn_benchmarks.py
            - --batch_size=32
            - --model=resnet50
            - --variable_update=parameter_server
            - --flush_stdout=true
            - --num_gpus=1
            - --local_parameter_device=cpu
            - --device=gpu
            - --data_format=NHWC
            image: registry.cn-hangzhou.aliyuncs.com/kubeflow-images-public/tf-benchmarks-cpu:v20171202-bdab599-dirty-284af3
            name: tensorflow
            ports:
            - containerPort: 2222
              name: tfjob-port
            resources:
              limits:
                cpu: 10
            workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks
          restartPolicy: OnFailure

    Campos principais:

    Campo

    Descrição

    pod-group.scheduling.sigs.k8s.io/name

    Agrupa os pods em um grupo de pods. Pods com o mesmo nome são agendados juntos.

    pod-group.scheduling.sigs.k8s.io/min-available

    Quantidade mínima de pods que devem ter condições de agendamento antes que qualquer pod do grupo inicie. Neste exemplo, pelo menos 2 dos 5 pods (1 PS + 4 Workers) precisam estar aptos para agendamento.

    schedulerName: ack-co-scheduler

    Roteia o pod pelo co-scheduler do ACK. Defina este campo em cada modelo de pod do job.

    Verifique o Gang scheduling

    Após enviar o job, verifique se os pods entram em estado pendente simultaneamente:

    kubectl get pods -l pod-group.scheduling.sigs.k8s.io/name=tf-smoke-gpu

    Os pods permanecem em Pending até que pelo menos min-available pods possam ser agendados ao mesmo tempo. Esse comportamento é esperado. Caso os pods continuem pendentes, consulte os Eventos para verificar mensagens de agendamento:

    kubectl describe pod <pod-name>

    Consulte Usar Gang scheduling.

    Agendamento ciente de topologia de CPU

    O agendamento ciente de topologia de CPU fixa os núcleos de CPU do contêiner no mesmo nó de Non-Uniform Memory Access (NUMA), o que reduz a latência de memória entre nós. Essa configuração beneficia workloads intensivos em CPU, como inferência em tempo real e serviços sensíveis a latência.

    Pré-requisitos

    O componente resource-controller deve estar implantado. Consulte Gerenciar complementos.

    Ative o agendamento ciente de topologia de CPU

    Adicione a anotação cpuset-scheduler: "true" ao modelo de pod do Deployment e defina schedulerName como ack-co-scheduler:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-numa
  labels:
    app: nginx-numa
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-numa
  template:
    metadata:
      annotations:
        cpuset-scheduler: "true"   # Enable CPU topology-aware scheduling.
      labels:
        app: nginx-numa
    spec:
      schedulerName: ack-co-scheduler   # Route pods through the ACK co-scheduler.
      containers:
      - name: nginx-numa
        image: nginx:1.13.3
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 4
          limits:
            cpu: 4

    Campos principais:

    Campo

    Descrição

    cpuset-scheduler: "true"

    Fixa os núcleos de CPU do pod em um único nó NUMA. Configure em template.metadata.annotations.

    schedulerName: ack-co-scheduler

    Roteia o pod pelo co-scheduler do ACK.

    resources.requests.cpu / resources.limits.cpu

    Solicitações e limites de recursos de CPU para o contêiner.

    Verifique o agendamento ciente de topologia de CPU

    Com os pods em execução, confirme se o agendamento ocorreu com fixação de cpuset:

    kubectl get pods -l app=nginx-numa -o wide

    Para confirmar a fixação NUMA, acesse o nó e verifique o cpuset do contêiner:

    cat /sys/fs/cgroup/cpuset/kubepods/pod<pod-uid>/<container-id>/cpuset.cpus

    Se todos os núcleos listados pertencerem ao mesmo nó NUMA, a fixação de cpuset estará ativa.

    Consulte Ativar agendamento ciente de topologia de CPU.

    Agendamento elástico de ECI

    O agendamento elástico de ECI controla se os pods são executados em nós do Elastic Compute Service (ECS), em recursos do Elastic Container Instance (ECI) ou se usam burst para ECI apenas quando a capacidade do ECS for insuficiente. Use esse recurso para workloads com picos de demanda de recursos e evitar o provisionamento excessivo de nós ECS.

    Pré-requisitos

    O componente ack-virtual-node deve estar implantado. Consulte Usar ECI no ACK.

    Ative o agendamento elástico de ECI

    Adicione a anotação alibabacloud.com/burst-resource ao modelo de pod do Deployment:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx
      annotations:
        alibabacloud.com/burst-resource: eci   # Use ECI when ECS capacity is insufficient.
      labels:
        app: nginx
    spec:
      schedulerName: ack-co-scheduler   # Route pods through the ACK co-scheduler.
      containers:
      - name: nginx
        image: nginx
        resources:
          limits:
            cpu: 2
          requests:
            cpu: 2

    Valores da anotação alibabacloud.com/burst-resource:

    Valor

    Comportamento

    Não definido

    Usa apenas nós ECS no cluster.

    eci

    Prioriza nós ECS; faz burst para ECI quando a capacidade do ECS for insuficiente.

    eci_only

    Usa exclusivamente recursos ECI.

    Verifique o agendamento elástico de ECI

    Após a implantação, verifique em quais nós os pods estão sendo executados:

    kubectl get pods -l app=nginx -o wide

    Consulte Usar ElasticResource para implementar agendamento elástico de ECI (descontinuado).

    Agendamento compartilhado de GPU

    O agendamento compartilhado de GPU permite que vários pods compartilhem uma única GPU, o que melhora a utilização para inferência e workloads que não exigem uma GPU dedicada.

    Consulte:

    Próximos passos