etcd ist eine verteilte Key-Value-Datenbank und speichert den kompletten Zustand eines Kubernetes-Clusters. Für Kubernetes ist etcd die eigentliche Quelle der Wahrheit: Alles, was im Cluster existiert – Pods, Deployments, Services, ConfigMaps, Nodes und Events – liegt als Objekt in etcd.
Wo wird etcd betrieben?
etcd wird innerhalb der Control Plane betrieben, meist auf denselben Maschinen wie kube-apiserver, scheduler und controller-manager. In Produktionsumgebungen betreibe ich etcd typischerweise:
- als externen etcd-Cluster auf dedizierten Nodes
- als Teil der Control-Plane-Nodes (Stacked Setup mit kubeadm)
- vollständig gemanagt durch Cloud-Provider (AKS, EKS, GKE)
Der kube-apiserver ist der einzige Dienst, der im Alltag direkt mit etcd spricht. Andere Komponenten lesen Änderungen über Watches vom API-Server, nicht direkt aus etcd.
Wie funktioniert etcd?
Verteiltes Konsensmodell
etcd basiert auf dem Raft-Protokoll. Für mich bedeutet das:
- Mehrere etcd-Instanzen bilden ein Quorum
- Ein Leader schreibt meine Änderungen
- Follower replizieren den Zustand für mich
- Ohne Quorum kann ich nicht zuverlässig schreiben
Versionierung statt Überschreiben
Ich überschreibe in etcd keine Objekte, ich erstelle neue Versionen. Wenn ich kubectl edit pod ausführe, landet für mich eine neue Objektversion in etcd, inklusive ResourceVersion und Timestamp.
Watch-Mechanismus
etcd informiert Kubernetes eventbasiert. Controller beobachten über den API-Server, dass „mein“ gespeicherter Zustand sich geändert hat, etwa:
- Deployment → ReplicaSet
- ReplicaSet → Pods
- Service → Endpoints
Beispiele aus meiner Nutzung
Beispiel 1 – Ich lege einen Service an
kubectl apply -f service.yaml Für mich schreibt der kube-apiserver ein Service-Objekt in etcd. Der Endpoints-Controller erzeugt anschließend Einträge, die ebenfalls in etcd landen.
Beispiel 2 – Ich verliere den Leader
In meinem Testlab stoppte ich einen etcd-Node. Für mich konnte ich noch schreiben, weil das Quorum erhalten blieb. Beim Stop von zwei
Beispiel 3 – Ich beobachte ResourceVersions
Ich führte kubectl get pods -o yaml aus und sah für mich: metadata.resourceVersion. Genau diese Version kommt direkt aus etcd und schützt mich vor konkurrierenden inkonsistenten Änderungen.
Meine Betriebs-Erkenntnisse über etcd
- Für mich sind Backups
- etcd braucht schnelle SSD und niedrige Latenz
- Ich muss Quorum-Health überwachen
- Defragmentation ist für mich regelmäßig nötig
- Zertifikate in etcd sind für mich kritisch
Ich habe gelernt: etcd ist empfindlicher als meine Worker-Nodes. Schlechte Disk-Performance führte bei mir sofort zu langsamer API.
Fazit
etcd speichert für mich den kompletten Kubernetes-Zustand und läuft innerhalb der Control Plane. Es arbeitet verteilt mit Raft-Konsens und Versionierung. Für mich ist klar: Ein gesunder kube-apiserver braucht vor allem ein gesundes etcd.