Chapitre 4. Contrôle du placement de la gousse sur les nœuds (programmation)
4.1. Contrôler le placement de la gousse à l’aide du planificateur Copier lienLien copié sur presse-papiers!
La planification des pod est un processus interne qui détermine le placement de nouvelles gousses sur les nœuds à l’intérieur du cluster.
Le code du programmeur a une séparation propre qui regarde les nouveaux pods au fur et à mesure qu’ils sont créés et identifie le nœud le plus approprié pour les héberger. Il crée ensuite des liaisons (pod à nœud) pour les pods à l’aide de l’API principale.
- Calendrier des pod par défaut
- Le service OpenShift Red Hat sur AWS est livré avec un programmeur 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 le meilleur ajustement pour un pod.
- Calendrier avancé des gousses
Dans les situations où vous pourriez vouloir plus de contrôle sur l’endroit où de nouveaux pods sont placés, le Red Hat OpenShift Service sur AWS fonctionnalités de planification avancées vous permettent de configurer un pod de sorte que le pod est requis ou a une préférence pour fonctionner sur un nœud particulier ou à côté d’un pod spécifique.
Il est possible de contrôler l’emplacement des pod en utilisant les fonctions de planification suivantes:
4.1.1. À propos du planificateur par défaut Copier lienLien copié sur presse-papiers!
Le Red Hat OpenShift Service par défaut sur AWS Pod scheduler est responsable de déterminer le placement de nouveaux pods sur les nœuds dans le cluster. Il lit les données du pod et trouve un nœud qui est un bon ajustement basé sur des profils configurés. Il est complètement indépendant et existe en tant que solution autonome. Il ne modifie pas la gousse; il crée une liaison pour la gousse qui lie la gousse au nœud particulier.
4.1.1.1. Comprendre la planification par défaut Copier lienLien copié sur presse-papiers!
Le planificateur générique existant est le moteur de planification fourni par la plate-forme par défaut qui sélectionne un nœud pour héberger le pod dans une opération en trois étapes:
- Filtre les nœuds
- Les nœuds disponibles sont filtrés en fonction des contraintes ou des exigences spécifiées. Cela se fait en exécutant chaque nœud à travers la liste des fonctions de filtre appelées prédicats, ou filtres.
- Priorise la liste filtrée des nœuds
- Ceci est réalisé en passant chaque nœud à travers une série de fonctions prioritaires, ou de notation, qui lui attribuent un score entre 0 - 10, avec 0 indiquant un mauvais ajustement et 10 indiquant un bon ajustement pour héberger le pod. La configuration du planning peut également prendre un poids simple (valeur numérique positive) pour chaque fonction de notation. Le score de nœud fourni par chaque fonction de notation est multiplié par le poids (poids par défaut pour la plupart des scores est 1), puis combiné en ajoutant les scores pour chaque nœud fourni par tous les scores. Cet attribut poids peut être utilisé par les administrateurs pour donner une plus grande importance à certains scores.
- Sélectionne le nœud le mieux adapté
- Les nœuds sont triés en fonction de leurs scores et le nœud avec le score le plus élevé est sélectionné pour héberger le pod. Lorsque plusieurs nœuds ont le même score élevé, l’un d’entre eux est sélectionné au hasard.
4.1.2. Cas d’utilisation du programmeur Copier lienLien copié sur presse-papiers!
L’un des cas d’utilisation importants pour la planification dans Red Hat OpenShift Service sur AWS est de prendre en charge des politiques d’affinité et de lutte contre l’affinité flexibles.
4.1.2.1. Affinité Copier lienLien copié sur presse-papiers!
Les administrateurs devraient être en mesure de configurer le programmeur pour spécifier l’affinité à n’importe quel niveau topologique, ou même à 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 gère toutes les exigences de latence des applications en permettant aux administrateurs de s’assurer que les pairs ne finissent pas par être trop séparés géographiquement. Dans le cas où aucun nœud n’est disponible au sein du même groupe d’affinité pour héberger la gousse, la gousse n’est pas programmée.
Lorsque vous avez besoin d’un plus grand contrôle sur l’endroit où les gousses sont programmées, consultez le placement de la gousse de contrôle sur les nœuds en utilisant les règles d’affinité des nœuds et les gousses de placement par rapport à d’autres gousses en utilisant des règles d’affinité et d’anti-affinité.
Ces fonctionnalités de planification avancée permettent aux administrateurs de spécifier quel nœud un pod peut être programmé et de forcer ou de rejeter la planification par rapport aux autres pods.
4.1.2.2. Anti-affinité Copier lienLien copié sur presse-papiers!
Les administrateurs devraient être en mesure de configurer le programmeur pour spécifier l’anti-affinité à n’importe quel niveau topologique, ou même à plusieurs niveaux. L’anti-affinité (ou « propagation ») à un niveau particulier indique que tous les pods appartenant au même service sont répartis entre les nœuds qui appartiennent à ce niveau. Cela garantit que l’application est bien répartie à des fins de haute disponibilité. Le planificateur essaie d’équilibrer les pods de service sur tous les nœuds applicables aussi uniformément que possible.
Lorsque vous avez besoin d’un plus grand contrôle sur l’endroit où les gousses sont programmées, consultez le placement de la gousse de contrôle sur les nœuds en utilisant les règles d’affinité des nœuds et les gousses de placement par rapport à d’autres gousses en utilisant des règles d’affinité et d’anti-affinité.
Ces fonctionnalités de planification avancée permettent aux administrateurs de spécifier quel nœud un pod peut être programmé et de forcer ou de rejeter la planification par rapport aux autres pods.