## Introduction Etcd est le magasin clé-valeur distribué au cœur de chaque cluster Kubernetes. Il contient tout l'état du cluster, y compris les Pods, Services, ConfigMaps et Secrets. Si etcd devient indisponible ou perd des données, tout le plan de contrôle peut tomber en panne. La surveillance et les alertes pour etcd sont donc essentielles pour la sécurité opérationnelle. Ce guide se concentre sur la configuration pratique et la mise à niveau de la surveillance et des alertes d'etcd dans Kubernetes. Il s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui opèrent leurs propres clusters et doivent passer de l'observation d'un problème à la vérification d'une correction. Vous apprendrez à : - Inventorier votre version d'etcd et la topologie de déploiement. - Exposer et collecter les métriques etcd. - Construire des tableaux de bord montrant les indicateurs de santé clés. - Configurer des alertes qui détectent les pannes avant que les utilisateurs ne les remarquent. - Mettre à niveau etcd en toute sécurité avec la surveillance en place. - Répondre aux incidents avec un chemin de diagnostic clair. Chaque section comprend des commandes concrètes, les sorties attendues, les signaux d'échec et les décisions de récupération. L'objectif est la sécurité opérationnelle : observer avant de changer, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier le résultat et documenter la récupération avant qu'un incident ne l'impose. ## Inventaire de la version et de l'environnement Avant de toucher à la surveillance ou de mettre à niveau etcd, vous devez savoir exactement ce que vous exécutez. Commencez par un inventaire en lecture seule du cluster et du composant etcd. Identifiez la version d'etcd : ```bash kubectl get pods -n kube-system -l component=etcd -o jsonpath='{.items[0].spec.containers[0].image}' ``` Exemple de sortie attendue : ``` registry.k8s.io/etcd:3.5.9-0 ``` Déterminez la topologie de déploiement d'etcd. La plupart des clusters kubeadm exécutent etcd comme un Pod statique sur chaque nœud du plan de contrôle. Listez les Pods etcd : ```bash kubectl get pods -n kube-system -l component=etcd -o wide ``` Exemple de sortie attendue : ``` NAME READY STATUS RESTARTS AGE IP NODE etcd-control-plane-1 1/1 Running 0 10m 192.168.1.10 control-plane-1 etcd-control-plane-2 1/1 Running 0 10m 192.168.1.11 control-plane-2 etcd-control-plane-3 1/1 Running 0 10m 192.168.1.12 control-plane-3 ``` Vérifiez les prérequis : - Accès `kubectl` au cluster avec les permissions pour obtenir les Pods dans `kube-system`. - Capacité à exécuter `exec` dans le conteneur etcd ou à accéder au système de fichiers du nœud si nécessaire. - Accès réseau depuis votre pile de surveillance vers le point d'accès des métriques etcd. Effectuez un contrôle de santé en lecture seule avec `etcdctl` à l'intérieur du Pod : ```bash kubectl exec -n kube-system etcd-control-plane-1 -- 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 ``` Sortie saine attendue : ``` https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 2.1ms ``` Si le cluster utilise un etcd externe (pas des Pods statiques), ajustez les commandes en conséquence. Enregistrez la version etcd, le nombre de membres et l'état de santé dans votre journal des opérations avec des horodatages. Cette base de référence est essentielle avant tout changement. ## Chemin de configuration sécurisé Configurer la surveillance d'etcd nécessite d'activer le point d'accès des métriques et de s'assurer que votre Prometheus ou autre scraper peut l'atteindre de manière sécurisée. Etcd expose les métriques sur le port 2379 par défaut lorsqu'il est démarré avec le drapeau `--listen-metrics-urls`. Vérifiez la spécification actuelle du Pod etcd pour l'URL des métriques : ```bash kubectl get pod -n kube-system etcd-control-plane-1 -o yaml | grep -A2 'listen-metrics-urls' ``` La sortie attendue peut inclure : ```yaml - --listen-metrics-urls=http://0.0.0.0:2381 ``` Si le drapeau est absent, etcd expose toujours les métriques sur le port 2379, mais ce port est également utilisé pour les requêtes des clients. Il est plus sûr de séparer le trafic des métriques sur un port dédié (par exemple, 2381) pour éviter les interférences. Pour activer un port de métriques dédié sur un Pod statique géré par kubeadm, modifiez le manifeste etcd sur le nœud du plan de contrôle : ```bash sudo vi /etc/kubernetes/manifests/etcd.yaml ``` Ajoutez ou modifiez les arguments de commande du conteneur : ```yaml spec: containers: - command: - etcd - --listen-metrics-urls=http://0.0.0.0:2381 - --metrics=extensive ``` L'option `--metrics=extensive` fournit des métriques supplémentaires comme les histogrammes de requêtes gRPC, utiles pour l'analyse de la latence. Après avoir enregistré le manifeste, kubelet redémarrera automatiquement le Pod etcd. Vérifiez que le nouveau port écoute : ```bash kubectl exec -n kube-system etcd-control-plane-1 -- sh -c 'curl -s http://localhost:2381/metrics | head -5' ``` Sortie attendue : ``` # HELP etcd_server_has_leader Whether or not a leader exists. 1 is leader exists. # TYPE etcd_server_has_leader gauge etcd_server_has_leader 1 ``` Maintenant, configurez Prometheus pour scraper ce point d'accès. Si vous utilisez l'Opérateur Prometheus, créez un ServiceMonitor ciblant les Pods etcd. Si vous utilisez une configuration Prometheus brute, ajoutez un job de scraping : ```yaml scrape_configs: - job_name: 'etcd' scheme: https tls_config: ca_file: /etc/prometheus/secrets/etcd-ca.crt cert_file: /etc/prometheus/secrets/etcd-client.crt key_file: /etc/prometheus/secrets/etcd-client.key static_configs: - targets: ['192.168.1.10:2379', '192.168.1.11:2379', '192.168.1.12:2379'] ``` Si vous avez activé le port de métriques dédié, utilisez ce port à la place. Assurez-vous que les certificats ont les bons Subject Alternative Names pour les IP des nœuds. Testez le scrape manuellement depuis le Pod Prometheus : ```bash kubectl exec -n monitoring prometheus-0 -- wget -qO- https://192.168.1.10:2379/metrics --ca-certificate=/etc/prometheus/secrets/etcd-ca.crt | head ``` La sortie attendue montre les métriques Prometheus. Si vous obtenez une erreur de certificat, vérifiez la validité du certificat et les SAN. ## Vérification et diagnostics Après avoir activé la collecte des métriques, vérifiez que Prometheus reçoit les métriques etcd et qu'elles ne sont pas vides. Interrogez Prometheus pour la métrique `up` des cibles etcd : ``` up{job="etcd"} ``` Résultat attendu : toutes les cibles etcd doivent afficher `1`. Vérifiez un échantillon de métrique, par exemple `etcd_server_has_leader` : ``` etcd_server_has_leader ``` Résultat attendu : la valeur est `1` sur le nœud leader et `0` sur les suiveurs. Si la métrique est absente, vérifiez la configuration de scrape et les politiques réseau. Diagnostiquez les problèmes courants : - **Cible down dans Prometheus** : Vérifiez que le point d'accès est joignable depuis le Pod Prometheus. Vérifiez les règles de pare-feu ou les NetworkPolicy Kubernetes. - **Erreurs de certificat** : Assurez-vous que le CA et les certificats clients dans Prometheus correspondent aux certificats serveur etcd. `etcd` utilise TLS mutuel par défaut dans les clusters kubeadm. - **Pas de métriques sur le port 2381** : Confirmez que le drapeau `--listen-metrics-urls` a été appliqué. Consultez les journaux du Pod etcd pour les erreurs de démarrage : ```bash kubectl logs -n kube-system etcd-control-plane-1 ``` Vous pouvez également utiliser `etcdctl` pour vérifier la santé du cluster et la liste des membres afin d'éviter un split brain : ```bash kubectl exec -n kube-system etcd-control-plane-1 -- 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 attendue liste tous les membres avec leurs URL client et pair. Si les métriques circulent, vous pouvez maintenant construire des tableaux de bord. Pour Grafana, importez un tableau de bord qui utilise les métriques etcd. Un choix populaire est le tableau de bord etcd des Kubernetes Mixins ou de la communauté Grafana. Les panneaux clés à inclure : - **Changements de leader** : `increase(etcd_server_leader_changes_seen_total[1h])` doit être faible. Des changements fréquents indiquent des problèmes réseau. - **Durée de proposition Raft** : `histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (le))` doit être inférieure à 25ms. - **Durée des opérations disque** : `histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (le))` inférieure à 50ms. - **Taux de requêtes gRPC** : `sum(rate(grpc_server_handled_total[5m])) by (grpc_method)` pour voir la charge de requêtes. ## Modes de défaillance et récupération Les défaillances d'etcd peuvent être subtiles. Connaître les modes de défaillance courants vous aide à réagir rapidement. ### Tempêtes d'élection de leader Si le leader etcd change fréquemment (plus d'une fois par heure), cela indique une latence réseau ou une perte de paquets entre les membres. Cela peut provoquer des délais d'attente d'écriture pour le serveur API. **Diagnostic** : Vérifiez `increase(etcd_server_leader_changes_seen_total[1h])`. Vérifiez également la latence réseau entre les nœuds avec `ping` ou `iperf`. **Récupération** : Enquêtez sur les performances réseau. Si cela est dû à une E/S disque élevée sur le leader, réduisez la charge ou déplacez etcd vers des disques dédiés. Si le problème réseau persiste, envisagez d'ajouter un réseau plus rapide ou d'ajuster l'intervalle de pulsation etcd (non recommandé sans connaissance approfondie). ### Épuisement de l'espace disque Etcd stocke les données dans un répertoire. Si le disque se remplit, etcd peut cesser d'accepter les écritures ou planter. **Diagnostic** : Vérifiez l'utilisation du disque sur le nœud : ```bash df -h /var/lib/etcd ``` Exemple de sortie attendue : ``` Filesystem Size Used Avail Use% Mounted on /dev/sda1 100G 95G 5G 95% /var/lib/etcd ``` Si l'utilisation est supérieure à 80 %, planifiez une compaction et une défragmentation. **Récupération** : Compactez l'historique etcd pour supprimer les anciennes révisions : ```bash kubectl exec -n kube-system etcd-control-plane-1 -- 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 compact $(etcdctl ... get / --prefix --keys-only | wc -l) ``` Il est préférable d'utiliser la révision actuelle moins une marge de sécurité. Ensuite, défragmentez : ```bash kubectl exec -n kube-system etcd-control-plane-1 -- 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 defrag ``` Exécutez la défragmentation sur chaque membre séquentiellement pour éviter la perte de quorum. Planifiez une compaction régulière via un CronJob si votre version d'etcd n'auto-compacte pas. ### Perte de quorum Si plus de (n/2) membres échouent, le cluster perd le quorum et ne peut pas traiter les écritures. Les requêtes en lecture seule peuvent encore fonctionner selon la configuration. **Diagnostic** : Vérifiez la métrique `etcd_server_has_leader` ; si elle est à 0 sur tous les nœuds, le quorum est perdu. Exécutez également `etcdctl endpoint status` pour voir le leader et le terme raft. **Récupération** : Restaurez les membres défaillants dès que possible. Si la majorité est définitivement perdue, vous devez effectuer une reprise après sinistre d'etcd à partir d'un instantané. Prenez toujours des instantanés réguliers : ```bash kubectl exec -n kube-system etcd-control-plane-1 -- 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 ``` Stockez les instantanés hors nœud. Testez la restauration dans un environnement non productif régulièrement. ## Mise à niveau d'Etcd avec la surveillance en place La mise à niveau d'etcd nécessite une planification minutieuse. Surveillez le cluster pendant la mise à niveau pour détecter les problèmes tôt. **Liste de contrôle pré-mise à niveau :** - Vérifiez la version actuelle et la santé du cluster (voir Inventaire de la version et de l'environnement). - Prenez un instantané des données etcd. - Vérifiez la compatibilité : Kubernetes prend en charge etcd 3.5.x pour les versions récentes ; ne sautez pas de versions majeures sans test. - Informez les parties prenantes et planifiez une fenêtre de maintenance si nécessaire. Pour les clusters kubeadm, la mise à niveau d'etcd fait partie de la mise à niveau du plan de contrôle. D'abord, mettez à niveau kubeadm : ```bash sudo apt-get update && sudo apt-get install -y kubeadm=1.28.0-00 ``` Ensuite, exécutez le plan de mise à niveau : ```bash sudo kubeadm upgrade plan ``` Cela montrera la version etcd recommandée. Appliquez la mise à niveau sur le premier nœud du plan de contrôle : ```bash sudo kubeadm upgrade apply v1.28.0 ``` Cela met à niveau etcd, kube-apiserver, kube-controller-manager et kube-scheduler sur ce nœud. Surveillez les métriques etcd pendant le processus. Surveillez les changements de leader et la perte de quorum. Le cluster doit continuer à fonctionner grâce à la redondance. Après la mise à niveau du premier nœud, mettez à niveau les autres nœuds du plan de contrôle un par un : ```bash sudo kubeadm upgrade node ``` Surveillez etcd après chaque nœud. Vérifiez `etcd_server_has_leader` et `etcd_server_leader_changes_seen_total`. Assurez-vous que les métriques sont toujours scrapées. Si vous utilisez un etcd externe, suivez la documentation etcd pour les mises à niveau sur place. Ne mettez jamais à niveau plus d'un membre à la fois et laissez le cluster se stabiliser entre les mises à niveau. **Vérification post-mise à niveau :** - Vérifiez la version etcd : `kubectl exec ... etcdctl version` - Vérifiez la santé du cluster : `etcdctl endpoint health` - Vérifiez les métriques dans Prometheus : `up{job="etcd"}` est 1. - Vérifiez les tableaux de bord pour les anomalies. Si une mise à niveau échoue, vous pouvez revenir en arrière en restaurant l'instantané si nécessaire. Cependant, les mises à niveau etcd sont généralement rétrocompatibles au sein de la même version majeure. Revenir en arrière sur Kubernetes est plus complexe ; testez toujours dans un environnement de staging. ## Configuration des alertes Configurez des alertes Prometheus pour etcd. Utilisez les règles d'alerte suivantes comme point de départ. Ajustez les seuils en fonction de votre environnement. Créez un fichier de règles d'alerte (par exemple, `etcd-alerts.yaml`) et chargez-le dans Prometheus. ```yaml groups: - name: etcd rules: - alert: EtcdNoLeader expr: etcd_server_has_leader == 0 for: 5m labels: severity: critical annotations: summary: "etcd cluster has no leader" description: "etcd instance {{ $labels.instance }} has no leader for more than 5 minutes." - alert: EtcdHighFsyncDuration expr: histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (le)) > 0.025 for: 10m labels: severity: warning annotations: summary: "etcd fsync latency high" description: "etcd instance {{ $labels.instance }} 99th percentile fsync duration is above 25ms for 10 minutes." - alert: EtcdHighCommitDuration expr: histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (le)) > 0.05 for: 10m labels: severity: warning annotations: summary: "etcd commit latency high" description: "etcd instance {{ $labels.instance }} 99th percentile commit duration is above 50ms for 10 minutes." - alert: EtcdLeaderChangesFrequent expr: increase(etcd_server_leader_changes_seen_total[1h]) > 3 for: 5m labels: severity: warning annotations: summary: "etcd leader changes are frequent" description: "etcd cluster has had more than 3 leader changes in the last hour." - alert: EtcdMemberDown expr: up{job="etcd"} == 0 for: 5m labels: severity: critical annotations: summary: "etcd member is down" description: "etcd instance {{ $labels.instance }} has been down for more than 5 minutes." ``` Ces alertes couvrent le leadership, la latence disque et la disponibilité des membres. Intégrez-les à votre système de notification (par exemple, PagerDuty, Slack). Définissez une politique d'escalade : les alertes critiques appellent immédiatement l'astreinte, les avertissements peuvent attendre les heures ouvrées. Pour chaque alerte, attribuez un propriétaire. Par exemple : - EtcdNoLeader : Priya Shah, responsable ingénierie (primaire), Ravi Kumar, SRE (secondaire). Réviser les seuils d'alerte mensuellement. - EtcdHighFsyncDuration : Ravi Kumar, SRE. Réviser mensuellement. - EtcdHighCommitDuration : Ravi Kumar, SRE. Réviser mensuellement. - EtcdLeaderChangesFrequent : Priya Shah. Réviser hebdomadairement si déclenchée. - EtcdMemberDown : Ingénieur d'astreinte. Réponse immédiate. Documentez ces propriétaires dans votre runbook. ## Pièges courants et comment les éviter ### 1. Surveiller le mauvais port Beaucoup d'utilisateurs supposent que les métriques etcd sont sur le port client 2379, mais si vous définissez un port de métriques dédié comme 2381, votre job de scrape Prometheus doit utiliser ce port. Piège : oublier de mettre à jour la configuration de scrape après avoir activé `--listen-metrics-urls`. Vérifiez toujours avec un curl manuel. ### 2. Inadéquation des certificats Etcd utilise TLS mutuel. Si Prometheus scrape avec des certificats erronés ou expirés, la cible apparaît comme down. Piège : ne pas renouveler les certificats avant expiration. Utilisez un outil de gestion des certificats (cert-manager) et définissez des alertes sur l'expiration des certificats. ### 3. Ignorer la latence disque Etcd est sensible à la latence disque. Exécuter etcd sur du stockage réseau ou des disques lents provoque des problèmes de fsync. Piège : supposer que n'importe quel disque fonctionne. Utilisez un stockage SSD local rapide dédié à etcd. Surveillez `etcd_disk_wal_fsync_duration_seconds_bucket` et alertez si le p99 dépasse 25ms. ### 4. Négliger la compaction et la défragmentation Etcd conserve un historique de tous les changements. Sans compaction, la base de données grossit et les performances se dégradent. Piège : ne pas planifier la compaction. Activez la compaction automatique dans etcd en définissant `--auto-compaction-mode=periodic --auto-compaction-retention=1h` ou créez un CronJob pour exécuter régulièrement `etcdctl compact` et `defrag`. ### 5. Mettre à niveau tous les membres etcd simultanément Si vous mettez à niveau tous les membres etcd en même temps, vous risquez une perte de quorum et une indisponibilité des données. Piège : ne pas suivre une mise à niveau progressive. Mettez toujours à niveau un membre à la fois et attendez que le cluster soit sain avant le suivant. ### 6. Pas de stratégie de sauvegarde ou d'instantané Si les données etcd sont perdues, sans instantanés, la récupération est impossible. Piège : ne pas tester les restaurations. Prenez des instantanés régulièrement à l'aide d'un CronJob, stockez-les hors cluster et testez la procédure de restauration dans un environnement de staging trimestriellement. ## Liste de contrôle des opérations Utilisez cette liste de contrôle avant et après tout changement de configuration ou mise à niveau d'etcd. **Avant le changement :** - [ ] Enregistrer les métriques de base : leader, durée de fsync, durée de commit, liste des membres. - [ ] Prendre un instantané etcd et vérifier son intégrité. - [ ] Informer l'équipe et planifier si nécessaire. - [ ] S'assurer que tous les membres sont sains. - [ ] Vérifier l'espace disque disponible. **Pendant le changement :** - [ ] Appliquer le changement à un seul membre (si applicable). - [ ] Surveiller les métriques etcd en continu. - [ ] Surveiller les changements de leader ou la perte de quorum. - [ ] Vérifier que `up` dans Prometheus reste à 1. **Après le changement :** - [ ] Vérifier la version et la santé d'etcd. - [ ] Vérifier les métriques et les tableaux de bord pour les anomalies. - [ ] Confirmer que les alertes ne se déclenchent pas de manière inattendue. - [ ] Documenter le changement et le résultat dans le journal des opérations. - [ ] Revenir après 24 heures pour vérifier la stabilité. Attribuez un propriétaire pour chaque exécution de la liste de contrôle : l'ingénieur d'astreinte est responsable des vérifications avant changement, le responsable SRE approuve le changement et l'ingénieur d'astreinte effectue la vérification après changement. Révisez cette liste trimestriellement pour les mises à jour nécessaires en fonction des incidents. ## Conclusion La surveillance et les alertes d'etcd ne sont pas des tâches à configurer et oublier. Elles nécessitent une attention continue, surtout lors des mises à niveau et des changements de configuration. Ce guide a fourni un chemin pratique de l'inventaire à la configuration sécurisée, la vérification, les alertes et la récupération. En suivant les commandes et les exemples, vous pouvez construire une pile de surveillance qui détecte tôt les problèmes etcd et réduit les temps d'arrêt. N'oubliez pas de : - Délimiter la portée de chaque recommandation selon la version. - Observer avant de changer. - Limiter le rayon d'impact. - Utiliser des espaces réservés pour les secrets. - Vérifier les résultats. - Documenter les procédures de récupération. Comme prochaine étape, choisissez une vérification à faible risque de ce guide, comme vérifier les métriques sur le port 2381 ou créer une alerte de test. Enregistrez l'état actuel, exécutez la vérification, comparez avec la sortie attendue et examinez les dépendances comme le Kube API Server et les certificats. Un flux de travail de surveillance etcd fiable rend les pannes visibles, protège les valeurs sensibles et définit la récupération avant qu'un incident ne force la décision.