Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

13.2. À l’aide de taintes et de tolérances pour contrôler le placement des pods d’enregistrement

Les taintes et les tolérances permettent au nœud de contrôler quels pods doivent (ou ne devraient pas) être programmés sur eux.

13.2.1. Comprendre les taintes et les tolérances
Copier lien

La tainte permet à un nœud de refuser la programmation d’une gousse à moins que cette gousse n’ait une tolérance correspondante.

Appliquez des taintes à un nœud via la spécification Node (NodeSpec) et appliquez des tolérances à un pod via la spécification Pod (PodSpec). Lorsque vous appliquez un nœud taint, le planificateur ne peut pas placer une gousse sur ce nœud à moins que la gousse ne puisse tolérer la tainte.

Exemple taint dans une spécification de nœud

apiVersion: v1
kind: Node
metadata:
  name: my-node
#...
spec:
  taints:
  - effect: NoExecute
    key: key1
    value: value1
#...

Exemple de tolérance dans un Pod spec

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
#...
spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"
    tolerationSeconds: 3600
#...

Les taintes et les tolérances se composent d’une clé, d’une valeur et d’un effet.

Expand
Tableau 13.1. Composants de tainte et de tolérance
Le paramètreDescription

la clé

La clé est n’importe quelle chaîne, jusqu’à 253 caractères. La clé doit commencer par une lettre ou un nombre, et peut contenir des lettres, des chiffres, des traits d’union, des points et des accents.

la valeur

La valeur est n’importe quelle chaîne, jusqu’à 63 caractères. La valeur doit commencer par une lettre ou un nombre, et peut contenir des lettres, des chiffres, des traits d’union, des points et des accents.

effet

L’effet est l’un des suivants:

Expand

Calendrier [1]

  • Les nouvelles gousses qui ne correspondent pas à la tainte ne sont pas programmées sur ce nœud.
  • Des gousses existantes sur le nœud restent.

La préférenceNoSchedule

  • De nouvelles gousses qui ne correspondent pas à la tainte peuvent être programmées sur ce nœud, mais le planificateur essaie de ne pas le faire.
  • Des gousses existantes sur le nœud restent.

Le noexecute

  • Les nouvelles gousses qui ne correspondent pas à la tainte ne peuvent pas être programmées sur ce nœud.
  • Les gousses existantes sur le nœud qui n’ont pas de tolérance correspondante sont supprimées.

exploitant

Expand

Égale

Les paramètres clé/valeur/effet doivent correspondre. C’est la valeur par défaut.

Existe

Les paramètres clés/effets doivent correspondre. Il faut laisser un paramètre de valeur vierge, qui correspond à n’importe quel paramètre.

  1. Lorsque vous ajoutez un taint NoSchedule à un nœud de plan de contrôle, le nœud doit avoir le node-role.kubernetes.io/master=:NoSchedule taint, qui est ajouté par défaut.

    À titre d’exemple: 

    apiVersion: v1
kind: Node
metadata:
  annotations:
    machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
    machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
  name: my-node
#...
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
#...

A tolérance correspond à une tainte:

  • Lorsque le paramètre de l’opérateur est défini sur Equal:

    • les paramètres clés sont les mêmes;
    • les paramètres de valeur sont les mêmes;
    • les paramètres d’effet sont les mêmes.

  • Lorsque le paramètre opérateur est défini sur Exist:

    • les paramètres clés sont les mêmes;
    • les paramètres d’effet sont les mêmes.

Les taintes suivantes sont intégrées dans OpenShift Dedicated:

  • node.kubernetes.io/not-ready: Le nœud n’est pas prêt. Cela correspond à la condition du nœud Ready=False.
  • node.kubernetes.io/unreachable: Le nœud est inaccessible à partir du contrôleur du nœud. Cela correspond à la condition du nœud Ready=Inknown.
  • node.kubernetes.io/Memory-pression: Le nœud a des problèmes de pression de mémoire. Cela correspond à la condition du nœud MemoryPressure=True.
  • node.kubernetes.io/disk-pression: Le nœud a des problèmes de pression du disque. Cela correspond à la condition du nœud DiskPressure=True.
  • node.kubernetes.io/network-indisponible: Le réseau de nœuds n’est pas disponible.
  • node.kubernetes.io/Unschedulable: Le nœud est imprévu.
  • node.cloudprovider.kubernetes.io/non initialisé: Lorsque le contrôleur de nœud est démarré avec un fournisseur de cloud externe, cette tainte est définie sur un nœud pour le marquer comme inutilisable. Après qu’un contrôleur du cloud-controller-manager initialise ce nœud, le kubelet enlève cette tainte.

  • node.kubernetes.io/pid-pression: Le nœud a une pression pid. Cela correspond à la condition du nœud PIDPressure=True.

    Important

    L’option OpenShift Dedicated n’est pas définie par défaut pid.available evictionHard.

13.2.2. Loki Pod placement
Copier lien

Il est possible de contrôler les nœuds sur lesquels les pods Loki s’exécutent et d’empêcher d’autres charges de travail d’utiliser ces nœuds, en utilisant des tolérances ou des sélecteurs de nœuds sur les pods.

Avec la ressource personnalisée LokiStack (CR) vous pouvez appliquer des tolérances aux pods de log store et appliquer des taintes à un nœud avec la spécification du nœud. La tainte sur un nœud est une paire key:value qui ordonne au nœud de repousser toutes les gousses qui ne permettent pas la tainte. En utilisant une paire clé:valeur spécifique qui n’est pas sur d’autres gousses garantit que seuls les pods de log store peuvent fonctionner sur ce nœud.

Exemple LokiStack avec sélecteurs de nœuds

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
1 

      nodeSelector:
        node-role.kubernetes.io/infra: ""
