etcd ist ein quelloffener, verteilter Schlüsselwertspeicher, der dazu verwendet wird, um die kritischen Informationen zu speichern und zu verwalten, die verteilte Systeme zur Ausführung benötigen. Vor allem verwaltet es die Konfigurationsdaten, Statusdaten und Metadaten für Kubernetes, die weitverbreitete Plattform für die Containerorchestrierung.

Wie alle verteilten Workloads haben containerisierte Workloads komplexe Managementanforderungen, die bei Skalierung der Workload noch komplexer werden. Kubernetes vereinfacht das Management dieser Workloads durch Koordination von Aufgaben wie Konfiguration, Bereitstellung, Serviceerkennung, Lastausgleich, Job-Scheduling und Statusüberwachung über alle Cluster hinweg, die auf mehreren Maschinen an mehreren Standorten ausgeführt werden können.

Um dieses Level der Koordination zu erreichen, benötigt Kubernetes jedoch einen Datenspeicher, der eine einzige, einheitliche Wissensressource über den Status des Systems – d. h. all seiner Cluster und Pods sowie der darin enthaltenen Anwendungsinstanzen – zu jedem beliebigen Zeitpunkt bereitstellt. etcd ist der Datenspeicher, der verwendet wird, um diese Wissensressource zu erstellen und zu pflegen.

etcd übernimmt eine ähnliche Rolle für Cloud Foundry (Link befindet sich außerhalb von ibm.com) – die Open-Source- und Multicloud-basierte Platform-as-a-Service (PaaS) – und ist eine gangbare Option zur Koordination kritischer Systeme und Metadaten in Clustern beliebiger verteilter Anwendungen. Der Name „etcd" kommt von einer Namenskonvention innerhalb der Linux-Verzeichnisstruktur: Unter UNIX sind alle Systemkonfigurationsdateien für ein einzelnes System in einem Ordner mit dem Namen „/etc" enthalten; „d" steht hier für „distributed" (verteilt).

Sehen Sie sich das Video „What is etcd?" an, um mehr zu erfahren (6:09):

Es ist keine einfache Aufgabe, als Daten-Backbone zu dienen, der eine verteilte Workload ausführt. Aber etcd wurde für genau diese Aufgabe konzipiert und von Grund auf entwickelt, um die folgenden Leistungsmerkmale bereitzustellen:

• Vollständig repliziert: Jeder Knoten in einem etcd-Cluster hat Zugriff auf den vollständigen Datenspeicher.
  
  
• Hoch verfügbar: etcd wurde mit dem Ziel konzipiert, einen Single Point of Failure zu vermeiden und Hardwareausfälle und Netzpartitionen problemlos zu verkraften.
  
  
• Zuverlässig konsistent: Jeder Datenlesevorgang gibt die zuletzt geschriebenen Daten in allen Clustern zurück.
  
  
• Schnell: etcd erreichte eine Testleistung von 10.000 Schreibvorgängen pro Sekunde.
  
  
• Sicher: etcd unterstützt die automatische Client-Zertifikat-Authentifizierung Transport Layer Security (TLS) und optional Secure Sockets Layer (SSL). Da etcd kritisch wichtige und hochsensible Konfigurationsdaten speichert, sollten Administratoren rollenbasierte Zugriffskontrollen in der Bereitstellung implementieren und sicherstellen, dass der Zugriff von Teammitgliedern, die mit etcd interagieren, auf die niedrigste Berechtigungsstufe beschränkt wird, die zur Durchführung ihrer Arbeit erforderlich ist.
  
  
• Einfach: Jede Anwendung, von einfachen Webanwendungen bis hin zu hoch komplexen Containerorchestrierungsengines wie Kubernetes, kann Daten unter Verwendung von HTTP/JSON-Standardtools in etcd lesen oder schreiben.

Hierbei ist zu beachten, dass in etcd-Umgebungen idealerweise SSDs verwendet werden sollten, da die Leistung von etcd stark von der Speicherplattengeschwindigkeit abhängt. Weitere Informationen dazu und zu anderen etcd-Speicheranforderungen finden Sie im Blogbeitrag „Mit fio feststellen, ob Ihr Speicher schnell genug für etcd ist“.

etcd basiert auf dem Raft-Konsensalgorithmus, um Datenspeicherkonsistenz über alle Knoten in einem Cluster hinweg sicherzustellen – die Minimalanforderung für ein fehlertolerantes verteiltes System.

Raft erreicht diese Konsistenz durch einen gewählten Führungsknoten, der die Replizierung für die anderen Knoten im Cluster – die Follower – verwaltet. Der Führungsknoten nimmt Anfragen von den Clients entgegen, die er dann an die Follower-Knoten weiterleitet. Nachdem der Führungsknoten festgestellt hat, dass eine Mehrheit der Follower-Knoten jede neue Anfrage als Protokolleintrag gespeichert hat, wendet er den Eintrag auf seine lokale Zustandsmaschine an und gibt das Ergebnis dieser Ausführung – einen „Schreibvorgang" – an den Client zurück. Wenn Follower-Knoten abstürzen oder Netzpakete verloren gehen, versucht es der Führungsknoten immer wieder, bis alle Follower alle Protokolleinträge durchgängig gespeichert haben.

Wenn ein Follower-Knoten vom Führungsknoten innerhalb eines bestimmten Zeitintervalls keine Nachricht erhält, findet eine „Wahl" statt, um einen neuen Führungsknoten zu ermitteln. Der Follower erklärt sich selbst zum „Kandidaten" und die anderen Follower entscheiden sich auf der Grundlage seiner Verfügbarkeit für ihn oder einen beliebigen anderen Knoten. Sobald der neue Führungsknoten gewählt ist, beginnt er mit der Verwaltung der Replizierung, und der Prozess beginnt von neuem. Durch diesen Prozess können alle etcd-Knoten hoch verfügbare, durchgängig replizierte Kopien des Datenspeichers unterhalten.

