7.14. Utilisation de l'opérateur Node Tuning
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.
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.
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.
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 oufalse
pour off. La valeur par défaut estfalse
. - 9
- Active ou désactive la fonctionnalité
reapply_sysctl
pour le démon TuneD. Les options sonttrue
pour on etfalse
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
oupod
). 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.
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é.
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
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
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.