Aide-mémoire etcd : backup, restauration et maintenance pour un cluster Kubernetes

etcd est la base de données clé-valeur distribuée qui stocke l'ensemble de l'état d'un cluster Kubernetes. Le backup restauration etcd Kubernetes constitue une compétence critique pour tout administrateur système Kubernetes. Sans sauvegarde etcd fonctionnelle, une corruption ou perte de données signifie la reconstruction complète du cluster.

TL;DR : etcd stocke 100% de l'état Kubernetes. Snapshot quotidien minimum. Testez vos restaurations en staging. Utilisez etcdctl snapshot save avec ETCDCTL_API=3.

La maîtrise d'etcd est couverte dans la formation LFS458 Administration Kubernetes.

---

Commandes etcdctl essentielles

Variables d'environnement requises

export ETCDCTL_API=3
export ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.crt
export ETCDCTL_CERT=/etc/kubernetes/pki/etcd/server.crt
export ETCDCTL_KEY=/etc/kubernetes/pki/etcd/server.key
export ETCDCTL_ENDPOINTS=https://127.0.0.1:2379

À retenir : Toujours définir ETCDCTL_API=3. L'API v2 est dépréciée et incompatible avec Kubernetes 1.24+.

---

Backup etcd : procédure complète

Snapshot manuel

# Créer un snapshot
etcdctl snapshot save /backup/etcd-$(date +%Y%m%d-%H%M%S).db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Vérifier l'intégrité
etcdctl snapshot status /backup/etcd-20260228-143000.db --write-out=table

Output attendu :

+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| 3c5e8d2a |   284519 |       1847 |     5.2 MB |
+----------+----------+------------+------------+

Cronjob de sauvegarde etcd Kubernetes

apiVersion: batch/v1
kind: CronJob
metadata:
  name: etcd-backup
  namespace: kube-system
spec:
  schedule: "0 */6 * * *"  # Toutes les 6 heures
  jobTemplate:
    spec:
      template:
        spec:
          hostNetwork: true
          containers:
          - name: backup
            image: registry.k8s.io/etcd:3.5.12-0
            command:
            - /bin/sh
            - -c
            - |
              etcdctl snapshot save /backup/etcd-$(date +%Y%m%d-%H%M%S).db
              find /backup -mtime +7 -delete
            env:
            - name: ETCDCTL_API
              value: "3"
            volumeMounts:
            - name: etcd-certs
              mountPath: /etc/kubernetes/pki/etcd
              readOnly: true
            - name: backup
              mountPath: /backup
          volumes:
          - name: etcd-certs
            hostPath:
              path: /etc/kubernetes/pki/etcd
          - name: backup
            hostPath:
              path: /var/backup/etcd
          restartPolicy: OnFailure
          nodeSelector:
            node-role.kubernetes.io/control-plane: ""
          tolerations:
          - key: node-role.kubernetes.io/control-plane
            effect: NoSchedule

Selon le CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent Kubernetes en production. Une stratégie de sauvegarde etcd cluster Kubernetes robuste est indispensable.

---

Restauration etcd : procédure pas à pas

Étape 1 : Arrêter les composants control plane

# Sur chaque control plane node
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/
sudo mv /etc/kubernetes/manifests/kube-controller-manager.yaml /tmp/
sudo mv /etc/kubernetes/manifests/kube-scheduler.yaml /tmp/
sudo mv /etc/kubernetes/manifests/etcd.yaml /tmp/

# Vérifier l'arrêt
sudo crictl ps | grep -E "etcd|kube-api"

Étape 2 : Restaurer le snapshot

# Supprimer les données etcd existantes
sudo rm -rf /var/lib/etcd

# Restaurer vers un nouveau répertoire
etcdctl snapshot restore /backup/etcd-20260228-143000.db \
  --data-dir=/var/lib/etcd \
  --name=control-plane-1 \
  --initial-cluster=control-plane-1=https://192.168.1.10:2380 \
  --initial-advertise-peer-urls=https://192.168.1.10:2380

# Corriger les permissions
sudo chown -R etcd:etcd /var/lib/etcd

Étape 3 : Redémarrer les composants

