Was ist etcd?

Wie alle verteilten Workloads haben auch containerisierte Workloads komplexe Verwaltungsanforderungen, die mit zunehmender Skalierung der Workload komplexer werden. Kubernetes vereinfacht den Prozess der Verwaltung dieser Workloads, indem Aufgaben wie Konfiguration, Bereitstellung, Serviceerkennung, Lastausgleich, Auftragsplanung und Zustandsüberwachung über alle Cluster hinweg koordiniert werden, die auf mehreren Maschinen an mehreren Standorten ausgeführt werden können.

Um diese Koordination zu erreichen, benötigt Kubernetes jedoch einen Datenspeicher, der zu jedem beliebigen Zeitpunkt eine einzige, konsistente Quelle mit Informationen über den Status des Systems (aller seiner Cluster und Pod und der darin enthaltenen Anwendungsinstanzen) bietet. etcd ist der Datenspeicher, der zum Erstellen und Verwalten dieser Version der Wahrheit verwendet wird.

etcd erfüllt eine ähnliche Rolle für Cloud Foundry – die Open-Source-Multicloud-Platform-as-a-Service (PaaS) – und ist eine praktikable Option für die Koordinierung entscheidender System- und Metadaten über Cluster jeder verteilten Anwendung hinweg. Der Name „etcd“ stammt von einer Namenskonvention innerhalb der Linux-Verzeichnisstruktur: In UNIX sind alle Systemkonfigurationsdateien für ein einzelnes System in einem Ordner namens „/etc“ enthalten; „d“ steht für „distributed“.

Es ist keine leichte Aufgabe, als Daten-Rückgrat zu dienen, das eine verteilte Workload am Laufen hält. Aber etcd ist für diese Aufgabe konzipiert und von Grund auf mit den folgenden Eigenschaften ausgestattet:

• Vollständig repliziert: Jeder Knoten in einem etcd-Cluster hat Zugriff auf den gesamten Datenspeicher.
  
  
• Hohe Verfügbarkeit: etcd ist so konzipiert, dass es keinen Single Point of Failure es toleriert Hardwareausfälle und Netzwerkpartitionen problemlos.
  
  
• Zuverlässig konsistent: Jedes „Lesen“ von Daten gibt den letzten Datenschreibvorgang über alle Cluster zurück.
  
  
• Schnell: etcd wurde mit 10.000 Schreibvorgängen pro Sekunde Benchmark.
  
  
• Sicher: etcd unterstützt die automatische Authentifizierung von Transport Layer Security (TLS) und optional Secure Socket Layer (SSL) Client-Zertifikatsauthentifizierung. Da etcd wichtige und hochsensible Konfigurationsdaten speichert, sollten Administratoren rollenbasierte Zugriffskontrollen innerhalb der Bereitstellung implementieren und sicherstellen, dass Teammitglieder, die mit etcd interagieren, auf die am wenigsten privilegierte Zugriffsebene beschränkt sind, die für ihre Arbeit erforderlich ist.
  
  
• Unkompliziert: Jede Anwendung, von einfachen Web-Apps bis hin zu hochkomplexen Container-Orchestrierungs-Engines wie Kubernetes, kann mit Standard-HTTP/JSON-Tools Daten in etcd lesen und schreiben.

Beachten Sie, dass die Leistung von etcd stark von der Geschwindigkeit der Speicherfestplatte abhängt und die Verwendung von SSDs in etcd-Umgebungen dringend empfohlen wird.

etcd basiert auf dem Konsensalgorithmus Raf, um die Konsistenz der Datenspeicher auf allen Knoten in einem Cluster sicherzustellen – Tabellen-Stakes für ein fehlertolerantes verteiltes System.

Raft erreicht diese Konsistenz über einen gewählten Leader-Knoten, der die Replikation für die anderen Knoten im Cluster, die sogenannten Followers, verwaltet. Der Leader nimmt Anfragen von den Clients an, die er dann an die Follower-Knoten weiterleitet. Sobald der Leiter festgestellt hat, dass die Mehrheit der Follower-Knoten jede neue Anfrage als Log-Einträge gespeichert hat, wendet er den Eintrag auf seinen lokalen Zustandsmaschinen an und gibt das Ergebnis dieser Ausführung – einen Schreibvorgang – an den Client zurück. Wenn die Follower abstürzen oder Netzwerkpakete verloren gehen, versucht der Leader es erneut, bis alle Follower alle Log-Einträge einheitlich gespeichert haben.

Wenn ein Follower-Knoten innerhalb eines angegebenen Zeitintervalls keine Nachricht vom Leader empfängt, wird eine Wahl abgehalten, um einen neuen Leader zu wählen. Der Follower erklärt sich selbst zum Kandidaten, und die anderen Follower stimmen für ihn oder einen anderen Knoten, je nach Verfügbarkeit. Sobald der neue Leader gewählt ist, beginnt er mit der Verwaltung der Replikation, und der Prozess wiederholt sich. Dieser Prozess ermöglicht es allen etcd-Knoten, hochverfügbare, konsistent replizierte Kopien des Datenspeichers aufrechtzuerhalten.

