SupportConsoleDéveloppeursCommencer un essaiContact

5.2. Remplacement d'un membre etcd malsain

Ce document décrit le processus de remplacement d'un membre etcd malsain.

Ce processus dépend du fait que le membre etcd est malsain parce que la machine ne fonctionne pas ou que le nœud n'est pas prêt, ou qu'il est malsain parce que le pod etcd est en train de faire du crashlooping.

Note

Si vous avez perdu la majorité de vos hôtes du plan de contrôle, suivez la procédure de reprise après sinistre pour restaurer un état antérieur du cluster au lieu de suivre cette procédure.

Si les certificats du plan de contrôle ne sont pas valides sur le membre remplacé, vous devez suivre la procédure de récupération des certificats de plan de contrôle expirés au lieu de cette procédure.

Si un nœud de plan de contrôle est perdu et qu'un nouveau est créé, l'opérateur de cluster etcd se charge de générer les nouveaux certificats TLS et d'ajouter le nœud en tant que membre etcd.

5.2.1. Conditions préalables

5.2.2. Identification d'un membre etcd malsain

Vous pouvez identifier si votre cluster a un membre etcd en mauvaise santé.

Conditions préalables

  • Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Vérifiez l'état de la condition d'état EtcdMembersAvailable à l'aide de la commande suivante : 

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}'

  2. Examiner les résultats : 

    2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy

    Cet exemple montre que le membre ip-10-0-131-183.ec2.internal etcd n'est pas sain.

5.2.3. Déterminer l'état d'un membre etcd malsain

Les étapes pour remplacer un membre etcd malsain dépendent de l'état dans lequel se trouve votre membre etcd :

  • La machine ne fonctionne pas ou le nœud n'est pas prêt
  • Le pod etcd est en train de faire un crashloop

Cette procédure permet de déterminer dans quel état se trouve votre membre etcd. Cela vous permet de savoir quelle procédure suivre pour remplacer le membre etcd en mauvais état.

Note

Si vous savez que la machine ne fonctionne pas ou que le nœud n'est pas prêt, mais que vous vous attendez à ce qu'il revienne bientôt à un état sain, vous n'avez pas besoin d'exécuter une procédure pour remplacer le membre etcd. L'opérateur de cluster etcd se synchronisera automatiquement lorsque la machine ou le nœud redeviendra sain.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez identifié un membre etcd malsain.

Procédure

  1. Déterminer si le site machine is not running: 

    $ oc get machines -A -ojsonpath='{range .items[*]}{@.status.nodeRef.name}{@.status.providerStatus.instanceState}{@.status.providerStatus.instanceState}{\N-"\N-"\N"}" | grep -v running

    Exemple de sortie

    ip-10-0-131-183.ec2.internal  stopped 1

    1
    Cette sortie indique le nœud et l'état de la machine du nœud. Si l'état est différent de running, alors la page machine is not running.

    Si le site machine is not running, suivre la procédure Replacing an unhealthy etcd member whose machine is not running or whose node is not ready.

  2. Déterminer si le site node is not ready.

    Si l'un ou l'autre des scénarios suivants est vrai, alors le site node is not ready.

    • Si la machine fonctionne, vérifiez si le nœud est inaccessible : 

      $ oc get nodes -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.taints[*]}{.key}{" "}' | grep unreachable

      Exemple de sortie

      ip-10-0-131-183.ec2.internal	node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable 1

      1
      Si le nœud est répertorié avec une tare unreachable, alors la tare node is not ready.

    • Si le nœud est toujours accessible, vérifiez si le nœud est répertorié comme NotReady: 

      $ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"

      Exemple de sortie

      ip-10-0-131-183.ec2.internal   NotReady   master   122m   v1.25.0 1

      1
      Si le nœud est répertorié comme NotReady, alors le nœud node is not ready.

    Si le site node is not ready, suivre la procédure Replacing an unhealthy etcd member whose machine is not running or whose node is not ready.

  3. Déterminer si le site etcd pod is crashlooping.

    Si la machine fonctionne et que le nœud est prêt, vérifiez si le pod etcd fait du crashlooping.

    1. Vérifiez que tous les nœuds du plan de contrôle sont répertoriés comme Ready: 

      $ oc get nodes -l node-role.kubernetes.io/master

      Exemple de sortie

      NAME                           STATUS   ROLES    AGE     VERSION