# Restaurer les manifests
sudo mv /tmp/etcd.yaml /etc/kubernetes/manifests/
sudo mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/
sudo mv /tmp/kube-controller-manager.yaml /etc/kubernetes/manifests/
sudo mv /tmp/kube-scheduler.yaml /etc/kubernetes/manifests/

# Vérifier le cluster
kubectl get nodes
kubectl get pods -A

À retenir : Testez la restauration en staging avant la production. Le processus etcd snapshot restore Kubernetes modifie les identifiants de cluster.

Pour approfondir ces procédures critiques, consultez la formation LFS458 Administration Kubernetes qui prépare à la certification CKA.

---

Maintenance etcd : commandes de diagnostic

Vérification de santé

# Santé de tous les endpoints
etcdctl endpoint health --cluster
# Output: https://192.168.1.10:2379 is healthy: successfully committed proposal

# Statut détaillé
etcdctl endpoint status --cluster --write-out=table

Output attendu :

+---------------------------+------------------+---------+---------+-----------+
|         ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER |
+---------------------------+------------------+---------+---------+-----------+
| https://192.168.1.10:2379 | 8e9e05c52164694d |  3.5.12 |   5.2MB |      true |
| https://192.168.1.11:2379 | 2d3c8a5e7b1f4c92 |  3.5.12 |   5.2MB |     false |
| https://192.168.1.12:2379 | 4f6d9c8b2a1e3d70 |  3.5.12 |   5.2MB |     false |
+---------------------------+------------------+---------+---------+-----------+

Défragmentation (maintenance régulière)

# Vérifier l'utilisation disque avant
etcdctl endpoint status --write-out=table

# Défragmenter (un membre à la fois)
etcdctl defrag --endpoints=https://192.168.1.10:2379

# Vérifier après
etcdctl endpoint status --write-out=table

Compaction de l'historique

# Obtenir la révision actuelle
rev=$(etcdctl endpoint status --write-out="json" | jq -r '.[0].Status.header.revision')

# Compacter jusqu'à cette révision
etcdctl compact $rev

# Défragmenter après compaction
etcdctl defrag --endpoints=https://192.168.1.10:2379

---

Erreurs fréquentes et solutions

À retenir : Le quorum etcd nécessite (n/2)+1 membres. Un cluster de 3 nœuds tolère 1 panne. Un cluster de 5 nœuds tolère 2 pannes.

---

Checklist backup/restore pour l'administrateur système Kubernetes certification CKS

# ✅ AVANT backup
etcdctl endpoint health --cluster
etcdctl endpoint status --cluster --write-out=table

# ✅ BACKUP
etcdctl snapshot save /backup/etcd-$(date +%Y%m%d).db
etcdctl snapshot status /backup/etcd-*.db --write-out=table

# ✅ VALIDATION
ls -la /backup/etcd-*.db
etcdctl snapshot status <file> | grep "TOTAL KEYS"

# ✅ RESTORE (test en staging)
etcdctl snapshot restore <file> --data-dir=/tmp/etcd-test
ls -la /tmp/etcd-test/member/

# ✅ APRÈS restore
kubectl get nodes
kubectl get pods -A
kubectl get cs

Selon la Linux Foundation, la certification CKA requiert un score de 66% et dure 2 heures. Les opérations etcd représentent une partie significative de l'examen.

---

Ressources complémentaires

Pour aller plus loin dans l'Administration cluster Kubernetes, consultez :

• Aide-mémoire kubectl : commandes essentielles pour l'administration de clusters Kubernetes
• Guide complet : installer un cluster Kubernetes multi-nœuds avec kubeadm
• Formation Administration cluster Kubernetes à Paris
• Carte thématique Formation Kubernetes
• Formation Kubernetes : Guide Complet

---

Prochaines étapes : certifications et formation

Selon le CNCF Training Report, plus de 104 000 professionnels ont passé l'examen CKA (croissance de 49% en un an). La maîtrise d'etcd est essentielle pour l'ingénieur infrastructure Kubernetes certification CKS.

Formations recommandées :. Pour approfondir, consultez notre formation administration cluster kubernetes bordeaux.

Contactez nos conseillers pour planifier votre parcours de certification Kubernetes.