etcd est un magasin clé-valeur distribué open source qui contient et gère les informations critiques dont les systèmes distribués ont besoin pour fonctionner. Plus particulièrement, il gère les données de configuration, les données d'état et les métadonnées de Kubernetes, la plateforme d'orchestration de conteneur largement utilisée.

Comme toutes les charges de travail distribuées, les charges de travail conteneurisées ont des exigences de gestion complexes qui se complexifient davantage avec l'augmentation de la charge de travail. Kubernetes simplifie la gestion de ces charges de travail en coordonnant des tâches telles que la configuration, le déploiement, la reconnaissance de service, l'équilibrage de charge, l'ordonnancement des travaux et la surveillance de l'état dans toutes les grappes, qui peuvent s'exécuter sur plusieurs machines dans divers emplacements.

Cependant, pour réaliser cette coordination, Kubernetes nécessite un magasin de données qui fournit une seule source cohérente de référence sur le statut du système, tous ses grappes et pods et les applications qu'ils contiennent, à tout moment. etcd est le magasin de données qui permet de créer et de gérer cette version de référence.

etcd remplit un rôle similaire pour Cloud Foundry (lien externe à ibm.com), la solution Platform-as-a-Service (PaaS) multicloud open source. Il s'agit d'une option viable pour coordonner le système critique et les métadonnées dans les grappes d'une application distribuée. Le nom « etcd » provient d'une convention de dénomination au sein de la structure de répertoire Linux : sous UNIX, tous les fichiers de configuration d'un système unique sont contenus dans un dossier appelé « /etc; », où « d » signifie « distribué ».

Voir la vidéo « Qu'est-ce qu'etcd ? » pour le découvrir etcd en détail (6:09) :

Ce n'est pas une petite affaire que de servir de colonne vertébrale aux données qui assurent le fonctionnement d'une charge de travail distribuée. Cependant, etcd est complètement conçu pour cette tâche pour offrir les qualités suivantes :

• Entièrement répliqué : chaque nœud d'une grappe etcd a accès au magasin de données complet.
  
  
• Hautement disponible : etcd n'a aucun point de défaillance unique et tolère correctement les défaillances matérielles et les partitions réseau.
  
  
• Fiable et cohérent : chaque lecture de données renvoie la dernière écriture de données dans toutes les grappes.
  
  
• Rapide : les évaluations comparatives d'etcd indiquent 10 000 écritures par seconde.
  
  
• Sécurisé : etcd prend en charge le protocole TLS (Transport Layer Security) et l'authentification par certificat client SSL (Secure Socket Layerde couche) en option. Comme etcd stocke des données de configuration vitales et très sensibles, les administrateurs doivent mettre en place des contrôles d'accès basés sur les rôles dans le déploiement et s'assurer que les membres de l'équipe qui interagissent avec etcd sont limités au niveau d'accès minimum requis pour effectuer leur travail.
  
  
• Simple : les applications, des applications Web simples aux moteurs d'orchestration de conteneur très complexes tels que Kubernetes, peuvent lire ou écrire des données sur etcd en utilisant les outils standard HTTP/JSON.

Notez qu'étant donné que les performance d'etcd dépendent largement de la vitesse du disque de stockage, il est fortement recommandé d'utiliser des disques SSD dans les environnements etcd. Pour plus d'informations à ce propos et sur les exigences du stockage etcd, consultez « Utilisation de Fio pour savoir si votre stockage est suffisamment rapide pour etcd ».

etcd repose sur l'algorithme de consensus de Raft pour assurer la cohérence du magasin de données entre tous les nœuds d'une grappe, un enjeu de taille pour un système distribué tolérant aux pannes.

Raft parvient à cette cohérence par le biais d'un nœud leader élu qui gère la réplication pour les autres nœuds de la grappe, appelés suiveurs. Le nœud leader accepte les demandes des clients, qu'il transmet ensuite aux nœuds suiveurs. Une fois que le nœud leader sait qu'une majorité des nœuds suiveurs ont enregistré chaque nouvelle demande comme entrée de journal, il applique l'entrée à son automate local et renvoie le résultat de cette exécution, une « écriture », au client. Si les suiveurs tombent en panne ou que des paquets réseau sont perdus, le leader réessaye jusqu'à ce que tous les suiveurs aient enregistré tout l'historique de manière cohérente.

Si un nœud suiveur ne parvient pas à recevoir un message du leader dans un délai spécifié, une élection est organisée pour sélectionner un nouveau leader. Le suiveur se déclare candidat, et les autres suiveurs votent pour lui ou tout autre nœud en fonction de sa disponibilité. Une fois le nouveau leader élu, il commence à gérer la réplication, et le processus se répète. Ce processus permet à tous nœuds etcd de maintenir des copies du magasin de données hautement disponibles et répliquées de manière cohérente.

