Qu'est-ce que etcd ?

Comme tous les workloads distribués, les workloads conteneurisés sont associés à des exigences de gestion dont la complexité évolue avec leur échelle. Kubernetes simplifie le processus de gestion de ces workloads en coordonnant des tâches telles que la configuration, le déploiement, la découverte de services, l’équilibrage de charge, la planification des tâches et la surveillance de l’état de santé de tous les clusters, qui peuvent s’exécuter sur plusieurs machines et plusieurs sites.

Mais pour atteindre ce niveau de coordination, Kubernetes a besoin d’un magasin de données fournissant une source unique et cohérente de vérité sur l’état du système : tous ses clusters et pods ainsi que les instances d’application qui s’y trouvent, à tout moment. etcd est le magasin de données utilisé pour créer et maintenir cette version de la vérité.

etcd joue un rôle similaire pour Cloud Foundry, la plateforme en tant que service (PaaS) open source et multicloud, et il constitue une option viable pour coordonner les systèmes critiques et les métadonnées sur les clusters de toute application distribuée. Le nom « etcd » suit une convention de nommage appliquée au sein de la structure de répertoires de Linux : dans UNIX, tous les fichiers de configuration système d'un seul et même système sont contenus dans un dossier nommé « /etc; » où « d » signifie « distribué ».

Être le socle de données qui assure le bon fonctionnement d’un workload distribué, ce n’est pas rien. Mais etcd est à la hauteur de la tâche. Il a été conçu dès le départ avec les qualités suivantes :

• Réplication intégrale : Chaque nœud d’un cluster etcd a accès au magasin de données complet.
  
  
• Haute disponibilité : etcd est conçu pour n’avoir aucun point de défaillance unique et tolère avec grâce les pannes matérielles et les partitions de réseau.
  
  
• Cohérence fiable : Chaque « lecture » de données renvoie la dernière « écriture » sur tous les clusters.
  
  
• Rapidité : etcd a été évalué à 10 000 écritures par seconde pendant ses tests de benchmarking.
  
  
• Sécurité : etcd prend en charge le protocole TLS (Transport Layer Security) automatique et l’authentification par certificat client SSL (Secure Socket Layer) en option. Parce qu’etcd stocke des données de configuration vitales et hautement sensibles, les administrateurs doivent implémenter des contrôles d’accès basés sur les rôles au sein du déploiement et s’assurer que les membres de l’équipe qui interagissent avec etcd sont limités au niveau d’accès le moins privilégié nécessaire pour effectuer leurs tâches.
  
  
• Simplicité : N’importe quelle application, qu’il s’agisse de simples applications web ou de moteurs d’orchestration de conteneurs très complexes tels que Kubernetes, peut lire ou écrire des données dans etcd à l’aide d’outils HTTP/JSON standard.

Notez que les performances d’etcd dépendent fortement de la vitesse des disques de stockage, il est donc vivement recommandé d’utiliser des SSD dans les environnements etcd.

etcd est basé sur l’algorithme de consensus Raft pour garantir la cohérence du magasin de données sur tous les nœuds d’un cluster, des enjeux de taille pour un système distribué tolérant aux pannes.

Raft parvient à cette cohérence via un nœud leader choisi qui gère la réplication des autres nœuds du cluster, appelés suiveurs. Le leader accepte les demandes des clients, qu’il transmet ensuite aux nœuds suiveurs. Une fois que le leader s’est assuré qu’une la majorité des nœuds suiveurs ont enregistré chaque nouvelle demande sous forme d’entrée de journal, il applique l’entrée à sa machine locale et renvoie le résultat de cette exécution, une « écriture », au client. Si les suiveurs tombent en panne ou si des paquets réseau sont perdus, le leader effectue d’autres tentatives jusqu’à ce que tous les suiveurs aient stocké toutes les entrées de journal de manière cohérente.

