6.3. À l’aide de l’opérateur de tuning de nœud

Ce processus permet d’accéder à un exemple de spécification de l’opérateur de tuning de nœud.

Le CR par défaut est destiné à fournir un réglage standard au niveau des nœuds pour le service Red Hat OpenShift sur la plate-forme AWS et il ne peut être modifié que pour définir l’état de gestion de l’opérateur. Les autres modifications personnalisées apportées au CR par défaut seront annulées par l’opérateur. Créez vos propres CR Tuned pour un réglage personnalisé. Les CR nouvellement créés seront combinés avec le CR par défaut et le réglage personnalisé appliqué à Red Hat OpenShift Service sur les nœuds AWS basés sur les étiquettes de nœuds ou de pod et les priorités de profil.

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

De multiples spécifications de réglage personnalisées peuvent coexister sous la forme de plusieurs CR 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. 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.

État de gestion

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

Données de profil

Le profil: section répertorie les profils TuneD et 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

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

Les profils recommandés

Le profil : la logique de sélection est définie par la recommandation : section du CR. La section recommandée est une liste d’éléments pour recommander les profils en fonction de critères de sélection.

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

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

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

- machineConfigLabels: 
    <mcLabels> 
  match: 
    <match> 
  priority: <priority> 
  profile: <tuned_profile_name> 
  operand: 
    debug: <bool> 
    tunedConfig:
      reapply_sysctl: <bool> 

- machineConfigLabels: 

    <mcLabels> 

  match: 

    <match> 

  priority: <priority> 

  profile: <tuned_profile_name> 

  operand: 

    debug: <bool> 

    tunedConfig:
      reapply_sysctl: <bool> 

<match> est une liste facultative définie de manière récursive comme suit:

- label: <label_name> 
  value: <label_value> 
  type: <label_type> 
    <match> 

- label: <label_name> 

  value: <label_value> 

  type: <label_type> 

    <match> 

Lorsque <match> n’est pas omis, toutes les sections imbriquées <match> doivent également évaluer à true. Dans le cas contraire, false est supposé et le profil avec la section respective <match> ne sera pas appliqué ou recommandé. Ainsi, la nidification (sections enfant <match>) fonctionne en tant qu’opérateur logique ET. Inversement, si un élément de la liste <match> correspond, l’ensemble de la liste <match> évalue à true. La liste agit donc en tant qu’opérateur logique ou opérateur.

En cas de définition de machineConfigLabels, la correspondance basée sur le pool de configuration de machine est activée pour l’élément de liste recommandé. <mcLabels> spécifie les étiquettes d’une configuration de 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>. Cela implique de trouver tous les pools de configuration de machine avec le sélecteur de configuration de machine correspondant <mcLabels> et de définir le profil <tuned_profile_name> sur tous les nœuds qui sont assignés aux pools de configuration de machine trouvés. Afin de cibler les nœuds qui ont à la fois des rôles de maître et de travailleur, vous devez utiliser le rôle maître.

Les éléments de liste correspondent et machineConfigLabels sont connectés par l’opérateur logique OU. L’élément de match est évalué d’abord en court-circuit. Donc, s’il évalue à true, l’élément machineConfigLabels n’est pas pris en compte.

- 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

- 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 basé sur les priorités du profil. Le profil avec la priorité la plus élevée (10) est l’avion de contrôle ouvert et, par conséquent, il est considéré en premier. Le démon TuneD conteneurisé fonctionnant sur un nœud donné semble voir s’il y a un pod fonctionnant sur le même nœud avec le set d’étiquettes tuned.openshift.io/élastique. Dans le cas contraire, l’ensemble de la section <match> évalue comme faux. En cas d’un tel pod avec l’étiquette, pour que la section <match> évalue à true, l’étiquette du nœud doit également être node-role.kubernetes.io/master ou node-role.kubernetes.io/infra.

Lorsque les étiquettes du profil avec priorité 10 correspondent, le profil openshift-control-plane-es est appliqué et aucun autre profil n’est pris en compte. Dans le cas où la combinaison d’étiquettes node/pod ne correspondait pas, le deuxième profil de priorité (openshift-control-plan) est pris en compte. Ce profil est appliqué si le pod conteneurisé TuneD fonctionne sur un nœud avec les étiquettes node-role.kubernetes.io/master ou node-role.kubernetes.io/infra.

Enfin, le nœud ouvert de profil a la priorité la plus basse de 30. Il manque la section <match> et, par conséquent, correspondra toujours. Il agit comme un profil catch-all pour définir le profil de nœud ouvert, s’il n’y a pas d’autre profil avec une priorité plus élevée sur un nœud donné.

View larger image

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

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

Afin de minimiser le redémarrage des nœuds, étiqueter les nœuds cibles avec une étiquette que le sélecteur de nœud du pool de configuration de la machine correspondra, puis créer le CR Tuned ci-dessus et enfin créer le pool de configuration de la machine personnalisée lui-même.

Les profils TuneD spécifiques aux fournisseurs de cloud

Grâce à cette fonctionnalité, tous les nœuds spécifiques aux fournisseurs de Cloud peuvent facilement se voir attribuer un profil TuneD spécifiquement adapté à un fournisseur de Cloud donné sur un service Red Hat OpenShift sur le cluster AWS. Cela peut être accompli sans ajouter d’étiquettes de nœuds supplémentaires ou regrouper des nœuds dans les pools de configuration de la machine.

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

Le profil openshift que les profils openshift-contrôle-plan et openshift-node héritent des paramètres est maintenant mis à jour pour utiliser cette fonctionnalité grâce à l’utilisation du chargement de profil conditionnel. Actuellement, ni NTO ni TuneD n’incluent des profils spécifiques aux fournisseurs Cloud. Cependant, il est possible de créer un profil personnalisé fournisseur-<cloud-fourr> qui sera appliqué à tous les nœuds de cluster spécifiques au fournisseur 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

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

Ce qui suit sont les profils par défaut définis sur un cluster.

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/ocp-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

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/ocp-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

À partir de Red Hat OpenShift Service sur AWS 4.9, tous les profils OpenShift TuneD sont livrés avec le package TuneD. La commande oc exec permet d’afficher 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 ^ {} \;

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

À l’exclusion de la section [principale], les plugins TuneD suivants sont pris en charge lors de l’utilisation de profils personnalisés définis dans le profil : section du CR Tuned:

Il existe une fonctionnalité de réglage dynamique fournie par certains de ces plugins qui n’est pas pris en charge. Les plugins TuneD suivants ne sont actuellement pas pris en charge: