Ajuster 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 des ressources (des processeurs ou de la mémoire, par exemple) à vos nœuds. Toutefois, cette approche peut devenir coûteuse. Ajuster les 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 Performance Tuning Operator pour ajuster 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 peuvent bénéficier de paramètres de nœud de réglage tels que les suivants (en particulier les applications hautes performances) :

  • 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 "hugepages" énormes de 1 Gio (gigaoctet) ou 2 Mio (mébioctets)
  • Répartition de la charge de travail en fonction de l'architecture du système, comme les processeurs multicœurs et NUMA

Avec Performance Tuning Operator, vous configurez les paramètres de performances au niveau des nœuds 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 Performance Tuning Operator, vous mettez à jour un ou plusieurs fichiers manifestes PerformanceTuningProfile pouvant être appliqués aux nœuds de calcul avec des sélecteurs de nœuds. Vous n'avez pas besoin de configurer chaque nœud individuellement avec de multiples paramètres de configuration et de règles. Cette approche vous permet de gérer les configurations au niveau des nœuds et des conteneurs de manière centralisée et unifiée.

  • Persistance et fiabilité : vous bénéficiez également de la fiabilité que Kubernetes offre avec 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 de cluster majeures, telles que les mises à niveau.

Performance Tuning Operator fonctionne en orchestrant les fonctionnalités et les outils liés aux performances suivants de Kubernetes et du système d'exploitation (OS) :

Pour éviter les conflits, lorsque vous utilisez Performance Tuning Operator, nous vous recommandons de ne pas utiliser les outils et fonctionnalités Kubernetes et OS mentionnés précédemment de manière indépendante.

Prérequis et limitations

Voici les conditions préalables et les limitations relatives à l'utilisation de Performance Tuning Operator :

  • Red Hat Enterprise Linux (RHEL) uniquement : Performance Tuning Operator est compatible avec les nœuds exécutant des versions compatibles de RHEL uniquement.

  • Cluster d'utilisateur ou cluster hybride avec des nœuds de calcul : Performance Tuning Operator est compatible avec des nœuds de calcul dans des clusters d'utilisateur ou dans des clusters hybrides uniquement. L'utilisation de Performance Tuning Operator pour ajuster les nœuds de plan de contrôle n'est pas possible. Performance Tuning Operator utilise un sélecteur de nœuds pour déterminer comment appliquer les profils de réglage. Pour vous assurer 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 le libellé de nœud de calcul standard node-role.kubernetes.io/worker: "". Si le nodeSelector d'un profil de réglage correspond aux libellés d'un nœud du 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 Vérifier l'état. Assurez-vous que votre cluster fonctionne correctement avant d'installer Performance Tuning Operator et d'appliquer des profils de réglage.

  • TuneD 2.22.0 : Performance Tuning Operator nécessite que TuneD 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 section Premiers pas avec TuneD dans la documentation Red Hat Enterprise Linux. Performance Tuning Operator 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 pour la charge de travail : pour tirer le meilleur parti de l'optimisation 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) dont dispose un nœud de calcul pour les pods.

  • Nécessite un drainage : 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 de l'optimisation 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 pour minimiser la non-disponibilité de la charge de travail.

  • Redémarrage requis : pour que les modifications de réglage du nœud prennent effet, Performance Tuning Operator redémarre le nœud après avoir appliqué le profil de réglage.

Installer Performance Tuning Operator

Performance Tuning Operator 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. Performance Tuning Operator n'est pas installé par défaut avec Google Distributed Cloud. Vous téléchargez les fichiers manifestes de Performance Tuning Operator à partir de Cloud Storage et vous utilisez kubectl apply pour créer des ressources Performance Tuning Operator sur votre cluster.

Pour activer l'optimisation 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 Performance Tuning Operator à partir du bucket de version Cloud Storage :

    gcloud storage cp gs://anthos-baremetal-release/node-performance-tuning/0.1.0-gke.47 . --recursive

    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 les fonctions associées, tels que le contrôle des accès basé sur les rôles (RBAC) et le contrôle dynamique des accès, sont également inclus.

  3. En tant qu'utilisateur racine, appliquez récursivement tous les fichiers manifestes Performance Tuning Operator à votre cluster 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.

Vérifier les ressources requises pour vos charges de travail

Avant de pouvoir ajuster vos nœuds, vous devez comprendre les exigences en termes de ressources de calcul et de mémoire de vos charges de travail. Si vos nœuds de calcul disposent de ressources suffisantes, vous pouvez les ajuster pour qu'ils fournissent une mémoire garantie (pages standard et pages "hugepages") pour vos charges de travail dans la classe de qualité de service (QoS) garantie.

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

