6.14. tâches etcd

Sauvegarder etcd, activer ou désactiver le cryptage etcd, ou défragmenter les données etcd.

6.14.1. À propos du chiffrement d'etcd

Par défaut, les données etcd ne sont pas cryptées dans OpenShift Container Platform. Vous pouvez activer le chiffrement etcd pour votre cluster afin de fournir une couche supplémentaire de sécurité des données. Par exemple, cela peut aider à protéger la perte de données sensibles si une sauvegarde etcd est exposée à des parties incorrectes.

Lorsque vous activez le chiffrement etcd, les ressources suivantes du serveur API OpenShift et du serveur API Kubernetes sont chiffrées :

Secrets
Cartes de configuration
Routes
Jetons d'accès OAuth
Jetons d'autorisation OAuth

Lorsque vous activez le chiffrement etcd, des clés de chiffrement sont créées. Ces clés font l'objet d'une rotation hebdomadaire. Vous devez disposer de ces clés pour restaurer une sauvegarde etcd.

Note

Le cryptage Etcd ne crypte que les valeurs, pas les clés. Les types de ressources, les espaces de noms et les noms d'objets ne sont pas chiffrés.

Si le chiffrement etcd est activé pendant une sauvegarde, le fichier static_kuberesources_<datetimestamp>.tar.gz contient les clés de chiffrement de l'instantané etcd. Pour des raisons de sécurité, ce fichier doit être stocké séparément de l'instantané etcd. Cependant, ce fichier est nécessaire pour restaurer un état antérieur de etcd à partir de l'instantané etcd correspondant.

6.14.2. Activation du chiffrement d'etcd

Vous pouvez activer le chiffrement etcd pour chiffrer les ressources sensibles de votre cluster.

Avertissement

Ne sauvegardez pas les ressources etcd tant que le processus de cryptage initial n'est pas terminé. Si le processus de chiffrement n'est pas terminé, la sauvegarde risque de n'être que partiellement chiffrée.

Après avoir activé le chiffrement d'etcd, plusieurs changements peuvent survenir :

Le chiffrement d'etcd peut affecter la consommation de mémoire de quelques ressources.
Il se peut que vous remarquiez un effet transitoire sur les performances de la sauvegarde, car le leader doit servir la sauvegarde.
Une entrée/sortie de disque peut affecter le nœud qui reçoit l'état de sauvegarde.

Conditions préalables

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

Procédure

Modifier l'objet APIServer:
```
$ oc edit apiserver
```
Définissez le type de champ encryption sur aescbc:
```
spec:
  encryption:
    type: aescbc 1
```
1
Le type aescbc signifie que le chiffrement est effectué par AES-CBC avec un remplissage PKCS#7 et une clé de 32 octets.
Enregistrez le fichier pour appliquer les modifications.
Le processus de cryptage démarre. Ce processus peut durer 20 minutes ou plus, en fonction de la taille de votre cluster.
Vérifiez que le chiffrement d'etcd a réussi.
1. Examinez la condition d'état Encrypted pour le serveur OpenShift API afin de vérifier que ses ressources ont été chiffrées avec succès :
```
$ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
```
  La sortie indique EncryptionCompleted lorsque le cryptage a réussi :
```
EncryptionCompleted
All resources encrypted: routes.route.openshift.io
```
  Si la sortie indique EncryptionInProgress, le cryptage est toujours en cours. Attendez quelques minutes et réessayez.
2. Consultez la condition d'état Encrypted pour le serveur API Kubernetes afin de vérifier que ses ressources ont été chiffrées avec succès :
```
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
```
  La sortie indique EncryptionCompleted lorsque le cryptage a réussi :
```
EncryptionCompleted
All resources encrypted: secrets, configmaps
```
  Si la sortie indique EncryptionInProgress, le cryptage est toujours en cours. Attendez quelques minutes et réessayez.
3. Examinez l'état Encrypted pour le serveur OpenShift OAuth API afin de vérifier que ses ressources ont été chiffrées avec succès :
```
$ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
```
  La sortie indique EncryptionCompleted lorsque le cryptage a réussi :
```
EncryptionCompleted
All resources encrypted: oauthaccesstokens.oauth.openshift.io, oauthauthorizetokens.oauth.openshift.io
```
  Si la sortie indique EncryptionInProgress, le cryptage est toujours en cours. Attendez quelques minutes et réessayez.

6.14.3. Désactiver le chiffrement d'etcd

Vous pouvez désactiver le chiffrement des données etcd dans votre cluster.

Conditions préalables

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

Procédure

Modifier l'objet APIServer:
```
$ oc edit apiserver
```
Définissez le type de champ encryption sur identity:
```
spec:
  encryption:
    type: identity 1
```
1
Le type identity est la valeur par défaut et signifie qu'aucun cryptage n'est effectué.
Enregistrez le fichier pour appliquer les modifications.
Le processus de décryptage démarre. Ce processus peut durer 20 minutes ou plus, en fonction de la taille de votre cluster.
Vérifier que le décryptage d'etcd a été effectué avec succès.
1. Examinez la condition d'état Encrypted pour le serveur OpenShift API afin de vérifier que ses ressources ont été déchiffrées avec succès :
```
$ oc get openshiftapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
```
  La sortie montre DecryptionCompleted lorsque le décryptage est réussi :
