Régler les performances des nœuds

Pour améliorer les performances des applications basées sur des conteneurs, vous pouvez augmenter les ressources du cluster en ajoutant des nœuds ou en ajoutant des ressources, telles que des processeurs ou de la mémoire, à vos nœuds. Toutefois, cette approche peut s'avérer coûteuse. Le réglage des nœuds de votre cluster pour de meilleures 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 Google Distributed Cloud.

Pour tirer le meilleur parti du matériel et des logiciels sous-jacents, différents types d'applications, en particulier les applications hautes performances, ont tout intérêt à régler les 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 de mémoire avec des pages énormes de 1 Gio (gibioctet) ou 2 Mio (mébioctet)
  • Répartition de la charge de travail basée sur l'architecture du système (processeurs multicœurs et NUMA, par exemple)

Avec l'opérateur de réglage des performances, vous configurez les paramètres de performances au niveau du nœud en créant des ressources personnalisées Kubernetes qui appliquent des configurations de performances. Voici les avantages:

  • Interface de configuration unique et unifiée:avec l'opérateur de réglage des performances, vous mettez à jour un ou plusieurs fichiers manifestes PerformanceTuningProfile pouvant être appliqués aux nœuds de calcul à l'aide 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 stratégie. 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é offerte par 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 lors des opérations majeures du cluster, telles que les mises à niveau.

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

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 disponible que pour les nœuds exécutant des versions compatibles de RHEL.

  • Cluster d'utilisateur ou hybride avec nœuds de calcul:l'opérateur de réglage des 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 des profils de réglage. Pour garantir que les profils de réglage ne s'appliquent 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 des performances et d'appliquer des profils de réglage.

  • TuneD 2.22.0:l'opérateur de réglage des performances nécessite que TuneD version 2.22.0 soit préinstallé sur 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 Enterprise. 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 termes 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œud 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) d'un nœud de calcul disponibles pour les pods.

  • Drainage requis:dans le cadre du processus de réglage, l'opérateur de réglage des performances draine d'abord les nœuds, puis applique un profil de réglage. Par conséquent, les nœuds peuvent signaler 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.

  • Redémarrage requis:Pour que les modifications de réglage de nœud soient prises en compte, l'opérateur de réglage des performances redémarre le nœud après avoir appliqué le 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 entre eux 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 Google Distributed Cloud. Vous téléchargez les fichiers manifestes de l'opérateur de réglage des performances à partir de Cloud Storage et utilisez kubectl apply pour créer des ressources de l'opérateur de réglage des performances sur votre cluster.

Pour activer le réglage des performances avec les valeurs par défaut pour votre cluster:

  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 de l'opérateur de réglage des performances à partir du 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 les fichiers manifestes pour le déploiement performance-tuning-operator et le DaemonSet nodeconfig-controller-manager. Les fichiers manifestes pour des fonctions associées, 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 de manière récursive tous les fichiers manifestes de l'opérateur de réglage des performances à 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 ressources suffisantes, ils peuvent être réglés pour fournir une mémoire garantie (standard et hugepages) 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. Pour tirer pleinement parti du réglage des nœuds pour vos charges de travail, celles-ci doivent comporter des paramètres de demandes ou de limites de ressources de processeur ou de mémoire.

Pour se voir attribuer une classe QoS garantie, vos pods 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 demandes 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 demandes de processeur.

L'extrait de spécification de pod suivant montre les paramètres des 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 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 de leur attribuer une classe QoS, consultez la page 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 de conteneur. Ce même ensemble de processeurs réservés exécute également des daemons de système d'exploitation, tels que sshd et udev. Les cœurs de processeur restants sur le sont isolés. Les processeurs isolés sont destinés aux applications liées au processeur, qui nécessitent du temps CPU dédié sans interférence d'autres applications ni interruptions provenant 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).

  • La configuration requise et les limites de processeur doivent être indiquées en nombres entiers. Si vous spécifiez des ressources de processeur partielles dans la spécification du 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 des performances, vous pouvez créer des énormes pages et les associer aux nœuds d'accès à la mémoire non uniforme (NUMA) de la machine. En fonction des paramètres du pod et du nœud, les pods peuvent être programmés avec une affinité de nœud NUMA.

Créer un profil de réglage des performances

Après avoir installé l'opérateur de réglage des performances, vous n'interagissez qu'avec le cluster qui exécute vos charges de travail. Vous créez des ressources personnalisées PerformanceTuningProfile 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 des performances appliquée à un nœud.