Si un nœud suiveur ne reçoit pas de message du leader dans un intervalle de temps spécifié, l’élection d’un nouveau leader a lieu. Le suiveur se déclare candidat, et les autres suiveurs votent pour lui ou pour un autre nœud en fonction de sa disponibilité. Une fois le nouveau leader choisi, il commence à gérer la réplication et le processus se répète. Ce processus permet à tous les nœuds etcd de maintenir des copies du magasin de données hautement disponibles, répliquées de manière cohérente.

etcd figure parmi les composants de base de Kubernetes et sert de magasin de paires clé-valeur principal pour la création d’un cluster Kubernetes fonctionnel et tolérant aux pannes. Le serveur d’API Kubernetes stocke l’état de chaque cluster dans etcd. Kubernetes utilise la fonction « watch » d’etcd pour surveiller ces données et se reconfigurer en cas de modification. La fonction « watch » stocke des valeurs représentant l’état réel et idéal du cluster et peut initier une réponse en cas de divergence.

Pour un aperçu global de la façon dont Kubernetes gère les clusters, les services et les nœuds de travail, regardez notre vidéo « Kubernetes Explained » :

etcd est créé par l’équipe également responsable de la conception de CoreOS Container Linux, un système d’exploitation de conteneur largement utilisé qui peut être exécuté et géré efficacement à grande échelle. À l’origine, elle conçoit etcd sur Raft pour coordonner simultanément plusieurs copies de Container Linux, afin de garantir un temps de fonctionnement ininterrompu des applications.

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

D’autres bases de données sont développées pour coordonner les informations entre les clusters d’applications distribués. Les deux solutions les plus souvent comparées à etcd sont ZooKeeper et Consul.

À l’origine, ZooKeeper est créé pour coordonner les données de configuration et les métadonnées sur les clusters Apache Hadoop. (Apache Hadoop est un cadre open source, ou un ensemble d’applications, permettant de stocker et de traiter de grands volumes de données sur des clusters de matériel standard.) ZooKeeper est plus ancien qu’etcd, et les leçons tirées de son utilisation ont influencé la conception d’etcd.

Etcd possède donc des capacités majeures que ZooKeeper ne possède pas. Voici les fonctionnalités absentes de Zookeeper qu’etcd propose :

• Il permet la reconfiguration dynamique de l’appartenance à un cluster.
  
  
• Il permet de maintenir un système stable pendant l’exécution des opérations de lecture/écriture dans des conditions de charge plus élevées.
  
  
• Il permet de maintenir un modèle de données MVCC (Multiversion Concurrency Control).
  
  
• Il offre une surveillance fiable des clés qui ne supprime jamais les événements sans envoyer de notification.
  
  
• Il utilise des primitives de concurrence qui dissocient les connexions des sessions.
  
  
• Il prend en charge un large éventail de langues et de frameworks (ZooKeeper possède son propre protocole Jute RPC personnalisé, qui prend en charge des bindings de langages limités).

Consul est une solution de mise en réseau de services pour les systèmes distribués, dont les capacités se situent quelque part entre celles d’etcd et du maillage de services Istio pour Kubernetes. Comme etcd, Consul comprend un magasin de paires clé-valeur distribué basé sur l’algorithme Raft et prend en charge les interfaces de programmation des applications (API) HTTP/JSON. Ces deux solutions permettent une configuration dynamique de l’appartenance aux clusters, mais Consul ne permet pas un contrôle aussi solide des multiples versions simultanées des données de configuration. De plus, la taille maximale de la base de données avec laquelle il fonctionne de manière fiable est plus petite.

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

Redis est un magasin de données en mémoire et peut fonctionner comme une base de données, un cache ou un broker de messages. Redis prend en charge une plus grande variété de types de données et de structures qu’etcd et offre des performances de lecture/écriture beaucoup plus rapides.

Mais etcd présente une plus grande tolérance aux pannes, des capacités supérieures en termes de basculement et de disponibilité continue des données, et surtout, il conserve toutes les données stockées sur disque, sacrifiant essentiellement la vitesse pour garantir une meilleure fiabilité et une plus grande cohérence. C’est pourquoi Redis est plus adapté à la mise en cache de mémoire distribuée qu’au stockage des informations de configuration de systèmes distribués.