Les clusters ACS exposent les ressources sous forme de nœuds virtuels. Vous travaillez ainsi avec des règles d'orchestration plutôt qu'avec la capacité brute des nœuds. Cette rubrique associe les besoins courants d'ordonnancement (répartition entre zones de disponibilité, colocalisation des charges de travail, coordination des jobs par lots et isolation des ressources multi-locataires) aux politiques d'ordonnancement ACS correspondantes. Vous pouvez ainsi choisir la politique adaptée sans consulter chaque guide lié.
Politiques d'ordonnancement natives Kubernetes
L'ordonnanceur Kubernetes fournit un ensemble de plug-ins. Pour les nœuds virtuels ACS, les politiques basées sur l'affinité sont les plus pertinentes pour contrôler le placement des pods et répondre aux exigences de performance et de haute disponibilité.
| Politique | Fonctionnement | Référence |
|---|---|---|
| Contraintes de répartition topologique | Spécifiez un libellé sur un nœud virtuel dans le champ topologyKey pour répartir les réplicas de charge de travail entre plusieurs zones de disponibilité. Adoptez cette approche lorsqu'une panne affectant une seule zone risque d'indisponibiliser votre application. |
Utiliser les contraintes de répartition topologique pour distribuer les pods entre les zones |
| Affinité de nœud | Ajoutez des libellés aux nœuds virtuels afin de représenter des attributs tels que la zone de disponibilité. Référencez ces libellés dans nodeSelector pour ancrer les pods aux nœuds présentant des caractéristiques spécifiques. |
Ordonnancer les pods en fonction de l'affinité de nœud |
| Affinité inter-pods | Maîtrisez le placement des pods en vous basant sur les libellés des pods déjà en cours d'exécution sur les nœuds. Utilisez podAffinity pour ordonnancer les pods vers un domaine topologique précis. |
Ordonnancer les pods en fonction de l'affinité inter-pods |
Ordonnancement des ressources basé sur des priorités personnalisées
Si votre cluster exécute plusieurs types de classes de calcul, classez-les par ordre de préférence. Lorsque le type prioritaire n'est plus disponible, l'ordonnanceur tente automatiquement d'utiliser le type suivant de votre liste. Ce mécanisme s'avère particulièrement utile pour les charges de travail sensibles aux coûts qui privilégient les instances best-effort, mais doivent tout de même s'exécuter en cas d'indisponibilité de ces dernières.
| Politique | Fonctionnement | Référence |
|---|---|---|
| Ordonnancement des ressources basé sur des priorités personnalisées | Spécifiez plusieurs classes de calcul ou classes de QoS de calcul pour un pod. En cas d'épuisement des ressources, l'ordonnanceur tente de créer des pods d'autres types. |
Ordonnancement des ressources basé sur des priorités personnalisées |
Ordonnancement des jobs
Les charges de travail par lots et d'IA présentent des exigences différentes de celles des services à exécution continue. Un job d'entraînement IA nécessite généralement le démarrage simultané de tous ses pods : un démarrage partiel du groupe gaspille des ressources sans faire progresser le traitement. Dans les clusters partagés entre plusieurs équipes, les plafonds de ressources par namespace empêchent une charge de travail unique de monopoliser les ressources au détriment des autres.
| Politique | Fonctionnement | Cas d'usage | Référence |
|---|---|---|---|
| Gang scheduling | Alloue les ressources à un groupe entier de pods en tant que lot. Si le cluster ne peut pas satisfaire la demande complète, tous les pods du groupe restent à l'état Pending. | Jobs de calcul haute performance (HPC) et d'entraînement IA, tels que les jobs Message Passing Interface (MPI), où tous les réplicas doivent démarrer avant que le job puisse progresser. | |
| Capacity scheduling | Définit des limites de capacité de ressources par namespace. | Clusters partagés par plusieurs équipes ou applications nécessitant une allocation minimale de ressources garantie pour chaque groupe et une prévention de la surconsommation. |