5.6. Résolution des problèmes liés à l'ordonnancement NUMA


Pour résoudre les problèmes courants liés à l'ordonnancement de pods NUMA-aware, procédez comme suit.

Conditions préalables

  • Installez le CLI OpenShift Container Platform (oc).
  • Connectez-vous en tant qu'utilisateur disposant des privilèges d'administrateur de cluster.
  • Installez l'opérateur de ressources NUMA et déployez l'ordonnanceur secondaire compatible NUMA.

Procédure

  1. Vérifiez que le CRD noderesourcetopologies est déployé dans le cluster en exécutant la commande suivante :

    $ oc get crd | grep noderesourcetopologies
    Copy to Clipboard

    Exemple de sortie

    NAME                                                              CREATED AT
    noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z
    Copy to Clipboard

  2. Vérifiez que le nom de l'ordonnanceur NUMA-aware correspond au nom spécifié dans vos charges de travail NUMA-aware en exécutant la commande suivante :

    $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'
    Copy to Clipboard

    Exemple de sortie

    topo-aware-scheduler
    Copy to Clipboard

  3. Vérifiez que les nœuds programmables compatibles NUMA ont reçu l'application noderesourcetopologies CR. Exécutez la commande suivante :

    $ oc get noderesourcetopologies.topology.node.k8s.io
    Copy to Clipboard

    Exemple de sortie

    NAME                    AGE
    compute-0.example.com   17h
    compute-1.example.com   17h
    Copy to Clipboard

    Note

    Le nombre de nœuds doit être égal au nombre de nœuds de travailleur configurés par la définition de travailleur du pool de configuration de la machine (mcp).

  4. Vérifiez la granularité de la zone NUMA pour tous les nœuds programmables en exécutant la commande suivante :

    $ oc get noderesourcetopologies.topology.node.k8s.io -o yaml
    Copy to Clipboard

    Exemple de sortie

    apiVersion: v1
    items:
    - apiVersion: topology.node.k8s.io/v1alpha1
      kind: NodeResourceTopology
      metadata:
        annotations:
          k8stopoawareschedwg/rte-update: periodic
        creationTimestamp: "2022-06-16T08:55:38Z"
        generation: 63760
        name: worker-0
        resourceVersion: "8450223"
        uid: 8b77be46-08c0-4074-927b-d49361471590
      topologyPolicies:
      - SingleNUMANodeContainerLevel
      zones:
      - costs:
        - name: node-0
          value: 10
        - name: node-1
          value: 21
        name: node-0
        resources:
        - allocatable: "38"
          available: "38"
          capacity: "40"
          name: cpu
        - allocatable: "134217728"
          available: "134217728"
          capacity: "134217728"
          name: hugepages-2Mi
        - allocatable: "262352048128"
          available: "262352048128"
          capacity: "270107316224"
          name: memory
        - allocatable: "6442450944"
          available: "6442450944"
          capacity: "6442450944"
          name: hugepages-1Gi
        type: Node
      - costs:
        - name: node-0
          value: 21
        - name: node-1
          value: 10
        name: node-1
        resources:
        - allocatable: "268435456"
          available: "268435456"
          capacity: "268435456"
          name: hugepages-2Mi
        - allocatable: "269231067136"
          available: "269231067136"
          capacity: "270573244416"
          name: memory
        - allocatable: "40"
          available: "40"
          capacity: "40"
          name: cpu
        - allocatable: "1073741824"
          available: "1073741824"
          capacity: "1073741824"
          name: hugepages-1Gi
        type: Node
    - apiVersion: topology.node.k8s.io/v1alpha1
      kind: NodeResourceTopology
      metadata:
        annotations:
          k8stopoawareschedwg/rte-update: periodic
        creationTimestamp: "2022-06-16T08:55:37Z"
        generation: 62061
        name: worker-1
        resourceVersion: "8450129"
        uid: e8659390-6f8d-4e67-9a51-1ea34bba1cc3
      topologyPolicies:
      - SingleNUMANodeContainerLevel
      zones: 
    1
    
      - costs:
        - name: node-0
          value: 10
        - name: node-1
          value: 21
        name: node-0
        resources: 
    2
    
        - allocatable: "38"
          available: "38"
          capacity: "40"
          name: cpu
        - allocatable: "6442450944"
          available: "6442450944"
          capacity: "6442450944"
          name: hugepages-1Gi
        - allocatable: "134217728"
          available: "134217728"
          capacity: "134217728"
          name: hugepages-2Mi
        - allocatable: "262391033856"
          available: "262391033856"
          capacity: "270146301952"
          name: memory
        type: Node
      - costs:
        - name: node-0
          value: 21
        - name: node-1
          value: 10
        name: node-1
        resources:
        - allocatable: "40"
          available: "40"
          capacity: "40"
          name: cpu
        - allocatable: "1073741824"
          available: "1073741824"
          capacity: "1073741824"
          name: hugepages-1Gi
        - allocatable: "268435456"
          available: "268435456"
          capacity: "268435456"
          name: hugepages-2Mi
        - allocatable: "269192085504"
          available: "269192085504"
          capacity: "270534262784"
          name: memory
        type: Node
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
    Copy to Clipboard

    1
    Chaque strophe sous zones décrit les ressources d'une seule zone NUMA.
    2
    resources décrit l'état actuel des ressources de la zone NUMA. Vérifiez que les ressources répertoriées sous items.zones.resources.available correspondent aux ressources exclusives de la zone NUMA allouées à chaque pod garanti.

