12.6. Dépannage de l'ensemble de machines du plan de contrôle

Utilisez les informations de cette section pour comprendre et résoudre les problèmes que vous pourriez rencontrer.

12.6.1. Vérification de l'état des ressources personnalisées de l'ensemble des machines du plan de contrôle

Vous pouvez vérifier l'existence et l'état de la ressource personnalisée (CR) ControlPlaneMachineSet.

Procédure

  • Déterminez l'état de la CR en exécutant la commande suivante :

    $ oc get controlplanemachineset.machine.openshift.io cluster \
      --namespace openshift-machine-api
    • Un résultat de Active indique que la CR ControlPlaneMachineSet existe et est activée. Aucune action de l'administrateur n'est requise.
    • Un résultat de Inactive indique qu'une CR ControlPlaneMachineSet existe mais qu'elle n'est pas activée.
    • Un résultat de NotFound indique qu'il n'existe pas de CR ControlPlaneMachineSet.

Prochaines étapes

Pour utiliser le jeu de machines du plan de contrôle, vous devez vous assurer qu'il existe un CR ControlPlaneMachineSet avec les paramètres corrects pour votre cluster.

  • Si votre cluster dispose d'un CR existant, vous devez vérifier que la configuration du CR est correcte pour votre cluster.
  • Si votre cluster n'a pas de CR existant, vous devez en créer un avec la configuration correcte pour votre cluster.

12.6.2. Ajouter un équilibreur de charge interne Azure manquant

Le paramètre internalLoadBalancer est requis dans les ressources personnalisées (CR) ControlPlaneMachineSet et Machine du plan de contrôle pour Azure. Si ce paramètre n'est pas préconfiguré sur votre cluster, vous devez l'ajouter aux deux CR.

Pour plus d'informations sur l'emplacement de ce paramètre dans la spécification du fournisseur Azure, voir l'exemple de spécification du fournisseur Azure. L'emplacement dans le plan de contrôle Machine CR est similaire.

Procédure

  1. Dressez la liste des machines du plan de contrôle de votre cluster en exécutant la commande suivante :

    $ oc get machines \
      -l machine.openshift.io/cluster-api-machine-role==master \
      -n openshift-machine-api
  2. Pour chaque machine du plan de contrôle, modifiez le CR en exécutant la commande suivante :

    oc edit machine <control_plane_machine_name> $ oc edit machine <control_plane_machine_name>
  3. Ajoutez le paramètre internalLoadBalancer avec les détails corrects pour votre cluster et enregistrez vos modifications.
  4. Modifiez le jeu de machines CR de votre plan de contrôle en exécutant la commande suivante :

    $ oc edit controlplanemachineset.machine.openshift.io cluster \
      -n openshift-machine-api
  5. Ajoutez le paramètre internalLoadBalancer avec les détails corrects pour votre cluster et enregistrez vos modifications.

Prochaines étapes

  • Pour les clusters qui utilisent la stratégie de mise à jour par défaut RollingUpdate, l'opérateur propage automatiquement les modifications à votre configuration du plan de contrôle.
  • Pour les clusters configurés pour utiliser la stratégie de mise à jour OnDelete, vous devez remplacer manuellement les machines du plan de contrôle.

12.6.3. Récupération d'un opérateur etcd dégradé

Certaines situations peuvent entraîner une dégradation de l'opérateur etcd.

Par exemple, lors de la remédiation, le bilan de santé de la machine peut supprimer une machine du plan de contrôle qui héberge etcd. Si le membre etcd n'est pas joignable à ce moment-là, l'opérateur etcd est dégradé.

Lorsque l'opérateur etcd est dégradé, une intervention manuelle est nécessaire pour forcer l'opérateur à retirer le membre défaillant et restaurer l'état du cluster.

Procédure

  1. Dressez la liste des machines du plan de contrôle de votre cluster en exécutant la commande suivante :

    $ oc get machines \
      -l machine.openshift.io/cluster-api-machine-role==master \
      -n openshift-machine-api \
      -o wide

    L'une des conditions suivantes peut indiquer une défaillance de la machine du plan de contrôle :

    • La valeur STATE est stopped.
    • La valeur PHASE est Failed.
    • La valeur PHASE est Deleting pendant plus de dix minutes.
    Important

    Avant de continuer, assurez-vous que votre cluster dispose de deux machines de plan de contrôle saines. L'exécution des actions de cette procédure sur plus d'une machine de plan de contrôle risque de perdre le quorum etcd et peut entraîner une perte de données.

    Si vous avez perdu la majorité de vos hôtes du plan de contrôle, ce qui entraîne la perte du quorum etcd, vous devez suivre la procédure de reprise après sinistre "Restauration d'un état antérieur du cluster" au lieu de cette procédure.

  2. Modifiez le CR de la machine du plan de contrôle défaillant en exécutant la commande suivante :

    oc edit machine <control_plane_machine_name> $ oc edit machine <control_plane_machine_name>
  3. Supprimez le contenu du paramètre lifecycleHooks de la machine du plan de contrôle défaillante et enregistrez vos modifications.

    L'opérateur etcd retire la machine défaillante du cluster et peut alors ajouter de nouveaux membres etcd en toute sécurité.