## Introduction

etcd est la base de données clé-valeur cohérente et hautement disponible qui alimente Kubernetes. Elle conserve l'intégralité de l'état du cluster, y compris chaque objet, configuration et secret. Un etcd sain est essentiel pour un cluster stable, et une mauvaise configuration ou une mise à niveau ratée peut entraîner l'indisponibilité de tout le plan de contrôle.

Cet article fournit un guide pratique des opérations etcd destiné aux développeurs, ingénieurs DevOps et équipes techniques gérant des clusters Kubernetes. Nous couvrirons les commandes et procédures essentielles pour inspecter, configurer, mettre à niveau et récupérer etcd en toute sécurité.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint.

Tout au long, remplacez toutes les valeurs d'espace réservé comme <nom-du-pod> ou <pod-etcd> par vos noms de pods réels. Pour un cluster kubeadm typique, le pod etcd s'exécute souvent comme un pod statique nommé `etcd-<nom-du-nœud-maître>` dans l'espace de noms `kube-system`.

## Comprendre etcd dans Kubernetes

Dans un cluster Kubernetes, etcd est la source de vérité pour le plan de contrôle. Le serveur d'API lit et écrit dans etcd, et chaque commande `kubectl` interagit finalement avec cette base clé-valeur. Par conséquent, les performances et la santé d'etcd impactent directement la réactivité du cluster.

etcd s'exécute généralement comme un pod statique géré par le kubelet sur chaque nœud du plan de contrôle. Dans une configuration hautement disponible, vous pouvez avoir un cluster etcd externe ou plusieurs membres etcd répartis sur les nœuds du plan de contrôle. Connaître votre topologie etcd est la première étape avant toute opération.

Concepts clés :

- **Pod statique** : un pod défini par un fichier YAML dans `/etc/kubernetes/manifests/` sur le nœud du plan de contrôle. Le kubelet le gère automatiquement.
- **Membre etcd** : une instance etcd unique. Un cluster se compose d'un nombre impair de membres (généralement 3 ou 5) pour le quorum.
- **Consensus Raft** : l'algorithme qu'etcd utilise pour maintenir un journal cohérent entre les membres. Une majorité (quorum) est requise pour les écritures.
- **Instantaneés** : sauvegardes cohérentes du répertoire de données etcd, utilisées pour la reprise après sinistre.

Comprendre ces bases vous aide à interpréter les commandes et à diagnostiquer les problèmes.

## Inventaire de version et d'environnement

Avant d'apporter des modifications, rassemblez des informations sur votre installation etcd. Cela inclut la version, la santé du cluster et la configuration.

### Vérifier la version d'etcd

Utilisez le binaire `etcdctl` à l'intérieur du conteneur ou du pod etcd.

```bash
# Exécuter dans le pod etcd (en supposant qu'il est dans kube-system)
kubectl exec -n kube-system etcd-nœud-maître -- etcdctl version
```

Exemple de sortie attendue :

```
etcdctl version: 3.5.10
API version: 3.5
```

Si vous êtes sur le nœud avec `etcdctl` installé localement, vous pouvez exécuter `etcdctl version` directement, mais assurez-vous d'avoir les bons certificats et le bon endpoint.

### Vérifier la santé du cluster

Listez les endpoints et vérifiez la santé de chaque membre.

```bash
# Sur le nœud du plan de contrôle, en utilisant etcdctl avec l'API v3 et les certificats peer
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  --key=/etc/kubernetes/pki/etcd/peer.key \
  endpoint health
```

Pour plus de commodité, vous pouvez définir des variables d'environnement ou utiliser un script d'encapsulation. Souvent, les configurations kubeadm ont déjà les certificats à ces chemins. Si etcdctl n'est pas disponible sur le nœud du plan de contrôle, exécutez-le à l'intérieur du conteneur etcd en utilisant `crictl run`, pas via `kubectl exec`. Ajustez l'endpoint si votre etcd écoute sur une adresse différente.

Sortie saine attendue :

```
https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 2.5ms
```

### Voir les membres du cluster

```bash
# Exécuter sur le nœud du plan de contrôle avec l'API v3
ETCDCTL_API=3 etcdctl --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 \
  member list
```

La sortie pourrait ressembler à :

```
8211f1d0a64f3269, started, nœud-maître, https://192.168.1.10:2380, https://192.168.1.10:2379, false
```

Cela montre l'ID du membre, le statut, le nom, l'adresse peer, l'adresse client et s'il s'agit d'un apprenant.

