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 Copier lienLien copié sur presse-papiers!
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
$ oc get controlplanemachineset.machine.openshift.io cluster \ --namespace openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Un résultat de
Activeindique que la CRControlPlaneMachineSetexiste et est activée. Aucune action de l'administrateur n'est requise. -
Un résultat de
Inactiveindique qu'une CRControlPlaneMachineSetexiste mais qu'elle n'est pas activée. -
Un résultat de
NotFoundindique qu'il n'existe pas de CRControlPlaneMachineSet.
-
Un résultat de
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 Copier lienLien copié sur presse-papiers!
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
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
$ oc get machines \ -l machine.openshift.io/cluster-api-machine-role==master \ -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
oc edit machine <control_plane_machine_name> $ oc edit machine <control_plane_machine_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Ajoutez le paramètre
internalLoadBalanceravec les détails corrects pour votre cluster et enregistrez vos modifications. 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
$ oc edit controlplanemachineset.machine.openshift.io cluster \ -n openshift-machine-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Ajoutez le paramètre
internalLoadBalanceravec 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é Copier lienLien copié sur presse-papiers!
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
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
$ oc get machines \ -l machine.openshift.io/cluster-api-machine-role==master \ -n openshift-machine-api \ -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow L'une des conditions suivantes peut indiquer une défaillance de la machine du plan de contrôle :
-
La valeur
STATEeststopped. -
La valeur
PHASEestFailed. -
La valeur
PHASEestDeletingpendant plus de dix minutes.
ImportantAvant 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.
-
La valeur
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>
oc edit machine <control_plane_machine_name> $ oc edit machine <control_plane_machine_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Supprimez le contenu du paramètre
lifecycleHooksde 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é.