6.8. Affectation des ressources de l'ensemble de machines aux nœuds d'infrastructure
Après avoir créé un jeu de machines d'infrastructure, les rôles worker
et infra
sont appliqués aux nouveaux nœuds d'infrastructure. Les nœuds dotés du rôle infra
ne sont pas pris en compte dans le nombre total d'abonnements nécessaires à l'exécution de l'environnement, même si le rôle worker
est également appliqué.
Cependant, lorsqu'un nœud infra se voit attribuer le rôle de travailleur, il est possible que les charges de travail des utilisateurs soient affectées par inadvertance au nœud infra. Pour éviter cela, vous pouvez appliquer une taint au nœud infra et des tolérances pour les pods que vous souhaitez contrôler.
6.8.1. Lier les charges de travail des nœuds d'infrastructure à l'aide de taches et de tolérances
Si vous disposez d'un nœud infra auquel les rôles infra
et worker
ont été attribués, vous devez configurer le nœud de manière à ce que les charges de travail utilisateur ne lui soient pas affectées.
Il est recommandé de conserver le double label infra,worker
créé pour les nœuds infra et d'utiliser les taints et les tolérances pour gérer les nœuds sur lesquels les charges de travail des utilisateurs sont planifiées. Si vous supprimez le label worker
du nœud, vous devez créer un pool personnalisé pour le gérer. Un nœud doté d'une étiquette autre que master
ou worker
n'est pas reconnu par le MCO sans pool personnalisé. Le maintien de l'étiquette worker
permet au nœud d'être géré par le pool de configuration de la machine de travail par défaut, s'il n'existe aucun pool personnalisé qui sélectionne l'étiquette personnalisée. Le label infra
indique au cluster qu'il ne compte pas dans le nombre total d'abonnements.
Conditions préalables
-
Configurez des objets
MachineSet
supplémentaires dans votre cluster OpenShift Container Platform.
Procédure
Ajouter une tare au nœud infra pour empêcher la programmation des charges de travail des utilisateurs sur ce nœud :
Déterminer si le nœud est contaminé :
oc describe nodes <node_name>
Exemple de sortie
oc describe node ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l Name: ci-ln-iyhx092-f76d1-nvdfm-worker-b-wln2l Roles: worker ... Taints: node-role.kubernetes.io/infra:NoSchedule ...
Cet exemple montre que le nœud a une tare. Vous pouvez procéder à l'ajout d'une tolérance à votre pod à l'étape suivante.
Si vous n'avez pas configuré une taint pour empêcher la planification des charges de travail des utilisateurs sur cette taint :
$ oc adm taint nodes <node_name> <key>=<value>:<effect>
Par exemple :
$ oc adm taint nodes node1 node-role.kubernetes.io/infra=reserved:NoExecute
AstuceVous pouvez également appliquer le YAML suivant pour ajouter l'altération :
kind: Node apiVersion: v1 metadata: name: <node_name> labels: ... spec: taints: - key: node-role.kubernetes.io/infra effect: NoExecute value: reserved ...
Cet exemple place une taint sur
node1
qui a la clénode-role.kubernetes.io/infra
et l'effet de taintNoSchedule
. Les nœuds avec l'effetNoSchedule
ne planifient que les pods qui tolèrent l'altération, mais permettent aux pods existants de rester planifiés sur le nœud.NoteSi un planificateur est utilisé, les pods violant les taints de nœuds peuvent être expulsés du cluster.
Ajoutez des tolérances pour les configurations de pods que vous souhaitez planifier sur le nœud infra, comme le routeur, le registre et les charges de travail de surveillance. Ajoutez le code suivant à la spécification de l'objet
Pod
:tolerations: - effect: NoExecute 1 key: node-role.kubernetes.io/infra 2 operator: Exists 3 value: reserved 4
- 1
- Spécifiez l'effet que vous avez ajouté au nœud.
- 2
- Spécifiez la clé que vous avez ajoutée au nœud.
- 3
- Spécifiez l'opérateur
Exists
pour exiger la présence d'une taint avec la clénode-role.kubernetes.io/infra
sur le nœud. - 4
- Spécifiez la valeur de la paire clé-valeur taint que vous avez ajoutée au nœud.
Cette tolérance correspond à l'altération créée par la commande
oc adm taint
. Un pod avec cette tolérance peut être programmé sur le nœud infra.NoteIl n'est pas toujours possible de déplacer les modules d'un opérateur installé via OLM vers un nœud infra. La possibilité de déplacer les pods d'un opérateur dépend de la configuration de chaque opérateur.
- Programmer le pod sur le nœud infra à l'aide d'un planificateur. Voir la documentation de Controlling pod placement onto nodes pour plus de détails.
Ressources supplémentaires
- Voir Contrôle du placement des pods à l'aide de l'ordonnanceur pour des informations générales sur la planification d'un pod sur un nœud.