ip-10-0-131-183.ec2.internal   Ready    master   6h13m   v1.25.0
ip-10-0-164-97.ec2.internal    Ready    master   6h13m   v1.25.0
ip-10-0-154-204.ec2.internal   Ready    master   6h13m   v1.25.0

    2. Vérifier si l'état d'un pod etcd est Error ou CrashloopBackoff: 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      Exemple de sortie

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m 1
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m

      1
      Puisque le statut de ce pod est Error, alors le etcd pod is crashlooping.

    Si le site etcd pod is crashlooping, suivre la procédure Replacing an unhealthy etcd member whose etcd pod is crashlooping.

5.2.4. Remplacement d'un membre etcd malsain

Selon l'état de votre membre etcd malsain, utilisez l'une des procédures suivantes :

5.2.4.1. Remplacement d'un membre etcd en mauvaise santé dont la machine ne fonctionne pas ou dont le nœud n'est pas prêt

Cette procédure détaille les étapes à suivre pour remplacer un membre etcd qui n'est pas sain, soit parce que la machine ne fonctionne pas, soit parce que le nœud n'est pas prêt.

Note

Si votre cluster utilise un jeu de machines de plan de contrôle, voir "Récupération d'un opérateur etcd dégradé" dans "Dépannage du jeu de machines de plan de contrôle" pour une procédure de récupération etcd plus simple.

Conditions préalables

  • Vous avez identifié le membre etcd malsain.

  • Vous avez vérifié que la machine n'est pas en cours d'exécution ou que le nœud n'est pas prêt.

    Important

    Vous devez attendre si les autres nœuds du plan de contrôle sont hors tension. Les nœuds du plan de contrôle doivent rester hors tension jusqu'à ce que le remplacement d'un membre etcd malsain soit terminé.

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

  • Vous avez effectué une sauvegarde etcd.

    Important

    Il est important de faire une sauvegarde d'etcd avant d'effectuer cette procédure afin de pouvoir restaurer votre cluster en cas de problème.

Procédure

  1. Retirer l'élément malsain.

    1. Choisissez un pod qui est not sur le nœud affecté :

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      Exemple de sortie

      etcd-ip-10-0-131-183.ec2.internal                3/3     Running     0          123m
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m

    2. Se connecter au conteneur etcd en cours d'exécution, en passant le nom d'un pod qui n'est pas sur le nœud affecté :

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal

    3. Consulter la liste des membres : 

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 6fc1e7c9db35841d | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

      Notez l'ID et le nom du membre etcd malsain, car ces valeurs seront nécessaires plus tard dans la procédure. La commande $ etcdctl endpoint health listera le membre supprimé jusqu'à ce que la procédure de remplacement soit terminée et qu'un nouveau membre soit ajouté.

    4. Supprimez le membre etcd malsain en fournissant l'ID à la commande etcdctl member remove: 

      sh-4.2# etcdctl member remove 6fc1e7c9db35841d

      Exemple de sortie

      Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346

    5. Consultez à nouveau la liste des membres et vérifiez que le membre a bien été supprimé : 

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

      Vous pouvez maintenant quitter le shell du nœud.

      Important

      Après avoir supprimé le membre, le cluster peut être inaccessible pendant une courte période, le temps que les instances etcd restantes redémarrent.

  2. Désactivez la garde du quorum en entrant la commande suivante : 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    Cette commande permet de s'assurer que vous pouvez recréer les secrets et déployer les pods statiques avec succès.

  3. Supprime les anciens secrets du membre etcd malsain qui a été supprimé.

    1. Liste les secrets du membre etcd malsain qui a été supprimé. 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1
      1
      Saisissez le nom du membre etcd malsain dont vous avez pris note plus tôt dans cette procédure.

      Il y a un pair, un serveur et un secret de métrique, comme le montre la sortie suivante :

      Exemple de sortie

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m

    2. Supprime les secrets du membre etcd malsain qui a été supprimé.

      1. Supprimer le secret de l'homologue : 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal

      2. Supprimer le secret de service : 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal

      3. Supprimer le secret des métriques : 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal

  4. Supprimer et recréer la machine du plan de contrôle. Une fois cette machine recréée, une nouvelle révision est forcée et etcd se met automatiquement à l'échelle.

    Si vous utilisez une infrastructure fournie par l'installateur ou si vous avez utilisé l'API Machine pour créer vos machines, suivez ces étapes. Sinon, vous devez créer le nouveau master en utilisant la même méthode que celle utilisée pour le créer à l'origine.

    1. Obtenir la machine pour le membre en mauvaise santé.

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

      $ oc get machines -n openshift-machine-api -o wide

      Exemple de sortie

      NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 1
clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

      1
      Il s'agit de la machine du plan de contrôle pour le nœud malsain, ip-10-0-131-183.ec2.internal.

    2. Enregistrez la configuration de la machine dans un fichier sur votre système de fichiers : 

      $ oc get machine clustername-8qw5l-master-0 \ 1
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml
      1
      Indiquez le nom de la machine du plan de contrôle pour le nœud malsain.

    3. Modifiez le fichier new-master-machine.yaml créé à l'étape précédente pour lui attribuer un nouveau nom et supprimer les champs inutiles.

      1. Retirer toute la section status: 

        status:
  addresses:
  - address: 10.0.131.183
    type: InternalIP
  - address: ip-10-0-131-183.ec2.internal
    type: InternalDNS
  - address: ip-10-0-131-183.ec2.internal
    type: Hostname
  lastUpdated: "2020-04-20T17:44:29Z"
  nodeRef:
    kind: Node
    name: ip-10-0-131-183.ec2.internal
    uid: acca4411-af0d-4387-b73e-52b2484295ad
  phase: Running
  providerStatus:
    apiVersion: awsproviderconfig.openshift.io/v1beta1
    conditions:
    - lastProbeTime: "2020-04-20T16:53:50Z"
      lastTransitionTime: "2020-04-20T16:53:50Z"
      message: machine successfully created
      reason: MachineCreationSucceeded
      status: "True"
      type: MachineCreation
    instanceId: i-0fdb85790d76d0c3f
    instanceState: stopped
    kind: AWSMachineProviderStatus

      2. Changez le nom du champ metadata.name.

        Il est recommandé de conserver le même nom de base que l'ancienne machine et de remplacer le numéro de fin par le prochain numéro disponible. Dans cet exemple, clustername-8qw5l-master-0 est remplacé par clustername-8qw5l-master-3.

        Par exemple : 

        apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...

      3. Supprimer le champ spec.providerID: 

          providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f

    4. Supprimez l'objet BareMetalHost en exécutant la commande suivante, en remplaçant <host_name> par le nom de l'hôte à nu du nœud malsain : 

      oc delete bmh -n openshift-machine-api <host_name>

    5. Supprimez la machine du membre malsain en exécutant la commande suivante, en remplaçant <machine_name> par le nom de la machine du plan de contrôle du nœud malsain, par exemple clustername-8qw5l-master-0: 

      $ oc delete machine -n openshift-machine-api <nom_de_la_machine>

    6. Vérifiez que la machine a été supprimée : 

      $ oc get machines -n openshift-machine-api -o wide

      Exemple de sortie

      NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

    7. Créez la nouvelle machine à l'aide du fichier new-master-machine.yaml: 

      $ oc apply -f new-master-machine.yaml

    8. Vérifiez que la nouvelle machine a été créée : 

      $ oc get machines -n openshift-machine-api -o wide

      Exemple de sortie

      NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-133-53.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8   running 1
clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

      1
      La nouvelle machine, clustername-8qw5l-master-3, est en cours de création et sera prête lorsque la phase passera de Provisioning à Running.

      La création de la nouvelle machine peut prendre quelques minutes. L'opérateur du cluster etcd se synchronisera automatiquement lorsque la machine ou le nœud reviendra à un état sain.

  5. Réactivez la garde du quorum en entrant la commande suivante : 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

  6. Vous pouvez vérifier que la section unsupportedConfigOverrides est supprimée de l'objet en entrant cette commande : 

    $ oc get etcd/cluster -oyaml

  7. Si vous utilisez OpenShift à nœud unique, redémarrez le nœud. Sinon, vous risquez de rencontrer l'erreur suivante dans l'opérateur de cluster etcd :

    Exemple de sortie

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

Vérification

  1. Vérifiez que tous les pods etcd fonctionnent correctement.

    Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    Exemple de sortie

    etcd-ip-10-0-133-53.ec2.internal                 3/3     Running     0          7m49s
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m

    Si la sortie de la commande précédente n'indique que deux pods, vous pouvez forcer manuellement un redéploiement d'etcd. Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

    $ oc patch etcd cluster -p='{"spec" : {\i1}"forceRedeploymentReason" : \N-"recovery-'\N"$( date --rfc-3339=ns )'\N'\N"}'' -type=merge} --type=merge 1
    1
    La valeur forceRedeploymentReason doit être unique, c'est pourquoi un horodatage est ajouté.

  2. Vérifiez qu'il y a exactement trois membres etcd.

    1. Se connecter au conteneur etcd en cours d'exécution, en passant le nom d'un pod qui n'était pas sur le nœud affecté :

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal

    2. Consulter la liste des membres : 

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 5eb0d6b8ca24730c | started |  ip-10-0-133-53.ec2.internal |  https://10.0.133.53:2380 |  https://10.0.133.53:2379 |
| 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

      Si la sortie de la commande précédente répertorie plus de trois membres etcd, vous devez supprimer avec précaution le membre indésirable.

      Avertissement

      Veillez à supprimer le bon membre etcd ; la suppression d'un bon membre etcd peut entraîner une perte de quorum.

