3.6. Contrôle du placement de pods à l'aide de taches de nœuds

Vous pouvez spécifier la durée pendant laquelle un pod peut rester lié à un nœud avant d'être expulsé en spécifiant le paramètre tolerationSeconds dans la spécification Pod ou l'objet MachineSet. Si une altération ayant l'effet NoExecute est ajoutée à un nœud, un module qui tolère l'altération, qui a le paramètre tolerationSeconds, le module n'est pas expulsé avant l'expiration de ce délai.

spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"
    tolerationSeconds: 3600

Ici, si ce pod est en cours d'exécution mais n'a pas de tolérance correspondante, le pod reste lié au nœud pendant 3 600 secondes avant d'être expulsé. Si l'altération est supprimée avant ce délai, le module n'est pas expulsé.

Vous pouvez placer plusieurs taints sur le même nœud et plusieurs tolérances sur le même pod. OpenShift Container Platform traite les plaintes et tolérances multiples de la manière suivante :

Par exemple :

Dans ce cas, le module ne peut pas être programmé sur le nœud, car il n'y a pas de tolérance correspondant à la troisième tare. Le module continue de fonctionner s'il est déjà en cours d'exécution sur le nœud lorsque la tare est ajoutée, car la troisième tare est la seule des trois qui n'est pas tolérée par le module.

La fonction d'altération des nœuds par condition, activée par défaut, altère automatiquement les nœuds qui signalent des conditions telles que la pression de la mémoire et la pression du disque. Lorsqu'un nœud signale une condition, une erreur est ajoutée jusqu'à ce que la condition disparaisse. Les taches ont l'effet NoSchedule, ce qui signifie qu'aucun pod ne peut être planifié sur le nœud à moins que le pod n'ait une tolérance correspondante.

L'ordonnanceur vérifie la présence de ces anomalies sur les nœuds avant de planifier les modules. Si l'erreur est présente, le module est planifié sur un nœud différent. Comme l'ordonnanceur vérifie les anomalies et non les conditions réelles des nœuds, vous pouvez configurer l'ordonnanceur pour qu'il ignore certaines de ces conditions en ajoutant des tolérances appropriées pour les nœuds.

Pour assurer la compatibilité ascendante, le contrôleur de jeu de démons ajoute automatiquement les tolérances suivantes à tous les démons :

Vous pouvez également ajouter des tolérances arbitraires aux ensembles de démons.

La fonction Taint-Based Evictions, qui est activée par défaut, expulse les pods d'un nœud qui présente des conditions spécifiques, telles que not-ready et unreachable. Lorsqu'un nœud est confronté à l'une de ces conditions, OpenShift Container Platform ajoute automatiquement des taints au nœud et commence à expulser et à replanifier les pods sur différents nœuds.

Les évictions basées sur l'altération ont un effet NoExecute, où tout pod qui ne tolère pas l'altération est évincé immédiatement et tout pod qui tolère l'altération ne sera jamais évincé, à moins que le pod n'utilise le paramètre tolerationSeconds.

Le paramètre tolerationSeconds vous permet de spécifier la durée pendant laquelle un pod reste lié à un nœud qui a une condition de nœud. Si la condition existe toujours après la période tolerationSeconds, l'altération reste sur le nœud et les pods avec une tolérance correspondante sont expulsés. Si la condition disparaît avant la période tolerationSeconds, les pods avec les tolérances correspondantes ne sont pas supprimés.

Si vous utilisez le paramètre tolerationSeconds sans valeur, les pods ne sont jamais expulsés en raison des conditions "not ready" et "unreachable node".

OpenShift Container Platform ajoute automatiquement une tolérance pour node.kubernetes.io/not-ready et node.kubernetes.io/unreachable avec tolerationSeconds=300, à moins que la configuration Pod ne spécifie l'une ou l'autre tolérance.

spec:
  tolerations:
  - key: node.kubernetes.io/not-ready
    operator: Exists
    effect: NoExecute
    tolerationSeconds: 300 1
  - key: node.kubernetes.io/unreachable
    operator: Exists
    effect: NoExecute
    tolerationSeconds: 300

Vous pouvez configurer ces tolérances selon vos besoins. Par exemple, si vous avez une application avec beaucoup d'état local, vous pourriez vouloir garder les pods liés au nœud plus longtemps en cas de partition du réseau, ce qui permettrait à la partition de se rétablir et d'éviter l'éviction des pods.

Les pods générés par un ensemble de démons sont créés avec des tolérances de NoExecute pour les taches suivantes, sans tolerationSeconds:

Par conséquent, les pods de l'ensemble des démons ne sont jamais expulsés en raison de ces conditions de nœuds.

Vous pouvez configurer un pod pour qu'il tolère toutes les plaintes en ajoutant une tolérance operator: "Exists" sans paramètres key et value. Les pods ayant cette tolérance ne sont pas retirés d'un nœud qui a des taches.

spec:
  tolerations:
  - operator: "Exists"

Vous pouvez ajouter des taches aux nœuds à l'aide d'un ensemble de machines de calcul. Tous les nœuds associés à l'objet MachineSet sont mis à jour avec l'erreur. Les tolérances réagissent aux taches ajoutées par un ensemble de machines de calcul de la même manière que les taches ajoutées directement aux nœuds.

Si vous souhaitez réserver un ensemble de nœuds à l'usage exclusif d'un groupe particulier d'utilisateurs, ajoutez une tolérance à leurs pods. Ajoutez ensuite une altération correspondante à ces nœuds. Les pods avec les tolérances sont autorisés à utiliser les nœuds altérés ou tout autre nœud du cluster.

Si vous voulez vous assurer que les pods sont programmés uniquement sur les nœuds altérés, ajoutez également une étiquette au même ensemble de nœuds et ajoutez une affinité de nœud aux pods de sorte que les pods ne puissent être programmés que sur des nœuds avec cette étiquette.

Vous pouvez créer un projet qui utilise un sélecteur de nœud et une tolérance, qui sont définis comme des annotations, pour contrôler le placement des pods sur des nœuds spécifiques. Toutes les ressources ultérieures créées dans le projet sont alors planifiées sur des nœuds dont l'altération correspond à la tolérance.

Toutes les ressources créées ultérieurement dans l'espace de noms <project_name> doivent désormais être planifiées sur les nœuds spécifiés.

Dans un cluster où un petit sous-ensemble de nœuds dispose d'un matériel spécialisé, vous pouvez utiliser les taints et les tolérances pour empêcher les pods qui n'ont pas besoin de ce matériel spécialisé d'utiliser ces nœuds, laissant ainsi les nœuds aux pods qui ont besoin de ce matériel spécialisé. Vous pouvez également exiger que les modules qui ont besoin d'un matériel spécialisé utilisent des nœuds spécifiques.

Vous pouvez y parvenir en ajoutant une tolérance aux pods qui ont besoin d'un matériel spécial et en altérant les nœuds qui disposent de ce matériel.