Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

6.4. Ajuster les nœuds de travail

download PDF

Si vous avez mal dimensionné les nœuds de travail lors du déploiement, ajustez-les en créant un ou plusieurs nouveaux ensembles de machines de calcul, augmentez-les, puis réduisez l'ensemble de machines de calcul d'origine avant de les supprimer.

6.4.1. Comprendre la différence entre les ensembles de machines de calcul et le pool de configuration des machines

MachineSet décrivent les nœuds d'OpenShift Container Platform par rapport au fournisseur de nuages ou de machines.

L'objet MachineConfigPool permet aux composants MachineConfigController de définir et de fournir l'état des machines dans le contexte des mises à niveau.

L'objet MachineConfigPool permet aux utilisateurs de configurer la manière dont les mises à niveau sont déployées sur les nœuds OpenShift Container Platform dans le pool de configuration de la machine.

L'objet NodeSelector peut être remplacé par une référence à l'objet MachineSet.

6.4.2. Mise à l'échelle manuelle d'un ensemble de machines de calcul

Pour ajouter ou supprimer une instance d'une machine dans un ensemble de machines de calcul, vous pouvez mettre à l'échelle manuellement l'ensemble de machines de calcul.

Ce guide s'applique aux installations d'infrastructure entièrement automatisées et fournies par l'installateur. Les installations d'infrastructure personnalisées et fournies par l'utilisateur n'ont pas d'ensembles de machines de calcul.

Conditions préalables

  • Installer un cluster OpenShift Container Platform et la ligne de commande oc.
  • Connectez-vous à oc en tant qu'utilisateur disposant de l'autorisation cluster-admin.

Procédure

  1. Affichez les ensembles de machines de calcul qui se trouvent dans le cluster en exécutant la commande suivante : 

    $ oc get machinesets -n openshift-machine-api

    Les ensembles de machines de calcul sont répertoriés sous la forme de <clusterid>-worker-<aws-region-az>.

  2. Affichez les machines de calcul qui se trouvent dans le cluster en exécutant la commande suivante : 

    $ oc get machine -n openshift-machine-api

  3. Définissez l'annotation sur la machine de calcul que vous souhaitez supprimer en exécutant la commande suivante : 

    $ oc annotate machine/<machine_name> -n openshift-machine-api machine.openshift.io/delete-machine="true"

  4. Mettez à l'échelle l'ensemble de machines de calcul en exécutant l'une des commandes suivantes : 

    $ oc scale --replicas=2 machineset <machineset> -n openshift-machine-api

    Ou bien : 

    $ oc edit machineset <machineset> -n openshift-machine-api
    Astuce

    Vous pouvez également appliquer le YAML suivant pour mettre à l'échelle l'ensemble des machines de calcul : 

    apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  replicas: 2

    Vous pouvez augmenter ou diminuer le nombre de machines de calcul. Il faut quelques minutes pour que les nouvelles machines soient disponibles.

    Important

    Par défaut, le contrôleur de machine tente de drainer le nœud soutenu par la machine jusqu'à ce qu'il y parvienne. Dans certaines situations, comme dans le cas d'un budget de perturbation de pods mal configuré, l'opération de vidange peut ne pas aboutir. Si l'opération de vidange échoue, le contrôleur de machine ne peut pas procéder au retrait de la machine.

    Vous pouvez éviter de vider le nœud en annotant machine.openshift.io/exclude-node-draining dans une machine spécifique.

Vérification

  • Vérifiez la suppression de la machine prévue en exécutant la commande suivante : 

    $ oc get machines

6.4.3. Politique de suppression des ensembles de machines de calcul

Random, Newest, et Oldest sont les trois options de suppression prises en charge. La valeur par défaut est Random, ce qui signifie que des machines aléatoires sont choisies et supprimées lorsque des machines de calcul à échelle réduite sont mises hors service. La politique de suppression peut être définie en fonction du cas d'utilisation en modifiant l'ensemble particulier de machines de calcul : 

