3.2. Redémarrage du cluster
Vous pouvez redémarrer votre cluster après qu'il ait été arrêté de manière gracieuse.
Conditions préalables
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
. - Cette procédure suppose que vous avez arrêté le cluster de manière gracieuse.
Procédure
- Activez toutes les dépendances du cluster, telles que le stockage externe ou un serveur LDAP.
Démarrer toutes les machines du cluster.
Utilisez la méthode appropriée à votre environnement cloud pour démarrer les machines, par exemple à partir de la console web de votre fournisseur de cloud.
Attendez environ 10 minutes avant de continuer à vérifier l'état des nœuds du plan de contrôle.
Vérifier que tous les nœuds du plan de contrôle sont prêts.
$ oc get nodes -l node-role.kubernetes.io/master
Les nœuds du plan de contrôle sont prêts si l'état est
Ready
, comme le montre la sortie suivante :NAME STATUS ROLES AGE VERSION ip-10-0-168-251.ec2.internal Ready master 75m v1.25.0 ip-10-0-170-223.ec2.internal Ready master 75m v1.25.0 ip-10-0-211-16.ec2.internal Ready master 75m v1.25.0
Si les nœuds du plan de contrôle sont prêts pour not, vérifiez s'il y a des demandes de signature de certificat (CSR) en attente qui doivent être approuvées.
Obtenir la liste des CSR actuels :
$ oc get csr
Examinez les détails d'un CSR pour vérifier qu'il est valide :
oc describe csr <csr_name> 1
- 1
<csr_name>
est le nom d'un CSR figurant dans la liste des CSR actuels.
Approuver chaque RSE valide :
$ oc adm certificate approve <csr_name>
Une fois que les nœuds du plan de contrôle sont prêts, vérifiez que tous les nœuds de travail sont prêts.
$ oc get nodes -l node-role.kubernetes.io/worker
Les nœuds de travail sont prêts si le statut est
Ready
, comme le montre la sortie suivante :NAME STATUS ROLES AGE VERSION ip-10-0-179-95.ec2.internal Ready worker 64m v1.25.0 ip-10-0-182-134.ec2.internal Ready worker 64m v1.25.0 ip-10-0-250-100.ec2.internal Ready worker 64m v1.25.0
Si les nœuds de travail sont prêts pour not, vérifiez s'il y a des demandes de signature de certificat (CSR) en attente qui doivent être approuvées.
Obtenir la liste des CSR actuels :
$ oc get csr
Examinez les détails d'un CSR pour vérifier qu'il est valide :
oc describe csr <csr_name> 1
- 1
<csr_name>
est le nom d'un CSR figurant dans la liste des CSR actuels.
Approuver chaque RSE valide :
$ oc adm certificate approve <csr_name>
Vérifiez que le cluster a démarré correctement.
Vérifiez qu'il n'y a pas d'opérateurs de cluster dégradés.
$ oc get clusteroperators
Vérifiez qu'il n'y a pas d'opérateurs de cluster dont la condition
DEGRADED
est définie surTrue
.NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.12.0 True False False 59m cloud-credential 4.12.0 True False False 85m cluster-autoscaler 4.12.0 True False False 73m config-operator 4.12.0 True False False 73m console 4.12.0 True False False 62m csi-snapshot-controller 4.12.0 True False False 66m dns 4.12.0 True False False 76m etcd 4.12.0 True False False 76m ...
Vérifiez que tous les nœuds sont dans l'état
Ready
:$ oc get nodes
Vérifiez que l'état de tous les nœuds est
Ready
.NAME STATUS ROLES AGE VERSION ip-10-0-168-251.ec2.internal Ready master 82m v1.25.0 ip-10-0-170-223.ec2.internal Ready master 82m v1.25.0 ip-10-0-179-95.ec2.internal Ready worker 70m v1.25.0 ip-10-0-182-134.ec2.internal Ready worker 70m v1.25.0 ip-10-0-211-16.ec2.internal Ready master 82m v1.25.0 ip-10-0-250-100.ec2.internal Ready worker 69m v1.25.0
Si le cluster n'a pas démarré correctement, il se peut que vous deviez le restaurer à l'aide d'une sauvegarde etcd.
Ressources complémentaires
- Voir Restauration d'un état antérieur du cluster pour savoir comment utiliser une sauvegarde etcd pour restaurer si votre cluster n'a pas réussi à se rétablir après un redémarrage.