Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

7.4. Déplacement de ressources vers des ensembles de machines d'infrastructure

Certaines ressources d'infrastructure sont déployées par défaut dans votre cluster. Vous pouvez les déplacer vers les ensembles de machines d'infrastructure que vous avez créés en ajoutant le sélecteur de nœuds d'infrastructure, comme indiqué : 

spec:
  nodePlacement:
1 

    nodeSelector:
      matchLabels:
        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
1
Ajoutez un paramètre nodeSelector avec la valeur appropriée au composant que vous souhaitez déplacer. Vous pouvez utiliser un nodeSelector dans le format indiqué ou utiliser des paires <key>: <value>, en fonction de la valeur spécifiée pour le nœud. Si vous avez ajouté une tare au nœud de l'infrasructure, ajoutez également une tolérance correspondante.

En appliquant un sélecteur de nœud spécifique à tous les composants de l'infrastructure, OpenShift Container Platform planifie ces charges de travail sur les nœuds portant ce label.

7.4.1. Déplacement du routeur
Copier lien

Vous pouvez déployer le module de routeur sur un ensemble de machines de calcul différent. Par défaut, le module est déployé sur un nœud de travail.

Conditions préalables

  • Configurez des ensembles de machines de calcul supplémentaires dans votre cluster OpenShift Container Platform.

Procédure

  1. Voir la ressource personnalisée IngressController pour l'opérateur de routeur : 

    $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

    La sortie de la commande ressemble au texte suivant : 

    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  creationTimestamp: 2019-04-18T12:35:39Z
  finalizers:
  - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
  generation: 1
  name: default
  namespace: openshift-ingress-operator
  resourceVersion: "11341"
  selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
  uid: 79509e05-61d6-11e9-bc55-02ce4781844a
spec: {}
status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2019-04-18T12:36:15Z
    status: "True"
    type: Available
  domain: apps.<cluster>.example.com
  endpointPublishingStrategy:
    type: LoadBalancerService
  selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default

  2. Modifiez la ressource ingresscontroller et changez la ressource nodeSelector pour qu'elle utilise l'étiquette infra: 

    $ oc edit ingresscontroller default -n openshift-ingress-operator
     
      spec:
    nodePlacement:
      nodeSelector:
    1 
    
        matchLabels:
          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
    1
    Ajoutez un paramètre nodeSelector avec la valeur appropriée au composant que vous souhaitez déplacer. Vous pouvez utiliser un nodeSelector au format indiqué ou des paires <key>: <value>, en fonction de la valeur spécifiée pour le nœud. Si vous avez ajouté une taint au nœud d'infrastructure, ajoutez également une tolérance correspondante.

  3. Confirmez que le pod routeur est en cours d'exécution sur le nœud infra.

    1. Affichez la liste des modules de routeur et notez le nom du nœud du module en cours d'exécution : 

      $ oc get pod -n openshift-ingress -o wide

      Exemple de sortie

      NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

      Dans cet exemple, le pod en cours d'exécution se trouve sur le nœud ip-10-0-217-226.ec2.internal.

    2. Visualiser l'état du nœud du pod en cours d'exécution : 

      oc get node <node_name>
      1
      1
      Spécifiez l'adresse <node_name> que vous avez obtenue à partir de la liste des pods.

      Exemple de sortie

      NAME                          STATUS  ROLES         AGE   VERSION
ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.25.0

      Comme la liste des rôles comprend infra, le pod est exécuté sur le bon nœud.

7.4.2. Déplacement du registre par défaut
Copier lien

Vous configurez l'opérateur de registre pour qu'il déploie ses pods sur différents nœuds.

Conditions préalables

  • Configurez des ensembles de machines de calcul supplémentaires dans votre cluster OpenShift Container Platform.

Procédure

  1. Voir l'objet config/instance: 

    $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

    Exemple de sortie

    apiVersion: imageregistry.operator.openshift.io/v1
kind: Config
metadata:
  creationTimestamp: 2019-02-05T13:52:05Z
  finalizers:
  - imageregistry.operator.openshift.io/finalizer
  generation: 1
  name: cluster
  resourceVersion: "56174"
  selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
  uid: 36fd3724-294d-11e9-a524-12ffeee2931b
spec:
  httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
  logging: 2
  managementState: Managed
  proxy: {}
  replicas: 1
  requests:
    read: {}
    write: {}
  storage:
    s3:
      bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
      region: us-east-1
