Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 13. Calendrier des ressources

Le sélecteur de nœuds spécifie une carte des paires de clés/valeurs qui sont définies à l’aide d’étiquettes personnalisées sur les nœuds et les sélecteurs spécifiés dans les pods.

Afin que la gousse puisse fonctionner sur un nœud, la gousse doit avoir le même sélecteur de nœud clé/valeur que l’étiquette sur le nœud.

13.1.1. À propos des sélecteurs de nœuds
Copier lien

Il est possible d’utiliser des sélecteurs de nœuds sur les gousses et les étiquettes sur les nœuds pour contrôler l’endroit où la gousse est programmée. Avec les sélecteurs de nœuds, Red Hat OpenShift Service sur AWS programme les pods sur les nœuds qui contiennent des étiquettes correspondantes.

Il est possible d’utiliser un sélecteur de nœuds pour placer des pods spécifiques sur des nœuds spécifiques, des sélecteurs de nœuds à l’échelle du cluster pour placer de nouveaux pods sur des nœuds spécifiques n’importe où dans le cluster, et des sélecteurs de nœuds de projet pour placer de nouveaux pods dans un projet sur des nœuds spécifiques.

En tant qu’administrateur de cluster, par exemple, vous pouvez créer une infrastructure où les développeurs d’applications peuvent déployer des pods uniquement sur les nœuds les plus proches de leur emplacement géographique en incluant un sélecteur de nœuds dans chaque pod qu’ils créent. Dans cet exemple, le cluster se compose de cinq centres de données répartis dans deux régions. Aux États-Unis, étiquetez les nœuds comme nous-est, nous-central, ou nous-ouest. Dans la région Asie-Pacifique (APAC), étiqueter les nœuds comme apac-est ou apac-west. Les développeurs peuvent ajouter un sélecteur de nœuds aux gousses qu’ils créent pour s’assurer que les gousses sont programmées sur ces nœuds.

La pod n’est pas programmée si l’objet Pod contient un sélecteur de nœuds, mais le nœud a une étiquette correspondante.

Important

Lorsque vous utilisez les sélecteurs de nœuds et l’affinité des nœuds dans la même configuration, les règles suivantes contrôlent le placement des pod sur les nœuds:

  • Lorsque vous configurez à la fois nodeSelector et nodeAffinity, les deux conditions doivent être remplies pour que la gousse soit programmée sur un nœud candidat.
  • Lorsque vous spécifiez plusieurs nodeSelectorTerms associés aux types nodeAffinity, le pod peut être programmé sur un nœud si l’un des nodeSelectorTerms est satisfait.
  • Lorsque vous spécifiez plusieurs correspondancesExpressions associées à nodeSelectorTerms, le pod ne peut être programmé sur un nœud que si toutes les correspondancesExpressions sont satisfaites.
Les sélecteurs de nœuds sur des gousses et nœuds spécifiques

Il est possible de contrôler quel nœud est programmé en utilisant des sélecteurs de nœuds et des étiquettes.

Afin d’utiliser des sélecteurs de nœuds et des étiquettes, d’abord étiqueter le nœud pour éviter que les gousses ne soient décalées, puis ajouter le sélecteur de nœud à la gousse.

Note

Il n’est pas possible d’ajouter un sélecteur de nœuds directement à un pod existant. Il faut étiqueter l’objet qui contrôle la pod, comme la configuration de déploiement.

À titre d’exemple, l’objet Node suivant a la région:

Échantillon d’objet Node avec une étiquette

kind: Node
apiVersion: v1
metadata:
  name: ip-10-0-131-14.ec2.internal
  selfLink: /api/v1/nodes/ip-10-0-131-14.ec2.internal
  uid: 7bc2580a-8b8e-11e9-8e01-021ab4174c74
  resourceVersion: '478704'
  creationTimestamp: '2019-06-10T14:46:08Z'
  labels:
    kubernetes.io/os: linux
    topology.kubernetes.io/zone: us-east-1a
    node.openshift.io/os_version: '4.5'
    node-role.kubernetes.io/worker: ''
    topology.kubernetes.io/region: us-east-1
    node.openshift.io/os_id: rhcos
    node.kubernetes.io/instance-type: m4.large
    kubernetes.io/hostname: ip-10-0-131-14
    kubernetes.io/arch: amd64
    region: east
1 

    type: user-node
#...
Copy to Clipboard Toggle word wrap

1
Étiquettes pour correspondre au sélecteur de nœud de pod.

A pod a le type: user-node,région: sélecteur de nœud est:

Échantillon d’objet Pod avec sélecteurs de nœuds

apiVersion: v1
kind: Pod
metadata:
  name: s1
#...
spec:
  nodeSelector:
1 

    region: east
    type: user-node
#...
Copy to Clipboard Toggle word wrap

1
Les sélecteurs de nœuds correspondent à l’étiquette du nœud. Le nœud doit avoir une étiquette pour chaque sélecteur de nœud.

Lorsque vous créez le pod à l’aide de l’exemple pod spec, il peut être programmé sur le nœud d’exemple.

Les sélecteurs par défaut de nœuds à l’échelle du cluster

Avec les sélecteurs de nœuds larges par défaut, lorsque vous créez un pod dans ce cluster, Red Hat OpenShift Service sur AWS ajoute les sélecteurs de nœuds par défaut au pod et programme le pod sur les nœuds avec des étiquettes correspondantes.

À titre d’exemple, l’objet Scheduler suivant a la région par défaut de cluster=Est et type=node-utilisateur sélecteur:

Exemple d’opérateur de programmeur de ressources personnalisées

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
#...
spec:
  defaultNodeSelector: type=user-node,region=east
#...
Copy to Clipboard Toggle word wrap

Dans ce cluster, un nœud a le type= user-node,region=East Labels:

Exemple d’objet Node

apiVersion: v1
kind: Node
metadata:
  name: ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4
#...
  labels:
    region: east
    type: user-node
#...
Copy to Clipboard Toggle word wrap

Exemple Pod objet avec un sélecteur de nœud

apiVersion: v1
kind: Pod
metadata:
  name: s1
#...
spec:
  nodeSelector:
    region: east
#...
Copy to Clipboard Toggle word wrap

Lorsque vous créez le pod à l’aide de l’exemple pod spec dans le cluster d’exemples, le pod est créé avec le sélecteur de nœud de cluster-large et est programmé sur le nœud étiqueté:

Exemple de pod list avec la gousse sur le nœud étiqueté

NAME     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
pod-s1   1/1     Running   0          20s   10.131.2.6   ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4   <none>           <none>
Copy to Clipboard Toggle word wrap

Note

Lorsque le projet où vous créez le pod a un sélecteur de nœud de projet, ce sélecteur prend la préférence sur un sélecteur de nœuds à l’échelle du cluster. Le pod n’est pas créé ou programmé si le pod n’a pas le sélecteur de nœud de projet.

Les sélecteurs de nœuds de projet

Avec les sélecteurs de nœuds de projet, lorsque vous créez un pod dans ce projet, Red Hat OpenShift Service sur AWS ajoute les sélecteurs de nœuds au pod et programme les pods sur un nœud avec des étiquettes correspondantes. Lorsqu’il existe un sélecteur de nœuds par défaut à l’échelle du cluster, un sélecteur de nœud de projet prend la préférence.

À titre d’exemple, le projet suivant a le sélecteur de nœud région=Est:

Exemple d’objet Namespace

apiVersion: v1
kind: Namespace
metadata:
  name: east-region
  annotations:
    openshift.io/node-selector: "region=east"
#...
Copy to Clipboard Toggle word wrap

Le nœud suivant a le type=nœud utilisateur,région=est étiquettes:

Exemple d’objet Node

apiVersion: v1
kind: Node
metadata:
  name: ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4
#...
  labels:
    region: east
    type: user-node
#...
Copy to Clipboard Toggle word wrap

Lorsque vous créez le pod à l’aide de l’exemple pod spec dans ce projet d’exemple, le pod est créé avec les sélecteurs de nœud de projet et est programmé sur le nœud étiqueté:

Exemple d’objet Pod

apiVersion: v1
kind: Pod
metadata:
  namespace: east-region
#...
spec:
  nodeSelector:
    region: east
    type: user-node
#...
Copy to Clipboard Toggle word wrap

Exemple de pod list avec la gousse sur le nœud étiqueté

NAME     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
pod-s1   1/1     Running   0          20s   10.131.2.6   ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4   <none>           <none>
Copy to Clipboard Toggle word wrap

Dans le projet, un pod n’est pas créé ou programmé si le pod contient différents sélecteurs de nœuds. À titre d’exemple, si vous déployez la pod suivante dans le projet d’exemple, il n’est pas créé:

Exemple d’objet Pod avec un sélecteur de nœud invalide

apiVersion: v1
kind: Pod
metadata:
  name: west-region
#...
spec:
  nodeSelector:
    region: west
#...
Copy to Clipboard Toggle word wrap

13.1.2. Loki Pod placement
Copier lien