5.6.1. Vérification des journaux de l'ordonnanceur NUMA-aware

Dépannez les problèmes liés à l'ordonnanceur NUMA-aware en examinant les journaux. Si nécessaire, vous pouvez augmenter le niveau de journalisation de l'ordonnanceur en modifiant le champ spec.logLevel de la ressource NUMAResourcesScheduler. Les valeurs acceptables sont Normal, Debug, et Trace, Trace étant l'option la plus verbeuse.

Note

Pour modifier le niveau de journalisation de l'ordonnanceur secondaire, supprimez la ressource de l'ordonnanceur en cours d'exécution et redéployez-la avec le niveau de journalisation modifié. L'ordonnanceur n'est pas disponible pour l'ordonnancement de nouvelles charges de travail pendant ce temps d'arrêt.

Conditions préalables

  • Installez le CLI OpenShift (oc).
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

  1. Supprimer la ressource NUMAResourcesScheduler en cours d'exécution :

    1. Obtenez le site actif NUMAResourcesScheduler en exécutant la commande suivante :

      $ oc get NUMAResourcesScheduler
      Copy to Clipboard

      Exemple de sortie

      NAME                     AGE
      numaresourcesscheduler   90m
      Copy to Clipboard

    2. Supprimez la ressource du planificateur secondaire en exécutant la commande suivante :

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler
      Copy to Clipboard

      Exemple de sortie

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
      Copy to Clipboard

  2. Enregistrez le YAML suivant dans le fichier nro-scheduler-debug.yaml. Cet exemple modifie le niveau de journalisation à Debug:

    apiVersion: nodetopology.openshift.io/v1alpha1
    kind: NUMAResourcesScheduler
    metadata:
      name: numaresourcesscheduler
    spec:
      imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.12"
      logLevel: Debug
    Copy to Clipboard
  3. Créez la ressource Debug logging NUMAResourcesScheduler mise à jour en exécutant la commande suivante :

    $ oc create -f nro-scheduler-debug.yaml
    Copy to Clipboard

    Exemple de sortie

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
    Copy to Clipboard

Verification steps

  1. Vérifiez que l'ordonnanceur NUMA-aware a été déployé avec succès :

    1. Exécutez la commande suivante pour vérifier que le CRD a été créé avec succès :

      $ oc get crd | grep numaresourcesschedulers
      Copy to Clipboard

      Exemple de sortie

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z
      Copy to Clipboard

    2. Vérifiez que le nouvel ordonnanceur personnalisé est disponible en exécutant la commande suivante :

      $ oc get numaresourcesschedulers.nodetopology.openshift.io
      Copy to Clipboard

      Exemple de sortie

      NAME                     AGE
      numaresourcesscheduler   3h26m
      Copy to Clipboard

  2. Vérifiez que les journaux de l'ordonnanceur affichent le niveau de journal augmenté :

    1. Obtenez la liste des pods fonctionnant dans l'espace de noms openshift-numaresources en exécutant la commande suivante :

      $ oc get pods -n openshift-numaresources
      Copy to Clipboard

      Exemple de sortie

      NAME                                               READY   STATUS    RESTARTS   AGE
      numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
      numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
      numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
      secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m
      Copy to Clipboard

    2. Obtenez les journaux du module de planification secondaire en exécutant la commande suivante :

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources
      Copy to Clipboard

      Exemple de sortie

      ...
      I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
      I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
      I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
      I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
      I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      Copy to Clipboard

5.6.2. Dépannage de l'exportateur de topologie de ressources

Dépanner les objets noderesourcetopologies pour lesquels des résultats inattendus se produisent en inspectant les journaux resource-topology-exporter correspondants.

Note

Il est recommandé de nommer les instances de l'exportateur de topologie de ressources NUMA dans le cluster en fonction des nœuds auxquels elles se réfèrent. Par exemple, un nœud de travail portant le nom worker doit avoir un objet noderesourcetopologies correspondant appelé worker.

Conditions préalables

  • Installez le CLI OpenShift (oc).
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.

