Rechercher

6.8. Affectation des ressources de l'ensemble de machines aux nœuds d'infrastructure

download PDF

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.

Important

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

  1. Ajouter une tare au nœud infra pour empêcher la programmation des charges de travail des utilisateurs sur ce nœud :

    1. 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.

    2. 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
      Astuce

      Vous 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 taint NoSchedule. Les nœuds avec l'effet NoSchedule ne planifient que les pods qui tolèrent l'altération, mais permettent aux pods existants de rester planifiés sur le nœud.

      Note

      Si un planificateur est utilisé, les pods violant les taints de nœuds peuvent être expulsés du cluster.

  2. 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.

    Note

    Il 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.

  3. 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

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.