Régler les performances des nœuds

Une façon d'améliorer les performances des applications basées sur des conteneurs consiste à augmenter le nombre de ressources de cluster en ajoutant des nœuds ou des ressources, telles que des processeurs ou de la mémoire, à vos nœuds. Cependant, cette approche peut devenir coûteuse. Le réglage des nœuds de votre cluster pour améliorer les performances vous permet d'optimiser l'utilisation des ressources pour vos charges de travail de manière rentable. Ce document explique comment utiliser l'opérateur de réglage des performances pour régler les nœuds de calcul afin d'optimiser les performances des charges de travail pour GKE sur Bare Metal.

Pour tirer le meilleur parti du matériel et des logiciels sous-jacents, différents types d'applications, en particulier les applications hautes performances, bénéficient du réglage des paramètres des nœuds, comme suit:

  • Processeurs dédiés pour les charges de travail sensibles aux performances
  • Processeurs réservés pour les daemons et services Kubernetes standards
  • Augmentation de la taille des pages en mémoire avec 1 Gio (gibioctet) ou 2 Mio (mébioctet)
  • Répartition de la charge de travail en fonction de l'architecture du système (processeurs multicœurs, processeurs NUMA, etc.)

Avec "Performance Tuning Operator", vous configurez les paramètres de performances au niveau du nœud en créant des ressources Kubernetes personnalisées qui appliquent des configurations de performances. Voici les avantages:

  • Interface de configuration unifiée et unifiée:avec Performance Tuning Operator, vous mettez à jour un ou plusieurs fichiers manifestes PerformanceTuningProfile pouvant être appliqués aux nœuds de calcul dotés de sélecteurs de nœuds. Vous n'avez pas besoin de configurer chaque nœud individuellement avec plusieurs paramètres de configuration et de règles. Cette approche vous permet de gérer les configurations au niveau du nœud et du conteneur de manière unique et unifiée.

  • Persistance et fiabilité:vous bénéficiez également de la fiabilité de Kubernetes grâce à son architecture haute disponibilité. Les ressources personnalisées PerformanceTuningProfile peuvent être mises à jour à tout moment, et leurs paramètres sont conservés pour les opérations de cluster importantes, telles que les mises à niveau.

L'opérateur de réglage des performances fonctionne en orchestrant les fonctionnalités et outils Kubernetes et du système d'exploitation (OS) suivants liés aux performances:

Pour éviter les conflits, lorsque vous utilisez l'opérateur de réglage des performances, nous vous recommandons de ne pas utiliser indépendamment les outils et fonctionnalités Kubernetes et OS mentionnés précédemment.

Prérequis et limitations

Voici les conditions préalables et les limites d'utilisation de l'opérateur de réglage des performances:

  • Red Hat Enterprise Linux (RHEL) uniquement:l'opérateur de réglage des performances n'est compatible qu'avec les nœuds exécutant des versions compatibles de RHEL uniquement.

  • Cluster d'utilisateur ou hybride avec nœuds de calcul:l'opérateur de réglage de performances n'est compatible qu'avec les nœuds de calcul des clusters d'utilisateur ou hybrides. Il n'est pas possible d'utiliser l'opérateur de réglage des performances pour régler les nœuds du plan de contrôle. L'opérateur de réglage des performances utilise un sélecteur de nœuds pour déterminer comment appliquer les profils de réglage. Pour garantir que les profils de réglage ne sont appliqués qu'aux nœuds de calcul, le nodeSelector de chaque ressource personnalisée de profil doit inclure l'étiquette de nœud de calcul standard node-role.kubernetes.io/worker: "". Si le nodeSelector d'un profil de réglage correspond aux étiquettes d'un nœud de plan de contrôle, ce nœud n'est pas réglé et une condition d'erreur est définie. Pour en savoir plus sur les conditions d'erreur, consultez la section Vérifier l'état. Assurez-vous que votre cluster fonctionne correctement avant d'installer l'opérateur de réglage de performances et d'appliquer des profils de réglage.

  • TuneD 2.22.0:l'opérateur de réglage des performances nécessite que la version 2.22.0 de TuneD soit préinstallée dans les nœuds de calcul que vous souhaitez régler. Pour en savoir plus sur TuneD, y compris les instructions d'installation, consultez la page Premiers pas avec TuneD dans la documentation Linux de Red Hat. L'opérateur de réglage des performances utilise TuneD avec le profil cpu-partitioning. Si vous ne disposez pas de ce profil, vous pouvez l'installer à l'aide de la commande suivante:

    dnf install -y tuned-profiles-cpu-partitioning

  • Exigences en matière de ressources de charge de travail:pour tirer le meilleur parti du réglage des performances, vous devez bien comprendre les exigences en termes de mémoire et de processeur (demandes et limites de ressources) pour vos charges de travail.

  • Ressources de nœuds disponibles:recherchez les ressources de processeur et de mémoire pour vos nœuds. Vous pouvez obtenir des informations détaillées sur le processeur et la mémoire de votre nœud dans les fichiers /proc/cpuinfo et /proc/meminfo, respectivement. Vous pouvez également utiliser kubectl get nodes pour récupérer la quantité de ressources de calcul et de mémoire (status.allocatable) disponibles sur un nœud de calcul pour les pods.

  • Drainage requis:lors du processus de réglage, l'opérateur de réglage des performances commence par drainer les nœuds, puis applique un profil de réglage. Par conséquent, les nœuds peuvent indiquer un état NotReady lors du réglage des performances. Nous vous recommandons d'utiliser la stratégie de mise à jour progressive (spec.updateStrategy.type: rolling) plutôt qu'une mise à jour groupée afin de minimiser l'indisponibilité de la charge de travail.

  • Nécessite un redémarrage:pour que les modifications apportées au réglage des nœuds soient prises en compte, l'opérateur de réglage de performances redémarre le nœud après l'application du profil de réglage.

Installer l'opérateur de réglage des performances

L'opérateur de réglage des performances se compose principalement de deux contrôleurs (un déploiement et un DaemonSet) qui interagissent les uns avec les autres pour régler les nœuds en fonction des paramètres de votre profil. Par défaut, l'opérateur de réglage des performances n'est pas installé avec GKE sur une solution Bare Metal. Vous téléchargez les fichiers manifestes de l'opérateur de réglage de performances à partir de Cloud Storage et utilisez kubectl apply pour créer des ressources d'opérateur de réglage de performances sur votre cluster.

Pour activer le réglage des performances avec les valeurs par défaut pour votre cluster, procédez comme suit:

  1. Créez un répertoire performance-tuning sur votre poste de travail administrateur.

  2. Dans le répertoire performance-tuning, téléchargez le dernier package d'opérateur de réglage de performances depuis le bucket de versions Cloud Storage:

    gsutil cp -r gs://anthos-baremetal-release/node-performance-tuning/0.1.0-gke.47 .

    Les fichiers téléchargés incluent des fichiers manifestes pour le déploiement performance-tuning-operator et le DaemonSet nodeconfig-controller-manager. Des fichiers manifestes pour des fonctions connexes, telles que le contrôle des accès basé sur les rôles (RBAC) et le contrôle d'admission dynamique, sont également inclus.

  3. En tant qu'utilisateur racine, appliquez tous les fichiers manifestes de l'opérateur de réglage de performances de manière récursive à votre cluster d'utilisateur (ou hybride) :

    kubectl apply -f performance-tuning --recursive –-kubeconfig USER_KUBECONFIG

    Une fois le déploiement et le DaemonSet créés et en cours d'exécution, votre seule interaction consiste à modifier et appliquer les fichiers manifestes PerformanceTuningProfile.

Examiner les besoins en ressources pour vos charges de travail

Avant de pouvoir régler vos nœuds, vous devez comprendre les besoins en ressources de calcul et de mémoire de vos charges de travail. Si vos nœuds de calcul disposent de suffisamment de ressources, ils peuvent être réglés pour fournir une mémoire garantie (standard et immenses pages) pour vos charges de travail dans la classe de qualité de service (QoS) garantie.

Kubernetes attribue des classes QoS à chacun de vos pods en fonction des contraintes de ressources que vous spécifiez pour les conteneurs associés. Kubernetes utilise ensuite les classes QoS pour déterminer comment planifier vos pods et vos conteneurs, et allouer des ressources à vos charges de travail. Afin de tirer pleinement parti du réglage des nœuds pour vos charges de travail, vos charges de travail doivent comporter des paramètres concernant les demandes ou les limites de ressources mémoire ou de processeur.

Pour qu'une classe QoS de type "Garanti" soit attribuée à vos pods, ceux-ci doivent répondre aux exigences suivantes:

  • Pour chaque conteneur du pod :
    • Spécifiez les valeurs des demandes de ressources de mémoire (spec.containers[].resources.requests.memory) et des limites (spec.containers[].resources.limits.memory).
    • La valeur des limites de mémoire doit être égale à la valeur des requêtes de mémoire.
    • Spécifiez des valeurs pour les demandes de ressources de processeur (spec.containers[].resources.requests.cpu) et les limites (spec.containers[].resources.limits.cpu).
    • La valeur des limites de processeur doit être égale à la valeur des requêtes de ressources de processeur.

L'extrait de spécification de pod suivant montre les paramètres de ressources de processeur qui répondent aux exigences de la classe QoS garantie:

spec:
  containers:
  - name: sample-app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "128Mi"
        cpu: "2"
      limits:
        memory: "128Mi"
        cpu: "2"
  ...

Lorsque vous récupérez les détails du pod avec kubectl get pods, la section status doit inclure la classe QoS attribuée, comme illustré dans l'exemple suivant:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2023-09-22T21:05:23Z"
  generateName: my-deployment-6fdd69987d-
  labels:
    app: metrics
    department: sales
    pod-template-hash: 6fdd69987d
  name: my-deployment-6fdd69987d-7kv42
  namespace: default
  ...
spec:
  containers:
  ...
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2023-09-22T21:05:23Z"
    status: "True"
    type: Initialized
  ...
  qosClass: BestEffort
  startTime: "2023-09-22T21:05:23Z"

Pour en savoir plus sur les classes QoS, consultez la page sur la qualité des classes de service des pods dans la documentation de Kubernetes. Pour obtenir des instructions sur la configuration de vos pods et conteneurs afin qu'une classe QoS leur soit attribuée, consultez la section Configurer la qualité de service pour les pods.

Configuration requise pour le processeur

Lors du réglage d'un nœud, vous pouvez spécifier un ensemble de cœurs de processeur réservés (spec.cpu.reservedCPUs) pour l'exécution des daemons système Kubernetes, tels que le kubelet et l'environnement d'exécution du conteneur. Ce même ensemble de processeurs réservés exécute également les daemons de système d'exploitation, tels que sshd et udev. Les autres cœurs de processeur sur sont alloués de manière isolée. Les processeurs isolés sont destinés aux applications liées au processeur, qui nécessitent du temps CPU dédié sans interférence des autres applications ni interruptions du réseau ou d'autres appareils.

Pour planifier un pod sur les processeurs isolés d'un nœud de calcul, procédez comme suit:

  • Configurez le pod pour garantir une qualité de service (QoS) garantie.

  • Les exigences et les limites du processeur doivent être spécifiées sous forme d'entiers. Si vous spécifiez des ressources de processeur partielles dans la spécification de pod, telles que cpu: 0.5 ou cpu: 250m (250 millicores), la planification ne peut pas être garantie.

Exigences relatives à la mémoire

Lors du réglage d'un nœud avec l'opérateur de réglage de performances, vous pouvez créer des "hugepages" et les associer aux nœuds d'accès non uniforme à la mémoire (NUMA) de la machine. En fonction des paramètres des pods et des nœuds, les pods peuvent être programmés avec une affinité de nœud NUMA.

Créer un profil d'optimisation des performances

Après avoir installé Performance Tuning Operator, vous n'interagissez qu'avec le cluster qui exécute vos charges de travail. Vous créez PerformanceTuningProfile ressources personnalisées directement sur votre cluster d'utilisateur ou votre cluster hybride, et non sur votre cluster d'administrateur. Chaque ressource PerformanceTuningProfile contient un ensemble de paramètres qui spécifie la configuration de performances appliquée à un nœud.

Le nodeSelector de la ressource détermine les nœuds auxquels le profil de réglage est appliqué. Pour appliquer un profil à un nœud, vous devez placer le libellé de paire clé-valeur correspondant sur le nœud. Un profil de réglage est appliqué aux nœuds comportant tous les libellés spécifiés dans le champ nodeSelector.

Vous pouvez créer plusieurs ressources PerformanceTuningProfile dans un cluster. Si plusieurs profils correspondent à un nœud donné, une condition d'erreur est définie dans le status de la ressource personnalisée PerformanceTuningProfile. Pour en savoir plus sur la section status, consultez Vérifier l'état.