Il est possible de contrôler les nœuds sur lesquels les pods Loki s’exécutent et d’empêcher d’autres charges de travail d’utiliser ces nœuds, en utilisant des tolérances ou des sélecteurs de nœuds sur les pods.

Avec la ressource personnalisée LokiStack (CR) vous pouvez appliquer des tolérances aux pods de log store et appliquer des taintes à un nœud avec la spécification du nœud. La tainte sur un nœud est une paire key:value qui ordonne au nœud de repousser toutes les gousses qui ne permettent pas la tainte. En utilisant une paire clé:valeur spécifique qui n’est pas sur d’autres gousses garantit que seuls les pods de log store peuvent fonctionner sur ce nœud.

Exemple LokiStack avec sélecteurs de nœuds

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
1 

      nodeSelector:
        node-role.kubernetes.io/infra: ""
2 

    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...
Copy to Clipboard Toggle word wrap

1
Indique le type de pod de composant qui s’applique au sélecteur de nœud.
2
Indique les pods qui sont déplacés vers des nœuds contenant l’étiquette définie.

Dans la configuration de l’exemple précédent, tous les pods Loki sont déplacés vers des nœuds contenant l’étiquette node-role.kubernetes.io/infra: "".

Exemple LokiStack CR avec sélecteurs de nœuds et tolérances

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...
Copy to Clipboard Toggle word wrap

Afin de configurer les champs nodeSelector et tolerations du LokiStack (CR), vous pouvez utiliser la commande oc explicative pour afficher la description et les champs d’une ressource particulière: 

$ oc explain lokistack.spec.template
Copy to Clipboard Toggle word wrap

Exemple de sortie

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...
Copy to Clipboard Toggle word wrap

Afin d’obtenir des informations plus détaillées, vous pouvez ajouter un champ spécifique: 

$ oc explain lokistack.spec.template.compactor
Copy to Clipboard Toggle word wrap

Exemple de sortie

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...
Copy to Clipboard Toggle word wrap

Les administrateurs peuvent modifier les ressources ou la planification du collecteur en créant une ressource personnalisée ClusterLogging (CR) qui se trouve dans le même espace de noms et a le même nom que le ClusterLogForwarder CR qu’il prend en charge.

Les strophes applicables au ClusterLogging CR lors de l’utilisation de plusieurs transmetteurs de journaux dans un déploiement sont l’état de gestion et la collecte. Les autres strophes sont ignorées.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • La version 5.8 ou plus récente de Red Hat OpenShift Logging Operator a été installée.
  • ClusterLogForwarder CR a créé un ClusterLogForwarder CR.

Procédure

  1. Créez un ClusterLogging CR qui prend en charge votre ClusterLogForwarder CR existant:

    Exemple ClusterLogging CR YAML

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name:  <name>
    1 
    
  namespace: <namespace>
    2 
    
spec:
  managementState: "Managed"
  collection:
    type: "vector"
    tolerations:
    - key: "logging"
      operator: "Exists"
      effect: "NoExecute"
      tolerationSeconds: 6000
    resources:
      limits:
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 1Gi
    nodeSelector:
      collector: needed
# ...
    Copy to Clipboard Toggle word wrap

    1
    Le nom doit être le même nom que le ClusterLogForwarder CR.
    2
    L’espace de noms doit être le même espace de noms que le ClusterLogForwarder CR.

  2. Appliquez le ClusterLogging CR en exécutant la commande suivante: 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

13.1.4. Affichage des pods de collecteurs de journalisation
Copier lien

Il est possible d’afficher les pods de collecteurs de journalisation et les nœuds correspondants sur lesquels ils sont en cours d’exécution.

Procédure

  • Exécutez la commande suivante dans un projet pour afficher les pods de collecte de journalisation et leurs détails: 

    $ oc get pods --selector component=collector -o wide -n <project_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME           READY  STATUS    RESTARTS   AGE     IP            NODE                  NOMINATED NODE   READINESS GATES
collector-8d69v  1/1    Running   0          134m    10.130.2.30   master1.example.com   <none>           <none>
collector-bd225  1/1    Running   0          134m    10.131.1.11   master2.example.com   <none>           <none>
collector-cvrzs  1/1    Running   0          134m    10.130.0.21   master3.example.com   <none>           <none>
collector-gpqg2  1/1    Running   0          134m    10.128.2.27   worker1.example.com   <none>           <none>
collector-l9j7j  1/1    Running   0          134m    10.129.2.31   worker2.example.com   <none>           <none>
    Copy to Clipboard Toggle word wrap

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