etcd gehört zu den Kern-Komponenten von Kubernetes und dient als primärer Schlüssel-Werte-Speicher für die Erstellung eines funktionierenden, fehlertoleranten Kubernetes-Clusters. Der Kubernetes-API-Server speichert die Zustandsdaten jedes Clusters in etcd. Kubernetes verwendet die „Watch“-Funktion von etcd, um diese Daten zu überwachen und sich bei Änderungen neu zu konfigurieren. Die Funktion „Watch“ speichert Werte, die den tatsächlichen und den idealen Zustand des Clusters repräsentieren, und kann eine Reaktion einleiten, wenn diese abweichen.

Einen Überblick über die Verwaltung von Clustern, Services und Worker-Knoten durch Kubernetes finden Sie in unserem Video „Kubernetes Explained“.

etcd wurde von demselben Team entwickelt, das für die Entwicklung von CoreOS Container Linux verantwortlich war, einem weit verbreiteten Container-Betriebssystem, das in großem Umfang effizient ausgeführt und verwaltet werden kann. Ursprünglich wurde etcd auf Raft aufgebaut, um mehrere Kopien von Container Linux gleichzeitig zu koordinieren und so einen ununterbrochenen Anwendungsbetrieb mit hoher Betriebszeit zu gewährleisten.

Im Dezember 2018 spendete das Team etcd an die Cloud Native Computing Foundation (CNCF), eine neutrale gemeinnützige Organisation, die den Quellcode, die Domänen, die gehosteten Dienste, die Cloud-Infrastruktur und anderes projektbezogenes Eigentum von etcd als Open Source Ressourcen für die Entwicklercommunity der containerbasierten Cloud betreut. CoreOS hat mit Red Hat fusioniert.

Andere Datenbanken wurden entwickelt, um koordinierte Informationen zwischen verteilten Anwendungsclustern zu verwalten. Die beiden am häufigsten mit etcd verglichenen sind ZooKeeper und Consul.

ZooKeeper wurde ursprünglich entwickelt, um Konfigurationsdaten und Metadaten in Apache Hadoop-Clustern zu koordinieren. (Apache Hadoop ist ein Open-Source-Framework bzw. eine Sammlung von Anwendungen zum Speichern und Verarbeiten großer Datenmengen auf Clustern handelsüblicher Hardware.) ZooKeeper ist älter als etcd und die Erkenntnisse aus der Arbeit mit ZooKeeper haben das Design von etcd beeinflusst.

Als Ergebnis verfügt etcd über einige wichtige Funktionen, die ZooKeeper nicht bietet. Im Gegensatz zu ZooKeeper kann etcd beispielsweise Folgendes:

• Eine dynamische Rekonfiguration der Cluster-Mitgliedschaft erlauben.
  
  
• Bleibt bei der Ausführung von Lese-/Schreibvorgängen unter hoher Last stabil.
  
  
• Verwaltet ein Datenmodell zur Kontrolle des gemeinsamen Zugriffs auf mehreren Versionen.
  
  
• Bietet eine zuverlässige Schlüsselüberwachung, bei der Ereignisse niemals ohne Benachrichtigung gelöscht werden.
  
  
• Verwendet Parallelitätsprimitive, die Verbindungen von Sitzungen entkoppeln.
  
  
• Unterstützt eine breite Palette an Sprachen und Frameworks (ZooKeeper verfügt über ein eigenes benutzerdefiniertes Jute RPC-Protokoll, das begrenzte Sprachbindungen unterstützt).

Consul ist eine Service-Networking-Lösung für verteilte Systeme, deren Funktionen irgendwo zwischen denen von etcd und dem Service-Mesh von Istio  für Kubernetes liegen. Wie etcd umfasst Consul einen verteilten Schlüssel-Werte-Speicher, der auf dem Algorithmus Raft basiert und HTTP/JSON-Anwendungsprogrammierschnittstellen (APIs) unterstützt. Beide bieten eine dynamische Konfiguration der Cluster-Mitgliedschaft, aber Consul kontrolliert nicht so stark mehrere gleichzeitige Versionen von Konfigurationsdaten, und die maximale Datenbankgröße, mit der es zuverlässig funktioniert, ist kleiner.

Wie etcd ist auch Redis ein Open-Source-Tool, aber die grundlegenden Funktionen sind unterschiedlich.

Redis ist ein In-Memory-Datenspeicher und kann als Datenbank, Cache oder Nachrichtenbroker fungieren. Redis unterstützt eine größere Vielfalt an Datentypen und -strukturen als etcd und hat eine viel schnellere Lese-/Schreibleistung.

Aber etcd verfügt über eine höhere Fehlertoleranz, stärkere Failover- und kontinuierliche Datenverfügbarkeits-Funktionen und, was am wichtigsten ist, etcd speichert alle gespeicherten Daten auf einen Datenträger und opfert im Wesentlichen Geschwindigkeit zugunsten einer höheren Zuverlässigkeit und garantierten Konsistenz. Aus diesen Gründen eignet sich Redis besser als verteiltes Speicher-Caching-System als zum Speichern und Verteilen von Systemkonfigurationsinformationen.