Pour qu'une classe de qualité de service garantie vous soit attribuée, vos pods doivent répondre aux exigences suivantes :

  • Pour chaque conteneur du pod :
    • Spécifiez des valeurs pour les demandes de ressources (spec.containers[].resources.requests.memory) et les limites (spec.containers[].resources.limits.memory) de mémoire.
    • 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 (spec.containers[].resources.requests.cpu) et les limites (spec.containers[].resources.limits.cpu) de processeur.
    • La valeur des limites de processeur doit être égale à la valeur des requêtes 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 de qualité de service (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 section Classes de qualité de service (QoS) des pods dans la documentation Kubernetes. Pour savoir comment configurer vos pods et conteneurs afin qu'une classe QoS leur soit attribuée, consultez Configurer la qualité de service (QoS) pour les pods.

Exigences en matière de processeur

Lorsque vous ajustez un nœud, vous pouvez spécifier un ensemble de cœurs de processeur réservés (spec.cpu.reservedCPUs) pour exécuter 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 du système d'exploitation, tels que sshd et udev. Le reste des cœurs de processeur est isolé. Les processeurs isolés sont destinés aux applications liées au processeur, qui nécessitent un temps CPU dédié sans interférence d'autres applications ni interruption par le réseau ou d'autres appareils.

Pour planifier un pod sur les processeurs isolés d'un nœud de calcul :

  • Configurez le pod pour une QoS garantie.

  • Les exigences et les limites de processeur doivent être spécifiées en entiers. Si vous spécifiez des ressources de processeur partielles dans la spécification de votre pod (cpu: 0.5 ou cpu: 250m soit 250 millicores, par exemple), la planification ne peut pas être garantie.

Exigences relatives à la mémoire

Lorsque vous ajustez un nœud avec Performance Tuning Operator, vous pouvez créer des pages "hugepages" et les associer aux nœuds NUMA (accès à la mémoire non uniforme) de la machine. En fonction des paramètres des pods et des nœuds, les pods peuvent être planifiés avec une affinité de nœud NUMA.

Créer un profil d'optimisation des performances

Une fois Performance Tuning Operator installé, 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'utilisateurs ou 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 portant 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 ajuster 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 les ressources 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établir l'état d'origine d'un nœud, c'est-à-dire un état non configuré :

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

  2. Modifiez ou supprimez les libellés du nœud pour qu'il ne soit plus 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, le cas échéant.

Suspendre un profil de réglage

Si vous devez effectuer la maintenance de 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 de cluster critiques, telles qu'une mise à niveau de cluster.

Vous pouvez également suspendre le réglage si l'application du profil échoue. Si le processus de réglage échoue, le contrôleur peut continuer à essayer de régler le nœud, ce qui peut entraîner le redémarrage répété du nœud. Si vous constatez que l'état du nœud passe de "prêt" à "non prêt", suspendez le réglage afin de pouvoir récupérer l'état défectueux.

Pour mettre en pause le réglage :

  1. Modifiez le fichier manifeste des ressources personnalisées 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 Performance Tuning Operator arrête toutes ses opérations. La suspension permet d'éviter que les opérations du contrôleur Performance Tuning Operator n'entrent en conflit avec les opérations du contrôleur Google Distributed Cloud.

Référence de 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 :

  • 4 cœurs de processeur (0-3) sont réservés au fonctionnement du système Kubernetes.

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

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

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

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

  • Topology Manager utilise la règle de type "best-effort" 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é en preview a été ajoutée à la ressource de cluster autogéré.

Configuration du processeur

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

Le champ cpu.reservedCPUs accepte une liste de numéros de processeur ou des plages de numéros de processeur. Assurez-vous que la liste des processeurs n'est pas en chevauchement avec la liste spécifiée par cpu.isolatedCPUs. L'ensemble des processeurs listés dans ces deux champs doit inclure tous les processeurs du nœud.
cpu.isolatedCPUs Facultatif. Non immuable. 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 planifie les conteneurs uniquement sur les processeurs non réservés, en fonction des classes de qualité de service (QoS) de Kubernetes. Pour vous assurer que les charges de travail s'exécutent sur des processeurs isolés, configurez des pods avec la classe QoS garantie et attribuez une ressource de processeur au pod ou au conteneur. Pour une planification de pods garantie, 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"
  ...

Maximiser les processeurs isolés pour les charges de travail permet d'obtenir les meilleures performances. Ce champ accepte une liste de numéros de processeur ou des plages de numéros de processeur. Assurez-vous que la liste des processeurs n'est pas en chevauchement avec la liste spécifiée par cpu.reservedCPUs et que l'union des listes dans ces deux champs inclut tous les processeurs du nœud.
cpu.balanceIsolated Facultatif. Non immuable. Valeur booléenne. Valeur par défaut : true Ce champ indique si l'ensemble de processeurs isolés est éligible à l'équilibrage automatique de la charge de travail sur les 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 sur les processeurs. Avec les attributions de processeur explicites, vous obtenez les performances les plus prévisibles pour les charges de travail garanties, mais cela ajoute de la complexité à vos charges de travail.
cpu.globallyEnableIRQLoadBalancing Obligatoire. Non immuable. Valeur booléenne. Valeur par défaut : true Ce champ indique si l'équilibrage de charge des requêtes d'interruption (IRQ) doit être activé ou non pour l'ensemble de processeurs isolé.

Configuration de la mémoire

Propriété Description
defaultHugePageSize Facultatif. Non immuable. Énumération : 1G ou 2M. Ce champ définit la taille par défaut des pages "hugepages" dans les paramètres de démarrage du noyau. Les pages "hugepages" sont allouées au démarrage, avant que la mémoire ne soit fragmentée. Notez que si vous définissez la taille par défaut des pages "hugepages" sur 1 Gio, tous les dossiers associés à 2 Mio sont supprimés du nœud. Une taille de page "hugepages" énorme par défaut de 1 Gio vous empêche de configurer des pages "hugepages" de 2 Mio dans le nœud.
pages Facultatif. Non immuable. Entier. Ce champ spécifie le nombre de pages "hugepages" à 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 "hugepages". Ne demandez pas plus de pages "hugepages" que nécessaire et ne réservez pas toute la mémoire pour les pages "hugepages". Vos charges de travail ont également besoin de mémoire standard.

Sélection de nœud

Propriété Description
nodeSelector Obligatoire. Non immuable. Ce champ nécessite toujours le libellé de nœud de calcul Kubernetes, node-role.kubernetes.io/worker:"", qui garantit que l'optimisation des performances est effectuée uniquement sur les nœuds de calcul. Ce champ accepte un libellé de nœud facultatif sous la forme d'une paire clé-valeur. Les libellés de paires clé-valeur permettent de sélectionner des nœuds de calcul spécifiques porteurs des libellés correspondants. 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é clé-valeur dans votre profil, il est appliqué à tous les nœuds de calcul du cluster.

Par exemple, le nodeSelector suivant spécifie que le profil de réglage n'est appliqué qu'aux nœuds de calcul porteurs de libellés app: database correspondants :

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

Configuration de Kubelet

Propriété Description
topologyManagerPolicy Facultatif. Non immuable. Énumération : none, best-effort, restricted ou single-numa-node. Valeur par défaut : best-effort. Ce champ spécifie la règle Topology Manager Kubernetes utilisée pour 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 Configurer la qualité de service pour les pods.

Opérations de profil

Propriété Description
paused Facultatif. Non immuable. Valeur booléenne. Définissez paused sur true pour empêcher temporairement les contrôleurs DaemonSet d'ajuster les nœuds sélectionnés.
updateStrategy Facultatif. Non immuable. Spécifie la stratégie d'application des modifications de configuration d'optimisation aux nœuds sélectionnés.
updateStrategy.rollingUpdateMaxUnavailalble Facultatif. Non immuable. Entier. Valeur par défaut : 1 Spécifie le nombre maximal de nœuds pouvant être configurés simultanément. Ce champ ne s'applique que lorsque type est défini sur rolling.
updateStrategy.type Facultatif. Non immuable. É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'un 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 exposons 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 transition de la condition d'un état à un autre. Cette heure indique généralement le moment où la condition sous-jacente a changé. Si cette heure n'est pas connue, elle indique le moment où le champ d'API a changé.
conditions.message Facultatif. Chaîne. Message lisible indiquant des détails sur la transition. Ce champ peut être vide.
conditions.observedGeneration Facultatif. Entier. Si ce champ est défini, il 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. Raison de la dernière transition de condition.
conditions.status Obligatoire. État de la condition : True, False ou Unknown.
conditions.type Obligatoire. Type est le 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) 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.

Étape suivante