2 

    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...

1
Indique le type de pod de composant qui s’applique au sélecteur de nœud.
2
Indique les pods qui sont déplacés vers des nœuds contenant l’étiquette définie.

Dans la configuration de l’exemple précédent, tous les pods Loki sont déplacés vers des nœuds contenant l’étiquette node-role.kubernetes.io/infra: "".

Exemple LokiStack CR avec sélecteurs de nœuds et tolérances

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...

Afin de configurer les champs nodeSelector et tolerations du LokiStack (CR), vous pouvez utiliser la commande oc explicative pour afficher la description et les champs d’une ressource particulière: 

$ oc explain lokistack.spec.template

Exemple de sortie

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...

Afin d’obtenir des informations plus détaillées, vous pouvez ajouter un champ spécifique: 

$ oc explain lokistack.spec.template.compactor

Exemple de sortie

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...

Les pods collector de journaux par défaut ont la configuration de tolérance suivante: 

apiVersion: v1
kind: Pod
metadata:
  name: collector-example
  namespace: openshift-logging
spec:
# ...
  collection:
    type: vector
    tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/master
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/disk-pressure
      operator: Exists
    - effect: NoExecute
      key: node.kubernetes.io/not-ready
      operator: Exists
    - effect: NoExecute
      key: node.kubernetes.io/unreachable
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/memory-pressure
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/pid-pressure
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/unschedulable
      operator: Exists
# ...

Conditions préalables

  • Le Red Hat OpenShift Logging Operator et OpenShift CLI (oc) ont été installés.

Procédure

  1. Ajoutez un taint à un nœud où vous voulez enregistrer des pods collector pour programmer les pods de collecte de journalisation en exécutant la commande suivante: 

    $ oc adm taint nodes <node_name> <key>=<value>:<effect>

    Commande d’exemple

    $ oc adm taint nodes node1 collector=node:NoExecute

    Cet exemple place une tainte sur node1 qui a le collecteur de clés, le nœud de valeur et l’effet taint NoExecute. Il faut utiliser l’effet NoExecute taint. Le programme noexecute uniquement les pods qui correspondent à la tainte et supprime les pods existants qui ne correspondent pas.

  2. Éditer la strophe de collection de la ressource personnalisée ClusterLogging (CR) pour configurer une tolérance pour les pods de collecte de journalisation: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
  collection:
    type: vector
    tolerations:
    - key: collector
    1 
    
      operator: Exists
    2 
    
      effect: NoExecute
    3 
    
      tolerationSeconds: 6000
    4 
    
    resources:
      limits:
        memory: 2Gi
      requests:
        cpu: 100m
        memory: 1Gi
# ...
    1
    Indiquez la clé que vous avez ajoutée au nœud.
    2
    Indiquez l’opérateur existant pour exiger que les paramètres clés/valeur/effet correspondent.
    3
    Indiquez l’effet NoExecute.
    4
    En option, spécifiez le paramètre de toléranceSeconds pour définir combien de temps un pod peut rester lié à un nœud avant d’être expulsé.

Cette tolérance correspond à la tainte créée par la commande oc adm taint. La gousse avec cette tolérance peut être programmée sur le nœud1.

Les administrateurs peuvent modifier les ressources ou la planification du collecteur en créant une ressource personnalisée ClusterLogging (CR) qui se trouve dans le même espace de noms et a le même nom que le ClusterLogForwarder CR qu’il prend en charge.

Les strophes applicables au ClusterLogging CR lors de l’utilisation de plusieurs transmetteurs de journaux dans un déploiement sont l’état de gestion et la collecte. Les autres strophes sont ignorées.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • La version 5.8 ou plus récente de Red Hat OpenShift Logging Operator a été installée.
  • ClusterLogForwarder CR a créé un ClusterLogForwarder CR.

Procédure

  1. Créez un ClusterLogging CR qui prend en charge votre ClusterLogForwarder CR existant:

    Exemple ClusterLogging CR YAML

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name:  <name>
    1 
    
  namespace: <namespace>
    2 
    
spec:
  managementState: "Managed"
  collection:
    type: "vector"
    tolerations:
    - key: "logging"
      operator: "Exists"
      effect: "NoExecute"
      tolerationSeconds: 6000
    resources:
      limits:
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 1Gi
    nodeSelector:
      collector: needed
# ...

    1
    Le nom doit être le même nom que le ClusterLogForwarder CR.
    2
    L’espace de noms doit être le même espace de noms que le ClusterLogForwarder CR.

  2. Appliquez le ClusterLogging CR en exécutant la commande suivante: 

    $ oc apply -f <filename>.yaml

13.2.5. Affichage des pods de collecteurs de journalisation
Copier lien

Il est possible d’afficher les pods de collecteurs de journalisation et les nœuds correspondants sur lesquels ils sont en cours d’exécution.

Procédure

  • Exécutez la commande suivante dans un projet pour afficher les pods de collecte de journalisation et leurs détails: 

    $ oc get pods --selector component=collector -o wide -n <project_name>

    Exemple de sortie

    NAME           READY  STATUS    RESTARTS   AGE     IP            NODE                  NOMINATED NODE   READINESS GATES
collector-8d69v  1/1    Running   0          134m    10.130.2.30   master1.example.com   <none>           <none>
collector-bd225  1/1    Running   0          134m    10.131.1.11   master2.example.com   <none>           <none>
collector-cvrzs  1/1    Running   0          134m    10.130.0.21   master3.example.com   <none>           <none>
collector-gpqg2  1/1    Running   0          134m    10.128.2.27   worker1.example.com   <none>           <none>
collector-l9j7j  1/1    Running   0          134m    10.129.2.31   worker2.example.com   <none>           <none>

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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2026 Red HatRetour au début