Définissez l'espace de noms de votre ressource personnalisée PerformanceTuningProfile sur kube-system.

Pour régler un ou plusieurs nœuds de calcul:

  1. Modifiez le fichier manifeste PerformanceTuningProfile.

    Pour en savoir plus sur chaque champ du fichier manifeste et obtenir un exemple de fichier manifeste, consultez la documentation de référence de la ressource PerformanceTuningProfile.

  2. (Facultatif) Pour les nœuds de calcul auxquels vous appliquez un profil, ajoutez des libellés correspondant à la paire clé-valeur spec.nodeSelector.

    Si aucune paire clé-valeur spec.nodeSelector n'est spécifiée dans la ressource personnalisée PerformanceTuningProfile, le profil est appliqué à tous les nœuds de calcul.

  3. Appliquez le fichier manifeste à votre cluster :

    kubectl apply -f PROFILE_MANIFEST --kubeconfig KUBECONFIG

    Remplacez les éléments suivants :

    • PROFILE_MANIFEST : chemin d'accès au fichier manifeste de la ressource personnalisée PerformanceTuningProfile.
    • KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster.

Supprimer un profil de réglage

Pour réinitialiser un nœud à son état d'origine non réglé:

  1. Supprimez la ressource personnalisée PerformanceTuningProfile du cluster.

  2. Mettez à jour ou supprimez les étiquettes sur le nœud afin qu'il ne soit pas à nouveau sélectionné par le profil de réglage.

Si plusieurs profils de réglage sont associés au nœud, répétez les étapes précédentes si nécessaire.

Suspendre un profil de réglage

Si vous devez effectuer une maintenance sur votre cluster, vous pouvez suspendre temporairement les réglages en modifiant la ressource personnalisée PerformanceTuningProfile. Nous vous recommandons de suspendre le réglage avant d'effectuer des opérations critiques sur le cluster, telles qu'une mise à niveau.

L'échec de l'application du profil est un autre cas où vous pouvez suspendre le réglage. Si le processus de réglage échoue, le contrôleur peut continuer à essayer de régler le nœud, ce qui peut entraîner un redémarrage sans arrêt. Si vous constatez que l'état du nœud passe de l'état "prêt" à l'état "pas prêt", suspendez le réglage pour pouvoir récupérer l'état défectueux.

Pour suspendre le réglage:

  1. Modifiez le fichier manifeste de ressource personnalisée PerformanceTuningProfile pour définir spec.paused sur true.

  2. Utilisez kubectl apply pour mettre à jour la ressource.

Lorsque le réglage des performances est suspendu, le contrôleur de l'opérateur de réglage des performances arrête toutes ses opérations. La mise en pause évite le risque que les opérations du contrôleur de l'opérateur de réglage des performances entrent en conflit avec les opérations du contrôleur GKE sur Bare Metal.

Documentation de référence sur la ressource PerformanceTuningProfile

Cette section décrit chacun des champs de la ressource personnalisée PerformanceTuningProfile. Cette ressource permet de créer un profil de réglage pour un ou plusieurs nœuds de votre cluster. Tous les champs de la ressource sont modifiables après la création du profil. Les profils doivent se trouver dans l'espace de noms kube-system.

L'exemple de fichier manifeste de profil numa suivant pour les nœuds avec 8 cœurs de processeur spécifie les allocations de ressources suivantes:

  • Quatre cœurs de processeur (0-3) sont réservés pour la surcharge du système Kubernetes.

  • 4 cœurs de processeur (4-7) sont réservés pour les charges de travail.

  • La mémoire du nœud est divisée en pages de 2 Mio par défaut au lieu des pages standards de 4 Ki.

  • 10 pages de mémoire de 1 Gio sont réservées au nœud NUMA 0.

  • 5 pages de mémoire de 2 Mio sont réservées au nœud NUMA 1.

  • Le gestionnaire de topologie utilise la règle d'optimisation pour planifier les charges de travail.

apiVersion: anthos.gke.io/v1alpha1
kind: PerformanceTuningProfile
metadata:
  name: numa
  namespace: kube-system
spec:
  cpu:
    isolatedCPUs: 4-7
    reservedCPUs: 0-3
  defaultHugepagesSize: 2M
  nodeSelector:
    app: database
    node-role.kubernetes.io/worker: ""
  pages:
  - count: 10
    numaNode: 0
    size: 1G
  - count: 5
    numaNode: 1
    size: 2M
  topologyManagerPolicy: best-effort

