Rechercher

7.14. Utilisation de l'opérateur Node Tuning

download PDF

Comprendre et utiliser l'opérateur Node Tuning.

L'opérateur d'optimisation des nœuds vous aide à gérer l'optimisation au niveau des nœuds en orchestrant le démon TuneD et à obtenir des performances à faible latence en utilisant le contrôleur de profil de performance. La majorité des applications à hautes performances nécessitent un certain niveau de réglage du noyau. Le Node Tuning Operator offre une interface de gestion unifiée aux utilisateurs de sysctls au niveau des nœuds et plus de flexibilité pour ajouter des réglages personnalisés en fonction des besoins de l'utilisateur.

L'opérateur gère le démon TuneD conteneurisé pour OpenShift Container Platform en tant qu'ensemble de démons Kubernetes. Il s'assure que la spécification de réglage personnalisé est transmise à tous les démons TuneD conteneurisés s'exécutant dans le cluster dans le format que les démons comprennent. Les démons s'exécutent sur tous les nœuds du cluster, un par nœud.

Les paramètres de niveau nœud appliqués par le démon TuneD conteneurisé sont annulés lors d'un événement qui déclenche un changement de profil ou lorsque le démon TuneD conteneurisé se termine de manière élégante en recevant et en gérant un signal de fin.

L'opérateur de réglage des nœuds utilise le contrôleur de profil de performance pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift Container Platform. L'administrateur du cluster configure un profil de performance pour définir des paramètres au niveau du nœud, tels que les suivants :

  • Mise à jour du noyau vers kernel-rt.
  • Choix des unités centrales de traitement pour l'entretien ménager.
  • Choix des unités centrales pour l'exécution des charges de travail.
Note

Actuellement, la désactivation de l'équilibrage de la charge du CPU n'est pas prise en charge par cgroup v2. Par conséquent, il se peut que vous n'obteniez pas le comportement souhaité des profils de performance si vous avez activé cgroup v2. L'activation de cgroup v2 n'est pas recommandée si vous utilisez des profils de performance.

L'opérateur Node Tuning fait partie de l'installation standard d'OpenShift Container Platform à partir de la version 4.1.

Note

Dans les versions antérieures d'OpenShift Container Platform, l'opérateur Performance Addon était utilisé pour mettre en œuvre un réglage automatique afin d'obtenir des performances de faible latence pour les applications OpenShift. Dans OpenShift Container Platform 4.11 et les versions ultérieures, cette fonctionnalité fait partie de l'opérateur Node Tuning.

7.14.1. Accéder à un exemple de spécification de l'opérateur Node Tuning

Cette procédure permet d'accéder à un exemple de spécification de l'opérateur de réglage des nœuds.

Procédure

  • Exécutez la commande suivante pour accéder à un exemple de spécification de l'opérateur Node Tuning :

    $ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator

Le CR par défaut est destiné à fournir un réglage standard au niveau du nœud pour la plateforme OpenShift Container Platform et il ne peut être modifié que pour définir l'état de gestion de l'opérateur. Toute autre modification personnalisée de la CR par défaut sera écrasée par l'opérateur. Pour un réglage personnalisé, créez vos propres CR réglés. Les CR nouvellement créés seront combinés avec le CR par défaut et les réglages personnalisés appliqués aux nœuds d'OpenShift Container Platform en fonction des étiquettes de nœuds ou de pods et des priorités de profil.

Avertissement

Bien que dans certaines situations, la prise en charge des étiquettes de pods puisse être un moyen pratique de fournir automatiquement les réglages nécessaires, cette pratique est déconseillée et fortement déconseillée, en particulier dans les clusters à grande échelle. Le CR Tuned par défaut est livré sans correspondance d'étiquettes de pods. Si un profil personnalisé est créé avec la correspondance des étiquettes de pods, alors la fonctionnalité sera activée à ce moment-là. La fonctionnalité d'étiquetage de pods sera obsolète dans les versions futures de l'opérateur de tuning de nœuds.

7.14.2. Spécification de réglage personnalisé

La ressource personnalisée (CR) de l'opérateur comporte deux sections principales. La première section, profile:, est une liste de profils TuneD et de leurs noms. La seconde, recommend:, définit la logique de sélection des profils.

Plusieurs spécifications de réglage personnalisées peuvent coexister en tant que CR multiples dans l'espace de noms de l'opérateur. L'existence de nouveaux CR ou la suppression d'anciens CR est détectée par l'Opérateur. Toutes les spécifications de réglage personnalisées existantes sont fusionnées et les objets appropriés pour les démons TuneD conteneurisés sont mis à jour.

Management state

