Todos os produtos
Search
Central de documentação

Container Compute Service:Node Affinity Scheduling

Última atualização: Sep 17, 2026

Os clusters ACS representam nós como nós virtuais e expõem atributos — como zona de disponibilidade, região e modelo de GPU — como rótulos do Kubernetes. Use nodeSelector ou nodeAffinity na especificação do pod para agendar pods em nós virtuais com atributos específicos.

Pré-requisitos

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

  • kube-scheduler instalado na versão mínima compatível com seu cluster:

    Versão do cluster ACS

    Versão mínima do kube-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 v2.12.0-acs.4 ou posterior instalado

Nota

A opção Enable custom labels for GPU-HPN nodes and scheduler vem ativada por padrão nas versões mais recentes do kube-scheduler. Não é necessária configuração manual. Para mais detalhes, consulte kube-scheduler.

Escolha um método de agendamento

Método

Quando usar

nodeSelector

Fixe pods em nós com um rótulo específico. Opção mais simples; comece por aqui.

nodeAffinity

Defina regras de agendamento mais complexas, como múltiplas condições de rótulo ou correspondência baseada em operadores (In, NotIn, Exists).

Rótulos de nó disponíveis

Os nós virtuais do ACS expõem os seguintes rótulos para agendamento:

Chave do rótulo

Descrição

Exemplo de valor

topology.kubernetes.io/zone

Zona de disponibilidade

cn-hangzhou-j

topology.kubernetes.io/region

Região

cn-hangzhou

kubernetes.io/hostname

Nome do nó virtual

virtual-kubelet-cn-hangzhou-j

nodeSelector

O nodeSelector associa pods a nós virtuais por meio de rótulos. Adicione o rótulo desejado em nodeSelector na especificação do pod. Para um exemplo prático, consulte Agendar pods em uma zona específica.

nodeAffinity

O nodeAffinity oferece a mesma correspondência baseada em rótulos do nodeSelector, mas com sintaxe mais expressiva. Há dois modos:

Modo

Comportamento

requiredDuringSchedulingIgnoredDuringExecution (afinidade rígida)

O agendador coloca o pod apenas em um nó que satisfaça a regra. Se nenhum nó correspondente existir, o pod não será agendado.

preferredDuringSchedulingIgnoredDuringExecution (afinidade flexível)

O agendador tenta encontrar um nó correspondente. Se nenhum estiver disponível, o pod ainda será agendado em qualquer nó elegível.

Nota

Se você especificar tanto nodeSelector quanto nodeAffinity no mesmo pod, ambos devem ser satisfeitos para que o agendamento ocorra. Em nodeSelectorTerms, múltiplos termos são avaliados com lógica OR: o pod é agendado se qualquer termo corresponder. Dentro de um único termo, múltiplas entradas matchExpressions são avaliadas com lógica AND: todas as expressões devem corresponder.

Restrições para pods GPU-HPN

As restrições a seguir se aplicam quando todas as três condições abaixo forem verdadeiras:

  • O pod utiliza tipo de computação GPU-HPN (GPU com rede de alto desempenho).

  • O schedulerName do pod é default-scheduler.

  • A opção Enable Custom Tags And Scheduler For GPU-HPN Nodes não está selecionada na configuração do componente de agendamento.

Campo

Restrição

requiredDuringSchedulingIgnoredDuringExecution

Em nodeSelectorTerms, apenas os rótulos de afinidade suportados são permitidos em matchExpressions. Não é possível especificar matchFields.

preferredDuringSchedulingIgnoredDuringExecution

Não suportado.

Para tipos de instância de uso geral, otimizadas para computação e GPU, o nodeAffinity não apresenta tais restrições.

Agendar pods em uma zona específica

Este exemplo usa nodeSelector para agendar um Deployment na zona cn-hangzhou-j.

  1. Liste os nós virtuais 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
  2. Crie um arquivo chamado dep-node-selector-demo.yaml com o seguinte conteúdo.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: dep-node-selector-demo
      labels:
        app: node-selector-demo
    spec:
      replicas: 4
      selector:
        matchLabels:
          app: node-selector-demo
      template:
        metadata:
          labels:
            app: node-selector-demo
        spec:
          containers:
          - name: node-selector-demo
            image: registry-cn-hangzhou.ack.aliyuncs.com/acs/stress:v1.0.4
            command:
            - "sleep"
            - "infinity"
          # Pin pods to the cn-hangzhou-j zone
          nodeSelector:
            topology.kubernetes.io/zone: cn-hangzhou-j
  3. Aplique o manifesto.

    kubectl apply -f dep-node-selector-demo.yaml
  4. Verifique se todos os pods foram agendados na zona cn-hangzhou-j.

    kubectl get pod -o wide

    Saída esperada:

    NAME                                     READY   STATUS    RESTARTS   AGE    IP               NODE                            NOMINATED NODE   READINESS GATES
    dep-node-selector-demo-b4578576b-cgpfq   1/1     Running   0          112s   192.168.xx.xxx   virtual-kubelet-cn-hangzhou-j   <none>           <none>
    dep-node-selector-demo-b4578576b-fs8kl   1/1     Running   0          110s   192.168.xx.xxx   virtual-kubelet-cn-hangzhou-j   <none>           <none>
    dep-node-selector-demo-b4578576b-nh8zm   1/1     Running   0          2m8s   192.168.xx.xxx   virtual-kubelet-cn-hangzhou-j   <none>           <none>
    dep-node-selector-demo-b4578576b-rpp8l   1/1     Running   0          2m8s   192.168.xx.xxx   virtual-kubelet-cn-hangzhou-j   <none>           <none>

    Todos os quatro pods estão em execução no virtual-kubelet-cn-hangzhou-j, o que confirma que o agendamento no nível de zona funciona conforme o esperado.

Próximos passos