spec:
  deletePolicy: <delete_policy>
  replicas: <desired_replica_count>

Des machines spécifiques peuvent également être supprimées en priorité en ajoutant l'annotation machine.openshift.io/delete-machine=true à la machine concernée, quelle que soit la politique de suppression.

Important

Par défaut, les pods de routeur de OpenShift Container Platform sont déployés sur des workers. Comme le routeur est nécessaire pour accéder à certaines ressources du cluster, notamment la console Web, ne mettez pas à l'échelle l'ensemble de machines de calcul de l'ouvrier à l'adresse 0 à moins de déplacer d'abord les pods de routeur.

Note

Les ensembles de machines de calcul personnalisés peuvent être utilisés pour des cas d'utilisation exigeant que des services s'exécutent sur des nœuds spécifiques et que ces services soient ignorés par le contrôleur lorsque les ensembles de machines de calcul travailleurs sont réduits. Cela permet d'éviter les interruptions de service.

6.4.4. Création de sélecteurs de nœuds par défaut pour l'ensemble du cluster

Vous pouvez utiliser des sélecteurs de nœuds par défaut à l'échelle du cluster sur les pods ainsi que des étiquettes sur les nœuds pour contraindre tous les pods créés dans un cluster à des nœuds spécifiques.

Avec des sélecteurs de nœuds à l'échelle du cluster, lorsque vous créez un pod dans ce cluster, OpenShift Container Platform ajoute les sélecteurs de nœuds par défaut au pod et planifie le pod sur des nœuds avec des étiquettes correspondantes.

Vous configurez les sélecteurs de nœuds à l'échelle du cluster en modifiant la ressource personnalisée (CR) de l'opérateur d'ordonnancement. Vous ajoutez des étiquettes à un nœud, à un ensemble de machines de calcul ou à une configuration de machine. L'ajout de l'étiquette à l'ensemble de machines de calcul garantit que si le nœud ou la machine tombe en panne, les nouveaux nœuds disposent de l'étiquette. Les étiquettes ajoutées à un nœud ou à une configuration de machine ne persistent pas si le nœud ou la machine tombe en panne.

Note

Vous pouvez ajouter des paires clé/valeur supplémentaires à un pod. Mais vous ne pouvez pas ajouter une valeur différente pour une clé par défaut.

Procédure

Pour ajouter un sélecteur de nœuds par défaut à l'échelle du cluster :

  1. Modifiez le CR de l'opérateur d'ordonnancement pour ajouter les sélecteurs de nœuds par défaut à l'échelle du cluster : 

    $ oc edit scheduler cluster

    Exemple d'opérateur d'ordonnancement CR avec un sélecteur de nœuds

    apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
...
spec:
  defaultNodeSelector: type=user-node,region=east 1
  mastersSchedulable: false

    1
    Ajouter un sélecteur de nœud avec les paires <key>:<value> appropriées.

    Après avoir effectué cette modification, attendez que les pods du projet openshift-kube-apiserver soient redéployés. Cela peut prendre plusieurs minutes. Le sélecteur de nœuds par défaut à l'échelle du cluster ne prend pas effet tant que les pods ne sont pas redéployés.

  2. Ajoutez des étiquettes à un nœud en utilisant un ensemble de machines de calcul ou en éditant le nœud directement :

    • Utiliser un ensemble de machines de calcul pour ajouter des étiquettes aux nœuds gérés par l'ensemble de machines de calcul lors de la création d'un nœud :

      1. Exécutez la commande suivante pour ajouter des étiquettes à un objet MachineSet: 

        $ oc patch MachineSet <name> --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"<key>"="<value>","<key>"="<value>"}}]'  -n openshift-machine-api 1
        1
        Ajouter une paire <key>/<value> pour chaque étiquette.

        Par exemple : 

        $ oc patch MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c --type='json' -p='[{"op":"add","path":"/spec/template/spec/metadata/labels", "value":{"type":"user-node","region":"east"}}]'  -n openshift-machine-api
        Astuce

        Vous pouvez également appliquer le YAML suivant pour ajouter des étiquettes à un ensemble de machines de calcul : 

        apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: <machineset>
  namespace: openshift-machine-api
spec:
  template:
    spec:
      metadata:
        labels:
          region: "east"
          type: "user-node"

      2. Vérifiez que les étiquettes sont ajoutées à l'objet MachineSet en utilisant la commande oc edit:

        Par exemple : 

        $ oc edit MachineSet abc612-msrtw-worker-us-east-1c -n openshift-machine-api

        Exemple d'objet MachineSet 

        apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
  ...
spec:
  ...
  template:
    metadata:
  ...
    spec:
      metadata:
        labels:
          region: east
          type: user-node
  ...

      3. Redéployez les nœuds associés à cet ensemble de machines de calcul en réduisant l'échelle à 0 et en augmentant l'échelle des nœuds :

        Par exemple : 

        $ oc scale --replicas=0 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api
        $ oc scale --replicas=1 MachineSet ci-ln-l8nry52-f76d1-hl7m7-worker-c -n openshift-machine-api

      4. Lorsque les nœuds sont prêts et disponibles, vérifiez que l'étiquette a été ajoutée aux nœuds à l'aide de la commande oc get: 

        $ oc get nodes -l <key>=<value>

        Par exemple : 

        $ oc get nodes -l type=user-node

        Exemple de sortie

        NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-c-vmqzp   Ready    worker   61s   v1.25.0

    • Ajouter des étiquettes directement à un nœud :

      1. Modifiez l'objet Node pour le nœud : 

        $ oc label nodes <name> <key>=<value>

        Par exemple, pour étiqueter un nœud : 

        $ oc label nodes ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49 type=user-node region=east
        Astuce

        Vous pouvez également appliquer le langage YAML suivant pour ajouter des étiquettes à un nœud : 

        kind: Node
apiVersion: v1
metadata:
  name: <node_name>
  labels:
    type: "user-node"
    region: "east"

      2. Vérifiez que les étiquettes sont ajoutées au nœud à l'aide de la commande oc get: 

        $ oc get nodes -l <key>=<value>,<key>=<valeur>

        Par exemple : 

        $ oc get nodes -l type=user-node,region=east

        Exemple de sortie

        NAME                                       STATUS   ROLES    AGE   VERSION
ci-ln-l8nry52-f76d1-hl7m7-worker-b-tgq49   Ready    worker   17m   v1.25.0

6.4.5. Création de charges de travail utilisateur dans les zones locales AWS

After you create an Amazon Web Service (AWS) Local Zone environment, and you deploy your cluster, you can use edge worker nodes to create user workloads in Local Zone subnets.

Une fois que openshift-installer a créé le cluster, le programme d'installation spécifie automatiquement un effet d'altération de NoSchedule pour chaque nœud de travailleur périphérique. Cela signifie qu'un ordonnanceur n'ajoute pas de nouveau module ou déploiement à un nœud si le module ne correspond pas aux tolérances spécifiées pour un effet d'altération. Vous pouvez modifier l'altération pour mieux contrôler la manière dont chaque nœud crée une charge de travail dans chaque sous-réseau de la zone locale.

Le site openshift-installer crée le fichier manifests de l'ensemble de machines de calcul avec les étiquettes node-role.kubernetes.io/edge et node-role.kubernetes.io/worker appliquées à chaque nœud de travailleur périphérique situé dans un sous-réseau de la zone locale.

Conditions préalables

  • Vous avez accès au CLI OpenShift (oc).
  • Vous avez déployé votre cluster dans un nuage privé virtuel (VPC) avec des sous-réseaux de zone locale définis.
  • Vous vous êtes assuré que l'ensemble de machines de calcul pour les travailleurs périphériques sur les sous-réseaux de la zone locale spécifie les taints pour node-role.kubernetes.io/edge.

Procédure

  1. Créez un fichier YAML de ressource deployment pour un exemple d'application à déployer dans le nœud de travailleur frontal qui opère dans un sous-réseau de la zone locale. Veillez à spécifier les tolérances correctes qui correspondent aux taints du nœud de travailleur frontal.

    Exemple de ressource deployment configurée pour un nœud de travailleur frontal opérant dans un sous-réseau de la zone locale

    kind: Namespace
apiVersion: v1
metadata:
  name: <local_zone_application_namespace>
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: <pvc_name>
  namespace: <local_zone_application_namespace>
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: gp2-csi 1
  volumeMode: Filesystem
---
apiVersion: apps/v1
kind: Deployment 2
metadata:
  name: <local_zone_application> 3
  namespace: <local_zone_application_namespace> 4
spec:
  selector:
    matchLabels:
      app: <local_zone_application>
  replicas: 1
  template:
    metadata:
      labels:
        app: <local_zone_application>
        zone-group: ${ZONE_GROUP_NAME} 5
    spec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      nodeSelector: 6
        machine.openshift.io/zone-group: ${ZONE_GROUP_NAME}
      tolerations: 7
      - key: "node-role.kubernetes.io/edge"
        operator: "Equal"
        value: ""
        effect: "NoSchedule"
      containers:
        - image: openshift/origin-node
          command:
           - "/bin/socat"
          args:
            - TCP4-LISTEN:8080,reuseaddr,fork
            - EXEC:'/bin/bash -c \"printf \\\"HTTP/1.0 200 OK\r\n\r\n\\\"; sed -e \\\"/^\r/q\\\"\"'
          imagePullPolicy: Always
          name: echoserver
          ports:
            - containerPort: 8080
          volumeMounts:
            - mountPath: "/mnt/storage"
              name: data
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: <pvc_name>

    1
    storageClassName: Pour la configuration de la zone locale, vous devez spécifier gp2-csi.
    2
    kind: Définit la ressource deployment.
    3
    name: Spécifie le nom de l'application de la zone locale. Par exemple, local-zone-demo-app-nyc-1.
    4
    namespace: Définit l'espace de noms de la zone locale AWS dans laquelle vous souhaitez exécuter la charge de travail de l'utilisateur. Par exemple : local-zone-app-nyc-1a.
    5
    zone-group: Définit le groupe auquel une zone appartient. Par exemple, us-east-1-iah-1.
    6
    nodeSelector: Cible les nœuds de travailleur d'arête qui correspondent aux étiquettes spécifiées.
    7
    tolerations: Définit les valeurs qui correspondent à taints définies dans le manifeste MachineSet pour le nœud de la zone locale.

  2. Créez un fichier YAML de ressource service pour le nœud. Cette ressource expose un pod d'un nœud de travailleur périphérique ciblé aux services qui s'exécutent à l'intérieur de votre réseau de zone locale.

    Exemple de ressource service configurée pour un nœud de travailleur frontal opérant dans un sous-réseau de la zone locale

    apiVersion: v1
kind: Service 1
metadata:
  name:  <local_zone_application>
  namespace: <local_zone_application_namespace>
spec:
  ports:
    - port: 80
      targetPort: 8080
      protocol: TCP
  type: NodePort
  selector: 2
    app: <local_zone_application>

    1
    kind: Définit la ressource service.
    2
    selector: Spécifie le type d'étiquette appliqué aux modules gérés.

Prochaines étapes

  • Facultatif : Utilisez l'opérateur AWS Load Balancer (ALB) pour exposer un pod d'un nœud de travail périphérique ciblé aux services qui s'exécutent dans un sous-réseau de la zone locale à partir d'un réseau public. Voir Installation de l'opérateur AWS Load Balancer.

Ressources supplémentaires

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.

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 leBlog 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.

© 2024 Red Hat, Inc.