etcd Deep Dive: Het Hart van Je Kubernetes Cluster

Als er iets misgaat in Kubernetes, is het vaak etcd. API server timeout? Check etcd. Pods stuck in pending? Misschien etcd. Cluster voelt traag? Waarschijnlijk etcd.

Toch behandelen de meeste Kubernetes operators etcd als een black box. Het is gewoon “de database” die naast het control plane draait. Maar etcd begrijpen maakt je dramatisch beter in Kubernetes operaties. Laat me je meenemen naar binnen.

Wat is etcd?

etcd is een gedistribueerde key-value store. Zie het als een zeer betrouwbaar woordenboek waar meerdere servers het over eens zijn. Kubernetes gebruikt het om alle cluster state op te slaan: elke pod, deployment, secret, configmap en custom resource leeft in etcd.

De naam “etcd” komt van “/etc distributed” — de Unix /etc directory bevat systeemconfiguratie, en etcd is dat concept gedistribueerd over nodes.

Belangrijke eigenschappen:

Strongly consistent: Alle nodes zien dezelfde data op hetzelfde moment
Highly available: Overleeft node failures (met quorum)
Watch-capable: Clients kunnen subscriben op wijzigingen
Ordered: Operaties gebeuren in strikte volgorde

Het Raft Consensus Algoritme

etcd gebruikt Raft om consistentie tussen nodes te behouden. Raft begrijpen verklaart het meeste etcd gedrag.

Leader Election

In elk etcd cluster is één node de leader. De leader handelt alle writes af. Followers repliceren de log van de leader.

flowchart LR
    L["Leader<br/>(etcd1)"] -->|replicates| F1["Follower<br/>(etcd2)"]
    L -->|replicates| F2["Follower<br/>(etcd3)"]
    L -.->|heartbeats| F1
    L -.->|heartbeats| F2

De leader stuurt heartbeats naar followers. Als een follower niet van de leader hoort voor een election timeout (typisch 1-2 seconden), wordt het een candidate en start een verkiezing.

# Zie wie de leader is
etcdctl endpoint status --cluster -w table

Log Replication

Wanneer een write binnenkomt:

Client stuurt write naar leader
Leader voegt toe aan zijn log
Leader repliceert naar followers
Zodra meerderheid bevestigt, commit leader
Leader antwoordt aan client

Dit is waarom etcd een meerderheid (quorum) nodig heeft om te schrijven. Met 3 nodes heb je er 2 nodig. Met 5 heb je er 3 nodig.

Term Numbers

Elke verkiezing verhoogt het term number. Het is als een logische klok. Als een node een hogere term ziet, weet het dat een nieuwe leader gekozen is en past zich aan.

# Check cluster health en terms
etcdctl endpoint health --cluster -w table

Data Model

etcd slaat data op als key-value paren in een platte namespace. Kubernetes gebruikt een hiërarchische conventie:

/registry/pods/default/nginx-abc123
/registry/pods/kube-system/coredns-xyz789
/registry/deployments/default/my-app
/registry/secrets/default/my-secret

Alles is geprefixed met /registry/. De Kubernetes API server is eigenlijk gewoon een vertaallaag tussen de Kubernetes API en etcd’s key-value model.

Revisions en MVCC

etcd gebruikt Multi-Version Concurrency Control (MVCC). Elke modificatie creëert een nieuwe revision. Oude revisions worden bewaard (een tijdje), wat mogelijk maakt:

Watch from revision: “Vertel me alles dat veranderd is sinds revision 12345”
Historical reads: “Wat was de waarde bij revision 12345?”
Optimistic locking: “Update alleen als nog steeds op revision 12345”

# Huidige revision ophalen
etcdctl get / --prefix --limit=1 -w json | jq '.header.revision'

# Key lezen met zijn revision
etcdctl get /registry/pods/default/nginx -w json | jq '.kvs[0].mod_revision'

Waarom etcd Performance Ertoe Doet

Kubernetes is spraakzaam met etcd. Elke API call, elke controller reconciliation, elke watch notification gaat via etcd. Een trage etcd betekent een traag cluster.

Kritieke Metrics

fsync latency: Tijd om naar disk te persisteren. Moet <10ms zijn. Boven 20ms ontstaan problemen.

# Check disk latency
etcdctl check perf --load="s"

Raft proposal latency: Tijd om een write te committen via Raft. Moet <50ms zijn.

Watch count: Aantal actieve watches. Kubernetes gebruikt er duizenden.

Veelvoorkomende Performance Problemen

Trage disks: etcd schrijft synchroon naar disk. Gebruik SSDs, geen HDDs. NVMe als het kan.

Netwerk latency: Raft heartbeats en log replication hebben lage latency nodig. Houd etcd nodes op hetzelfde netwerksegment.

Te veel objecten: Een cluster met 100k pods zet meer druk op etcd dan een met 1k. Watch kardinaliteit explodeert.

Grote objecten: Secrets met enorme certificaten, ConfigMaps met megabytes data — alles gaat door etcd.

Backup van etcd

Als etcd data verloren gaat, is je cluster weg. Backup regelmatig.

# Snapshot backup
etcdctl snapshot save /backup/etcd-$(date +%Y%m%d-%H%M%S).db

