Aller au contenu principal

Chapitre 2.3 - etcd

Objectifs d'Apprentissage​

À la fin de ce chapitre, vous serez capable de:

  • Comprendre le rôle d'etcd dans Kubernetes
  • Expliquer comment etcd stocke l'état du cluster
  • Comprendre la réplication et la haute disponibilité
  • Identifier les bonnes pratiques de sauvegarde

Qu'est-ce qu'etcd?​

etcd est une base de données clé-valeur distribuée, cohérente et hautement disponible utilisée comme source de vérité unique pour Kubernetes. Toute la configuration et l'état du cluster sont stockés dans etcd.

Rôle dans Kubernetes​

Source de Vérité Unique​

etcd stocke:

  • Toutes les ressources (Pods, Services, Deployments, etc.)
  • Configuration du cluster
  • État actuel de toutes les ressources
  • Métadonnées et annotations

Pas d'Accès Direct​

Important: Les utilisateurs et composants n'accèdent JAMAIS directement à etcd. Toutes les interactions passent par l'API Server.

Structure des Données​

Format Clé-Valeur​

Les données sont organisées hiérarchiquement:

/registry/pods/default/my-pod
/registry/services/default/my-service
/registry/deployments/default/my-deployment

Exemple de Données Stockées​

{
  "kind": "Pod",
  "apiVersion": "v1",
  "metadata": {
    "name": "my-pod",
    "namespace": "default",
    "uid": "123-456-789"
  },
  "spec": {
    "containers": [...]
  },
  "status": {
    "phase": "Running"
  }
}

Haute Disponibilité​

Réplication​

Pour la production, etcd doit être répliqué (généralement 3 ou 5 nodes):

Avantages:

  • Tolérance aux pannes (1 node peut tomber)
  • Performance améliorée (lectures distribuées)
  • Cohérence garantie

Consensus: Raft​

etcd utilise l'algorithme de consensus Raft:

Caractéristiques:

  • Un leader élu
  • Réplication vers les followers
  • Consensus par majorité
  • Cohérence forte garantie

Sauvegarde et Restauration​

Importance Critique​

⚠️ etcd contient TOUT l'état du cluster. Sa perte = perte du cluster!

Sauvegarde Régulière​

# Sauvegarder etcd
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.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

# Restaurer depuis une sauvegarde
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db

Bonnes Pratiques​

  • Sauvegardes automatiques quotidiennes
  • Stockage hors-site
  • Tests de restauration réguliers
  • Documentation du processus

Performance​

Facteurs Impactant les Performances​

  1. Taille du cluster: Plus de ressources = plus de données
  2. Fréquence des changements: Mises à jour fréquentes
  3. Taille des objets: Grands ConfigMaps/Secrets
  4. Compaction: Nettoyage des anciennes versions

Optimisations​

  • Compaction régulière des données
  • Défragmentation du disque
  • SSD pour de meilleures performances
  • Monitoring des métriques

Sécurité​

Chiffrement​

  • En transit: TLS entre API Server et etcd
  • Au repos: Chiffrement optionnel des données

Accès Restreint​

  • Seul l'API Server accède à etcd
  • Certificats client requis
  • Pas d'accès réseau public

Monitoring​

Métriques Importantes​

  • Taille de la base de données
  • Latence des opérations
  • Taux d'erreurs
  • État du leader
  • Espace disque disponible

Commandes Utiles​

# Vérifier l'état d'etcd
kubectl get componentstatuses

# Voir les métriques (si monitoring configuré)
# Via Prometheus ou outils similaires

Résumé​

Dans ce chapitre, vous avez appris:

etcd: Base de données distribuée, source de vérité unique
Stockage: Toutes les ressources et configuration du cluster
Haute Disponibilité: Réplication avec consensus Raft
Sauvegarde: Critique pour la continuité du cluster
Sécurité: Accès restreint, chiffrement en transit

Prochaines Étapes​

Maintenant que vous comprenez etcd:

Chapitre 2.4: Controller Manager - Maintien de l'État Désiré
Chapitre 2.5: Scheduler - Planification des Pods

Chapitre créé le: Décembre 2024