Etcd 3 soll einige Vorteile gegenüber dem Vorgänger bringen. So brauche die Kommunikation zwischen Clients aufgrund des Wechsels von Json auf gRPC weniger Ressourcen. Und trotz API-Änderungen seien Updates problemlos möglich.
Core OS spricht ihn ‘Etsi’ aus, der Name von Etcd dürfte an des Linux-Verzeichnis “/etc” angelehnt sein, in dem sich die überwiegenden Konfigurationsdateien für das Betriebssystem befinden. Das ‘d’ steht hingegen für den Daemon, der diese Konfigurationen ausliefert. So verteilt Etcd als Key-Value-Store Konfigurationen auf Systemen, etwa auf Googles Containerplattform Kubernetes. Über das bloße Ausliefern ist Etcd allerdings schon deutlich hinaus, Entwickler nutzen es unter anderem für verteiltes Netzwerken, Service Discovery, Scheduling und Load Balancing.
Core OS hat den Daemon nun in einer ersten stabilen Version 3.0 veröffentlicht. Damit Etcd auch auf komplexen Plattformen wie Kubernetes skaliert, die viele verteilte Systeme verwalten, setzt Etcd 3 auch verteilte Locks, beherrscht Leader Election und Software Transactional Memory, um geteilte Zugriffe auf Speicher zu koordinieren. Obwohl das API von Etcd 3 basierend auf dem Feedback der Etcd-2-User generalüberholt wurde, sollen Upgrades laut der Ankündigung einfach sein, weil die Version 3.0 die selben Json Endpoints und internen Clusterprotokolle nutzt wie Etcd 2.
Eines der Probleme von Etcd 2 bestand darin, dass es zu lebhaft kommunizierte. Als Antwort auf das Problem verwendet das Base-Server-Interface nun gRPC anstelle von Json, was die Kommunikationsperformance verdoppele. Für Keys mit einer begrenzten TTL-Laufzeit haben die Entwickler ein “Lease”-Feld eingeführt. Ein Key ist nun einem Lease mit einer bestimmten TTL zugeordnet. Läuft die TTL aus, löscht das Lease die zugehörigen Keys, was Keep-Alive-Traffic spart, wenn verschiedene Keys dasselbe Lease verwenden.
Auch die Watcher wurden überarbeitet. Wenn Anwendungen mit vielen Clients viele Keys im Auge behalten, erschöpfte das den Etcd 2 Server-Socket und beeinträchtigte den Arbeitsspeicher. Das Etcd-3-API multiplext Watches über eine einzelne Verbindung. Clients registrieren Watcher neuerdings in einem bidirektionalen gRPC-Stream, für sie bestimmte Events identifizieren sie anhand einer ID. Verschiedene Watch-Streams können dabei dieselbe TCP-Verbindung teilen, was den Memory Footprint von Etcd 3 deutlich reduziere.
Ansonsten lassen sich historische Key-Value-Mappings länger nachträglich auswerten. Damit Distributed Locks und Transactional Memory funktionieren, zerlegt Etcd 3 nun verschiedene Operationen in eine einzige bedingte Minitransaktion. Sie enthält eine Liste von Aktionen, die erst starten, wenn bestimmte Bedingungen wahr werden. Wer einen Blick auf den Quellcode von Etcd 3 werfen möchte, wird auf Github fündig.