Ressources complémentaires

5.2.4.2. Remplacement d'un membre etcd en mauvaise santé dont le pod etcd est en crashlooping

Cette procédure détaille les étapes à suivre pour remplacer un membre etcd qui n'est pas en bonne santé parce que le pod etcd fait du crashlooping.

Conditions préalables

  • Vous avez identifié le membre etcd malsain.
  • Vous avez vérifié que le pod etcd fait du crashlooping.
  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

  • Vous avez effectué une sauvegarde etcd.

    Important

    Il est important de faire une sauvegarde d'etcd avant d'effectuer cette procédure afin de pouvoir restaurer votre cluster en cas de problème.

Procédure

  1. Arrêter le pod etcd de crashlooping.

    1. Déboguer le nœud qui fait du crashlooping.

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

      oc debug node/ip-10-0-131-183.ec2.internal 1
      1
      Remplacez ce nom par le nom du nœud malsain.

    2. Changez votre répertoire racine en /host: 

      sh-4.2# chroot /host

    3. Déplacer le fichier pod etcd existant hors du répertoire kubelet manifest : 

      sh-4.2# mkdir /var/lib/etcd-backup
      sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/

    4. Déplacez le répertoire de données etcd vers un autre emplacement : 

      sh-4.2# mv /var/lib/etcd/ /tmp

      Vous pouvez maintenant quitter le shell du nœud.

  2. Retirer l'élément malsain.

    1. Choisissez un pod qui est not sur le nœud affecté.

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      Exemple de sortie

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m
etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m

    2. Se connecter au conteneur etcd en cours d'exécution, en passant le nom d'un pod qui n'est pas sur le nœud affecté.

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal

    3. Consulter la liste des membres : 

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| 62bcf33650a7170a | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
| b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

      Notez l'ID et le nom du membre etcd malsain, car ces valeurs seront nécessaires plus tard dans la procédure.

    4. Supprimez le membre etcd malsain en fournissant l'ID à la commande etcdctl member remove: 

      sh-4.2# etcdctl member remove 62bcf33650a7170a

      Exemple de sortie

      Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346

    5. Consultez à nouveau la liste des membres et vérifiez que le membre a bien été supprimé : 

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+------------------------------+---------------------------+---------------------------+
|        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
+------------------+---------+------------------------------+---------------------------+---------------------------+
| b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
| d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
+------------------+---------+------------------------------+---------------------------+---------------------------+

      Vous pouvez maintenant quitter le shell du nœud.

  3. Désactivez la garde du quorum en entrant la commande suivante : 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    Cette commande permet de s'assurer que vous pouvez recréer les secrets et déployer les pods statiques avec succès.

  4. Supprime les anciens secrets du membre etcd malsain qui a été supprimé.

    1. Liste les secrets du membre etcd malsain qui a été supprimé. 

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1
      1
      Saisissez le nom du membre etcd malsain dont vous avez pris note plus tôt dans cette procédure.

      Il y a un pair, un serveur et un secret de métrique, comme le montre la sortie suivante :

      Exemple de sortie

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m

    2. Supprime les secrets du membre etcd malsain qui a été supprimé.

      1. Supprimer le secret de l'homologue : 

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal

      2. Supprimer le secret de service : 

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal

      3. Supprimer le secret des métriques : 

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal

  5. Forcer le redéploiement de etcd.

    Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

    $ oc patch etcd cluster -p='{"spec" : {\i1}"forceRedeploymentReason" : \N "single-master-recovery-'\N"$( date --rfc-3339=ns )'\N"}'' -type=merge} --type=merge 1
    1
    La valeur forceRedeploymentReason doit être unique, c'est pourquoi un horodatage est ajouté.

    Lorsque l'opérateur de cluster etcd effectue un redéploiement, il s'assure que tous les nœuds du plan de contrôle disposent d'un pod etcd fonctionnel.

  6. Réactivez la garde du quorum en entrant la commande suivante : 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

  7. Vous pouvez vérifier que la section unsupportedConfigOverrides est supprimée de l'objet en entrant cette commande : 

    $ oc get etcd/cluster -oyaml

  8. Si vous utilisez OpenShift à nœud unique, redémarrez le nœud. Sinon, vous risquez de rencontrer l'erreur suivante dans l'opérateur de cluster etcd :

    Exemple de sortie

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

