Tous les produits
Search
Centre de documentation

Container Compute Service:Planification par affinité de pods

Dernière mise à jour :Aug 12, 2026

La planification par affinité de pods détermine l'emplacement d'un pod en fonction des libellés des pods déjà exécutés sur les nœuds virtuels, et non selon les propriétés du nœud. Dans un cluster ACS, cette fonctionnalité repose sur la sémantique native de Kubernetes : spécifiez des domaines topologiques et des règles de libellés dans podAffinity ou podAntiAffinity pour regrouper ou répartir les pods entre les zones.

Cas d'usage fréquent : vous exécutez un service sans état avec plusieurs réplicas et souhaitez que tous se trouvent dans la même zone de disponibilité qu'un pod de cache partagé afin de réduire la latence interzone. L'utilisation de requiredDuringSchedulingIgnoredDuringExecution applique strictement cette contrainte lors de la planification.

Prérequis

Avant de commencer, assurez-vous que :

  • Le composant kube-scheduler est installé et respecte les exigences de version suivantes :

    Version du cluster ACS Version du composant Scheduler
    1.31 v1.31.0-aliyun-1.2.0 et ultérieures
    1.30 v1.30.3-aliyun-1.1.1 et ultérieures
    1.28 v1.28.9-aliyun-1.1.0 et ultérieures
  • Le composant acs-virtual-node est installé en version v2.12.0-acs.4 ou ultérieure.

Limites

ACS impose les contraintes suivantes concernant l'affinité de pods.

Pods GPU-HPN

L'affinité de pods est soumise à des restrictions lorsque les trois conditions ci-dessous s'appliquent simultanément à un pod :

  • Le pod utilise le type de calcul High-Performance Network GPU (GPU-HPN).

  • Le champ schedulerName du pod est défini sur default-scheduler.

  • L'option Enable Custom Tags And Scheduler For GPU-HPN Nodes n'est pas sélectionnée dans la configuration du composant scheduler.

L'option Enable Custom Tags and the Scheduler for GPU-HPN Nodes est activée par défaut dans les versions récentes. Pour plus de détails, consultez kube-scheduler .

Politique prise en charge

Seule la directive requiredDuringSchedulingIgnoredDuringExecution est prise en charge. La directive preferredDuringSchedulingIgnoredDuringExecution n'est pas prise en charge.

Les champs suivants s'appliquent dans le cadre de requiredDuringSchedulingIgnoredDuringExecution :

Champ Description Contrainte
labelSelector Identifie les pods correspondants. Les pods portant ce libellé sont comptabilisés par domaine topologique. Les pods d'autres types de calcul (usage général, optimisé pour le calcul, GPU) sont exclus du décompte.
namespaces Définit les namespaces où rechercher les pods correspondants, en association avec labelSelector. Non pris en charge
namespaceSelector Sélectionne des namespaces via leurs libellés plutôt que par leur nom. Non pris en charge

Pour consulter la référence complète des champs, reportez-vous à la section Pod affinity and anti-affinity de la documentation Kubernetes.

Planifier des pods dans la même zone

Cet exemple illustre l'utilisation de podAffinity pour placer les pods d'un Deployment dans la même zone de disponibilité qu'un pod existant possédant un libellé spécifique. Ce schéma est typique lorsque les réplicas d'un service doivent partager la zone d'une dépendance (comme un cache) afin d'éviter la latence interzone.

Le processus comporte deux étapes : déployer d'abord un pod avec un libellé cible, puis créer un Deployment qui exploite podAffinity pour se colocaliser avec ce pod étiqueté.

Étape 1 : Déployer le pod de référence étiqueté

  1. Listez les nœuds virtuels du cluster.

    kubectl get node

    Sortie attendue :

    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. Créez un fichier nommé with-affinity-pod.yaml contenant les éléments suivants.

    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. Déployez le pod.

    kubectl apply -f with-affinity-pod.yaml
  4. Vérifiez que le pod est en cours d'exécution et notez la zone dans laquelle il a été placé.

    kubectl get pod -o wide

    Sortie attendue :

    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>

    Le pod est planifié dans la zone cn-hangzhou-i. Le Deployment de l'étape suivante utilisera le libellé de ce pod pour déterminer la zone cible.

Étape 2 : Déployer avec une affinité de pods

  1. Créez un fichier nommé origin-affinity-pod.yaml avec le contenu ci-dessous.

    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. Déployez le Deployment.

    kubectl apply -f origin-affinity-pod.yaml
  3. Confirmez que tous les pods sont bien planifiés dans la même zone.

    kubectl get pod -o wide

    Sortie attendue :

    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>

    Les cinq pods — les quatre réplicas du Deployment et le pod de référence — s'exécutent tous dans la zone cn-hangzhou-i.