etcd stocke la totalité de l’état d’un cluster Kubernetes : chaque objet, chaque Secret, chaque ConfigMap, chaque décision du scheduler y transite avant d’exister ailleurs. C’est le composant le plus critique du plan de contrôle et, paradoxalement, celui dont on se préoccupe le moins, parce qu’il fonctionne silencieusement jusqu’au jour où il ne fonctionne plus.

Ce qui dépend réellement d’etcd

Le serveur API Kubernetes ne fait que lire et écrire dans etcd : toute création, modification ou suppression d’objet passe par une écriture etcd avant d’être considérée effective. Un etcd inaccessible ne fait pas planter les pods déjà en cours d’exécution (le kubelet continue de faire tourner ce qu’il connaît déjà), mais bloque tout ce qui dépend d’une écriture : aucun nouveau déploiement, aucune mise à l’échelle, aucune réconciliation d’un contrôleur qui a besoin de lire l’état courant. Un cluster avec etcd en panne paraît vivant en surface tout en étant figé en profondeur.

# Vérifier la santé du cluster etcd directement,
# pas seulement celle du serveur API qui le masque en partie
etcdctl endpoint health --cluster

La latence disque, seule métrique qui compte vraiment

etcd utilise Raft (voir l’article sur le consensus Raft) pour répliquer chaque écriture sur une majorité de nœuds avant de la confirmer, ce qui implique un fsync disque à chaque écriture confirmée. Un disque lent (stockage réseau non dédié, SSD partagé avec d’autres charges) transforme cette exigence en goulot d’étranglement : la documentation etcd fixe un seuil de latence fsync autour de 10 ms au-delà duquel le cluster devient instable, avec des élections de leader intempestives qui n’ont aucun rapport avec une vraie panne réseau.

# La métrique qui prédit les problèmes avant qu'ils
# ne deviennent des élections de leader en cascade
etcd_disk_wal_fsync_duration_seconds

Un etcd hébergé sur un stockage réseau non garanti en IOPS, choix courant par simplicité d’infrastructure, est la cause la plus fréquente d’instabilité de plan de contrôle qui n’a jamais rien à voir avec Kubernetes lui-même.

La sauvegarde, jamais optionnelle

Une sauvegarde etcd (etcdctl snapshot save) capture l’état complet du cluster à un instant donné, la seule voie de restauration en cas de perte de quorum (majorité des nœuds etcd indisponibles simultanément, par exemple une panne de datacenter mal répartie). Une nuance mérite d’être exacte : ce qui est irrémédiablement perdu, c’est le quorum, pas nécessairement les données. Tant que le répertoire de données d’un membre survit, redémarrer ce membre avec --force-new-cluster écrase l’appartenance au cluster tout en conservant les données applicatives existantes. La documentation etcd décourage fortement cette manœuvre : elle panique si un membre du cluster précédent est encore vivant, et elle reconstruit un cluster à un seul nœud à partir d’un état dont rien ne garantit qu’il était à jour au moment de la panne. C’est une sortie de secours, pas un plan de restauration. En revanche, si plus aucun répertoire de données n’est exploitable, alors aucune commande ne reconstruit un état qui n’a jamais été capturé ailleurs.

# Sauvegarde régulière, à automatiser et à tester,
# pas à écrire une fois puis oublier
etcdctl snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db

# La vérification est une opération locale sur le fichier :
# elle passe par etcdutl. Dans etcdctl, "snapshot status"
# est déprécié en 3.5, puis retiré en 3.6.
etcdutl snapshot status /backup/etcd-snapshot-$(date +%Y%m%d).db

Une sauvegarde jamais restaurée en conditions réelles n’est qu’une hypothèse : la seule façon de savoir qu’une restauration fonctionne est de l’avoir déjà pratiquée, sur un cluster de test, avant d’en avoir besoin en urgence.

Le nombre de nœuds, un choix qui se fait une fois

Un cluster etcd à 3 nœuds tolère la perte d’un seul nœud sans perdre le quorum ; un cluster à 5 en tolère deux, au prix d’une réplication plus large et d’une latence d’écriture légèrement supérieure (plus de nœuds doivent confirmer chaque écriture). Le nombre pair n’apporte structurellement rien : 4 nœuds n’offrent aucune tolérance de panne supplémentaire par rapport à 3, tout en doublant le risque de blocage lors d’une partition réseau à 50/50, exactement le raisonnement détaillé dans l’article sur Raft.

À retenir

etcd porte tout l’état d’un cluster Kubernetes, mais son inaccessibilité ne tue pas les pods déjà en cours : elle gèle silencieusement tout ce qui dépend d’une nouvelle écriture, un symptôme facile à manquer avant qu’il ne s’aggrave. La latence disque (fsync) est la métrique qui prédit l’instabilité avant les élections de leader en cascade ; une sauvegarde jamais testée en restauration n’est qu’une hypothèse non vérifiée. Ces trois réflexes (surveiller la latence disque, sauvegarder et tester la restauration, choisir un nombre impair de nœuds) sont le socle silencieux sur lequel repose toute migration Kubernetes durable.