Vérification

  • Vérifier que le nouveau membre est disponible et en bonne santé.

    1. Connectez-vous à nouveau au conteneur etcd en cours d'exécution.

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal

    2. Vérifier que tous les membres sont en bonne santé : 

      sh-4.2# etcdctl endpoint health

      Exemple de sortie

      https://10.0.131.183:2379 is healthy: successfully committed proposal: took = 16.671434ms
https://10.0.154.204:2379 is healthy: successfully committed proposal: took = 16.698331ms
https://10.0.164.97:2379 is healthy: successfully committed proposal: took = 16.621645ms

5.2.4.3. Remplacement d'un membre etcd bare metal en mauvaise santé dont la machine ne fonctionne pas ou dont le nœud n'est pas prêt

Cette procédure détaille les étapes à suivre pour remplacer un membre etcd en métal nu qui n'est pas en bonne santé, soit parce que la machine ne fonctionne pas, soit parce que le nœud n'est pas prêt.

Si vous exécutez une infrastructure fournie par l'installateur ou si vous avez utilisé l'API Machine pour créer vos machines, suivez ces étapes. Sinon, vous devez créer le nouveau nœud de plan de contrôle en utilisant la même méthode que celle utilisée pour le créer à l'origine.

Conditions préalables

  • Vous avez identifié le membre malsain de bare metal etcd.
  • Vous avez vérifié que la machine n'est pas en cours d'exécution ou que le nœud n'est pas prêt.
  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

  • Vous avez effectué une sauvegarde etcd.

    Important

    Vous devez effectuer une sauvegarde d'etcd avant d'exécuter cette procédure afin de pouvoir restaurer votre cluster en cas de problème.

Procédure

  1. Vérifiez et supprimez le membre malsain.

    1. Choisissez un pod qui est not sur le nœud affecté :

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

      $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

      Exemple de sortie

      etcd-openshift-control-plane-0   5/5   Running   11   3h56m   192.168.10.9   openshift-control-plane-0  <none>           <none>
etcd-openshift-control-plane-1   5/5   Running   0    3h54m   192.168.10.10   openshift-control-plane-1   <none>           <none>
etcd-openshift-control-plane-2   5/5   Running   0    3h58m   192.168.10.11   openshift-control-plane-2   <none>           <none>

    2. Se connecter au conteneur etcd en cours d'exécution, en passant le nom d'un pod qui n'est pas sur le nœud affecté :

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

      $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0

    3. Consulter la liste des membres : 

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
| ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
| cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380/ | https://192.168.10.9:2379/   | false |
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+

      Notez l'ID et le nom du membre etcd malsain, car ces valeurs seront nécessaires plus tard dans la procédure. La commande etcdctl endpoint health listera le membre supprimé jusqu'à ce que la procédure de remplacement soit terminée et que le nouveau membre soit ajouté.

    4. Supprimez le membre etcd malsain en fournissant l'ID à la commande etcdctl member remove:

      Avertissement

      Veillez à supprimer le bon membre etcd ; la suppression d'un bon membre etcd peut entraîner une perte de quorum. 

      sh-4.2# etcdctl member remove 7a8197040a5126c8

      Exemple de sortie

      Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b

    5. Consultez à nouveau la liste des membres et vérifiez que le membre a bien été supprimé : 

      sh-4.2# etcdctl member list -w table

      Exemple de sortie

      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
| ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+

      Vous pouvez maintenant quitter le shell du nœud.

      Important

      Après avoir supprimé le membre, le cluster peut être inaccessible pendant une courte période, le temps que les instances etcd restantes redémarrent.

  2. Désactivez la garde du quorum en entrant la commande suivante : 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    Cette commande permet de s'assurer que vous pouvez recréer les secrets et déployer les pods statiques avec succès.

  3. Supprimez les anciens secrets du membre etcd malsain qui a été supprimé en exécutant les commandes suivantes.

    1. Liste les secrets du membre etcd malsain qui a été supprimé. 

      $ oc get secrets -n openshift-etcd | grep openshift-control-plane-2

      Saisissez le nom du membre etcd malsain dont vous avez pris note plus tôt dans cette procédure.

      Il y a un pair, un serveur et un secret de métrique, comme le montre la sortie suivante : 

      etcd-peer-openshift-control-plane-2             kubernetes.io/tls   2   134m
etcd-serving-metrics-openshift-control-plane-2  kubernetes.io/tls   2   134m
etcd-serving-openshift-control-plane-2          kubernetes.io/tls   2   134m

    2. Supprime les secrets du membre etcd malsain qui a été supprimé.

      1. Supprimer le secret de l'homologue : 

        $ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd

secret "etcd-peer-openshift-control-plane-2" deleted

      2. Supprimer le secret de service : 

        $ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-metrics-openshift-control-plane-2" deleted

      3. Supprimer le secret des métriques : 

        $ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd

secret "etcd-serving-openshift-control-plane-2" deleted

  4. Supprimer la machine du plan de contrôle.

    Si vous exécutez une infrastructure fournie par l'installateur ou si vous avez utilisé l'API Machine pour créer vos machines, suivez ces étapes. Sinon, vous devez créer le nouveau nœud de plan de contrôle en utilisant la même méthode que celle utilisée pour le créer à l'origine.

    1. Obtenir la machine pour le membre en mauvaise santé.

      Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

      $ oc get machines -n openshift-machine-api -o wide

      Exemple de sortie

      NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                               PROVIDERID                                                                                              STATE
examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned 1
examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-control-plane-2    Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

      1
      Il s'agit de la machine du plan de contrôle pour le nœud malsain, examplecluster-control-plane-2.

    2. Enregistrez la configuration de la machine dans un fichier sur votre système de fichiers : 

      $ oc get machine examplecluster-control-plane-2 \ 1
    -n openshift-machine-api \
    -o yaml \
    > new-master-machine.yaml
      1
      Indiquez le nom de la machine du plan de contrôle pour le nœud malsain.

    3. Modifiez le fichier new-master-machine.yaml créé à l'étape précédente pour lui attribuer un nouveau nom et supprimer les champs inutiles.

      1. Retirer toute la section status: 

        status:
  addresses:
  - address: ""
    type: InternalIP
  - address: fe80::4adf:37ff:feb0:8aa1%ens1f1.373
    type: InternalDNS
  - address: fe80::4adf:37ff:feb0:8aa1%ens1f1.371
    type: Hostname
  lastUpdated: "2020-04-20T17:44:29Z"
  nodeRef:
    kind: Machine
    name: fe80::4adf:37ff:feb0:8aa1%ens1f1.372
    uid: acca4411-af0d-4387-b73e-52b2484295ad
  phase: Running
  providerStatus:
    apiVersion: machine.openshift.io/v1beta1
    conditions:
    - lastProbeTime: "2020-04-20T16:53:50Z"
      lastTransitionTime: "2020-04-20T16:53:50Z"
      message: machine successfully created
      reason: MachineCreationSucceeded
      status: "True"
      type: MachineCreation
    instanceId: i-0fdb85790d76d0c3f
    instanceState: stopped
    kind: Machine

  5. Changez le nom du champ metadata.name.

    Il est recommandé de conserver le même nom de base que l'ancienne machine et de remplacer le numéro de fin par le prochain numéro disponible. Dans cet exemple, examplecluster-control-plane-2 est remplacé par examplecluster-control-plane-3.

    Par exemple : 

    apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: examplecluster-control-plane-3
  ...

    1. Supprimer le champ spec.providerID: 

        providerID: baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135

    2. Supprimer les champs metadata.annotations et metadata.generation: 

        annotations:
    machine.openshift.io/instance-state: externally provisioned
  ...
  generation: 2

    3. Supprimer les champs spec.conditions, spec.lastUpdated, spec.nodeRef et spec.phase: 

        lastTransitionTime: "2022-08-03T08:40:36Z"
message: 'Drain operation currently blocked by: [{Name:EtcdQuorumOperator Owner:clusteroperator/etcd}]'
reason: HookPresent
severity: Warning
status: "False"

type: Drainable
lastTransitionTime: "2022-08-03T08:39:55Z"
status: "True"
type: InstanceExists