L'état de gestion de l'opérateur est défini en ajustant le CR accordé par défaut. Par défaut, l'opérateur est en état de gestion et le champ spec.managementState n'est pas présent dans le CR accordé par défaut. Les valeurs valides pour l'état de gestion de l'opérateur sont les suivantes :

  • Géré : l'opérateur met à jour ses opérandes au fur et à mesure que les ressources de configuration sont mises à jour
  • Non géré : l'opérateur ignore les changements apportés aux ressources de configuration
  • Retiré : l'opérateur retire ses opérandes et les ressources qu'il a fournies

Profile data

La section profile: dresse la liste des profils TuneD et de leurs noms.

profile:
- name: tuned_profile_1
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD

# ...

- name: tuned_profile_n
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings

Recommended profiles

La logique de sélection de profile: est définie par la section recommend: du CR. La section recommend: est une liste d'éléments permettant de recommander les profils sur la base d'un critère de sélection.

recommend:
<recommend-item-1>
# ...
<recommend-item-n>

Les différents éléments de la liste :

- machineConfigLabels: 1
    <mcLabels> 2
  match: 3
    <match> 4
  priority: <priority> 5
  profile: <tuned_profile_name> 6
  operand: 7
    debug: <bool> 8
    tunedConfig:
      reapply_sysctl: <bool> 9
1
En option.
2
Un dictionnaire d'étiquettes clé/valeur MachineConfig. Les clés doivent être uniques.
3
En cas d'omission, la correspondance des profils est présumée, sauf si un profil ayant une priorité plus élevée correspond en premier ou si machineConfigLabels est défini.
4
Une liste facultative.
5
Ordre de priorité des profils. Les chiffres les plus bas signifient une priorité plus élevée (0 est la priorité la plus élevée).
6
Un profil TuneD à appliquer sur un match. Par exemple tuned_profile_1.
7
Configuration facultative de l'opérande.
8
Active ou désactive le débogage du démon TuneD. Les options sont true pour on ou false pour off. La valeur par défaut est false.
9
Active ou désactive la fonctionnalité reapply_sysctl pour le démon TuneD. Les options sont true pour on et false pour off.

<match> est une liste optionnelle définie récursivement comme suit :

- label: <label_name> 1
  value: <label_value> 2
  type: <label_type> 3
    <match> 4
1
Nom de l'étiquette du nœud ou du pod.
2
Valeur facultative de l'étiquette du nœud ou du pod. Si elle est omise, la présence de <label_name> suffit à établir une correspondance.
3
Type d'objet facultatif (node ou pod). En cas d'omission, node est considéré comme tel.
4
Une liste facultative <match>.

Si <match> n'est pas omis, toutes les sections imbriquées <match> doivent également être évaluées à true. Sinon, false est supposé et le profil avec la section <match> correspondante ne sera pas appliqué ou recommandé. Par conséquent, l'imbrication (sections <match> enfant) fonctionne comme un opérateur logique ET. Inversement, si un élément de la liste <match> correspond, toute la liste <match> est évaluée à true. La liste agit donc comme un opérateur logique OU.

Si machineConfigLabels est défini, la correspondance basée sur le pool de configuration de la machine est activée pour l'élément de liste recommend: donné. <mcLabels> spécifie les étiquettes d'une configuration de la machine. La configuration de la machine est créée automatiquement pour appliquer les paramètres de l'hôte, tels que les paramètres de démarrage du noyau, pour le profil <tuned_profile_name>. Il s'agit de trouver tous les pools de configuration de machine dont le sélecteur de configuration de machine correspond à <mcLabels> et de définir le profil <tuned_profile_name> sur tous les nœuds auxquels sont attribués les pools de configuration de machine trouvés. Pour cibler les nœuds qui ont à la fois un rôle de maître et de travailleur, vous devez utiliser le rôle de maître.

Les éléments de la liste match et machineConfigLabels sont reliés par l'opérateur logique OR. L'élément match est évalué en premier, en court-circuit. Par conséquent, s'il est évalué à true, l'élément machineConfigLabels n'est pas pris en compte.

Important

Lors de l'utilisation de la correspondance basée sur le pool de configuration machine, il est conseillé de regrouper les nœuds ayant la même configuration matérielle dans le même pool de configuration machine. Si cette pratique n'est pas respectée, les opérandes TuneD peuvent calculer des paramètres de noyau contradictoires pour deux nœuds ou plus partageant le même pool de configuration de machine.

Exemple : correspondance basée sur l'étiquette d'un nœud ou d'un pod

- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node

Le CR ci-dessus est traduit pour le démon TuneD conteneurisé dans son fichier recommend.conf en fonction des priorités du profil. Le profil ayant la priorité la plus élevée (10) est openshift-control-plane-es et, par conséquent, il est considéré en premier. Le démon TuneD conteneurisé fonctionnant sur un nœud donné vérifie s'il existe un pod fonctionnant sur le même nœud avec l'étiquette tuned.openshift.io/elasticsearch définie. Si ce n'est pas le cas, toute la section <match> est évaluée comme false. S'il existe un pod avec le label, pour que la section <match> soit évaluée comme true, le label du nœud doit également être node-role.kubernetes.io/master ou node-role.kubernetes.io/infra.