### Comprendre votre déploiement etcd

Déterminez si etcd est intégré comme pod statique ou externe. Sur un nœud du plan de contrôle, vérifiez la présence du manifeste :

```bash
ls -l /etc/kubernetes/manifests/etcd.yaml
```

S'il est présent, etcd est un pod statique. Le fichier contient la spécification du pod, y compris la version de l'image etcd, les arguments de commande et les montages de volume pour les certificats. Examinez ce fichier pour comprendre les détails de configuration tels que le répertoire de données, les URL d'écoute et le jeton initial du cluster.

Extrait d'exemple de `/etc/kubernetes/manifests/etcd.yaml` :

```yaml
spec:
  containers:
  - command:
    - etcd
    - --advertise-client-urls=https://192.168.1.10:2379
    - --cert-file=/etc/kubernetes/pki/etcd/server.crt
    - --data-dir=/var/lib/etcd
    - --initial-advertise-peer-urls=https://192.168.1.10:2380
    - --initial-cluster=master-node=https://192.168.1.10:2380
    - --key-file=/etc/kubernetes/pki/etcd/server.key
    - --listen-client-urls=https://127.0.0.1:2379,https://192.168.1.10:2379
    - --listen-peer-urls=https://192.168.1.10:2380
    - --name=master-node
    - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
    - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
    - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    - --snapshot-count=10000
    - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
    image: registry.k8s.io/etcd:3.5.10-0
    volumeMounts:
    - mountPath: /var/lib/etcd
      name: etcd-data
    - mountPath: /etc/kubernetes/pki/etcd
      name: etcd-certs
```

Cet inventaire vous donne le contexte pour toute action ultérieure.

## Chemin de configuration sécurisé

Modifier la configuration etcd doit être fait avec une extrême prudence. Une erreur peut entraîner une perte de quorum et un temps d'arrêt du cluster. Suivez ces principes :

- **Sauvegarder d'abord** : prenez toujours un instantané avant de modifier la configuration.
- **Changez un paramètre à la fois** : il est plus facile d'isoler les problèmes.
- **Testez d'abord dans un environnement non productif** : si possible, répliquez le cluster et essayez les modifications là-bas.
- **Documentez le changement et le plan de retour en arrière** : vous devez savoir exactement comment revenir en arrière.

### Modifications de configuration courantes

#### Ajuster le niveau de journalisation etcd

La verbosité de la journalisation peut être modifiée pour diagnostiquer des problèmes. Par exemple, pour augmenter temporairement la journalisation de débogage sur un pod statique, vous modifieriez le fichier manifeste pour ajouter `--log-level=debug` aux arguments de commande etcd. Le kubelet redémarre automatiquement le pod.

Cependant, modifier directement les manifestes de pods statiques est risqué car le kubelet peut ne pas valider le changement et pourrait faire planter le pod etcd à plusieurs reprises. Une approche plus sûre consiste à utiliser `kubectl edit` si etcd est géré par un opérateur, ou à suivre un processus contrôlé.

Pour un cluster kubeadm, le processus typique est :

1. **Sauvegardez le manifeste existant** :
   ```bash
   cp /etc/kubernetes/manifests/etcd.yaml /etc/kubernetes/manifests/etcd.yaml.bak
   ```
2. **Modifiez le manifeste** avec le changement souhaité :
   ```bash
   vi /etc/kubernetes/manifests/etcd.yaml
   ```
   Ajoutez `--log-level=debug` à la liste `command`.
3. **Enregistrez et quittez**. Le kubelet détecte le changement et redémarre le pod etcd.
4. **Surveillez le pod** pour vous assurer qu'il devient prêt :
   ```bash
   kubectl get pods -n kube-system -w | grep etcd
   ```
   Attendez que STATUS soit `Running` et READY `1/1`.
5. Si le pod ne démarre pas, revenez à la sauvegarde :
   ```bash
   cp /etc/kubernetes/manifests/etcd.yaml.bak /etc/kubernetes/manifests/etcd.yaml
   ```
   Le kubelet restaurera le pod d'origine.

#### Mise à jour des certificats

Les certificats etcd expirent et doivent être renouvelés. Kubeadm fournit un moyen de renouveler les certificats, mais le membre etcd peut devoir redémarrer pour charger les nouveaux certificats. La procédure implique :

