Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

6.7. Utiliser les tolérances pour contrôler le placement des pods OpenShift Logging

download PDF

Vous pouvez utiliser les taints et les tolérances pour vous assurer que les pods du sous-système de journalisation s'exécutent sur des nœuds spécifiques et qu'aucune autre charge de travail ne peut s'exécuter sur ces nœuds.

Les taches et les tolérances sont des paires simples key:value. Une tare sur un nœud indique au nœud de repousser tous les pods qui ne tolèrent pas la tare.

key est une chaîne de caractères quelconque, d'une longueur maximale de 253 caractères, et value est une chaîne de caractères quelconque, d'une longueur maximale de 63 caractères. La chaîne doit commencer par une lettre ou un chiffre et peut contenir des lettres, des chiffres, des traits d'union, des points et des traits de soulignement.

Sous-système d'enregistrement des échantillons CR avec tolérances

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: openshift-logging

...

spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      tolerations: 1
      - key: "logging"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 6000
      resources:
        limits:
          memory: 16Gi
        requests:
          cpu: 200m
          memory: 16Gi
      storage: {}
      redundancyPolicy: "ZeroRedundancy"
  visualization:
    type: "kibana"
    kibana:
      tolerations: 2
      - key: "logging"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 6000
      resources:
        limits:
          memory: 2Gi
        requests:
          cpu: 100m
          memory: 1Gi
      replicas: 1
  collection:
    logs:
      type: "fluentd"
      fluentd:
        tolerations: 3
        - key: "logging"
          operator: "Exists"
          effect: "NoExecute"
          tolerationSeconds: 6000
        resources:
          limits:
            memory: 2Gi
          requests:
            cpu: 100m
            memory: 1Gi

1
Cette tolérance est ajoutée aux pods Elasticsearch.
2
Cette tolérance est ajoutée au pod Kibana.
3
Cette tolérance est ajoutée aux pods du collecteur de journalisation.

6.7.1. Utilisation des tolérances pour contrôler le placement des pods du magasin de logs

Vous pouvez contrôler les nœuds sur lesquels les pods de stockage de logs s'exécutent et empêcher d'autres charges de travail d'utiliser ces nœuds en utilisant des tolérances sur les pods.

Vous appliquez des tolérances aux pods de stockage de journaux par le biais de la ressource personnalisée (CR) ClusterLogging et vous appliquez des altérations à un nœud par le biais de la spécification de nœud. Une tare sur un nœud est une key:value pair qui ordonne au nœud de repousser tous les modules qui ne tolèrent pas la tare. L'utilisation d'une paire spécifique de key:value qui n'est pas sur d'autres pods garantit que seuls les pods de stockage de logs peuvent fonctionner sur ce nœud.

Par défaut, les pods de stockage de logs ont la tolérance suivante : 

tolerations:
- effect: "NoExecute"
  key: "node.kubernetes.io/disk-pressure"
  operator: "Exists"

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

  1. Utilisez la commande suivante pour ajouter un taint à un nœud où vous souhaitez planifier les pods OpenShift Logging : 

    $ oc adm taint nodes <node-name> <key>=<value>:<effect>

    Par exemple : 

    $ oc adm taint nodes node1 elasticsearch=node:NoExecute

    Cet exemple place une taint sur node1 qui a la clé elasticsearch, la valeur node, et l'effet de taint NoExecute. Les nœuds avec l'effet NoExecute programment uniquement les pods qui correspondent à l'altération et suppriment les pods existants qui ne correspondent pas à l'altération.

  2. Modifiez la section logstore du CR ClusterLogging pour configurer une tolérance pour les pods Elasticsearch : 

      logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 1
      tolerations:
      - key: "elasticsearch"  1
        operator: "Exists"  2
        effect: "NoExecute"  3
        tolerationSeconds: 6000  4
    1
    Spécifiez la clé que vous avez ajoutée au nœud.
    2
    Spécifiez l'opérateur Exists pour exiger qu'une altération avec la clé elasticsearch soit présente sur le nœud.
    3
    Spécifiez l'effet NoExecute.
    4
    En option, le paramètre tolerationSeconds permet de définir la durée pendant laquelle un pod peut rester lié à un nœud avant d'être expulsé.

Cette tolérance correspond à l'altération créée par la commande oc adm taint. Un pod avec cette tolérance pourrait être programmé sur node1.

6.7.2. Utilisation des tolérances pour contrôler le placement du pod du visualiseur de logs