Vous pouvez récupérer la définition de ressource personnalisée PerformanceTuningProfile associée à partir du groupe anthos.gke.io de votre cluster. La définition de ressource personnalisée est installée une fois que l'annotation de fonctionnalité d'aperçu est ajoutée à la ressource de cluster autogéré.

Configuration du processeur

Propriété Description
cpu.reservedCPUs Obligatoire. Modifiable. Chaîne. Ce champ définit un ensemble de cœurs de processeur à réserver aux daemons système Kubernetes, tels que le kubelet, l'environnement d'exécution du conteneur et le détecteur de problèmes de nœuds. Ces cœurs de processeur sont également utilisés pour les daemons système de système d'exploitation, tels que sshd et udev.

Le champ cpu.reservedCPUs accepte une liste de numéros de processeurs ou des plages de numéros de processeurs. Assurez-vous que la liste des processeurs ne chevauche pas la liste spécifiée avec cpu.isolatedCPUs. L'union des processeurs répertoriés dans ces deux champs doit inclure tous les processeurs du nœud.
cpu.isolatedCPUs Facultatif. Modifiable. Chaîne. Le champ cpu.isolatedCPUs définit un ensemble de processeurs utilisés exclusivement pour les applications sensibles aux performances. Le gestionnaire de processeurs ne planifie les conteneurs que sur les processeurs non réservés, conformément aux classes de qualité de service (QoS) de Kubernetes. Pour vous assurer que les charges de travail s'exécutent sur les processeurs isolés, configurez les pods avec la classe QoS garantie et attribuez une ressource de processeur au pod ou au conteneur. Pour la planification garantie des pods, vous devez spécifier des unités de processeur entières, et non des ressources de processeur partielles (cpu: "0.5"). 
apiVersion: v1
kind: Pod
...
spec:
  containers:
  ...
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "1"
  ...

L'optimisation des processeurs isolés pour les charges de travail offre le meilleur avantage en termes de performances. Ce champ prend une liste de numéros de CPU ou de plages de numéros de CPU. Assurez-vous que la liste des processeurs ne chevauche pas la liste spécifiée avec cpu.reservedCPUs et que l'union des listes de ces deux champs inclut tous les processeurs du nœud.
cpu.balanceIsolated Facultatif. Modifiable. Valeur booléenne. Valeur par défaut : true Ce champ indique si l'ensemble de processeurs isolés est éligible à l'équilibrage de charge automatique des charges de travail entre les processeurs. Lorsque vous définissez ce champ sur false, vos charges de travail doivent attribuer explicitement chaque thread à un processeur spécifique afin de répartir la charge entre les processeurs. Avec des attributions explicites de processeurs, vous obtenez les performances les plus prévisibles pour les charges de travail garanties, mais cela augmente la complexité de vos charges de travail.
cpu.globallyEnableIRQLoadBalancing Obligatoire. Modifiable. Valeur booléenne. Valeur par défaut : true Ce champ indique s'il faut activer ou non l'équilibrage de charge de requête d'interruption (IRC) pour l'ensemble de processeurs isolés.

Configuration de la mémoire

Propriété Description
defaultHugePageSize Facultatif. Modifiable. Énumération: 1G ou 2M. Ce champ définit la taille par défaut de la page énorme dans les paramètres de démarrage du noyau. Les URL massives sont allouées au démarrage, avant que la mémoire ne soit fragmentée. Il est important de noter que si vous définissez la taille par défaut d'hugepages sur 1G, les 2 millions de dossiers associés sont supprimés du nœud. Une taille par défaut de 1 Go vous empêche de configurer 2 millions de "hugepages" dans le nœud.
pages Facultatif. Modifiable. Entier. Ce champ indique le nombre de grossespages à créer au démarrage. Ce champ accepte un tableau de pages. Vérifiez la mémoire disponible pour vos nœuds avant de spécifier des pages énormes. Ne demandez pas plus de pages énormes que nécessaire et ne réservez pas non plus toute la mémoire pour les très grandespages. Vos charges de travail nécessitent également une mémoire standard.

Sélection du nœud