- Renouveler les certificats avec `kubeadm certs renew etcd-server` et les commandes associées.
- Redémarrer etcd (souvent en déplaçant temporairement le fichier manifeste).

Nous couvrirons le renouvellement des certificats plus en détail dans la section de mise à niveau.

#### Changements de réseau

Changer l'URL d'écoute etcd ou l'URL peer est complexe et rarement nécessaire. Cela implique généralement de reconfigurer le cluster etcd avec de nouvelles URL de membres et potentiellement de réinitialiser. Cela ne doit être fait qu'avec une planification minutieuse et après consultation de la documentation etcd.

Un moyen plus sûr consiste à ajouter un nouveau membre avec l'URL souhaitée et à supprimer l'ancien membre.

### Utilisation d'etcdctl pour la configuration

Bien qu'etcd lui-même ait peu de paramètres de configuration d'exécution, vous pouvez inspecter et modifier certains paramètres du cluster via l'API etcd. Par exemple, vous pouvez définir des indicateurs à l'échelle du cluster comme `--max-request-bytes` au démarrage, mais pas dynamiquement. La configuration est donc principalement gérée via les indicateurs de démarrage.

Assurez-vous toujours que les modifications sont cohérentes sur tous les membres pour éviter toute mauvaise configuration.

## Vérification et diagnostics

Après tout changement, vérifiez que le cluster etcd est sain. Les diagnostics de routine aident également à détecter les problèmes avant qu'ils ne s'aggravent.

### Contrôles de santé

Exécutez `endpoint health` et `member list` comme indiqué précédemment. De plus, vérifiez les journaux etcd pour les erreurs :

```bash
kubectl logs -n kube-system etcd-nœud-maître --tail=50
```

Recherchez des avertissements tels que « failed to send out heartbeat on time » ou des motifs de « leader changed », qui peuvent indiquer des problèmes de réseau ou une charge élevée.

### Vérification du quorum

Si le cluster a plusieurs membres, assurez-vous qu'une majorité est en bonne santé. Pour un cluster de 3 membres, au moins 2 membres doivent être opérationnels. Utilisez :

```bash
kubectl exec -n kube-system etcd-nœud-maître -- etcdctl endpoint status --cluster -w table
```

Cela imprime un tableau avec l'endpoint, l'ID, la version, la taille de la base de données, le leader, le terme raft, etc. Vérifiez que tous les endpoints signalent la santé et qu'un leader est élu.

Exemple de sortie :

```
+-----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|          ENDPOINT           |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+-----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| https://192.168.1.10:2379   | 8211f1d0a64f3269 |  3.5.10 |   25 MB |      true |      false |         2 |       4567 |               4567 |        |
+-----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
```

### Surveillance des métriques

etcd expose des métriques Prometheus sur le port client. Vous pouvez les collecter pour suivre les performances. Les métriques utiles incluent :