lastTransitionTime: "2022-08-03T08:36:37Z"
status: "True"
type: Terminable
lastUpdated: "2022-08-03T08:40:36Z"
nodeRef:
kind: Node
name: openshift-control-plane-2
uid: 788df282-6507-4ea2-9a43-24f237ccbc3c
phase: Running

  6. Assurez-vous que l'opérateur Bare Metal est disponible en exécutant la commande suivante : 

    $ oc get clusteroperator baremetal

    Exemple de sortie

    NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
baremetal   4.12.0    True        False         False      3d15h

  7. Supprimez l'ancien objet BareMetalHost en exécutant la commande suivante : 

    $ oc delete bmh openshift-control-plane-2 -n openshift-machine-api

    Exemple de sortie

    baremetalhost.metal3.io "openshift-control-plane-2" deleted

  8. Supprimez la machine du membre malsain en exécutant la commande suivante : 

    $ oc delete machine -n openshift-machine-api examplecluster-control-plane-2

    Après avoir supprimé les objets BareMetalHost et Machine, le contrôleur Machine supprime automatiquement l'objet Node.

    Si la suppression de la machine est retardée pour une raison quelconque ou si la commande est entravée et retardée, vous pouvez forcer la suppression en supprimant le champ finalizer de l'objet machine.

    Important

    N'interrompez pas l'effacement de la machine en appuyant sur Ctrl c. Vous devez laisser la commande se dérouler jusqu'à son terme. Ouvrez une nouvelle fenêtre de terminal pour éditer et supprimer les champs du finalisateur.

    1. Modifiez la configuration de la machine en exécutant la commande suivante : 

      $ oc edit machine -n openshift-machine-api examplecluster-control-plane-2

    2. Supprimez les champs suivants dans la ressource personnalisée Machine, puis enregistrez le fichier mis à jour : 

      finalizers:
- machine.machine.openshift.io

      Exemple de sortie

      machine.machine.openshift.io/examplecluster-control-plane-2 edited

  9. Vérifiez que la machine a été supprimée en exécutant la commande suivante : 

    $ oc get machines -n openshift-machine-api -o wide

    Exemple de sortie

    NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                                 PROVIDERID                                                                                       STATE
examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

  10. Vérifiez que le nœud a été supprimé en exécutant la commande suivante : 

    $ oc get nodes

NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 3h24m v1.25.0
openshift-control-plane-1 Ready master 3h24m v1.25.0
openshift-compute-0       Ready worker 176m v1.25.0
openshift-compute-1       Ready worker 176m v1.25.0

  11. Créez le nouvel objet BareMetalHost et le secret pour stocker les informations d'identification BMC : 

    $ cat <<EOF | oc apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: openshift-control-plane-2-bmc-secret
  namespace: openshift-machine-api
data:
  password: <password>
  username: <username>
type: Opaque
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: openshift-control-plane-2
  namespace: openshift-machine-api
spec:
  automatedCleaningMode: disabled
  bmc:
    address: redfish://10.46.61.18:443/redfish/v1/Systems/1
    credentialsName: openshift-control-plane-2-bmc-secret
    disableCertificateVerification: true
  bootMACAddress: 48:df:37:b0:8a:a0
  bootMode: UEFI
  externallyProvisioned: false
  online: true
  rootDeviceHints:
    deviceName: /dev/sda
  userData:
    name: master-user-data-managed
    namespace: openshift-machine-api
EOF
    Note

    Le nom d'utilisateur et le mot de passe peuvent être trouvés dans les secrets de l'autre hôte bare metal. Le protocole à utiliser dans bmc:address peut être obtenu à partir d'autres objets bmh.

    Important

    Si vous réutilisez la définition de l'objet BareMetalHost à partir d'un hôte de plan de contrôle existant, ne laissez pas le champ externallyProvisioned sur true.

    Les objets du plan de contrôle BareMetalHost existants peuvent avoir l'indicateur externallyProvisioned défini sur true s'ils ont été provisionnés par le programme d'installation d'OpenShift Container Platform.

    Une fois l'inspection terminée, l'objet BareMetalHost est créé et disponible pour être approvisionné.

  12. Vérifier le processus de création à l'aide des objets disponibles sur BareMetalHost: 

    $ oc get bmh -n openshift-machine-api

NAME                      STATE                  CONSUMER                      ONLINE ERROR   AGE
openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
openshift-control-plane-2 available              examplecluster-control-plane-3 true         47m
openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m

    1. Créez la nouvelle machine du plan de contrôle à l'aide du fichier new-master-machine.yaml: 

      $ oc apply -f new-master-machine.yaml

    2. Vérifiez que la nouvelle machine a été créée : 

      $ oc get machines -n openshift-machine-api -o wide

      Exemple de sortie

      NAME                                   PHASE     TYPE   REGION   ZONE   AGE     NODE                              PROVIDERID                                                                                            STATE
