SupportConsoleDéveloppeursCommencer un essaiContact

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.

Important

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.

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

  1. Démarrer une session de débogage pour un nœud de plan de contrôle : 

    oc debug node/<node_name>

  2. Changez votre répertoire racine en /host: 

    sh-4.2# chroot /host
  3. 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.

  4. 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.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.