- `etcd_server_has_leader` (devrait être 1)
- `etcd_server_leader_changes_seen_total` (des changements fréquents indiquent une instabilité)
- `etcd_disk_backend_commit_duration_seconds` (une latence élevée peut suggérer des problèmes d'E/S disque)
- `etcd_network_peer_round_trip_time_seconds` (des RTT peer lents peuvent affecter le quorum)

Exemple de requête pour vérifier le leader :

```bash
curl -s https://127.0.0.1:2379/metrics | grep etcd_server_has_leader
```

Sortie attendue :

```
etcd_server_has_leader 1
```

### Test de performance

Utilisez `etcdctl check perf` pour exécuter un simple test de performance contre le cluster. Cette commande écrit et lit un certain nombre de clés et rapporte la latence.

```bash
kubectl exec -n kube-system etcd-nœud-maître -- etcdctl check perf --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
```

Exemple de sortie :

```
60 / 60 Booooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo! 100.00%1m0s
PASS: Throughput is 150 writes/s
Slowest request took too long (1.2s)
```

Cela aide à identifier si etcd est sous-performant.

## Modes de défaillance et récupération

Les défaillances etcd peuvent être catastrophiques si elles ne sont pas gérées correctement. Les modes de défaillance courants incluent :

- **Perte de quorum** : plus de (n-1)/2 membres en panne, le cluster devient en lecture seule ou indisponible.
- **Corruption du répertoire de données** : erreurs de système de fichiers ou panne de disque.
- **Expiration des certificats** : les erreurs TLS empêchent la connectivité.
- **Erreur de l'opérateur** : suppression accidentelle de clés ou mauvaise configuration.

### Sauvegarde et restauration

Des sauvegardes régulières sont votre filet de sécurité. Utilisez `etcdctl snapshot save` pour créer une sauvegarde à un instant donné.

```bash
ETCDCTL_API=3 etcdctl --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 \
  snapshot save /var/lib/etcd/snapshot.db
```

Cela enregistre un instantané dans le fichier spécifié sur le nœud du plan de contrôle. Vous devez le copier vers un emplacement sûr en dehors du cluster.

Pour restaurer à partir d'un instantané, vous devez arrêter le pod etcd, restaurer le répertoire de données et éventuellement démarrer un nouveau cluster. Cela se fait généralement sur un etcd à membre unique ou lors de la reconstruction d'un cluster.

Pour un pod statique, vous pouvez déplacer le manifeste pour arrêter le pod :

```bash
mkdir -p /etc/kubernetes/manifests-backup
mv /etc/kubernetes/manifests/etcd.yaml /etc/kubernetes/manifests-backup/
```

Attendez que le pod se termine. Ensuite, sur le nœud, exécutez `etcdctl snapshot restore` avec les indicateurs appropriés pour régénérer le répertoire de données. Veillez à spécifier un nouveau répertoire de données ou à nettoyer l'existant.

Exemple de commande de restauration (exécutée sur le nœud en tant que root avec le binaire etcdctl) :

```bash
etcdctl snapshot restore /chemin/vers/snapshot.db \
  --name nœud-maître \
  --initial-cluster nœud-maître=https://192.168.1.10:2380 \
  --initial-advertise-peer-urls https://192.168.1.10:2380 \
  --data-dir /var/lib/etcd-restore
```

Ensuite, mettez à jour le manifeste etcd pour pointer `--data-dir` vers le nouveau répertoire et restaurez le manifeste.

**Attention** : la restauration à partir d'un instantané écrasera l'état actuel du cluster et ne doit être effectuée que lorsque cela est nécessaire.

### Récupération après une perte de quorum

Une perte de quorum peut survenir si plusieurs nœuds tombent en panne simultanément. Pour récupérer, vous devrez peut-être forcer un nouveau cluster en utilisant les membres encore disponibles. Cela implique d'exécuter `etcd --force-new-cluster` sur un seul membre pour créer un nouveau cluster à nœud unique, puis d'ajouter les autres membres.

Exemple de forçage d'un nouveau cluster (sur un membre survivant) :

```bash
# Arrêter etcd et l'exécuter manuellement avec l'indicateur force-new-cluster (simplifié)
etcd --data-dir=/var/lib/etcd \
  --force-new-cluster \
  --name=nœud-maître \
  --initial-cluster nœud-maître=https://192.168.1.10:2380 \
  --initial-advertise-peer-urls https://192.168.1.10:2380 \
  --listen-peer-urls https://192.168.1.10:2380 \
  --listen-client-urls https://127.0.0.1:2379,https://192.168.1.10:2379 \
  --advertise-client-urls https://192.168.1.10:2379
```

Une fois que le membre est opérationnel en tant que cluster à nœud unique, vous pouvez ajouter de nouveaux membres et restaurer la redondance.

### Gestion de l'expiration des certificats

Si les certificats etcd expirent, le pod etcd peut boucler sur un crash. Pour résoudre ce problème, renouvelez les certificats en utilisant kubeadm le cas échéant :

```bash
kubeadm certs renew etcd-server
kubeadm certs renew etcd-peer
kubeadm certs renew etcd-healthcheck-client
```

Ensuite, redémarrez etcd en déplaçant le manifeste et en le remettant en place :

```bash
mv /etc/kubernetes/manifests/etcd.yaml /tmp/
mv /tmp/etcd.yaml /etc/kubernetes/manifests/
```

Attendez que le pod devienne prêt.

Si kubeadm n'est pas disponible, vous devez générer manuellement des certificats en utilisant votre autorité de certification et mettre à jour la configuration etcd.

## Mise à niveau d'etcd

La mise à niveau d'etcd doit être soigneusement planifiée. Dans Kubernetes, la version etcd est liée à la version du plan de contrôle mais peut être mise à niveau indépendamment dans certains cas.

### Liste de vérification avant mise à niveau

- Assurez-vous que tous les membres etcd sont en bonne santé.
- Prenez un instantané.
- Vérifiez la version etcd actuelle et la compatibilité avec la version cible.
- Consultez les notes de version de Kubernetes pour les changements etcd.
- Planifiez un temps d'arrêt si la mise à niveau progressive n'est pas possible.

### Processus de mise à niveau pour les clusters gérés par kubeadm

Pour les clusters déployés avec kubeadm, etcd est souvent mis à niveau dans le cadre du processus de mise à niveau Kubernetes. Les étapes standard sont :

1. Mettez à niveau l'outil kubeadm.
2. Exécutez `kubeadm upgrade plan` pour voir les versions disponibles.
3. Exécutez `kubeadm upgrade apply vX.Y.Z` qui met à niveau les composants du plan de contrôle, y compris etcd.

Cependant, vous pouvez mettre à niveau etcd manuellement en modifiant le manifeste etcd pour changer la version de l'image. Par exemple, pour passer de 3.5.10 à 3.5.11 :

```bash
# Sur le nœud du plan de contrôle
export ETCD_VERSION=3.5.11-0
sed -i "s/registry.k8s.io\/etcd:.*/registry.k8s.io\/etcd:${ETCD_VERSION}/" /etc/kubernetes/manifests/etcd.yaml
```

Le kubelet extraira la nouvelle image et redémarrera etcd automatiquement. Surveillez l'état du pod et la santé d'etcd après le redémarrage.

### Mise à niveau progressive des membres etcd

Si vous avez un cluster etcd externe ou plusieurs membres, vous pouvez effectuer une mise à niveau progressive. Le processus est le suivant :

1. Mettez à niveau un membre à la fois.
2. Pour chaque membre, arrêtez-le, remplacez le binaire ou mettez à jour l'image du conteneur, puis démarrez-le.
3. Attendez que le membre rejoigne le cluster et devienne sain avant de passer au suivant.
4. Vérifiez la santé du cluster après chaque membre.

Cela minimise les temps d'arrêt et permet au cluster de maintenir le quorum pendant la mise à niveau.

### Vérification après mise à niveau

Après la mise à niveau, exécutez les contrôles de santé et les commandes de version pour confirmer que la nouvelle version est active et que le cluster est sain. Vérifiez également les journaux du serveur d'API Kubernetes pour vous assurer qu'il peut communiquer avec le nouveau etcd.

## Pièges courants et comment les éviter

Travailler avec etcd peut être délicat. Voici quelques pièges courants et comment les éviter ou s'en remettre.

### Piège 1 : Utiliser de mauvais chemins de certificats

De nombreux opérateurs copient des commandes de la documentation sans ajuster les chemins de certificats à leur environnement. Cela conduit à des erreurs d'authentification.

**Comment éviter** : vérifiez toujours les chemins réels à l'intérieur du pod etcd. Vous pouvez lister les volumes montés :

```bash
kubectl exec -n kube-system etcd-nœud-maître -- ls /etc/kubernetes/pki/etcd
```

Fichiers typiques : `ca.crt`, `server.crt`, `server.key`, `peer.crt`, `peer.key`. En cas de doute, inspectez les montages de volume du pod à partir du manifeste.

**Récupération** : si vous obtenez des erreurs TLS, vérifiez si les certificats sont expirés ou manquants. Renouvelez-les si nécessaire.

### Piège 2 : Restauration d'un instantané sur un cluster en direct

Restaurer un instantané pendant qu'etcd est encore en cours d'exécution peut corrompre les données et provoquer un split-brain. Le processus de restauration suppose que le répertoire de données n'est pas utilisé.

**Comment éviter** : arrêtez toujours le membre etcd avant de restaurer. Pour les pods statiques, déplacez le fichier manifeste et assurez-vous que le pod est terminé. Sauvegardez le répertoire de données actuel avant de l'écraser.

**Récupération** : si vous avez accidentellement restauré sur un membre en direct, arrêtez-le immédiatement et restaurez à nouveau à partir d'un instantané propre.

### Piège 3 : Ignorer les exigences de quorum

Supposer qu'un etcd à 3 membres peut tolérer la perte de deux membres. En fait, un cluster à 3 membres ne peut survivre qu'à la défaillance d'un seul membre. En perdre deux signifie pas de quorum.

**Comment éviter** : comprenez la formule du quorum : un cluster de N membres nécessite (N/2)+1 membres disponibles. Pour 3, c'est 2. Pour 5, c'est 3. Planifiez votre topologie en conséquence et n'arrêtez jamais plus d'un membre à la fois pendant la maintenance.

### Piège 4 : Ne pas sauvegarder régulièrement

De nombreuses équipes ne pensent aux sauvegardes qu'après un sinistre. Des sauvegardes automatisées régulières sont essentielles.

**Comment éviter** : planifiez `etcdctl snapshot save` via une tâche cron ou utilisez un CronJob Kubernetes pour prendre des instantanés périodiques et les stocker en dehors du cluster (par exemple, dans un stockage d'objets). Testez périodiquement votre processus de restauration pour vous assurer que les sauvegardes sont valides.

### Piège 5 : Modifier la configuration sans tester

Modifier directement le manifeste etcd sur un cluster de production sans test peut provoquer des boucles de crash répétées et un temps d'arrêt prolongé.

**Comment éviter** : utilisez un cluster de préproduction ou au moins un environnement de développement pour tester les modifications. Documentez le changement exact et la procédure de retour en arrière. Si possible, utilisez des outils de gestion de configuration pour appliquer les modifications de manière uniforme.

## Liste de vérification des opérations

Cette liste de vérification est une référence rapide pour des opérations etcd sécurisées. Attribuez chaque élément à un propriétaire spécifique (pas une équipe) et revisitez la liste mensuellement ou après tout événement majeur du cluster.

### Avant l'opération

- [ ] **Propriétaire** : Priya Shah, responsable de l'ingénierie - Vérifiez la santé du cluster etcd avec `etcdctl endpoint health`.
- [ ] **Propriétaire** : Alex Chen, ingénieur DevOps - Prenez un instantané avec `etcdctl snapshot save` et stockez-le en toute sécurité en dehors du cluster.
- [ ] **Propriétaire** : Alex Chen - Vérifiez les versions actuelles et notez la compatibilité.
- [ ] **Propriétaire** : Priya Shah - Documentez le changement, le résultat attendu et les étapes de retour en arrière dans un runbook.
- [ ] **Propriétaire** : Alex Chen - Informez les parties prenantes si un temps d'arrêt est possible.

### Pendant l'opération

- [ ] **Propriétaire** : Alex Chen - Exécutez le changement sur un membre à la fois (le cas échéant).
- [ ] **Propriétaire** : Alex Chen - Surveillez les journaux du pod etcd pour les erreurs : `kubectl logs -n kube-system etcd-<nœud> -f`
- [ ] **Propriétaire** : Priya Shah - Vérifiez la santé du cluster après chaque étape.
- [ ] **Propriétaire** : Alex Chen - Si une étape échoue, suivez immédiatement le plan de retour en arrière.

### Après l'opération

- [ ] **Propriétaire** : Alex Chen - Confirmez que tous les membres sont sains et que le quorum est intact.
- [ ] **Propriétaire** : Priya Shah - Exécutez `etcdctl endpoint status --cluster` pour vérifier les versions et le leader.
- [ ] **Propriétaire** : Alex Chen - Vérifiez que le serveur d'API Kubernetes est réactif et que les charges de travail du cluster sont planifiées normalement.
- [ ] **Propriétaire** : Priya Shah - Enregistrez les détails de l'opération, les résultats réels et les écarts dans le runbook.
- [ ] **Propriétaire** : Alex Chen - Planifiez un examen de l'opération dans une semaine pour détecter tout problème retardé.

### Examen trimestriel

La liste de vérification elle-même doit être revue trimestriellement par le responsable de l'ingénierie (Priya Shah) pour intégrer les leçons apprises et les changements de l'environnement du cluster.

## Conclusion

etcd est le cœur de Kubernetes, et l'exploiter en toute sécurité exige une approche méthodique. En suivant les procédures décrites dans cet article, vous pouvez inspecter, configurer, mettre à niveau et récupérer etcd en toute confiance sans provoquer de temps d'arrêt inutile.

Rappelez-vous : observez toujours avant de modifier, prenez des sauvegardes, limitez le rayon d'impact, vérifiez la santé à chaque étape et ayez un plan de récupération. Avec ces pratiques, vous garderez votre plan de contrôle Kubernetes stable et vos données en sécurité.

Comme prochaine étape, choisissez une vérification à faible risque comme vérifier `etcdctl endpoint health` et effectuer une sauvegarde instantanée, puis mettez-la en action. Documentez les paramètres spécifiques de votre cluster dans un runbook opérationnel pour votre équipe.

Un flux de travail technique fiable rend les défaillances visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de la récupération avant qu'un incident ne force la décision.