Chapitre 3. Contrôle du placement des pods sur les nœuds (scheduling)
3.1. Contrôler le placement des pods à l'aide de l'ordonnanceur
L'ordonnancement des pods est un processus interne qui détermine le placement des nouveaux pods sur les nœuds du cluster.
Le code de l'ordonnanceur a une séparation propre qui observe les nouveaux pods lorsqu'ils sont créés et identifie le nœud le plus approprié pour les héberger. Il crée ensuite des liens (liens entre le pod et le nœud) pour les pods à l'aide de l'API principale.
- Ordonnancement par défaut des pods
- OpenShift Container Platform est livré avec un planificateur par défaut qui répond aux besoins de la plupart des utilisateurs. Le planificateur par défaut utilise à la fois des outils inhérents et des outils de personnalisation pour déterminer ce qui convient le mieux à un pod.
- Programmation avancée des nacelles
Dans les situations où vous souhaiteriez avoir plus de contrôle sur l'emplacement des nouveaux pods, les fonctionnalités de planification avancées d'OpenShift Container Platform vous permettent de configurer un pod de manière à ce qu'il soit nécessaire ou qu'il ait une préférence pour s'exécuter sur un nœud particulier ou aux côtés d'un pod spécifique.
Vous pouvez contrôler le placement des pods en utilisant les fonctions de planification suivantes :
3.1.1. À propos de l'ordonnanceur par défaut
Le planificateur de pods par défaut d'OpenShift Container Platform est chargé de déterminer le placement des nouveaux pods sur les nœuds du cluster. Il lit les données du pod et trouve un nœud qui convient en fonction des profils configurés. Il est complètement indépendant et existe en tant que solution autonome. Il ne modifie pas le module ; il crée une liaison pour le module qui lie le module à un nœud particulier.
3.1.1.1. Comprendre la programmation par défaut
L'ordonnanceur générique existant est l'ordonnanceur par défaut fourni par la plateforme engine qui sélectionne un nœud pour héberger le module en trois étapes :
- Filtre les nœuds
- Les nœuds disponibles sont filtrés en fonction des contraintes ou des exigences spécifiées. Pour ce faire, chaque nœud est soumis à la liste des fonctions de filtrage appelée predicates, ou filters.
- Hiérarchise la liste filtrée des nœuds
- Pour ce faire, chaque nœud est soumis à une série de fonctions priority ou scoring, qui lui attribuent une note comprise entre 0 et 10, 0 indiquant une mauvaise adaptation et 10 une bonne adaptation à l'hébergement du module. La configuration de l'ordonnanceur peut également prendre en compte un simple weight (valeur numérique positive) pour chaque fonction d'évaluation. La note du nœud fournie par chaque fonction de notation est multipliée par le poids (le poids par défaut pour la plupart des notes est de 1), puis combinée en ajoutant les notes de chaque nœud fournies par toutes les notes. Cet attribut de poids peut être utilisé par les administrateurs pour donner plus d'importance à certaines notes.
- Sélectionne le nœud le mieux adapté
- Les nœuds sont triés en fonction de leur score et le nœud ayant le score le plus élevé est sélectionné pour héberger le pod. Si plusieurs nœuds ont le même score, l'un d'entre eux est choisi au hasard.
3.1.2. Cas d'utilisation de l'ordonnanceur
L'un des principaux cas d'utilisation de l'ordonnancement dans OpenShift Container Platform est la prise en charge de politiques d'affinité et d'anti-affinité flexibles.
3.1.2.1. Niveaux topologiques de l'infrastructure
Les administrateurs peuvent définir plusieurs niveaux topologiques pour leur infrastructure (nœuds) en spécifiant des étiquettes sur les nœuds. Par exemple : region=r1 zone=z1 , rack=s1.
Ces noms d'étiquettes n'ont pas de signification particulière et les administrateurs sont libres de donner n'importe quel nom à leurs niveaux d'infrastructure, par exemple ville/bâtiment/chambre. En outre, les administrateurs peuvent définir un nombre quelconque de niveaux pour leur topologie d'infrastructure, trois niveaux étant généralement suffisants (par exemple : regions zones racks). Les administrateurs peuvent spécifier des règles d'affinité et d'anti-affinité à chacun de ces niveaux, dans n'importe quelle combinaison.
3.1.2.2. Affinité
Les administrateurs doivent pouvoir configurer l'ordonnanceur pour spécifier l'affinité à n'importe quel niveau topologique, voire à plusieurs niveaux. L'affinité à un niveau particulier indique que tous les pods appartenant au même service sont programmés sur des nœuds appartenant au même niveau. Cela permet de répondre aux exigences de latence des applications en permettant aux administrateurs de s'assurer que les pods homologues ne sont pas trop éloignés géographiquement les uns des autres. Si aucun nœud n'est disponible dans le même groupe d'affinité pour héberger le module, celui-ci n'est pas planifié.
Si vous avez besoin d'un meilleur contrôle sur l'emplacement des pods, consultez les sections Contrôle du placement des pods sur les nœuds à l'aide des règles d'affinité des nœuds et Placement des pods par rapport à d'autres pods à l'aide des règles d'affinité et d'anti-affinité.
Ces fonctions de planification avancées permettent aux administrateurs de spécifier le nœud sur lequel un pod peut être planifié et de forcer ou de rejeter la planification par rapport à d'autres pods.
3.1.2.3. Anti-affinité
Les administrateurs doivent pouvoir configurer l'ordonnanceur pour spécifier l'anti-affinité à n'importe quel niveau topologique, voire à plusieurs niveaux. L'anti-affinité (ou la "répartition") à un niveau particulier indique que tous les pods qui appartiennent au même service sont répartis sur les nœuds qui appartiennent à ce niveau. Cela garantit que l'application est bien répartie à des fins de haute disponibilité. L'ordonnanceur tente d'équilibrer les modules de service sur tous les nœuds concernés de la manière la plus homogène possible.
Si vous avez besoin d'un meilleur contrôle sur l'emplacement des pods, consultez les sections Contrôle du placement des pods sur les nœuds à l'aide des règles d'affinité des nœuds et Placement des pods par rapport à d'autres pods à l'aide des règles d'affinité et d'anti-affinité.
Ces fonctions de planification avancées permettent aux administrateurs de spécifier le nœud sur lequel un pod peut être planifié et de forcer ou de rejeter la planification par rapport à d'autres pods.