Propriété Description
nodeSelector Obligatoire. Modifiable. Ce champ nécessite toujours l'étiquette du nœud de calcul Kubernetes, node-role.kubernetes.io/worker:"", ce qui garantit que le réglage des performances n'est effectué que sur les nœuds de calcul. Ce champ accepte un libellé de nœud facultatif comme paire clé-valeur. Les libellés de paire clé/valeur permettent de sélectionner des nœuds de calcul spécifiques avec des libellés correspondants. Lorsque les libellés nodeSelector correspondent aux libellés d'un nœud de calcul, le profil de performances est appliqué à ce nœud. Si vous ne spécifiez pas de libellé de clé-valeur dans votre profil, celui-ci est appliqué à tous les nœuds de calcul du cluster.

Par exemple, l'élément nodeSelector suivant indique que le profil de réglage n'est appliqué qu'aux nœuds de calcul ayant les libellés app: database correspondants:

...
spec:
  nodeSelector:
    app: database
    node-role.kubernetes.io/worker: ""
  ...

Configuration du kubelet

Propriété Description
topologyManagerPolicy Facultatif. Modifiable. Énumération: none, best-effort, restricted ou single-numa-node. Valeur par défaut : best-effort. Ce champ spécifie la règle du gestionnaire de topologie de Kubernetes permettant d'allouer des ressources pour vos charges de travail en fonction de la classe de qualité de service (QoS) attribuée. Pour en savoir plus sur l'attribution des classes QoS, consultez la section Configurer la qualité de service des pods.

Opérations de profil

Propriété Description
paused Facultatif. Modifiable. Valeur booléenne. Définissez paused sur true pour empêcher temporairement les contrôleurs DaemonSet de régler les nœuds sélectionnés.
updateStrategy Facultatif. Modifiable. Spécifie la stratégie à utiliser pour appliquer les modifications de configuration du réglage aux nœuds sélectionnés.
updateStrategy.rollingUpdateMaxUnavailalble Facultatif. Modifiable. Entier. Valeur par défaut : 1 Spécifie le nombre maximal de nœuds pouvant être réglés en même temps. Ce champ ne s'applique que lorsque type est défini sur rolling.
updateStrategy.type Facultatif. Modifiable. Énumération: batch ou rolling. Valeur par défaut : rolling Spécifie comment appliquer les mises à jour de profil aux nœuds sélectionnés. Si vous souhaitez appliquer la mise à jour à tous les nœuds sélectionnés en même temps, définissez type sur batch. Par défaut, les mises à jour sont déployées de manière séquentielle sur des nœuds individuels, l'une après l'autre.

Vérifier l'état

Une fois la ressource personnalisée PerformanceTuningProfile créée ou mise à jour, un contrôleur règle les nœuds sélectionnés en fonction de la configuration fournie dans la ressource. Pour vérifier l'état de PerformanceTuningProfile, nous affichons le champ suivant dans Status:

Propriété Description
conditions La condition représente les dernières observations disponibles de l'état actuel de la ressource de profil.
conditions.lastTransitionTime Toujours renvoyé. Chaîne (au format date-heure). Heure de la dernière transition de la condition d'un état à un autre. Ce délai indique généralement à quel moment la condition sous-jacente a changé. Si cette heure n'est pas connue, elle indique à quel moment le champ de l'API a été modifié.
conditions.message Facultatif. Chaîne. Message lisible indiquant les détails de la transition. Ce champ peut être vide.
conditions.observedGeneration Facultatif. Entier. S'il est défini, ce champ représente le metadata.generation sur lequel la condition a été définie. Par exemple, si metadata.generation est 12, mais que status.condition[x].observedGeneration est 9, la condition est obsolète par rapport à l'état actuel de l'instance.
conditions.reason Obligatoire. Chaîne. Motif de la dernière transition de condition.
conditions.status Obligatoire. État de la condition: True, False ou Unknown.
conditions.type Obligatoire. "type" correspond au type de condition: Stalled ou Reconciling.
readyNodes Nombre de nœuds auxquels le profil de réglage a bien été appliqué.
reconcilingNodes Nombre de nœuds sélectionnés (ou précédemment sélectionnés) qui sont en cours de rapprochement avec le dernier profil de réglage par le DaemonSet nodeconfig-controller-manager.
selectedNodes Nombre de notes sélectionnées. Autrement dit, le nombre de nœuds correspondant au sélecteur de nœuds pour cette ressource personnalisée PerformanceTuningProfile.

Étapes suivantes