```
DecryptionCompleted
Encryption mode set to identity and everything is decrypted
```
  Si la sortie indique DecryptionInProgress, le décryptage est toujours en cours. Attendez quelques minutes et réessayez.
2. Consultez la condition d'état Encrypted pour le serveur API Kubernetes afin de vérifier que ses ressources ont été déchiffrées avec succès :
```
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
```
  La sortie montre DecryptionCompleted lorsque le décryptage est réussi :
```
DecryptionCompleted
Encryption mode set to identity and everything is decrypted
```
  Si la sortie indique DecryptionInProgress, le décryptage est toujours en cours. Attendez quelques minutes et réessayez.
3. Examinez l'état Encrypted pour le serveur OpenShift OAuth API afin de vérifier que ses ressources ont été déchiffrées avec succès :
```
$ oc get authentication.operator.openshift.io -o=jsonpath='{range .items[0].status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{.message}{"\n"}'
```
  La sortie montre DecryptionCompleted lorsque le décryptage est réussi :
```
DecryptionCompleted
Encryption mode set to identity and everything is decrypted
```
  Si la sortie indique DecryptionInProgress, le décryptage est toujours en cours. Attendez quelques minutes et réessayez.

6.14.4. Sauvegarde des données etcd

Suivez ces étapes pour sauvegarder les données etcd en créant un instantané etcd et en sauvegardant les ressources des pods statiques. Cette sauvegarde peut être enregistrée et utilisée ultérieurement si vous avez besoin de restaurer etcd.

Important

N'effectuez une sauvegarde qu'à partir d'un seul hôte de plan de contrôle. N'effectuez pas de sauvegarde à partir de chaque hôte de plan de contrôle du cluster.

Conditions préalables

Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
Vous avez vérifié si le proxy à l'échelle du cluster est activé.
Astuce
Vous pouvez vérifier si le proxy est activé en examinant la sortie de oc get proxy cluster -o yaml. Le proxy est activé si les champs httpProxy, httpsProxy et noProxy ont des valeurs définies.

Procédure

Démarrer une session de débogage pour un nœud de plan de contrôle :
```
oc debug node/<node_name>
```
Changez votre répertoire racine en /host:
```
sh-4.2# chroot /host
```
Si le proxy à l'échelle du cluster est activé, assurez-vous que vous avez exporté les variables d'environnement NO_PROXY, HTTP_PROXY, et HTTPS_PROXY.

Exécutez le script cluster-backup.sh et indiquez l'emplacement où sauvegarder la sauvegarde.

Astuce

Le script cluster-backup.sh est maintenu en tant que composant de l'opérateur de cluster etcd et est une enveloppe autour de la commande etcdctl snapshot save.

sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup

Exemple de sortie de script