Vous pouvez contrôler le nœud sur lequel le module de visualisation du journal s'exécute et empêcher d'autres charges de travail d'utiliser ces nœuds en utilisant des tolérances sur les modules.

Vous appliquez des tolérances au pod de visualisation du journal par le biais de la ressource personnalisée (CR) ClusterLogging et vous appliquez des taches à un nœud par le biais de la spécification du nœud. Une tare sur un nœud est une key:value pair qui demande au nœud de repousser tous les pods qui ne tolèrent pas la tare. L'utilisation d'une paire spécifique de key:value qui n'est pas sur d'autres pods garantit que seul le pod Kibana peut fonctionner sur ce nœud.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

  1. Utilisez la commande suivante pour ajouter une taint à un nœud où vous souhaitez planifier le pod de visualisation de logs : 

    $ oc adm taint nodes <node-name> <key>=<value>:<effect>

    Par exemple : 

    $ oc adm taint nodes node1 kibana=node:NoExecute

    Cet exemple place une taint sur node1 qui a la clé kibana, la valeur node, et l'effet de taint NoExecute. Vous devez utiliser l'effet de taint NoExecute. NoExecute planifie uniquement les pods qui correspondent au taint et supprime les pods existants qui ne correspondent pas.

  2. Modifiez la section visualization de la CR ClusterLogging pour configurer une tolérance pour le module Kibana : 

      visualization:
    type: "kibana"
    kibana:
      tolerations:
      - key: "kibana"  1
        operator: "Exists"  2
        effect: "NoExecute"  3
        tolerationSeconds: 6000 4
    1
    Spécifiez la clé que vous avez ajoutée au nœud.
    2
    Spécifiez l'opérateur Exists pour que les paramètres key/value/effect correspondent.
    3
    Spécifiez l'effet NoExecute.
    4
    En option, le paramètre tolerationSeconds permet de définir la durée pendant laquelle un pod peut rester lié à un nœud avant d'être expulsé.

Cette tolérance correspond à la taint créée par la commande oc adm taint. Un pod avec cette tolérance pourrait être programmé sur node1.

6.7.3. Utilisation des tolérances pour contrôler l'emplacement du collecteur de logs

Vous pouvez vous assurer des nœuds sur lesquels les pods du collecteur de journalisation s'exécutent et empêcher d'autres charges de travail d'utiliser ces nœuds en utilisant des tolérances sur les pods.

Vous appliquez des tolérances aux pods collecteurs de journalisation via la ressource personnalisée (CR) ClusterLogging et vous appliquez des taints à un nœud via la spécification de nœud. Vous pouvez utiliser les taints et les tolérances pour vous assurer que le pod n'est pas expulsé pour des raisons telles que des problèmes de mémoire ou de CPU.

Par défaut, les pods du collecteur de logs ont la tolérance suivante : 

tolerations:
- key: "node-role.kubernetes.io/master"
  operator: "Exists"
  effect: "NoExecute"

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

  1. Utilisez la commande suivante pour ajouter une taint à un nœud où vous souhaitez que les pods collecteurs de journalisation planifient les pods collecteurs de journalisation : 

    $ oc adm taint nodes <node-name> <key>=<value>:<effect>

    Par exemple : 

    $ oc adm taint nodes node1 collector=node:NoExecute

    Cet exemple place une taint sur node1 qui a la clé collector, la valeur node, et l'effet de taint NoExecute. Vous devez utiliser l'effet de taint NoExecute. NoExecute planifie uniquement les pods qui correspondent au taint et supprime les pods existants qui ne correspondent pas.

  2. Modifiez la strophe collection de la ressource personnalisée (CR) ClusterLogging pour configurer une tolérance pour les pods du collecteur de journalisation : 

      collection:
    logs:
      type: "fluentd"
      fluentd:
        tolerations:
        - key: "collector"  1
          operator: "Exists"  2
          effect: "NoExecute"  3
          tolerationSeconds: 6000  4
    1
    Spécifiez la clé que vous avez ajoutée au nœud.
    2
    Spécifiez l'opérateur Exists pour que les paramètres key/value/effect correspondent.
    3
    Spécifiez l'effet NoExecute.
    4
    En option, le paramètre tolerationSeconds permet de définir la durée pendant laquelle un pod peut rester lié à un nœud avant d'être expulsé.

Cette tolérance correspond à la taint créée par la commande oc adm taint. Un pod avec cette tolérance pourrait être programmé sur node1.

6.7.4. Ressources complé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.