Le paramètre 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 l'étiquette de la paire clé-valeur correspondante sur le nœud. Un profil de réglage est appliqué aux nœuds qui comportent 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 sur la ressource PerformanceTuningProfile.

  2. (Facultatif) Pour les nœuds de calcul auxquels vous appliquez un profil, ajoutez des étiquettes 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 non réglé d'origine:

  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 des opérations de maintenance sur votre cluster, vous pouvez suspendre temporairement le réglage 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 du cluster.

Si l'application du profil n'a pas abouti, vous pouvez également 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 répété du nœud. Si vous observez que l'état du nœud passe de l'état prêt à l'état non prêt, suspendez le réglage pour pouvoir récupérer de l'état défectueux.

Pour suspendre le réglage:

  1. Modifiez le fichier manifeste de la 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 du 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 Google Distributed Cloud Controller.

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 dotés de 8 cœurs de processeur spécifie les allocations de ressources suivantes:

  • 4 cœurs de processeur (0-3) sont réservés aux frais généraux du système Kubernetes.

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

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

  • 10 pages de mémoire d'une taille de 1 Gio sont mises de côté pour le nœud 0 NUMA.

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

  • Le gestionnaire de topologie utilise la règle la plus optimale possible 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 l'annotation de fonctionnalité preview 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 de système de système d'exploitation, tels que sshd et udev.

Le champ cpu.reservedCPUs prend une liste de numéros de processeurs ou des plages de numéros de processeur. Assurez-vous que la liste des processeurs ne chevauche pas celle 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 les meilleurs avantages en termes de performances. Ce champ prend une liste de numéros de processeur ou des plages de numéros de processeur. Assurez-vous que la liste des processeurs ne chevauche pas celle 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 sur plusieurs processeurs. Lorsque vous définissez ce champ sur false, vos charges de travail doivent attribuer explicitement chaque thread à un processeur spécifique pour répartir la charge entre les processeurs. Avec l'attribution explicite de processeurs, vous bénéficiez des performances les plus prévisibles pour les charges de travail garanties, mais cela accroît la complexité de vos charges de travail.
cpu.globallyEnableIRQLoadBalancing Obligatoire. Modifiable. Valeur booléenne. Valeur par défaut : true Ce champ indique si vous souhaitez ou non activer l'équilibrage de charge des requêtes d'interruption (IRQ) 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 de la vastpage par défaut dans les paramètres de démarrage du noyau. Les hyperpages 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 devastpages sur 1G, tous les 2 millions de dossiers associés sont supprimés du nœud. Une taille de gigantesque page par défaut de 1 Go vous empêche de configurer 2 millions de pages énormes dans le nœud.
pages Facultatif. Modifiable. Entier. Ce champ indique le nombre de énormespages à créer au démarrage. Ce champ accepte un tableau de pages. Vérifiez la mémoire disponible pour vos nœuds avant d'indiquer la taille de énormespages. Ne demandez pas plus de "largepages" que nécessaire et ne réservez pas non plus toute la mémoire aux énormes pages. 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 de nœud de calcul Kubernetes, node-role.kubernetes.io/worker:"", qui garantit que le réglage des performances n'est effectué que sur ces nœuds. Ce champ accepte une étiquette de nœud facultative en tant que paire clé/valeur. Les étiquettes de paire clé/valeur permettent de sélectionner des nœuds de calcul spécifiques avec des étiquettes correspondantes. Lorsque les libellés nodeSelector correspondent à ceux 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, il est appliqué à tous les nœuds de calcul du cluster.

Par exemple, le nodeSelector suivant indique que le profil de réglage n'est appliqué qu'aux nœuds de calcul avec les étiquettes app: database correspondantes:

...
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 Kubernetes permettant d'allouer des ressources à 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 page Configurer la qualité de service pour les pods.

Opérations de profilage

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 d'application des 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 les 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 ajuste 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). Dernière fois que la condition est passée 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 des détails sur la transition. Ce champ est peut-être vide.
conditions.observedGeneration Facultatif. Entier. S'il est défini, ce champ représente l'metadata.generation sur lequel la condition a été définie. Par exemple, si metadata.generation est défini sur 12, mais que status.condition[x].observedGeneration est défini sur 9, la condition par rapport à l'état actuel de l'instance est obsolète.
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 é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