etcd gehört zu den zentralen Kubernetes-Komponenten und dient als primärer Schlüsselwertspeicher für die Erstellung eines funktionsfähigen, fehlertoleranten Kubernetes-Clusters. Der Kubernetes API-Server speichert die Statusdaten jedes Clusters in etcd. Kubernetes verwendet die „Überwachungsfunktion" von etcd, um diese Daten zu überwachen und sich selbst zu rekonfigurieren, wenn Veränderungen auftreten. Die „Überwachungsfunktion" speichert Werte, die den Ist- und Ideal-Zustand des Clusters darstellen, und kann eine Reaktion initiieren, wenn sie von diesem Idealzustand abweichen.

Einen Gesamtüberblick, wie Kubernetes Cluster, Services und Worker-Knoten verwaltet, finden Sie in unserem Video „Kubernetes Explained":

etcd wurde vom gleichen Team entwickelt, das für die Konzipierung von CoreOS Container Linux verantwortlich zeichnet, einem gängigen Container-Betriebssystem, das in einem großen Umfang effizient ausgeführt und verwaltet werden kann. Dieses Team erstellte etcd ursprünglich auf Basis von Raft, um mehrere Kopien von Container Linux gleichzeitig zu koordinieren und damit unterbrechungsfreien Anwendungsbetrieb sicherzustellen.

Im Dezember 2018 spendete das Team etcd an die Cloud Native Computing Foundation (CNCF), eine neutrale Non-Profit-Organisation, die Quellcode, Domänen, Host-Services, Cloudinfrastruktur und andere Projekteigenschaften von etcd als Open-Source-Ressourcen für die Gemeinschaft der Container-basierten Cloud-Entwickler pflegt. CoreOS hat mit Red Hat fusioniert.

Es gibt auch andere Datenbanken, die Informationen zwischen verteilten Anwendungsclustern verwalten und koordinieren. Die beiden am häufigsten mit etcd verglichenen sind ZooKeeper und Consul.

ZooKeeper

ZooKeeper wurde ursprünglich entwickelt, um Konfigurationsdaten und Metadaten in Apache Hadoop-Clustern zu koordinieren. (Apache Hadoop (Link befindet sich außerhalb von ibm.com) ist ein Open-Source-Framework oder eine Zusammenstellung von Anwendungen zur Speicherung und Verarbeitung großer Datenmengen in Clustern von Standardhardware.) ZooKeeper ist älter als etcd, also beeinflussten gesammelte Erfahrungen aus der Arbeit mit ZooKeeper das Design von etcd.

Aus diesem Grund verfügt etcd auch über einige wichtige Funktionen, die ZooKeeper nicht hat. Zum Beispiel unterstützt etcd im Gegensatz zu ZooKeeper Folgendes:

• Möglichkeit der dynamischen Rekonfiguration der Clusterzugehörigkeit
  
  
• Sicherung der Stabilität bei Durchführung von Lese-/Schreibvorgängen bei hoher Auslastung
  
  
• Pflege eines Mehrversion-Datenmodells für die Gleichzeitigkeitskontrolle
  
  
• Zuverlässige Schlüsselüberwachung, die keine Ereignisse auslässt, ohne den Nutzer zu benachrichtigen
  
  
• Verwendung von Basiselementen für gleichzeitigen Zugriff, die Verbindungen aus Sitzungen entkoppeln
  
  
• Unterstützung einer breiten Palette von Sprachen und Frameworks (ZooKeeper hat ein eigenes angepasstes Jute RPC-Protokoll, das beschränkte programmiersprachenbezogene Bindungen unterstützt)

Consul

Consul ist eine Service-Networking-Lösung für verteilte Systeme, deren Leistungsspektrum ungefähr zwischen dem von etcd und dem Istio-Servicenetz für Kubernetes liegt. Wie etcd enthält auch Consul (Link befindet sich außerhalb von ibm.com) einen verteilten Schlüsselwertspeicher basierend auf dem Raft-Algorithmus und unterstützt HTTP/JSON-Anwendungsprogrammierschnittstellen (APIs). Beide bieten eine dynamische Konfiguration der Clusterzugehörigkeit, wobei Consul weniger streng mit mehreren gleichzeitigen Versionen von Konfigurationsdaten abgleicht und die maximale Datenbankgröße, mit der die Lösung zuverlässig arbeitet, kleiner ist.

Wie etcd ist auch Redis ein Open-Source-Tool, jedoch unterscheiden sich ihre grundlegenden Funktionalitäten.

Redis ist ein speicherinterner Datenspeicher und kann als Datenbank, Cache oder Nachrichtenbroker fungieren. Redis unterstützt eine größere Vielfalt von Datentypen und Strukturen als etcd und hat eine erheblich schnellere Lese-/Schreibleistung.

etcd bietet jedoch höhere Fehlertoleranz und leistungsfähigere Funktionen für Failover und kontinuierliche Datenverfügbarkeit. Was am wichtigsten ist: etcd speichert alle gespeicherten Daten dauerhaft auf der Festplatte, opfert also im Grunde genommen Geschwindigkeit zugunsten höherer Zuverlässigkeit und garantierter Konsistenz. Aus diesen Gründen eignet sich Redis besser als verteiltes Speichercaching-System als für die Speicherung verteilter Systemkonfigurationsdaten.