status:
...

  2. Modifiez l'objet config/instance: 

    $ oc edit configs.imageregistry.operator.openshift.io/cluster
     
    spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - podAffinityTerm:
          namespaces:
          - openshift-image-registry
          topologyKey: kubernetes.io/hostname
        weight: 100
  logLevel: Normal
  managementState: Managed
  nodeSelector:
    1 
    
    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
    1
    Ajoutez un paramètre nodeSelector avec la valeur appropriée au composant que vous souhaitez déplacer. Vous pouvez utiliser un nodeSelector dans le format indiqué ou utiliser des paires <key>: <value>, en fonction de la valeur spécifiée pour le nœud. Si vous avez ajouté une tare au nœud de l'infrasructure, ajoutez également une tolérance correspondante.

  3. Vérifiez que le pod de registre a été déplacé vers le nœud d'infrastructure.

    1. Exécutez la commande suivante pour identifier le nœud où se trouve le module de registre : 

      $ oc get pods -o wide -n openshift-image-registry

    2. Confirmez que le nœud a l'étiquette que vous avez spécifiée : 

      oc describe node <node_name>

      Examinez la sortie de la commande et confirmez que node-role.kubernetes.io/infra figure dans la liste LABELS.

7.4.3. Déplacement de la solution de surveillance
Copier lien

La pile de surveillance comprend plusieurs composants, notamment Prometheus, Thanos Querier et Alertmanager. L'opérateur de surveillance des clusters gère cette pile. Pour redéployer la pile de surveillance sur les nœuds d'infrastructure, vous pouvez créer et appliquer une carte de configuration personnalisée.

Procédure

  1. Modifiez la carte de configuration cluster-monitoring-config et changez la carte nodeSelector pour qu'elle utilise le label infra: 

    $ oc edit configmap cluster-monitoring-config -n openshift-monitoring
     
    apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |+
    alertmanagerMain:
      nodeSelector:
    1 
    
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    prometheusK8s:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    prometheusOperator:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    k8sPrometheusAdapter:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    kubeStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    telemeterClient:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    openshiftStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    thanosQuerier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoExecute
    1
    Ajoutez un paramètre nodeSelector avec la valeur appropriée au composant que vous souhaitez déplacer. Vous pouvez utiliser un nodeSelector dans le format indiqué ou utiliser des paires <key>: <value>, en fonction de la valeur spécifiée pour le nœud. Si vous avez ajouté une tare au nœud de l'infrasructure, ajoutez également une tolérance correspondante.

  2. Observez le déplacement des modules de surveillance vers les nouvelles machines : 

    $ watch 'oc get pod -n openshift-monitoring -o wide'

  3. Si un composant n'a pas été déplacé vers le nœud infra, supprimez le pod contenant ce composant : 

    oc delete pod -n openshift-monitoring <pod>

    Le composant du module supprimé est recréé sur le nœud infra.

7.4.4. Déplacer les ressources de journalisation d'OpenShift
Copier lien

Vous pouvez configurer le Cluster Logging Operator pour déployer les pods des composants du sous-système de journalisation, tels qu'Elasticsearch et Kibana, sur différents nœuds. Vous ne pouvez pas déplacer le pod Cluster Logging Operator de son emplacement d'installation.

Par exemple, vous pouvez déplacer les pods Elasticsearch vers un nœud distinct en raison des exigences élevées en matière de CPU, de mémoire et de disque.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés. Ces fonctionnalités ne sont pas installées par défaut.

Procédure

  1. Modifiez la ressource personnalisée (CR) ClusterLogging dans le projet openshift-logging: 

    $ oc edit ClusterLogging instance
     
    apiVersion: logging.openshift.io/v1
kind: ClusterLogging

...

spec:
  collection:
    logs:
      fluentd:
        resources: null
      type: fluentd
  logStore:
    elasticsearch:
      nodeCount: 3
      nodeSelector:
    1 
    
        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
      redundancyPolicy: SingleRedundancy
      resources:
        limits:
          cpu: 500m
          memory: 16Gi
        requests:
          cpu: 500m
          memory: 16Gi
      storage: {}
    type: elasticsearch
  managementState: Managed
  visualization:
    kibana:
      nodeSelector:
    2 
    
        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
      proxy:
        resources: null
      replicas: 1
      resources: null
    type: kibana

...
    1 2
    Ajoutez un paramètre nodeSelector avec la valeur appropriée au composant que vous souhaitez déplacer. Vous pouvez utiliser un nodeSelector dans le format indiqué ou utiliser des paires <key>: <value>, en fonction de la valeur spécifiée pour le nœud. Si vous avez ajouté une tare au nœud de l'infrasructure, ajoutez également une tolérance correspondante.

Vérification

Pour vérifier qu'un composant a été déplacé, vous pouvez utiliser la commande oc get pod -o wide.

Par exemple :

  • Vous souhaitez déplacer le pod Kibana du nœud ip-10-0-147-79.us-east-2.compute.internal: 

    $ oc get pod kibana-5b8bdf44f9-ccpq9 -o wide

    Exemple de sortie

    NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
