Container Service for Kubernetes:Topology-aware Scheduling

Présentation

Dans les tâches d'apprentissage automatique et d'analyse de big data, les pods ont souvent des exigences élevées en matière de communication réseau. Par défaut, le planificateur natif de Kubernetes répartit uniformément les pods dans l'ensemble du cluster. Cela augmente la distance de communication et allonge le temps d'exécution des tâches. Pour optimiser l'exécution des tâches, vous pouvez déployer les pods dans la même zone de disponibilité ou sur le même rack afin de réduire le nombre de sauts réseau et la latence. Kubernetes prend nativement en charge la planification par affinité via NodeAffinity et PodAffinity. Toutefois, cette planification par affinité native présente les limitations suivantes.

• Les pods ne peuvent pas retenter leur planification sur différents domaines de topologie. Dans la planification par affinité native de Kubernetes, la planification d'une tâche entière est déterminée par le placement du premier pod. Si l'emplacement du premier pod ne peut pas accueillir tous les pods de la tâche, certains pods resteront dans l'état Pending. Le planificateur ne basculera pas automatiquement vers une autre zone de disponibilité, même si un autre domaine de topologie pourrait accueillir l'intégralité de la tâche.

• Actuellement, les nœuds ne disposent que d'étiquettes au niveau de la zone de disponibilité. Par conséquent, l'affinité des pods est limitée à une seule zone de disponibilité et les pods ne peuvent pas être épinglés à des domaines de topologie plus fins.

Retenter la planification sur plusieurs domaines de topologie

Vous pouvez ajouter un identifiant de planification par groupe à une tâche pour activer l'allocation simultanée des ressources pour tous les pods et permettre des tentatives de planification sur plusieurs domaines de topologie.

1. Ajoutez un identifiant de planification par groupe aux étiquettes du pod. Pour en savoir plus sur la planification par groupe, consultez Utilisation de la planification par groupe.

   ...
   labels:
     pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpu # tf-smoke-gpu is the name of the PodGroup. Specify a custom value.
     pod-group.scheduling.sigs.k8s.io/min-available: "3" # You can set this value to the number of pods in the job.
   ...

2. Ajoutez la contrainte de planification tenant compte de la topologie à l'annotation du pod.

   annotations:
     alibabacloud.com/topology-aware-constraint: {\"name\":\"test\",\"required\":{\"topologies\":[{\"key\":\"kubernetes.io/hostname\"}],\"nodeSelectors\":[{\"matchLabels\":{\"test\":\"abc\"}}]}}

   La valeur de alibabacloud.com/topology-aware-constraint doit être une chaîne JSON valide présentant la structure suivante.

   {
     "name": xxx, # Any name.
     "required": {
       "topologies": [
         {
           "key": xxx # The key that specifies the topology domain for affinity.
         }
       ],
       "nodeSelectors": [
         {
           # This structure follows the labelSelector format in the native Kubernetes nodeAffinity.
           "matchLabels": {},
           "matchExpressions": {} 
         }
       ]
     }
   }

   Après avoir appliqué cette configuration, le planificateur place tous les pods portant l'étiquette pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpu sur les nœuds correspondant à l'étiquette test=abc. Voici un exemple de sortie :

   kubectl get pod -ojson | jq '.items[] | {"name":.metadata.name,"ann":.metadata.annotations["alibabacloud.com/topology-aware-constraint"], "node": spec.nodeName}'
   {
       "name": "nginx-deployment-basic-69f47fc6db-6****",
       "ann": "{\"name\": \"test\", \"required\": {\"topologies\":[{\"key\": \"kubernetes.io/hostname\"}], \"nodeSelectors\": [{\"matchLabels\": {\"test\": \"a\"}}]}} ",
       "node": "cn-shenzhen.10.0.2.4"
   }
   {
       "name":"nginx-deployment-basic-69f47fc6db-h****",
       "ann": "{\"name\": \"test\", \"required\": {\"topologies\":[{\"key\": \"kubernetes.io/hostname\"}], \"nodeSelectors\": [{\"matchLabels\": {\"test\": \"a\"}}]}} ",
       "node": "cn-shenzhen.10.0.2.4"
   }

Planifier vers un groupe de déploiement à faible latence

Dans certains scénarios, les tâches nécessitent une affinité au sein de domaines de topologie plus fins pour atteindre des performances optimales. ECS propose des groupes de déploiement à faible latence qui contraignent le placement des nœuds ECS. Pour plus d'informations, consultez Bonnes pratiques pour associer des groupes de déploiement à des pools de nœuds.

Lorsque vous créez un pool de nœuds utilisant un groupe de déploiement à faible latence, vous devez également ajouter une étiquette de nœud personnalisée pour le distinguer des autres pools de nœuds.

Une fois les étapes précédentes effectuées, utilisez l'annotation et les étiquettes suivantes pour planifier une tâche au sein d'un groupe de déploiement à faible latence.

1. Ajoutez un identifiant de planification par groupe aux étiquettes du pod. Pour en savoir plus sur la planification par groupe, consultez Utilisation de la planification par groupe.

   labels:
     pod-group.scheduling.sigs.k8s.io/name: xxx # xxx is the name of the PodGroup. Specify a custom value.
     pod-group.scheduling.sigs.k8s.io/min-available: "x" # You can set this value to the number of pods in the job.

2. Ajoutez la contrainte de planification tenant compte de la topologie à l'annotation du pod.

   Important

   Remplacez matchLabels par l'étiquette de nœud personnalisée de votre groupe de déploiement à faible latence et modifiez name selon vos besoins.

   annotations:
     alibabacloud.com/topology-aware-constraint: {\"name\":\"test\",\"required\":{\"topologies\":[{\"key\":\"alibabacloud.com/nodepool-id\"}],\"nodeSelectors\":[{\"matchLabels\":{\"np-type\":\"low-latency\"}}]}}