Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

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

    Exemple de sortie

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

  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'

    Exemple de sortie

    topo-aware-scheduler

  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

    Exemple de sortie

    NAME                    AGE
compute-0.example.com   17h
compute-1.example.com   17h

    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

    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: ""

    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
Copier lien

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

      Exemple de sortie

      NAME                     AGE
numaresourcesscheduler   90m

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

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      Exemple de sortie

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

  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

  3. Créez la ressource Debug logging NUMAResourcesScheduler mise à jour en exécutant la commande suivante : 

    $ oc create -f nro-scheduler-debug.yaml

    Exemple de sortie

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

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

      Exemple de sortie

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

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

      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      Exemple de sortie

      NAME                     AGE
numaresourcesscheduler   3h26m

  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

      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

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

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

      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"

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

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]}"

    Exemple de sortie

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

  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}"

    Exemple de sortie

    {"name":"resource-topology"}

  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

    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

  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

    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

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"

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

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

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

      Exemple de sortie

      machineConfigPoolSelector:
  matchLabels:
    cnf-worker-tuning: enabled

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

      $ oc get mcp worker -o yaml

      Exemple de sortie

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

      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

    Exemple de sortie

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

  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

    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

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

© 2026 Red HatRetour au début