examplecluster-control-plane-0         Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned 1
examplecluster-control-plane-1         Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
examplecluster-control-plane-2         Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
examplecluster-compute-0               Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
examplecluster-compute-1               Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

      1
      La nouvelle machine, clustername-8qw5l-master-3, est en cours de création et sera prête après le changement de phase de Provisioning à Running.

      La création de la nouvelle machine devrait prendre quelques minutes. L'opérateur du cluster etcd se synchronisera automatiquement lorsque la machine ou le nœud reviendra à un état sain.

    3. Vérifiez que l'hôte bare metal est provisionné et qu'aucune erreur n'est signalée en exécutant la commande suivante : 

      $ oc get bmh -n openshift-machine-api

      Exemple de sortie

      $ oc get bmh -n openshift-machine-api
NAME                      STATE                  CONSUMER                       ONLINE ERROR AGE
openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
openshift-control-plane-2 provisioned            examplecluster-control-plane-3 true          47m
openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m

    4. Vérifiez que le nouveau nœud est ajouté et prêt à fonctionner en exécutant la commande suivante : 

      $ oc get nodes

      Exemple de sortie

      $ oc get nodes
NAME                     STATUS ROLES   AGE   VERSION
openshift-control-plane-0 Ready master 4h26m v1.25.0
openshift-control-plane-1 Ready master 4h26m v1.25.0
openshift-control-plane-2 Ready master 12m   v1.25.0
openshift-compute-0       Ready worker 3h58m v1.25.0
openshift-compute-1       Ready worker 3h58m v1.25.0

  13. Réactivez la garde du quorum en entrant la commande suivante : 

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

  14. Vous pouvez vérifier que la section unsupportedConfigOverrides est supprimée de l'objet en entrant cette commande : 

    $ oc get etcd/cluster -oyaml

  15. Si vous utilisez OpenShift à nœud unique, redémarrez le nœud. Sinon, vous risquez de rencontrer l'erreur suivante dans l'opérateur de cluster etcd :

    Exemple de sortie

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

Vérification

  1. Vérifiez que tous les pods etcd fonctionnent correctement.

    Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    Exemple de sortie

    etcd-openshift-control-plane-0      5/5     Running     0     105m
etcd-openshift-control-plane-1      5/5     Running     0     107m
etcd-openshift-control-plane-2      5/5     Running     0     103m

    Si la sortie de la commande précédente n'indique que deux pods, vous pouvez forcer manuellement un redéploiement d'etcd. Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

    $ oc patch etcd cluster -p='{"spec" : {\i1}"forceRedeploymentReason" : \N-"recovery-'\N"$( date --rfc-3339=ns )'\N'\N"}'' -type=merge} --type=merge 1
    1
    La valeur forceRedeploymentReason doit être unique, c'est pourquoi un horodatage est ajouté.

    Pour vérifier qu'il y a exactement trois membres etcd, connectez-vous au conteneur etcd en cours d'exécution, en indiquant le nom d'un pod qui n'était pas sur le nœud affecté. Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante : 

    $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0

  2. Consulter la liste des membres : 

    sh-4.2# etcdctl member list -w table

    Exemple de sortie

    +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
|        ID        | STATUS  |        NAME        |        PEER ADDRS         |       CLIENT ADDRS        |    IS LEARNER    |
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
| 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380 | https://192.168.10.11:2379 |   false |
| 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380 | https://192.168.10.10:2379 |   false |
| cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380 | https://192.168.10.9:2379 |     false |
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+

    Note

    Si la sortie de la commande précédente répertorie plus de trois membres etcd, vous devez supprimer avec précaution le membre indésirable.

  3. Vérifiez que tous les membres d'etcd sont sains en exécutant la commande suivante : 

    # etcdctl endpoint health --cluster

    Exemple de sortie

    https://192.168.10.10:2379 is healthy: successfully committed proposal: took = 8.973065ms
https://192.168.10.9:2379 is healthy: successfully committed proposal: took = 11.559829ms
https://192.168.10.11:2379 is healthy: successfully committed proposal: took = 11.665203ms

  4. Validez que tous les nœuds sont à la dernière révision en exécutant la commande suivante : 

    $ oc get etcd -o=jsonpath='{range.items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
    AllNodesAtLatestRevision

5.2.5. Ressources complé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.