etcd fait partie des composants de base de Kubernetes et sert de magasin clé-valeur principal pour créer une grappe Kubernetes fonctionnelle et tolérante aux pannes. Le serveur d'API Kubernetes stocke les données d'état de chaque grappe dans etcd. Kubernetes utilise la fonction « watch » d'etcd pour surveiller ces données et se reconfigurer lorsque des changements surviennent. La fonction « watch » stocke les valeurs qui représentent l'état réel et idéal de la grappe et peut initier une réponse quand elles divergent.

Pour une présentation générale de la façon dont Kubernetes gère les grappes, les services, les nœuds worker, regardez la notre vidéo « Kubernetes Explained » :

etcd a été créé par l'équipe qui a conçu CoreOS Container Linux, un système d'exploitation de conteneur largement utilisé qui peut être exécuté et géré efficacement à très grande échelle. À l'origine, l'équipe a créé etcd sur Raft pour coordonner les multiples copies de Container Linux simultanément, afin d'assurer la disponibilité ininterrompue de l'application.

En décembre 2018, l'équipe a fait don d'etcd à la Cloud Native Computing Foundation (CNCF), une organisation à but non lucratif neutre qui gère le code source, les domaines, les services hébergés, l'infrastructure de cloud d'etcd, ainsi que d'autres propriété du projet comme ressources open source pour la communauté de développement cloud basée sur des conteneurs. CoreOS a fusionné avec Red Hat.

D'autres bases de données ont été développées pour gérer les informations de coordination entre les grappes d'applications distribuées. Les deux bases de données les plus souvent comparées à etcd sont ZooKeeper et Consul.

ZooKeeper

ZooKeeper a été créé à l'origine pour coordonner les données de configuration et les métadonnées entre les grappes Apache Hadoop. (Apache Hadoop (lien externe à ibm.com) est une infrastructure open source, ou une collection d'applications, pour le stockage et le traitement de gros volumes de données sur des grappes de matériel standard.) ZooKeeper est plus ancien qu'etcd, et les leçons apprises en travaillant avec ZooKeeper ont influencé la conception d'etcd.

En conséquence, etcd possède des fonctionnalités importantes dont ZooKeeper ne dispose pas. Par exemple, contrairement à ZooKeeper, etcd peut réaliser les tâches suivantes :

• Permettre la reconfiguration dynamique de l'appartenance à une grappe.
  
  
• Rester stable tout en effectuant des opérations de lecture/écriture sous de fortes charges.
  
  
• Maintenir un modèle de contrôle de simultanéité multiversion des données.
  
  
• Proposer une surveillance clé fiable qui ne supprime jamais d'événements sans notification.
  
  
• Utiliser des primitives d'accès concurrent qui découplent les connexions des sessions.
  
  
• Prendre en charge un large éventail de langages et d'infrastructures (ZooKeeper possède son propre protocole Jute RPC personnalisé qui prend en charge des liaisons de langage limitées).

Consul

Consul est une solution de mise en réseau de service pour les systèmes distribués, dont les fonctionnalités se situent quelque part entre celles d'etcd et le maillage de services Istio pour Kubernetes. Comme etcd, Consul (lien externe à ibm.com) comprend un magasin de valeurs clé-valeur distribué basé sur l'algorithme de Raft et prend en charge les interfaces de programme d'application (API) HHTP/JSON. Les deux proposent une configuration dynamique d'appartenance à une grappe, mais Consul ne contrôle pas aussi strictement l'existence de plusieurs versions simultanées des données de configuration, et la taille maximale de la base de données avec laquelle il fonctionnera de manière fiable est plus petite.

Comme etcd, Redis est un outil open source, mais leurs fonctionnalités de base sont différentes.

Redis est un magasin de données en mémoire et peut faire office de base de données, de cache ou un courtier messages. Redis prend en charge une plus large éventail de types et de structures de données qu'etcd et ses performances en lecture/écriture sont plus rapides.

Cependant, etcd offre une meilleure tolérance aux pannes, une reprise en ligne plus solide et des fonctionnalités de disponibilité des données en continu, mais surtout, etcd fait persister toutes les données stockées sur disque, sacrifiant essentiellement la vitesse pour offrir une plus grande fiabilité et garantir la cohérence. Pour ces raisons, Redis est mieux adapté pour servir de système de cache de mémoire distribué que pour le stockage et les informations de configuration de système distribué.