kibana-5b8bdf44f9-ccpq9   2/2     Running   0          27s   10.129.2.18   ip-10-0-147-79.us-east-2.compute.internal   <none>           <none>

  • Vous souhaitez déplacer le pod Kibana vers le nœud ip-10-0-139-48.us-east-2.compute.internal, un nœud d'infrastructure dédié : 

    $ oc get nodes

    Exemple de sortie

    NAME                                         STATUS   ROLES          AGE   VERSION
ip-10-0-133-216.us-east-2.compute.internal   Ready    master         60m   v1.25.0
ip-10-0-139-146.us-east-2.compute.internal   Ready    master         60m   v1.25.0
ip-10-0-139-192.us-east-2.compute.internal   Ready    worker         51m   v1.25.0
ip-10-0-139-241.us-east-2.compute.internal   Ready    worker         51m   v1.25.0
ip-10-0-147-79.us-east-2.compute.internal    Ready    worker         51m   v1.25.0
ip-10-0-152-241.us-east-2.compute.internal   Ready    master         60m   v1.25.0
ip-10-0-139-48.us-east-2.compute.internal    Ready    infra          51m   v1.25.0

    Notez que le nœud a une étiquette node-role.kubernetes.io/infra: '': 

    $ oc get node ip-10-0-139-48.us-east-2.compute.internal -o yaml

    Exemple de sortie

    kind: Node
apiVersion: v1
metadata:
  name: ip-10-0-139-48.us-east-2.compute.internal
  selfLink: /api/v1/nodes/ip-10-0-139-48.us-east-2.compute.internal
  uid: 62038aa9-661f-41d7-ba93-b5f1b6ef8751
  resourceVersion: '39083'
  creationTimestamp: '2020-04-13T19:07:55Z'
  labels:
    node-role.kubernetes.io/infra: ''
...

  • Pour déplacer le pod Kibana, modifiez le CR ClusterLogging pour ajouter un sélecteur de nœud : 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging

...

spec:

...

  visualization:
    kibana:
      nodeSelector:
    1 
    
        node-role.kubernetes.io/infra: ''
      proxy:
        resources: null
      replicas: 1
      resources: null
    type: kibana
    1
    Ajouter un sélecteur de nœud correspondant à l'étiquette de la spécification du nœud.

  • Après avoir sauvegardé le CR, le pod Kibana actuel est terminé et le nouveau pod est déployé : 

    $ oc get pods

    Exemple de sortie

    NAME                                            READY   STATUS        RESTARTS   AGE
cluster-logging-operator-84d98649c4-zb9g7       1/1     Running       0          29m
elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg   2/2     Running       0          28m
elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj   2/2     Running       0          28m
elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78    2/2     Running       0          28m
fluentd-42dzz                                   1/1     Running       0          28m
fluentd-d74rq                                   1/1     Running       0          28m
fluentd-m5vr9                                   1/1     Running       0          28m
fluentd-nkxl7                                   1/1     Running       0          28m
fluentd-pdvqb                                   1/1     Running       0          28m
fluentd-tflh6                                   1/1     Running       0          28m
kibana-5b8bdf44f9-ccpq9                         2/2     Terminating   0          4m11s
kibana-7d85dcffc8-bfpfp                         2/2     Running       0          33s

  • Le nouveau pod se trouve sur le nœud ip-10-0-139-48.us-east-2.compute.internal: 

    $ oc get pod kibana-7d85dcffc8-bfpfp -o wide

    Exemple de sortie

    NAME                      READY   STATUS        RESTARTS   AGE   IP            NODE                                        NOMINATED NODE   READINESS GATES
kibana-7d85dcffc8-bfpfp   2/2     Running       0          43s   10.131.0.22   ip-10-0-139-48.us-east-2.compute.internal   <none>           <none>

  • Après quelques instants, le pod Kibana original est retiré. 

    $ oc get pods

    Exemple de sortie

    NAME                                            READY   STATUS    RESTARTS   AGE
cluster-logging-operator-84d98649c4-zb9g7       1/1     Running   0          30m
elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg   2/2     Running   0          29m
elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj   2/2     Running   0          29m
elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78    2/2     Running   0          29m
fluentd-42dzz                                   1/1     Running   0          29m
fluentd-d74rq                                   1/1     Running   0          29m
fluentd-m5vr9                                   1/1     Running   0          29m
fluentd-nkxl7                                   1/1     Running   0          29m
fluentd-pdvqb                                   1/1     Running   0          29m
fluentd-tflh6                                   1/1     Running   0          29m
kibana-7d85dcffc8-bfpfp                         2/2     Running   0          62s

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