found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
etcdctl version: 3.4.14
API version: 3.4
{"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
{"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
{"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
{"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
{"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
{"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
snapshot db and kube resources are successfully saved to /home/core/assets/backup

Dans cet exemple, deux fichiers sont créés dans le répertoire /home/core/assets/backup/ sur l'hôte du plan de contrôle :

snapshot_<datetimestamp>.db: Ce fichier est le snapshot etcd. Le script cluster-backup.sh confirme sa validité.
static_kuberesources_<datetimestamp>.tar.gz: Ce fichier contient les ressources pour les pods statiques. Si le chiffrement etcd est activé, il contient également les clés de chiffrement pour l'instantané etcd.
Note
Si le cryptage etcd est activé, il est recommandé de stocker ce deuxième fichier séparément de l'instantané etcd pour des raisons de sécurité. Toutefois, ce fichier est nécessaire pour restaurer à partir de l'instantané etcd.
Gardez à l'esprit que le chiffrement etcd ne chiffre que les valeurs, pas les clés. Cela signifie que les types de ressources, les espaces de noms et les noms d'objets ne sont pas chiffrés.

6.14.5. Défragmentation des données etcd

Pour les clusters importants et denses, etcd peut souffrir de mauvaises performances si l'espace-clé devient trop grand et dépasse le quota d'espace. Maintenez et défragmentez périodiquement etcd pour libérer de l'espace dans le magasin de données. Surveillez les métriques etcd dans Prometheus et défragmentez-le si nécessaire ; sinon, etcd peut déclencher une alarme à l'échelle de la grappe qui la met en mode de maintenance n'acceptant que les lectures et les suppressions de clés.

Surveillez ces paramètres clés :

etcd_server_quota_backend_bytesce qui correspond à la limite actuelle du quota
etcd_mvcc_db_total_size_in_use_in_bytesqui indique l'utilisation réelle de la base de données après un compactage de l'historique
etcd_mvcc_db_total_size_in_bytesqui indique la taille de la base de données, y compris l'espace libre en attente de défragmentation

Défragmenter les données etcd pour récupérer de l'espace disque après des événements qui provoquent la fragmentation du disque, comme le compactage de l'historique etcd.

Le compactage de l'historique est effectué automatiquement toutes les cinq minutes et laisse des trous dans la base de données back-end. Cet espace fragmenté peut être utilisé par etcd, mais n'est pas disponible pour le système de fichiers hôte. Vous devez défragmenter etcd pour rendre cet espace disponible au système de fichiers hôte.

La défragmentation se produit automatiquement, mais vous pouvez également la déclencher manuellement.

Note

La défragmentation automatique est une bonne chose dans la plupart des cas, car l'opérateur etcd utilise les informations sur les clusters pour déterminer l'opération la plus efficace pour l'utilisateur.

6.14.5.1. Défragmentation automatique

L'opérateur etcd défragmente automatiquement les disques. Aucune intervention manuelle n'est nécessaire.

Vérifiez que le processus de défragmentation s'est déroulé correctement en consultant l'un de ces journaux :

journaux etcd
cluster-etcd-operator pod
statut de l'opérateur journal des erreurs

Avertissement

La défragmentation automatique peut provoquer une défaillance de l'élection du leader dans divers composants de base d'OpenShift, tels que le gestionnaire de contrôleur Kubernetes, ce qui déclenche un redémarrage du composant défaillant. Le redémarrage est inoffensif et déclenche le basculement vers la prochaine instance en cours d'exécution ou le composant reprend le travail après le redémarrage.

Exemple de sortie de journal pour une défragmentation réussie

le membre etcd a été défragmenté : <member_name>, memberID : <member_id>

Exemple de sortie de journal pour une défragmentation infructueuse

échec de la défragmentation sur le membre : <member_name>, memberID : <member_id>: <error_message>

6.14.5.2. Défragmentation manuelle

Une alerte Prometheus vous indique si vous devez utiliser la défragmentation manuelle. L'alerte s'affiche dans deux cas :

Lorsque etcd utilise plus de 50 % de son espace disponible pendant plus de 10 minutes
Lorsque etcd utilise activement moins de 50 % de la taille totale de sa base de données pendant plus de 10 minutes

Vous pouvez également déterminer si une défragmentation est nécessaire en vérifiant la taille de la base de données etcd en Mo qui sera libérée par la défragmentation avec l'expression PromQL : (etcd_mvcc_db_total_size_in_bytes - etcd_mvcc_db_total_size_in_use_in_bytes)/1024/1024

Avertissement

La défragmentation de etcd est une action bloquante. Le membre etcd ne répondra pas tant que la défragmentation ne sera pas terminée. Pour cette raison, attendez au moins une minute entre les actions de défragmentation sur chacun des pods pour permettre au cluster de récupérer.

Suivez cette procédure pour défragmenter les données etcd sur chaque membre etcd.

Conditions préalables

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

Procédure

Déterminer quel membre etcd est le leader, car le leader doit être défragmenté en dernier.

Obtenir la liste des pods etcd :

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

Exemple de sortie

etcd-ip-10-0-159-225.example.redhat.com                3/3     Running     0          175m   10.0.159.225   ip-10-0-159-225.example.redhat.com   <none>           <none>
etcd-ip-10-0-191-37.example.redhat.com                 3/3     Running     0          173m   10.0.191.37    ip-10-0-191-37.example.redhat.com    <none>           <none>
etcd-ip-10-0-199-170.example.redhat.com                3/3     Running     0          176m   10.0.199.170   ip-10-0-199-170.example.redhat.com   <none>           <none>

Choisissez un pod et exécutez la commande suivante pour déterminer quel membre etcd est le leader :

$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table

Exemple de sortie

Defaulting container name to etcdctl.
Use 'oc describe pod/etcd-ip-10-0-159-225.example.redhat.com -n openshift-etcd' to see all of the containers in this pod.
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

D'après la colonne IS LEADER de cette sortie, le point d'extrémité https://10.0.199.170:2379 est le leader. En faisant correspondre ce point d'extrémité avec la sortie de l'étape précédente, le nom de pod du leader est etcd-ip-10-0-199-170.example.redhat.com.

Défragmenter un membre etcd.

Se connecter au conteneur etcd en cours d'exécution, en indiquant le nom d'un pod qui est not le leader :
```
$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
```
Désactivez la variable d'environnement ETCDCTL_ENDPOINTS:
```
sh-4.4# unset ETCDCTL_ENDPOINTS
```
Défragmenter le membre etcd :
```
sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
```
Exemple de sortie
```
Finished defragmenting etcd member[https://localhost:2379]
```
En cas d'erreur de temporisation, augmentez la valeur de --command-timeout jusqu'à ce que la commande réussisse.

Vérifiez que la taille de la base de données a été réduite :

sh-4.4# etcdctl endpoint status -w table --cluster

Exemple de sortie

+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|  https://10.0.191.37:2379 | 251cd44483d811c3 |   3.4.9 |  104 MB |     false |      false |         7 |      91624 |              91624 |        |
| https://10.0.159.225:2379 | 264c7c58ecbdabee |   3.4.9 |   41 MB |     false |      false |         7 |      91624 |              91624 |        | 1
| https://10.0.199.170:2379 | 9ac311f93915cc79 |   3.4.9 |  104 MB |      true |      false |         7 |      91624 |              91624 |        |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

Cet exemple montre que la taille de la base de données pour ce membre etcd est maintenant de 41 Mo, alors qu'elle était de 104 Mo au départ.

Répétez ces étapes pour vous connecter à chacun des autres membres etcd et les défragmenter. Défragmentez toujours le leader en dernier.
Attendez au moins une minute entre les actions de défragmentation pour permettre au pod etcd de se rétablir. Tant que le pod etcd n'est pas rétabli, le membre etcd ne répond pas.

Si des alarmes NOSPACE ont été déclenchées en raison du dépassement du quota d'espace, effacez-les.
1. Vérifiez s'il y a des alarmes sur NOSPACE:
```
sh-4.4# etcdctl alarm list
```
  Exemple de sortie
```
memberID:12345678912345678912 alarm:NOSPACE
```
2. Effacer les alarmes :
```
sh-4.4# etcdctl alarm disarm
```

Prochaines étapes

Après la défragmentation, si etcd utilise toujours plus de 50 % de son espace disponible, envisagez d'augmenter le quota de disque pour etcd.

6.14.6. Rétablissement d'un état antérieur de la grappe

Vous pouvez utiliser une sauvegarde etcd enregistrée pour restaurer un état antérieur du cluster ou restaurer un cluster qui a perdu la majorité des hôtes du plan de contrôle.

Note

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

Important

Lorsque vous restaurez votre cluster, vous devez utiliser une sauvegarde etcd provenant de la même version de z-stream. Par exemple, un cluster OpenShift Container Platform 4.7.2 doit utiliser une sauvegarde etcd provenant de la version 4.7.2.

Conditions préalables

Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
Un hôte de plan de contrôle sain à utiliser comme hôte de reprise.
Accès SSH aux hôtes du plan de contrôle.
Un répertoire de sauvegarde contenant à la fois l'instantané etcd et les ressources pour les pods statiques, qui proviennent de la même sauvegarde. Les noms de fichiers dans le répertoire doivent être dans les formats suivants : snapshot_<datetimestamp>.db et static_kuberesources_<datetimestamp>.tar.gz.

Important

Pour les nœuds de plan de contrôle sans récupération, il n'est pas nécessaire d'établir une connectivité SSH ou d'arrêter les pods statiques. Vous pouvez supprimer et recréer d'autres machines de plan de contrôle sans récupération, une par une.

Procédure

Sélectionnez un hôte du plan de contrôle à utiliser comme hôte de restauration. Il s'agit de l'hôte sur lequel vous exécuterez l'opération de restauration.
Établir une connectivité SSH avec chacun des nœuds du plan de contrôle, y compris l'hôte de reprise.
Le serveur API Kubernetes devient inaccessible après le démarrage du processus de restauration, de sorte que vous ne pouvez pas accéder aux nœuds du plan de contrôle. Pour cette raison, il est recommandé d'établir une connectivité SSH à chaque hôte du plan de contrôle dans un terminal séparé.
Important
Si vous n'effectuez pas cette étape, vous ne pourrez pas accéder aux hôtes du plan de contrôle pour terminer la procédure de restauration, et vous ne pourrez pas récupérer votre cluster à partir de cet état.
Copiez le répertoire de sauvegarde etcd sur l'hôte du plan de contrôle de reprise.
Cette procédure suppose que vous avez copié le répertoire backup contenant le snapshot etcd et les ressources pour les pods statiques dans le répertoire /home/core/ de votre hôte de plan de contrôle de récupération.
Arrêtez les pods statiques sur tous les autres nœuds du plan de contrôle.
Note
Il n'est pas nécessaire d'arrêter manuellement les pods sur l'hôte de récupération. Le script de récupération arrêtera les pods sur l'hôte de récupération.
1. Accéder à un hôte du plan de contrôle qui n'est pas l'hôte de reprise.
2. Déplacer le fichier pod etcd existant hors du répertoire kubelet manifest :
```
$ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp
```
3. Vérifiez que les pods etcd sont arrêtés.
```
$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
```
  La sortie de cette commande doit être vide. Si ce n'est pas le cas, attendez quelques minutes et vérifiez à nouveau.
4. Déplacez le fichier pod du serveur API Kubernetes existant hors du répertoire kubelet manifest :
```
$ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
```
5. Vérifiez que les pods du serveur API Kubernetes sont arrêtés.
```
$ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"
```
  La sortie de cette commande doit être vide. Si ce n'est pas le cas, attendez quelques minutes et vérifiez à nouveau.
6. Déplacez le répertoire de données etcd vers un autre emplacement :
```
$ sudo mv /var/lib/etcd/ /tmp
```
7. Répétez cette étape sur chacun des autres hôtes du plan de contrôle qui n'est pas l'hôte de reprise.
Accéder à l'hôte du plan de contrôle de récupération.
Si le proxy à l'échelle du cluster est activé, assurez-vous que vous avez exporté les variables d'environnement NO_PROXY, HTTP_PROXY, et HTTPS_PROXY.
Astuce
Vous pouvez vérifier si le proxy est activé en examinant la sortie de oc get proxy cluster -o yaml. Le proxy est activé si les champs httpProxy, httpsProxy et noProxy ont des valeurs définies.

Exécutez le script de restauration sur l'hôte du plan de contrôle de récupération et indiquez le chemin d'accès au répertoire de sauvegarde etcd :

$ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup

Exemple de sortie de script

...stopping kube-scheduler-pod.yaml
...stopping kube-controller-manager-pod.yaml
...stopping etcd-pod.yaml
...stopping kube-apiserver-pod.yaml
Waiting for container etcd to stop
.complete
Waiting for container etcdctl to stop
.............................complete
Waiting for container etcd-metrics to stop
complete
Waiting for container kube-controller-manager to stop
complete
Waiting for container kube-apiserver to stop
..........................................................................................complete
Waiting for container kube-scheduler to stop
complete
Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup
starting restore-etcd static pod
starting kube-apiserver-pod.yaml
static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml
starting kube-controller-manager-pod.yaml
static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml
starting kube-scheduler-pod.yaml
static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml

Note

Le processus de restauration peut entraîner l'entrée des nœuds dans l'état NotReady si les certificats des nœuds ont été mis à jour après la dernière sauvegarde etcd.

Vérifiez que les nœuds sont dans l'état Ready.

Exécutez la commande suivante :

$ oc get nodes -w

Exemple de sortie

NAME                STATUS  ROLES          AGE     VERSION
host-172-25-75-28   Ready   master         3d20h   v1.25.0
host-172-25-75-38   Ready   infra,worker   3d20h   v1.25.0
host-172-25-75-40   Ready   master         3d20h   v1.25.0
host-172-25-75-65   Ready   master         3d20h   v1.25.0
host-172-25-75-74   Ready   infra,worker   3d20h   v1.25.0
host-172-25-75-79   Ready   worker         3d20h   v1.25.0
host-172-25-75-86   Ready   worker         3d20h   v1.25.0
host-172-25-75-98   Ready   infra,worker   3d20h   v1.25.0

Il peut s'écouler plusieurs minutes avant que tous les nœuds ne communiquent leur état.

Si des nœuds sont dans l'état NotReady, connectez-vous aux nœuds et supprimez tous les fichiers PEM du répertoire /var/lib/kubelet/pki sur chaque nœud. Vous pouvez vous connecter aux nœuds par SSH ou utiliser la fenêtre de terminal de la console web.
```
$  ssh -i <ssh-key-path> core@<master-hostname>
```
Exemple de répertoire pki
```
sh-4.4# pwd
/var/lib/kubelet/pki
sh-4.4# ls
kubelet-client-2022-04-28-11-24-09.pem  kubelet-server-2022-04-28-11-24-15.pem
kubelet-client-current.pem              kubelet-server-current.pem
```

Redémarrer le service kubelet sur tous les hôtes du plan de contrôle.
1. À partir de l'hôte de récupération, exécutez la commande suivante :
```
$ sudo systemctl restart kubelet.service
```
2. Répétez cette étape sur tous les autres hôtes du plan de contrôle.

Approuver les RSC en attente :

Note

Les clusters sans nœuds de travail, tels que les clusters à un seul nœud ou les clusters composés de trois nœuds de plan de contrôle ordonnançables, n'auront pas de CSR en attente à approuver. Dans ce cas, vous pouvez ignorer cette étape.

Obtenir la liste des CSR actuels :

$ oc get csr

Exemple de sortie

NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 1
csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 2
csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 3
csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 4
...

1 1 2: Un CSR de service kubelet en attente (pour les installations fournies par l'utilisateur).
3 4: Un CSR node-bootstrapper en attente.

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 CSR node-bootstrapper valide :
```
$ oc adm certificate approve <csr_name>
```
Pour les installations fournies par l'utilisateur, approuver chaque CSR de service kubelet valide :
```
$ oc adm certificate approve <csr_name>
```

Vérifiez que le plan de contrôle à membre unique a bien démarré.
1. Depuis l'hôte de récupération, vérifiez que le conteneur etcd est en cours d'exécution.
```
$ sudo crictl ps | grep etcd | grep -v operator
```
  Exemple de sortie
```
3ad41b7908e32       36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009                                                         About a minute ago   Running             etcd                                          0                   7c05f8af362f0
```
2. Depuis l'hôte de récupération, vérifiez que le pod etcd est en cours d'exécution.
```
$ oc -n openshift-etcd get pods -l k8s-app=etcd
```
  Note
  Si vous essayez d'exécuter oc login avant d'exécuter cette commande et que vous recevez l'erreur suivante, attendez quelques instants pour que les contrôleurs d'authentification démarrent et réessayez.
  Unable to connect to the server: EOF
  Exemple de sortie
```
NAME                                             READY   STATUS      RESTARTS   AGE
etcd-ip-10-0-143-125.ec2.internal                1/1     Running     1          2m47s
```
  Si l'état est Pending, ou si la sortie indique plus d'un pod etcd en cours d'exécution, attendez quelques minutes et vérifiez à nouveau.
Note
N'effectuez l'étape suivante que si vous utilisez le plugin réseau OVNKubernetes.
Supprimer les objets nœuds associés aux hôtes du plan de contrôle qui ne sont pas l'hôte du plan de contrôle de reprise.
```
oc delete node <non-recovery-controlplane-host-1> <non-recovery-controlplane-host-2>
```
Vérifier que le Cluster Network Operator (CNO) redéploie le plan de contrôle OVN-Kubernetes et qu'il ne référence plus les mauvaises adresses IP des contrôleurs. Pour vérifier ce résultat, vérifiez régulièrement la sortie de la commande suivante. Attendez qu'elle renvoie un résultat vide avant de passer à l'étape suivante.
```
$ oc -n openshift-ovn-kubernetes get ds/ovnkube-master -o yaml | grep -E '<wrong_master_ip_1>|<wrong_master_ip_2>'
```
Note
Cela peut prendre au moins 5 à 10 minutes pour que le plan de contrôle OVN-Kubernetes soit redéployé et que la commande précédente renvoie une sortie vide.
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.
Redémarrez les pods Kubernetes d'Open Virtual Network (OVN) sur tous les hôtes.
Note
Les webhooks de validation et de mutation des admissions peuvent rejeter les pods. Si vous ajoutez d'autres webhooks dont l'adresse failurePolicy est Fail, ils peuvent rejeter des pods et le processus de restauration peut échouer. Vous pouvez éviter cela en sauvegardant et en supprimant les webhooks lors de la restauration de l'état de la grappe. Une fois l'état du cluster restauré avec succès, vous pouvez réactiver les webhooks.
Vous pouvez également définir temporairement failurePolicy sur Ignore pendant la restauration de l'état de la grappe. Une fois l'état de la grappe restauré avec succès, vous pouvez définir failurePolicy sur Fail.
1. Supprimez la base de données en direction du nord (nbdb) et la base de données en direction du sud (sbdb). Accédez à l'hôte de reprise et aux nœuds de plan de contrôle restants à l'aide de Secure Shell (SSH) et exécutez la commande suivante :
```
$ sudo rm -f /var/lib/ovn/etc/*.db
```
2. Supprimez tous les pods du plan de contrôle OVN-Kubernetes en exécutant la commande suivante :
```
$ oc delete pods -l app=ovnkube-master -n openshift-ovn-kubernetes
```
3. Assurez-vous que tous les pods du plan de contrôle OVN-Kubernetes sont à nouveau déployés et sont dans un état Running en exécutant la commande suivante :
```
$ oc get pods -l app=ovnkube-master -n openshift-ovn-kubernetes
```
  Exemple de sortie
```
NAME                   READY   STATUS    RESTARTS   AGE
ovnkube-master-nb24h   4/4     Running   0          48s
ovnkube-master-rm8kw   4/4     Running   0          47s
ovnkube-master-zbqnh   4/4     Running   0          56s
```
4. Supprimez tous les pods ovnkube-node en exécutant la commande suivante :
```
$ oc get pods -n openshift-ovn-kubernetes -o name | grep ovnkube-node | while read p ; do oc delete $p -n openshift-ovn-kubernetes ; done
```
5. Assurez-vous que tous les pods ovnkube-node sont à nouveau déployés et sont dans un état Running en exécutant la commande suivante :
```
$ oc get  pods -n openshift-ovn-kubernetes | grep ovnkube-node
```

Supprimer et recréer les autres machines du plan de contrôle qui ne sont pas des machines de récupération, une par une. Une fois les machines recréées, une nouvelle révision est forcée et etcd passe automatiquement à l'échelle supérieure.

Si vous utilisez une installation bare metal fournie par l'utilisateur, vous pouvez recréer une machine de plan de contrôle en utilisant la même méthode que celle utilisée pour la créer à l'origine. Pour plus d'informations, voir "Installation d'un cluster fourni par l'utilisateur sur bare metal".
Avertissement
Ne supprimez pas et ne recréez pas la machine pour l'hôte de récupération.

Si vous utilisez une infrastructure fournie par l'installateur ou si vous avez utilisé l'API Machine pour créer vos machines, procédez comme suit :

Avertissement

Ne supprimez pas et ne recréez pas la machine pour l'hôte de récupération.

Pour les installations bare metal sur une infrastructure fournie par l'installateur, les machines du plan de contrôle ne sont pas recréées. Pour plus d'informations, voir "Remplacement d'un nœud de plan de contrôle bare-metal".

Obtenir la machine de l'un des hôtes du plan de contrôle perdus.

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-143-125.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-154-194.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 de l'hôte du plan de contrôle perdu, ip-10-0-131-183.ec2.internal.

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 l'hôte du plan de contrôle perdu.

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

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

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:
```
apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
  ...
  name: clustername-8qw5l-master-3
  ...
```

Supprimer le champ spec.providerID:

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

Supprimer les champs metadata.annotations et metadata.generation:

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

Supprimer les champs metadata.resourceVersion et metadata.uid:

resourceVersion: "13291"
uid: a282eb70-40a2-4e89-8009-d05dd420d31a

Supprimer la machine de l'hôte du plan de contrôle perdu :
```
oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1
```
1
Indiquez le nom de la machine du plan de contrôle pour l'hôte du plan de contrôle perdu.

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-143-125.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-154-194.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

Créez une machine en utilisant le fichier new-master-machine.yaml:
```
$ oc apply -f new-master-machine.yaml
```

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-143-125.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-154-194.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-173-171.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 après le changement de phase 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.

Répétez ces étapes pour chaque hôte du plan de contrôle perdu qui n'est pas l'hôte de récupération.

Dans une fenêtre de terminal séparée, connectez-vous au cluster en tant qu'utilisateur ayant le rôle cluster-admin en entrant la commande suivante :
```
$ oc login -u <cluster_admin> 1
```
1
Pour <cluster_admin>, indiquez un nom d'utilisateur avec le rôle cluster-admin.
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-"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é.
Lorsque l'opérateur du cluster etcd effectue un redéploiement, les nœuds existants sont démarrés avec de nouveaux pods, comme lors de la mise à l'échelle initiale.

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

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

Vous pouvez vérifier que la section unsupportedConfigOverrides est supprimée de l'objet en entrant cette commande :
```
$ oc get etcd/cluster -oyaml
```
Vérifier que tous les nœuds sont mis à jour avec la dernière révision.
Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez la commande suivante :
```
$ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
```
Examinez la condition d'état NodeInstallerProgressing pour etcd afin de vérifier que tous les nœuds sont à la dernière révision. La sortie indique AllNodesAtLatestRevision lorsque la mise à jour est réussie :
```
AllNodesAtLatestRevision
3 nodes are at revision 7 1
```
1
Dans cet exemple, le dernier numéro de révision est 7.
Si le résultat comprend plusieurs numéros de révision, tels que 2 nodes are at revision 6; 1 nodes are at revision 7, cela signifie que la mise à jour est toujours en cours. Attendez quelques minutes et réessayez.
Une fois etcd redéployé, forcez de nouveaux déploiements pour le plan de contrôle. Le serveur API Kubernetes se réinstallera sur les autres nœuds car le kubelet est connecté aux serveurs API à l'aide d'un équilibreur de charge interne.
Dans un terminal ayant accès au cluster en tant qu'utilisateur cluster-admin, exécutez les commandes suivantes.
1. Forcer un nouveau déploiement pour le serveur API Kubernetes :
```
$ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
```
  Vérifier que tous les nœuds sont mis à jour avec la dernière révision.
```
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
```
  Examinez l'état de NodeInstallerProgressing pour vérifier que tous les nœuds sont à la dernière révision. La sortie indique AllNodesAtLatestRevision lorsque la mise à jour est réussie :
```
AllNodesAtLatestRevision
3 nodes are at revision 7 1
```
  1
  Dans cet exemple, le dernier numéro de révision est 7.
  Si le résultat comprend plusieurs numéros de révision, tels que 2 nodes are at revision 6; 1 nodes are at revision 7, cela signifie que la mise à jour est toujours en cours. Attendez quelques minutes et réessayez.
2. Forcer un nouveau déploiement pour le gestionnaire de contrôleur Kubernetes :
```
$ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
```
  Vérifier que tous les nœuds sont mis à jour avec la dernière révision.
```
$ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
```
  Examinez l'état de NodeInstallerProgressing pour vérifier que tous les nœuds sont à la dernière révision. La sortie indique AllNodesAtLatestRevision lorsque la mise à jour est réussie :
```
AllNodesAtLatestRevision
3 nodes are at revision 7 1
```
  1
  Dans cet exemple, le dernier numéro de révision est 7.
  Si le résultat comprend plusieurs numéros de révision, tels que 2 nodes are at revision 6; 1 nodes are at revision 7, cela signifie que la mise à jour est toujours en cours. Attendez quelques minutes et réessayez.
3. Forcer un nouveau déploiement pour le planificateur Kubernetes :
```
$ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge
```
  Vérifier que tous les nœuds sont mis à jour avec la dernière révision.
```
$ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
```
  Examinez l'état de NodeInstallerProgressing pour vérifier que tous les nœuds sont à la dernière révision. La sortie indique AllNodesAtLatestRevision lorsque la mise à jour est réussie :
```
AllNodesAtLatestRevision
3 nodes are at revision 7 1
```
  1
  Dans cet exemple, le dernier numéro de révision est 7.
  Si le résultat comprend plusieurs numéros de révision, tels que 2 nodes are at revision 6; 1 nodes are at revision 7, cela signifie que la mise à jour est toujours en cours. Attendez quelques minutes et réessayez.

Vérifiez que tous les hôtes du plan de contrôle ont démarré et rejoint le cluster.

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-143-125.ec2.internal                2/2     Running     0          9h
etcd-ip-10-0-154-194.ec2.internal                2/2     Running     0          9h
etcd-ip-10-0-173-171.ec2.internal                2/2     Running     0          9h

Pour s'assurer que toutes les charges de travail reviennent à un fonctionnement normal à la suite d'une procédure de récupération, redémarrez chaque pod qui stocke les informations de l'API Kubernetes. Cela inclut les composants d'OpenShift Container Platform tels que les routeurs, les opérateurs et les composants tiers.

Notez que la restauration de tous les services peut prendre plusieurs minutes après l'exécution de cette procédure. Par exemple, l'authentification à l'aide de oc login peut ne pas fonctionner immédiatement jusqu'à ce que les pods du serveur OAuth soient redémarrés.

Ressources supplémentaires

6.14.7. Problèmes et solutions de contournement pour la restauration d'un état de stockage persistant

Si votre cluster OpenShift Container Platform utilise un stockage persistant sous quelque forme que ce soit, un état du cluster est généralement stocké en dehors d'etcd. Il peut s'agir d'un cluster Elasticsearch fonctionnant dans un pod ou d'une base de données fonctionnant dans un objet StatefulSet. Lorsque vous restaurez à partir d'une sauvegarde etcd, l'état des charges de travail dans OpenShift Container Platform est également restauré. Cependant, si le snapshot etcd est ancien, l'état peut être invalide ou obsolète.

Important

Le contenu des volumes persistants (PV) ne fait jamais partie de l'instantané etcd. Lorsque vous restaurez un cluster OpenShift Container Platform à partir d'un instantané etcd, les charges de travail non critiques peuvent avoir accès aux données critiques, et vice-versa.

Voici quelques exemples de scénarios qui produisent un état périmé :

La base de données MySQL s'exécute dans un pod sauvegardé par un objet PV. La restauration d'OpenShift Container Platform à partir d'un snapshot etcd ne rétablit pas le volume sur le fournisseur de stockage et ne produit pas de pod MySQL en cours d'exécution, malgré les tentatives répétées de démarrage du pod. Vous devez restaurer manuellement ce pod en restaurant le volume sur le fournisseur de stockage, puis en modifiant le PV pour qu'il pointe vers le nouveau volume.
Le pod P1 utilise le volume A, qui est attaché au nœud X. Si l'instantané etcd est pris alors qu'un autre pod utilise le même volume sur le nœud Y, alors lorsque la restauration etcd est effectuée, le pod P1 pourrait ne pas être en mesure de démarrer correctement en raison du fait que le volume est toujours attaché au nœud Y. OpenShift Container Platform n'est pas conscient de l'attachement et ne le détache pas automatiquement. Lorsque cela se produit, le volume doit être détaché manuellement du nœud Y afin que le volume puisse s'attacher au nœud X, puis le pod P1 peut démarrer.
Les informations d'identification du fournisseur de cloud ou du fournisseur de stockage ont été mises à jour après que l'instantané etcd a été pris. Par conséquent, les pilotes ou opérateurs CSI qui dépendent de ces informations d'identification ne fonctionnent pas. Il se peut que vous deviez mettre à jour manuellement les informations d'identification requises par ces pilotes ou opérateurs.
Un périphérique est supprimé ou renommé à partir des nœuds OpenShift Container Platform après que l'instantané etcd a été pris. L'opérateur de stockage local crée des liens symboliques pour chaque PV qu'il gère à partir des répertoires /dev/disk/by-id ou /dev. Cette situation peut amener les PV locaux à faire référence à des périphériques qui n'existent plus.
Pour résoudre ce problème, l'administrateur doit
1. Supprimer manuellement les PV dont les dispositifs ne sont pas valides.
2. Supprimer les liens symboliques des nœuds respectifs.
3. Supprimer les objets LocalVolume ou LocalVolumeSet (voir Storage Configuring persistent storage Persistent storage using local volumes Deleting the Local Storage Operator Resources).

6.14. tâches etcd

6.14.1. À propos du chiffrement d'etcd

6.14.2. Activation du chiffrement d'etcd

6.14.3. Désactiver le chiffrement d'etcd

6.14.4. Sauvegarde des données etcd

6.14.5. Défragmentation des données etcd

6.14.5.1. Défragmentation automatique

6.14.5.2. Défragmentation manuelle

6.14.6. Rétablissement d'un état antérieur de la grappe

6.14.7. Problèmes et solutions de contournement pour la restauration d'un état de stockage persistant

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links