# Verifieer de backup
etcdctl snapshot status /backup/etcd-*.db -w table

Voor geautomatiseerde backups:

#!/bin/bash
# /etc/cron.daily/etcd-backup

BACKUP_DIR=/var/backups/etcd
RETENTION_DAYS=7

etcdctl snapshot save $BACKUP_DIR/etcd-$(date +%Y%m%d-%H%M%S).db

# Oude backups opruimen
find $BACKUP_DIR -name "etcd-*.db" -mtime +$RETENTION_DAYS -delete

Restore van Backup

etcd restoren is serieuze business. Je reset cluster state naar een punt in tijd.

# Stop etcd op alle nodes eerst

# Restore op elke node (andere data-dir)
etcdctl snapshot restore /backup/etcd-snapshot.db \
  --name etcd1 \
  --initial-cluster etcd1=https://10.0.0.1:2380,etcd2=https://10.0.0.2:2380,etcd3=https://10.0.0.3:2380 \
  --initial-cluster-token etcd-cluster-restored \
  --initial-advertise-peer-urls https://10.0.0.1:2380 \
  --data-dir /var/lib/etcd-restored

# Start etcd met nieuwe data-dir

Na restore is alles dat gebeurde na de snapshot verloren. Pods refereren misschien verwijderde deployments. Services wijzen misschien naar niet-bestaande endpoints. Het cluster reconcileert, maar verwacht wat chaos.

Compaction en Defragmentation

etcd bewaart oude revisions tot ze gecompacteerd worden. Zonder compaction groeit de database eindeloos.

# Check huidige database grootte
etcdctl endpoint status --cluster -w table

# Compact naar revision
etcdctl compact 123456

# Defragmenteer om ruimte terug te winnen
etcdctl defrag --cluster

Kubernetes auto-compacteert etcd (geconfigureerd via --etcd-compaction-interval), maar defragmentation is handmatig.

etcd Watchen

Kubernetes controllers werken door etcd te watchen. Als iets verandert, notificeert etcd watchers direct.

# Watch alle pod wijzigingen
etcdctl watch /registry/pods --prefix

# Watch specifieke namespace
etcdctl watch /registry/pods/default --prefix

Dit is hoe de scheduler direct van nieuwe pods weet. Hoe de kubelet van pod assignments weet. Hoe alles in Kubernetes gesynchroniseerd blijft.

etcd Issues Debuggen

Hoge Latency

# Check of disk het probleem is
etcdctl check perf --load="s"

# Check cluster health
etcdctl endpoint health --cluster -w table

# Check leader changes (te veel = instabiliteit)
etcdctl endpoint status --cluster -w table

Disk Space Issues

# Check database grootte
etcdctl endpoint status --cluster -w table

# Forceer compaction en defrag
REV=$(etcdctl endpoint status -w json | jq '.[0].Status.header.revision')
etcdctl compact $REV
etcdctl defrag --cluster

Netwerk Issues

# Check of nodes elkaar kunnen bereiken
for ep in https://10.0.0.1:2379 https://10.0.0.2:2379 https://10.0.0.3:2379; do
  etcdctl --endpoints=$ep endpoint health
done

etcd in Productie

Mijn aanbevelingen voor productie etcd:

Dedicated SSDs: etcd heeft snelle, consistente disk I/O nodig. Deel geen disks met andere workloads.
Monitor meedogenloos: etcd_disk_backend_commit_duration_seconds, etcd_network_peer_round_trip_time_seconds, etcd_server_leader_changes_seen_total.
Regelmatige backups: Minstens dagelijks. Test restores periodiek.
Apart netwerk: Indien mogelijk, zet etcd traffic op een dedicated netwerk om contention te vermijden.
Right-size het cluster: 3 nodes voor de meeste workloads. 5 voor kritieke clusters. Meer dan 5 is zelden zinvol.

Conclusie

etcd is simpel in concept maar kritiek in uitvoering. Het is de basis waar al het andere op bouwt. Als etcd gezond is, is Kubernetes gezond. Als etcd worstelt, worstelt alles.

Het goede nieuws: zodra je Raft consensus, quorum en het belang van disk latency begrijpt, worden de meeste etcd problemen diagnoseerbaar. Het is geen magie — het is een goed ontworpen gedistribueerd systeem dat precies doet wat gedistribueerde systemen doen.

Behandel je etcd cluster met respect. Backup het. Monitor het. Geef het snelle disks. En het zal stil je cluster betrouwbaar draaiende houden.

etcd is de source of truth. Al het andere in Kubernetes is afgeleide state. Bescherm je source of truth.

Wat is etcd?#

Het Raft Consensus Algoritme#

Leader Election#

Log Replication#

Term Numbers#

Data Model#

Revisions en MVCC#

Waarom etcd Performance Ertoe Doet#

Kritieke Metrics#

Veelvoorkomende Performance Problemen#

Backup van etcd#

Restore van Backup#

Compaction en Defragmentation#

etcd Watchen#

etcd Issues Debuggen#

Hoge Latency#

Disk Space Issues#

Netwerk Issues#

etcd in Productie#

Conclusie#