Procédure

  1. Obtenir les daemonsets gérés par l'opérateur de ressources NUMA. Chaque daemonset a un nodeGroup correspondant dans le CR NUMAResourcesOperator. Exécutez la commande suivante :

    $ oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"
    Copy to Clipboard

    Exemple de sortie

    {"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}
    Copy to Clipboard

  2. Obtenir l'étiquette du daemonset concerné en utilisant la valeur de name obtenue à l'étape précédente :

    $ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"
    Copy to Clipboard

    Exemple de sortie

    {"name":"resource-topology"}
    Copy to Clipboard

  3. Obtenez les pods en utilisant l'étiquette resource-topology en exécutant la commande suivante :

    $ oc get pods -n openshift-numaresources -l name=resource-topology -o wide
    Copy to Clipboard

    Exemple de sortie

    NAME                                 READY   STATUS    RESTARTS   AGE    IP            NODE
    numaresourcesoperator-worker-5wm2k   2/2     Running   0          2d1h   10.135.0.64   compute-0.example.com
    numaresourcesoperator-worker-pb75c   2/2     Running   0          2d1h   10.132.2.33   compute-1.example.com
    Copy to Clipboard

  4. Examinez les journaux du conteneur resource-topology-exporter s'exécutant sur le module de travail correspondant au nœud que vous dépannez. Exécutez la commande suivante :

    $ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c
    Copy to Clipboard

    Exemple de sortie

    I0221 13:38:18.334140       1 main.go:206] using sysinfo:
    reservedCpus: 0,1
    reservedMemory:
      "0": 1178599424
    I0221 13:38:18.334370       1 main.go:67] === System information ===
    I0221 13:38:18.334381       1 sysinfo.go:231] cpus: reserved "0-1"
    I0221 13:38:18.334493       1 sysinfo.go:237] cpus: online "0-103"
    I0221 13:38:18.546750       1 main.go:72]
    cpus: allocatable "2-103"
    hugepages-1Gi:
      numa cell 0 -> 6
      numa cell 1 -> 1
    hugepages-2Mi:
      numa cell 0 -> 64
      numa cell 1 -> 128
    memory:
      numa cell 0 -> 45758Mi
      numa cell 1 -> 48372Mi
    Copy to Clipboard

5.6.3. Correction d'une carte de configuration de l'exportateur de topologie de ressources manquante

Si vous installez l'opérateur de ressources NUMA dans un cluster dont les paramètres sont mal configurés, dans certaines circonstances, l'opérateur est indiqué comme étant actif, mais les journaux des pods du démon RTE (resource topology exporter) montrent que la configuration du RTE est manquante, par exemple :

Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"
Copy to Clipboard

Ce message indique que la configuration requise de kubeletconfig n'a pas été correctement appliquée dans le cluster, ce qui entraîne l'absence d'une RTE configmap. Par exemple, il manque une ressource personnalisée (CR) numaresourcesoperator-worker configmap dans le cluster suivant :

$ oc get configmap
Copy to Clipboard

Exemple de sortie

NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h
Copy to Clipboard

Dans un groupe correctement configuré, oc get configmap renvoie également un CR numaresourcesoperator-worker configmap .

Conditions préalables

  • Installez le CLI OpenShift Container Platform (oc).
  • Connectez-vous en tant qu'utilisateur disposant des privilèges d'administrateur de cluster.
  • Installez l'opérateur de ressources NUMA et déployez l'ordonnanceur secondaire compatible NUMA.

Procédure

  1. Comparez les valeurs de spec.machineConfigPoolSelector.matchLabels dans kubeletconfig et de metadata.labels dans MachineConfigPool (mcp) worker CR à l'aide des commandes suivantes :

    1. Vérifiez les étiquettes kubeletconfig en exécutant la commande suivante :

      $ oc get kubeletconfig -o yaml
      Copy to Clipboard

      Exemple de sortie

      machineConfigPoolSelector:
        matchLabels:
          cnf-worker-tuning: enabled
      Copy to Clipboard

    2. Vérifiez les étiquettes mcp en exécutant la commande suivante :

      $ oc get mcp worker -o yaml
      Copy to Clipboard

      Exemple de sortie

      labels:
        machineconfiguration.openshift.io/mco-built-in: ""
        pools.operator.machineconfiguration.openshift.io/worker: ""
      Copy to Clipboard

      L'étiquette cnf-worker-tuning: enabled n'est pas présente dans l'objet MachineConfigPool.

  2. Modifiez le CR MachineConfigPool pour inclure l'étiquette manquante, par exemple :

    $ oc edit mcp worker -o yaml
    Copy to Clipboard

    Exemple de sortie

    labels:
      machineconfiguration.openshift.io/mco-built-in: ""
      pools.operator.machineconfiguration.openshift.io/worker: ""
      cnf-worker-tuning: enabled
    Copy to Clipboard

  3. Appliquez les changements d'étiquettes et attendez que le cluster applique la configuration mise à jour. Exécutez la commande suivante :

Vérification

  • Vérifier que le numaresourcesoperator-worker configmap CR manquant est appliqué :

    $ oc get configmap
    Copy to Clipboard

    Exemple de sortie

    NAME                           DATA   AGE
    0e2a6bd3.openshift-kni.io      0      6d21h
    kube-root-ca.crt               1      6d21h
    numaresourcesoperator-worker   1      5m
    openshift-service-ca.crt       1      6d21h
    topo-aware-scheduler-config    1      6d18h
    Copy to Clipboard

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat