Todos os produtos
Search
Central de documentação

Container Compute Service:Agendamento por afinidade de pods

Última atualização: Jun 29, 2026

O agendamento por afinidade de pods restringe o local onde um pod pode ser agendado com base nos rótulos dos pods que já estão em execução nos nós virtuais, e não nas propriedades do nó. Em um cluster ACS, a afinidade de pods utiliza a semântica nativa de agendamento do Kubernetes: especifique domínios de topologia e regras de rótulo em podAffinity ou podAntiAffinity para colocalizar ou distribuir pods entre zonas.

Um caso de uso comum envolve a execução de um serviço stateless com várias réplicas, em que se deseja manter todas as réplicas na mesma zona de disponibilidade de um pod de cache compartilhado para reduzir a latência entre zonas. A afinidade de pods com requiredDuringSchedulingIgnoredDuringExecution aplica essa regra estritamente no momento do agendamento.

Pré-requisitos

Antes de começar, certifique-se de que:

  • O componente kube-scheduler está instalado e atende aos seguintes requisitos de versão:

    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 está instalado na versão v2.12.0-acs.4 ou posterior.

Limitações

O ACS impõe as seguintes restrições à afinidade de pods.

Pods GPU-HPN

A afinidade de pods apresenta restrições quando as três condições abaixo se aplicam simultaneamente a um pod:

  • O pod utiliza o tipo de computação High-Performance Network GPU (GPU-HPN).

  • O campo schedulerName do pod está definido como default-scheduler.

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

A opção Enable Custom Tags and the Scheduler for GPU-HPN Nodes vem ativada por padrão nas versões mais recentes. Para mais detalhes, consulte kube-scheduler .

Política suportada

Apenas requiredDuringSchedulingIgnoredDuringExecution é suportado. O campo preferredDuringSchedulingIgnoredDuringExecution não é suportado.

Os seguintes campos são aplicáveis dentro de requiredDuringSchedulingIgnoredDuringExecution:

Campo

Descrição

Restrição

labelSelector

Localiza pods correspondentes. Os pods com este rótulo são contabilizados por domínio de topologia.

Pods de outros tipos de computação (uso geral, otimizado para computação, GPU) são excluídos da contagem.

namespaces

Especifique namespaces para buscar pods correspondentes, usado em conjunto com labelSelector.

Não suportado

namespaceSelector

Selecione namespaces com base em rótulos de namespace em vez de nomes.

Não suportado

Para a referência completa de campos, consulte Pod affinity and anti-affinity na documentação do Kubernetes.

Agendar pods na mesma zona

Este exemplo demonstra como usar podAffinity para agendar os pods de um Deployment na mesma zona de disponibilidade de um pod rotulado existente. Esse padrão é típico quando se deseja que as réplicas de um serviço compartilhem a mesma zona de uma dependência (como um cache) para evitar latência entre zonas.

O fluxo de trabalho possui duas etapas: primeiro, implante um pod com um rótulo alvo; em seguida, implante um Deployment que utilize podAffinity para colocalizar com esse pod rotulado.

Etapa 1: Implantar o pod de referência rotulado

  1. Liste os nós virtuais no 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 with-affinity-pod.yaml com o seguinte conteúdo.

    apiVersion: v1
    kind: Pod
    metadata:
      labels:
        pod-affinity-label: with-pod-affinity   # This label is the affinity target
      name: with-affinity-label-pod
    spec:
      containers:
        - args:
            - 'infinity'
          command:
            - sleep
          image: registry-cn-hangzhou.ack.aliyuncs.com/acs/stress:v1.0.4
          imagePullPolicy: IfNotPresent
          name: stress
          resources:
            limits:
              cpu: '1'
              memory: 1Gi
            requests:
              cpu: '1'
              memory: 1Gi
  3. Implante o pod.

    kubectl apply -f with-affinity-pod.yaml
  4. Verifique se o pod está em execução e anote em qual zona ele foi alocado.

    kubectl get pod -o wide

    Saída esperada:

    NAME                      READY   STATUS    RESTARTS   AGE   IP              NODE                            NOMINATED NODE   READINESS GATES
    with-affinity-label-pod   1/1     Running   0          75s   192.168.xx.xxx  virtual-kubelet-cn-hangzhou-i   <none>           <none>

    O pod foi agendado na zona cn-hangzhou-i. O Deployment na próxima etapa usará o rótulo deste pod para determinar a zona alvo.

Etapa 2: Implantar com afinidade de pods

  1. Crie um arquivo chamado origin-affinity-pod.yaml com o seguinte conteúdo.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: dep-pod-affinity
      labels:
        app: pod-affinity-demo
    spec:
      replicas: 4
      selector:
        matchLabels:
          app: pod-affinity-demo
      template:
        metadata:
          labels:
            app: pod-affinity-demo
        spec:
          containers:
          - name: pod-affinity-demo
            image: registry-cn-hangzhou.ack.aliyuncs.com/acs/stress:v1.0.4
            command:
            - "sleep"
            - "infinity"
            resources:
              limits:
                cpu: '1'
                memory: 1Gi
              requests:
                cpu: '1'
                memory: 1Gi
          affinity:
            podAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                  - key: pod-affinity-label
                    operator: In
                    values:
                    - with-pod-affinity  # Match the label on with-affinity-label-pod
                topologyKey: topology.kubernetes.io/zone  # Co-locate in the same zone
                # Note: only GPU-HPN pods count toward the labelSelector total.
                # Pods of other compute types are excluded from the count in ACS.
  2. Implante o Deployment.

    kubectl apply -f origin-affinity-pod.yaml
  3. Confirme se todos os pods foram agendados na mesma zona.

    kubectl get pod -o wide

    Saída esperada:

    NAME                                READY   STATUS    RESTARTS   AGE     IP              NODE                            NOMINATED NODE   READINESS GATES
    dep-pod-affinity-6b9d4f7c87-5jlfx   1/1     Running   0          3m26s   192.168.xx.xxx  virtual-kubelet-cn-hangzhou-i   <none>           <none>
    dep-pod-affinity-6b9d4f7c87-hwdpc   1/1     Running   0          3m26s   192.168.xx.xxx  virtual-kubelet-cn-hangzhou-i   <none>           <none>
    dep-pod-affinity-6b9d4f7c87-jfcrq   1/1     Running   0          3m26s   192.168.xx.xxx  virtual-kubelet-cn-hangzhou-i   <none>           <none>
    dep-pod-affinity-6b9d4f7c87-xwbfr   1/1     Running   0          3m26s   192.168.xx.xxx  virtual-kubelet-cn-hangzhou-i   <none>           <none>
    with-affinity-label-pod             1/1     Running   0          6m30s   192.168.xx.xxx  virtual-kubelet-cn-hangzhou-i   <none>           <none>

    Todos os cinco pods — as quatro réplicas do Deployment e o pod de referência — estão em execução na zona cn-hangzhou-i.