Si les étiquettes du profil ayant la priorité 10 correspondent, le profil openshift-control-plane-es est appliqué et aucun autre profil n'est pris en considération. Si la combinaison d'étiquettes nœud/pod ne correspond pas, le deuxième profil le plus prioritaire (openshift-control-plane) est pris en compte. Ce profil est appliqué si le pod TuneD conteneurisé fonctionne sur un nœud avec les étiquettes node-role.kubernetes.io/master ou node-role.kubernetes.io/infra.

Enfin, le profil openshift-node a la priorité la plus basse de 30. Il ne contient pas la section <match> et, par conséquent, correspondra toujours. Il sert de profil fourre-tout pour définir le profil openshift-node si aucun autre profil ayant une priorité plus élevée ne correspond à un nœud donné.

Decision workflow

Exemple : correspondance basée sur le pool de configuration de la machine

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom

Pour minimiser les redémarrages de nœuds, il faut étiqueter les nœuds cibles avec une étiquette que le sélecteur de nœuds du pool de configuration de la machine fera correspondre, puis créer le Tuned CR ci-dessus et enfin créer le pool de configuration de la machine personnalisé lui-même.

Cloud provider-specific TuneD profiles

Avec cette fonctionnalité, tous les nœuds spécifiques à un fournisseur de Cloud peuvent commodément se voir attribuer un profil TuneD spécifiquement adapté à un fournisseur de Cloud donné sur un cluster OpenShift Container Platform. Cela peut être accompli sans ajouter d'étiquettes de nœuds supplémentaires ou regrouper les nœuds dans des pools de configuration de machines.

Cette fonctionnalité tire parti des valeurs de l'objet de nœud spec.providerID sous la forme de <cloud-provider>://<cloud-provider-specific-id> et écrit le fichier /var/lib/tuned/provider avec la valeur <cloud-provider> dans les conteneurs d'opérandes NTO. Le contenu de ce fichier est ensuite utilisé par TuneD pour charger le profil provider-<cloud-provider> s'il existe.

Le profil openshift dont les profils openshift-control-plane et openshift-node héritent des paramètres est maintenant mis à jour pour utiliser cette fonctionnalité grâce à l'utilisation du chargement conditionnel de profil. Ni NTO ni TuneD ne fournissent actuellement de profils spécifiques aux fournisseurs de Cloud. Cependant, il est possible de créer un profil personnalisé provider-<cloud-provider> qui sera appliqué à tous les nœuds de cluster spécifiques au fournisseur de cloud.

Exemple de profil de fournisseur GCE Cloud

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: provider-gce
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=GCE Cloud provider-specific profile
      # Your tuning for GCE Cloud provider goes here.
    name: provider-gce

Note

En raison de l'héritage des profils, tout paramètre spécifié dans le profil provider-<cloud-provider> sera remplacé par le profil openshift et ses profils enfants.

7.14.3. Profils par défaut définis sur un cluster

Les profils par défaut définis sur un cluster sont les suivants.

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Optimize systems running OpenShift (provider specific parent profile)
      include=-provider-${f:exec:cat:/var/lib/tuned/provider},openshift
    name: openshift
  recommend:
  - profile: openshift-control-plane
    priority: 30
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
  - profile: openshift-node
    priority: 40

Depuis OpenShift Container Platform 4.9, tous les profils OpenShift TuneD sont livrés avec le package TuneD. Vous pouvez utiliser la commande oc exec pour voir le contenu de ces profils :

$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/openshift{,-control-plane,-node} -name tuned.conf -exec grep -H ^ {} \;

7.14.4. Plugins de démon TuneD pris en charge

À l'exception de la section [main], les plugins TuneD suivants sont pris en charge lors de l'utilisation des profils personnalisés définis dans la section profile: du CR Tuned :

  • audio
  • cpu
  • disque
  • eeepc_she
  • modules
  • montures
  • net
  • planificateur
  • scsi_host
  • selinux
  • sysctl
  • sysfs
  • uSB
  • vidéo
  • vm
  • chargeur de démarrage

Certains de ces plugins offrent une fonctionnalité d'accord dynamique qui n'est pas prise en charge. Les plugins TuneD suivants ne sont actuellement pas pris en charge :

  • scénario
  • systemd
Avertissement

Le plugin TuneD bootloader est actuellement pris en charge sur les nœuds de travail Red Hat Enterprise Linux CoreOS (RHCOS) 8.x. Pour les nœuds de travail Red Hat Enterprise Linux (RHEL) 7.x, le plugin de chargeur de démarrage TuneD n'est actuellement pas pris en charge.

Voir Plugins TuneD disponibles et Démarrer avec TuneD pour plus d'informations.

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.