Chapitre 5. Sauvegarde et restauration du plan de contrôle
5.1. Sauvegarde de etcd
etcd est le magasin clé-valeur d'OpenShift Container Platform, qui conserve l'état de tous les objets de ressources.
Sauvegardez régulièrement les données etcd de votre cluster et stockez-les dans un endroit sûr, idéalement en dehors de l'environnement OpenShift Container Platform. Ne prenez pas de sauvegarde etcd avant la fin de la première rotation des certificats, qui a lieu 24 heures après l'installation, sinon la sauvegarde contiendra des certificats expirés. Il est également recommandé d'effectuer des sauvegardes etcd en dehors des heures de pointe, car l'instantané etcd a un coût d'E/S élevé.
Veillez à effectuer une sauvegarde etcd après avoir mis à niveau votre cluster. Ceci est important car lorsque vous restaurez votre cluster, vous devez utiliser une sauvegarde etcd qui a été prise à partir de la même version de z-stream. Par exemple, un cluster OpenShift Container Platform 4.y.z doit utiliser une sauvegarde etcd provenant de la version 4.y.z.
Sauvegardez les données etcd de votre cluster en effectuant une seule invocation du script de sauvegarde sur un hôte du plan de contrôle. Ne faites pas de sauvegarde pour chaque hôte du plan de contrôle.
Après avoir effectué une sauvegarde d'etcd, vous pouvez restaurer un état antérieur du cluster.
5.1.1. 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.
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é.
AstuceVous 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 champshttpProxy,httpsProxyetnoProxyont 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, etHTTPS_PROXY. Exécutez le script
cluster-backup.shet indiquez l'emplacement où sauvegarder la sauvegarde.AstuceLe script
cluster-backup.shest maintenu en tant que composant de l'opérateur de cluster etcd et est une enveloppe autour de la commandeetcdctl 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/backupDans 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 scriptcluster-backup.shconfirme 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.NoteSi 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.
-
