Mit etcd arbeiten
Benutzer arbeiten mit etcd meist, indem sie den Wert eines Schlüssels schreiben oder lesen. Dieser Abschnitt beschreibt dies anhand von etcdctl, einem Befehlszeilenwerkzeug zur Interaktion mit dem etcd-Server. Die erläuterten Konzepte sollten auch für die gRPC-APIs und die APIs der Client-Bibliotheken gelten.
etcdctl v3.7 verwendet die v3-API. Die v2-API und die Versionsauswahl über ETCDCTL_API wurden entfernt.
Die folgenden Beispiele enthalten historische Befehlsausgaben; die angezeigten Versionsnummern können daher von Ihrer Installation abweichen. Frühere etcd-Versionen hielten v2- und v3-Schlüssel in getrennten Speichern. Migrieren Sie vorhandene v2-Daten vor dem Upgrade auf v3.7.
Versionen ermitteln
Die etcdctl-Version und die API-Version des Servers helfen dabei, die passenden Befehle für verschiedene etcd-Operationen zu bestimmen.
Mit folgendem Befehl lassen sich die Versionen ermitteln:
Einen Schlüssel schreiben
Anwendungen speichern Schlüssel im etcd-Cluster, indem sie Werte unter diesen Schlüsseln schreiben. Jeder gespeicherte Schlüssel wird über das Raft-Protokoll auf alle Mitglieder des etcd-Clusters repliziert, um Konsistenz und Zuverlässigkeit zu gewährleisten.
Mit folgendem Befehl wird der Wert des Schlüssels foo auf bar gesetzt:
Ein Schlüssel kann durch Zuordnen einer Lease auch für einen festgelegten Zeitraum gesetzt werden.
Mit folgendem Befehl wird der Wert des Schlüssels foo1 für 10s auf bar1 gesetzt.
Die Lease-ID 1234abcd im obigen Befehl ist die ID, die beim Erstellen der Lease mit 10s Laufzeit zurückgegeben wird. Diese ID kann anschließend dem Schlüssel zugeordnet werden.
Schlüssel lesen
Anwendungen können Schlüsselwerte aus einem etcd-Cluster lesen. Abfragen können einen einzelnen Schlüssel oder einen Schlüsselbereich lesen.
Angenommen, im etcd-Cluster sind folgende Schlüssel gespeichert:
Mit folgendem Befehl wird der Wert des Schlüssels foo gelesen:
Mit folgendem Befehl wird der Wert des Schlüssels foo im Hexadezimalformat gelesen:
Mit folgendem Befehl wird nur der Wert des Schlüssels foo gelesen:
Mit folgendem Befehl werden die Schlüssel von foo bis foo3 abgefragt:
foo3 ist ausgeschlossen, da der Bereich dem halboffenen Intervall [foo, foo3) entspricht, das foo3 nicht enthält.
Mit folgendem Befehl werden alle Schlüssel mit dem Präfix foo abgefragt:
Mit folgendem Befehl werden alle Schlüssel mit dem Präfix foo abgefragt und die Ergebnisse auf 2 begrenzt:
Mit folgendem Befehl werden alle Schlüssel mit dem Präfix foo über den RPC RangeStream
abgefragt. Das Ergebnis ist mit dem eines unären Range-Aufrufs identisch:
--stream unterstützt weder --order noch --sort-by noch Revisionsfilter.
Frühere Schlüsselversionen lesen
Anwendungen möchten möglicherweise ersetzte Versionen eines Schlüssels lesen. Beispielsweise kann eine Anwendung durch Zugriff auf eine frühere Schlüsselversion zu einer alten Konfiguration zurückkehren. Oder sie kann durch den Schlüsselverlauf über mehrere Anfragen hinweg eine konsistente Sicht auf mehrere Schlüssel erhalten. Da jede Änderung am Schlüssel-Wert-Speicher des etcd-Clusters dessen globale Revision erhöht, kann eine Anwendung ersetzte Schlüssel durch Angabe einer älteren etcd-Revision lesen.
Angenommen, im etcd-Cluster sind bereits folgende Schlüssel gespeichert:
Das folgende Beispiel zeigt den Zugriff auf frühere Schlüsselversionen:
Schlüssel lesen, deren Bytewert größer oder gleich dem angegebenen Schlüssel ist
Anwendungen möchten möglicherweise Schlüssel lesen, deren Bytewert größer oder gleich dem des angegebenen Schlüssels ist.
Angenommen, im etcd-Cluster sind bereits folgende Schlüssel gespeichert:
Mit folgendem Befehl werden Schlüssel gelesen, deren Bytewert größer oder gleich dem des Schlüssels b ist:
Schlüssel löschen
Anwendungen können einen einzelnen Schlüssel oder einen Schlüsselbereich aus einem etcd-Cluster löschen.
Angenommen, im etcd-Cluster sind bereits folgende Schlüssel gespeichert:
Mit folgendem Befehl wird der Schlüssel foo gelöscht:
Mit folgendem Befehl werden die Schlüssel von foo bis foo9 gelöscht:
Mit folgendem Befehl wird der Schlüssel zoo gelöscht und das gelöschte Schlüssel-Wert-Paar zurückgegeben:
Mit folgendem Befehl werden Schlüssel mit dem Präfix zoo gelöscht:
Mit folgendem Befehl werden Schlüssel gelöscht, deren Bytewert größer oder gleich dem des Schlüssels b ist:
Schlüsseländerungen beobachten
Anwendungen können einen Schlüssel oder einen Schlüsselbereich beobachten, um sämtliche Aktualisierungen zu überwachen.
Mit folgendem Befehl wird der Schlüssel foo beobachtet:
Mit folgendem Befehl wird der Schlüssel foo im Hexadezimalformat beobachtet:
Mit folgendem Befehl wird der Schlüsselbereich von foo bis foo9 beobachtet:
Mit folgendem Befehl werden Schlüssel mit dem Präfix foo beobachtet:
Mit folgendem Befehl werden die beiden Schlüssel foo und zoo beobachtet:
Historische Schlüsseländerungen beobachten
Anwendungen möchten möglicherweise historische Änderungen an Schlüsseln in etcd beobachten. Beispielsweise kann eine Anwendung alle Änderungen eines Schlüssels empfangen wollen. Solange sie mit etcd verbunden bleibt, genügt dafür watch. Fällt jedoch die Anwendung oder etcd aus, kann während des Ausfalls eine Änderung auftreten, die die Anwendung nicht in Echtzeit empfängt. Um die Zustellung der Aktualisierung zu garantieren, muss die Anwendung historische Schlüsseländerungen beobachten können. Dazu kann sie wie beim Lesen früherer Schlüsselversionen eine historische Revision für einen Watch angeben.
Angenommen, die folgende Folge von Operationen wurde ausgeführt:
Das folgende Beispiel zeigt die Beobachtung historischer Änderungen:
Das folgende Beispiel beobachtet erst ab der letzten historischen Änderung:
Watch-Fortschritt
Anwendungen möchten möglicherweise den Fortschritt eines Watches prüfen, um die Aktualität seines Streams zu bestimmen. Wird ein Watch beispielsweise zur Aktualisierung eines Caches verwendet, kann es hilfreich sein zu wissen, ob der Cache gegenüber der Revision eines Quorum-Lesezugriffs veraltet ist.
In einer interaktiven Watch-Sitzung kann mit dem Befehl “progress” eine Fortschrittsanfrage gestellt werden. Sie fordert den etcd-Server auf, eine Fortschrittsbenachrichtigung im Watch-Stream zu senden:
Die Revisionsnummer in der Fortschrittsantwort stammt vom lokalen etcd-Serverknoten, mit dem der Watch-Stream verbunden ist. Ist dieser Knoten durch eine Netzwerkpartition abgetrennt und nicht Teil des Quorums, kann diese Revision niedriger sein als die Revision eines Quorum-Lesezugriffs auf einen nicht abgetrennten etcd-Serverknoten.
Kompaktierte Revisionen
Wie erwähnt, bewahrt etcd Revisionen auf, damit Anwendungen frühere Schlüsselversionen lesen können. Damit sich jedoch kein unbegrenzt großer Verlauf ansammelt, ist es wichtig, frühere Revisionen zu kompaktieren. Nach der Kompaktierung entfernt etcd historische Revisionen und gibt Ressourcen für die spätere Nutzung frei. Alle ersetzten Daten mit Revisionen vor der Kompaktierungsrevision sind dann nicht mehr verfügbar.
Mit folgendem Befehl werden die Revisionen kompaktiert:
Die aktuelle Revision des etcd-Servers lässt sich mit einem get-Befehl im JSON-Format für einen beliebigen vorhandenen oder nicht vorhandenen Schlüssel ermitteln. Das folgende Beispiel verwendet mykey, das im etcd-Server nicht existiert:
Leases gewähren
Anwendungen können vom etcd-Cluster Leases für Schlüssel anfordern. Wird ein Schlüssel einer Lease zugeordnet, ist seine Lebensdauer an die der Lease gebunden, die ihrerseits durch eine Time-to-live (TTL) bestimmt wird. Jede Lease hat eine Mindest-TTL, die die Anwendung bei der Anforderung angibt. Ihre tatsächliche TTL ist mindestens so groß wie die Mindest-TTL und wird vom etcd-Cluster gewählt. Sobald sie verstrichen ist, läuft die Lease ab, und alle zugeordneten Schlüssel werden gelöscht.
Mit folgendem Befehl wird eine Lease gewährt:
Leases widerrufen
Anwendungen widerrufen Leases anhand ihrer Lease-ID. Dabei werden alle der Lease zugeordneten Schlüssel gelöscht.
Angenommen, die folgende Folge von Operationen wurde ausgeführt:
Mit folgendem Befehl wird dieselbe Lease widerrufen:
Leases am Leben halten
Anwendungen können eine Lease am Leben halten, indem sie deren TTL erneuern und so ihren Ablauf verhindern.
Angenommen, die folgende Folge von Operationen wurde ausgeführt:
Mit folgendem Befehl wird dieselbe Lease am Leben gehalten:
Lease-Informationen abrufen
Anwendungen möchten möglicherweise Informationen über Leases abrufen, um sie zu erneuern oder zu prüfen, ob eine Lease noch existiert oder bereits abgelaufen ist. Sie möchten möglicherweise auch wissen, welchen Schlüsseln eine bestimmte Lease zugeordnet ist.
Angenommen, die folgende Folge von Operationen wurde ausgeführt:
Mit folgendem Befehl werden Informationen zur Lease abgerufen:
Mit folgendem Befehl werden Informationen zur Lease einschließlich der ihr zugeordneten Schlüssel abgerufen: