Die häufigsten Probleme mit etcd in Kubernetes – und wie man sie wirklich behebt

Von /

Wenn ein Kubernetes-Cluster plötzlich merkwürdig reagiert – Pods starten nicht, Deployments hängen oder der API-Server wird spürbar langsamer – liegt die Ursache oft tiefer, als man zuerst vermutet. In vielen Fällen ist etcd das eigentliche Problem.

etcd ist die zentrale Datenbank von Kubernetes. Dort werden die Zustände des Clusters gespeichert: Nodes, Pods, ConfigMaps, Secrets, Deployments und vieles mehr. Wenn etcd instabil wird, wirkt sich das fast immer direkt auf das gesamte Cluster aus.

In diesem Artikel geht es um die häufigsten etcd-Probleme in Kubernetes, woran man sie erkennt und wie man sie in der Praxis behebt.

1. etcd ist langsam oder reagiert verzögert

Ein typisches Warnsignal ist ein träger Kubernetes-API-Server. Befehle wie kubectl get pods brauchen plötzlich deutlich länger als sonst, Deployments laufen verzögert an und Änderungen im Cluster kommen nur langsam an.

Typische Ursachen

  • Langsame Festplatten
  • Hohe Latenz zwischen etcd-Mitgliedern
  • Zu viele gleichzeitige Schreiboperationen

So behebst du das Problem

Der erste Blick sollte fast immer auf die Storage-Performance gehen. etcd ist sehr empfindlich, wenn die zugrunde liegende Festplatte zu langsam ist. Besonders bei HDDs oder überlasteten virtuellen Volumes treten schnell Engpässe auf. SSDs sind hier praktisch Pflicht.

Zusätzlich lohnt sich ein Blick auf die Cluster-Gesundheit:

etcdctl endpoint status --write-out=table

Wenn die Antwortzeiten hoch sind oder Leader-Wechsel häufig auftreten, sprechen viele Anzeichen für ein Performance-Problem im Unterbau.

2. Ein etcd-Mitglied fällt aus

Wenn ein einzelner etcd-Knoten ausfällt, muss das nicht sofort zum Totalausfall führen. Trotzdem wird das Cluster instabiler, und sobald weitere Probleme hinzukommen, kann es kritisch werden.

Woran du das erkennst

  • Meldungen wie unhealthy cluster
  • Verbindungsprobleme zum API-Server
  • Zeitweise Aussetzer bei Schreiboperationen

Typische Ursachen

  • Ein Node ist abgestürzt
  • Netzwerkprobleme zwischen den Mitgliedern
  • Fehlerhafte Konfiguration nach Wartungsarbeiten

So gehst du vor

Zuerst solltest du prüfen, welche Mitglieder aktuell Teil des Clusters sind:

etcdctl member list

Wenn ein Mitglied dauerhaft defekt ist, kann es nötig sein, es aus dem Cluster zu entfernen und sauber neu hinzuzufügen:

etcdctl member remove <ID>

Wichtig ist, dabei nicht hektisch zu handeln. etcd reagiert empfindlich auf halbherzige Reparaturversuche. Erst prüfen, dann gezielt austauschen.

3. Die etcd-Datenbank wird zu groß

Ein sehr häufiges, aber oft übersehenes Problem ist eine stetig wachsende Datenbank. etcd speichert Änderungen nicht einfach nur in einer kleinen Live-Datenbank, sondern verwaltet Revisionen und Historie. Dadurch kann die Datenbank mit der Zeit deutlich anwachsen.

Typische Folgen

  • Langsamere Antwortzeiten
  • Warnungen wegen Datenbankgröße
  • Speicherplatzprobleme auf dem Host

So behebst du das Problem

Hier helfen zwei Wartungsschritte: Compaction und Defragmentierung.

Zuerst wird die Historie bis zu einer bestimmten Revision komprimiert:

etcdctl compact <revision>

Danach wird die Datenbank defragmentiert:

etcdctl defrag

Gerade die Defragmentierung wird in vielen Setups vergessen. Dabei ist sie oft einer der einfachsten Hebel, um etcd wieder spürbar zu beschleunigen.

4. Zertifikatsprobleme mit TLS

Wenn etcd per TLS abgesichert ist – was in produktiven Umgebungen Standard sein sollte – können abgelaufene oder falsch konfigurierte Zertifikate das gesamte Cluster lahmlegen.

Typische Symptome

  • Fehler wie x509: certificate has expired
  • Der API-Server kann sich nicht mehr mit etcd verbinden
  • Plötzliche Ausfälle ohne erkennbare Lastprobleme

So löst du das Problem

In vielen kubeadm-basierten Clustern lassen sich Zertifikate erneuern mit:

kubeadm certs renew all

Danach müssen die betroffenen Komponenten neu gestartet werden, damit die neuen Zertifikate aktiv genutzt werden.

Ein Klassiker in der Praxis: Das Cluster läuft monatelang stabil, und dann schlägt plötzlich alles fehl, weil ein Zertifikat unbemerkt abgelaufen ist.

5. Quorum verloren – das Cluster blockiert

etcd funktioniert nur zuverlässig, wenn eine Mehrheit der Mitglieder erreichbar ist. Diese Mehrheit nennt man Quorum.

Bei einem Cluster mit drei etcd-Mitgliedern müssen mindestens zwei erreichbar sein. Fallen zwei aus oder ist die Verbindung unterbrochen, können keine konsistenten Schreiboperationen mehr durchgeführt werden.

Typische Symptome

  • Der Cluster reagiert kaum noch
  • Änderungen lassen sich nicht mehr speichern
  • Der API-Server wirkt teilweise komplett blockiert

Was in diesem Fall hilft

Wenn möglich, müssen genug etcd-Mitglieder wieder online gebracht werden, damit das Quorum zurückkommt. Falls das nicht gelingt, bleibt oft nur die Wiederherstellung aus einem funktionierenden Backup.

Genau hier zeigt sich, wie wichtig ein getesteter Recovery-Prozess ist.

6. Kein Backup – der größte Fehler von allen

Viele Teams beschäftigen sich erst mit etcd-Backups, wenn bereits etwas schiefgelaufen ist. Dann ist es meistens zu spät.

Da etcd die zentrale Wahrheit des Kubernetes-Clusters speichert, ist ein Backup kein nettes Extra, sondern absolute Pflicht.

Snapshot erstellen

etcdctl snapshot save backup.db

Restore testen

etcdctl snapshot restore backup.db

Wichtig ist nicht nur, regelmäßig Snapshots zu erstellen. Genauso wichtig ist es, die Wiederherstellung wirklich zu testen. Ein Backup, das nie erfolgreich zurückgespielt wurde, ist im Ernstfall nur eine Hoffnung – keine Absicherung.

Was man im Alltag mit etcd schnell lernt

Die meisten etcd-Probleme haben am Ende erstaunlich ähnliche Ursachen. In der Praxis geht es meist um drei Dinge:

  • schlechte Disk-Performance
  • Netzwerkprobleme
  • fehlende Wartung

etcd ist kein Bereich, den man täglich anfassen muss. Aber es ist der Teil des Clusters, den man verstehen sollte, bevor es ernst wird. Denn wenn etcd kaputt ist, sieht Kubernetes zwar oft noch von außen nach System aus – intern ist es dann aber meist nur noch Fassade.

Fazit

Wer Kubernetes produktiv betreibt, sollte etcd nicht als Blackbox behandeln. Schon mit ein paar sauberen Routinen lassen sich die meisten Probleme vermeiden:

  • regelmäßige Backups
  • Überwachung von Latenz und Storage-Performance
  • Compaction und Defragmentierung als Wartungsroutine
  • Zertifikate im Blick behalten

Wenn diese Punkte sauber umgesetzt sind, hat man einen großen Teil der typischen etcd-Probleme bereits entschärft – bevor sie den Cluster lahmlegen.

Nach oben scrollen