Etcd & Cluster Consistency #
Etcd adalah database yang menyimpan seluruh state cluster Kubernetes — setiap Pod, setiap Deployment, setiap Secret, setiap konfigurasi. Jika API Server adalah pintu masuk cluster, Etcd adalah ingatannya. Tanpa Etcd, cluster tidak tahu apa-apa: tidak tahu Pod mana yang seharusnya berjalan, tidak tahu Service mana yang ada, tidak tahu siapa yang punya akses ke apa. Memahami Etcd berarti memahami fondasi yang menjamin konsistensi seluruh cluster.
Apa Itu Etcd? #
Etcd adalah key-value store terdistribusi yang dirancang untuk menyimpan data konfigurasi yang perlu diakses secara konsisten oleh banyak node. Ia dibuat oleh CoreOS (sekarang bagian dari Red Hat) dan menjadi pilihan penyimpanan state Kubernetes sejak awal.
Etcd menyimpan semua resource Kubernetes dalam struktur key-value:
Key Value
─────────────────────────────────────────── ────────────────────
/registry/pods/default/api-abc123 → JSON serialized Pod object
/registry/deployments/prod/payment-api → JSON serialized Deployment
/registry/services/kube-system/kubernetes → JSON serialized Service
/registry/secrets/default/db-creds → JSON serialized Secret (encrypted)
/registry/configmaps/default/app-config → JSON serialized ConfigMap
/registry/leases/kube-system/kube-scheduler → JSON serialized Lease (leader election)
Setiap kali kamu menjalankan kubectl get pods, API Server membaca dari Etcd (atau cache-nya) dan mengembalikan hasilnya. Setiap kali kamu kubectl apply, API Server menulis perubahan ke Etcd dan semua komponen yang watch akan mendapat notifikasi.
Raft Consensus Protocol #
Etcd tidak berjalan sebagai single node di cluster produksi — ia berjalan sebagai cluster terdistribusi (biasanya 3 atau 5 node) untuk toleransi kegagalan. Ini menimbulkan pertanyaan: bagaimana memastikan semua node Etcd selalu punya data yang sama?
Etcd menggunakan Raft consensus protocol. Raft memastikan bahwa semua write yang berhasil telah diakui oleh majority nodes sebelum dianggap committed.
Raft dalam cluster Etcd 3 node:
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Etcd 1 │ │ Etcd 2 │ │ Etcd 3 │
│ (leader) │ │(follower) │ │(follower) │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
│ API Server menulis ke leader│
│◄──────────────────────────────┘
│
│ Leader replikasi ke semua follower
├──────────────────────────────►│ (Etcd 2: OK)
├──────────────────────────────► (Etcd 3: OK)
│
│ Majority (2 dari 3) mengakui
▼
Write committed → API Server mendapat konfirmasi
Quorum adalah konsep kunci di sini. Untuk cluster dengan N node, quorum = N/2 + 1 (pembulatan ke atas). Write hanya bisa berhasil jika quorum terpenuhi.
Tabel toleransi kegagalan:
Jumlah Node Quorum Toleransi Kegagalan
─────────── ────── ───────────────────
1 1 0 node
3 2 1 node
5 3 2 node
7 4 3 node
Gunakan angka ganjil — menambah node genap tidak meningkatkan toleransi:
4 node: quorum = 3, toleransi = 1 ← sama dengan 3 node, tapi lebih mahal
5 node: quorum = 3, toleransi = 2 ← lebih baik
Ketika jumlah node yang tersedia jatuh di bawah quorum, Etcd berhenti menerima write — cluster masuk mode read-only. Ini mencegah split-brain: situasi di mana dua bagian cluster yang terpisah masing-masing menganggap dirinya leader dan membuat keputusan yang konfliktual.
Strong Consistency vs Eventual Consistency #
Etcd menggunakan strong consistency (linearizability), bukan eventual consistency. Ini artinya setelah sebuah write berhasil, setiap read berikutnya — dari node Etcd manapun — dijamin mengembalikan data yang terbaru.
Strong consistency (yang Etcd gunakan):
Client A menulis: Pod X = Running (jam 10:00:01)
Client B membaca: Pod X = ?
Dengan strong consistency:
→ Client B SELALU mendapat Running, tidak peduli dari node mana ia membaca
Eventual consistency (yang TIDAK digunakan Etcd):
→ Client B MUNGKIN mendapat nilai lama untuk beberapa saat
→ Tergantung apakah node yang dibaca sudah ter-replikasi atau belum
Strong consistency membuat Etcd sedikit lebih lambat dari database eventual consistency, tapi ini trade-off yang tepat untuk sistem konfigurasi yang memerlukan keakuratan tinggi. Kamu tidak ingin Scheduler membuat keputusan berdasarkan data yang sudah stale.
Perlu dibedakan antara konsistensi Etcd (strong) dan konsistensi dari perspektif pengguna Kubernetes (eventual). Ketika kamu kubectl apply sebuah Deployment, perubahan tersedia di Etcd secara instan, tapi Pod yang sebenarnya mungkin butuh 30-60 detik untuk berjalan. Kubernetes sebagai sistem adalah eventually consistent — tapi Etcd sebagai storage adalah strongly consistent.Watch dan Notifikasi #
Etcd mendukung mekanisme watch yang sangat penting bagi Kubernetes. Komponen seperti Scheduler dan Controller Manager tidak terus-menerus polling Etcd — mereka membuka watch connection dan menerima notifikasi saat ada perubahan.
Watch mechanism di Etcd:
API Server membuka watch ke Etcd:
WATCH /registry/pods/
Etcd mengirim notifikasi setiap ada perubahan:
{"type":"PUT", "kv":{"key":"/registry/pods/default/api-abc", "value":"..."}}
{"type":"PUT", "kv":{"key":"/registry/pods/default/api-def", "value":"..."}}
{"type":"DELETE","kv":{"key":"/registry/pods/default/api-xyz","value":"..."}}
API Server meneruskan notifikasi ke komponen yang watch (Scheduler, Controller, dll.)
Setiap notifikasi menyertakan revision number — nomor urut yang menunjukkan urutan perubahan di Etcd. Komponen bisa reconnect dan melanjutkan dari revision tertentu jika koneksi terputus, sehingga tidak ada event yang terlewat.
Performa dan Kapasitas Etcd #
Etcd memiliki karakteristik performa yang penting untuk dipahami, terutama saat cluster tumbuh besar.
Write latency adalah bottleneck utama. Setiap write harus di-replikasi ke majority nodes sebelum committed — ini membutuhkan round-trip network. Di cluster produksi dengan node Etcd yang terdistribusi secara geografis, latency ini bisa signifikan.
Rekomendasi setup Etcd untuk produksi:
Hardware:
→ SSD untuk storage (bukan HDD) — Etcd sangat sensitif terhadap disk latency
→ CPU: minimal 2 core per node Etcd
→ Memory: minimal 8 GB per node (lebih besar untuk cluster besar)
→ Network: latensi antar node Etcd < 10ms untuk performa optimal
Ukuran database:
→ Default quota: 2 GB
→ Cluster besar bisa butuh 4-8 GB
→ Perlu compaction reguler untuk membersihkan revision history lama
Compaction adalah proses membersihkan revision history lama. Etcd menyimpan setiap versi dari setiap key, bukan hanya yang terbaru. Tanpa compaction reguler, database terus membesar.
# Cek ukuran database Etcd
ETCDCTL_API=3 etcdctl endpoint status --write-out=table
# Compaction manual (hapus semua revision sebelum revision 1000)
ETCDCTL_API=3 etcdctl compact 1000
# Defragmentasi setelah compaction (bebaskan disk space)
ETCDCTL_API=3 etcdctl defrag
Backup dan Restore #
Backup Etcd adalah satu-satunya cara untuk memulihkan cluster jika terjadi bencana. Kehilangan Etcd tanpa backup berarti kehilangan seluruh state cluster — semua konfigurasi harus direkonstruksi dari nol.
# Backup Etcd snapshot
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
# Verifikasi snapshot
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-snapshot.db --write-out=table
# Restore dari snapshot (jalankan di semua Etcd node, cluster harus di-stop dahulu)
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db \
--name=etcd-1 \
--data-dir=/var/lib/etcd-restored \
--initial-cluster=etcd-1=https://10.0.0.1:2380,etcd-2=https://10.0.0.2:2380 \
--initial-cluster-token=etcd-cluster-1 \
--initial-advertise-peer-urls=https://10.0.0.1:2380
Restore Etcd adalah operasi yang kompleks dan destruktif — cluster harus dihentikan sepenuhnya selama proses restore. Lakukan backup secara otomatis dan terjadwal (minimal sekali sehari untuk produksi), simpan backup di tempat terpisah dari cluster, dan uji proses restore secara reguler di environment non-produksi. Backup yang tidak pernah diuji sama dengan tidak punya backup.
Etcd dalam Managed Kubernetes #
Jika kamu menggunakan managed Kubernetes (GKE, EKS, AKS), Etcd dikelola sepenuhnya oleh cloud provider. Kamu tidak punya akses langsung ke Etcd, tidak perlu melakukan backup manual, dan tidak perlu khawatir tentang compaction atau upgrade.
Managed vs Self-managed Etcd:
Managed (GKE/EKS/AKS):
✓ Backup otomatis dikelola provider
✓ HA dan failover otomatis
✓ Upgrade ditangani provider
✗ Tidak ada akses langsung ke Etcd
✗ Tidak bisa customisasi konfigurasi Etcd
Self-managed:
✓ Kontrol penuh atas konfigurasi
✓ Bisa akses dan inspect langsung
✗ Tanggung jawab backup ada di kamu
✗ Harus handle upgrade dan maintenance sendiri
Untuk kebanyakan organisasi, managed Kubernetes adalah pilihan yang jauh lebih pragmatis — operasional Etcd yang benar membutuhkan keahlian dan waktu yang signifikan.
Ringkasan #
- Etcd adalah memori cluster — semua state Kubernetes tersimpan di sini; kehilangan Etcd tanpa backup berarti kehilangan seluruh konfigurasi cluster.
- Raft consensus untuk strong consistency — write hanya berhasil jika majority nodes mengakui; ini menjamin tidak ada data yang inconsistent antar node.
- Selalu gunakan jumlah node ganjil — 3 node toleran 1 kegagalan, 5 node toleran 2 kegagalan; menambah node genap tidak meningkatkan toleransi.
- Strong consistency bukan eventual consistency — setelah write berhasil, read berikutnya selalu mengembalikan data terbaru, dari node manapun.
- SSD adalah kebutuhan, bukan opsional — Etcd sangat sensitif terhadap disk latency; HDD menyebabkan timeout dan instabilitas cluster.
- Backup reguler dan uji restore — backup yang tidak pernah diuji tidak bisa diandalkan; jadwalkan backup otomatis dan uji restore di environment non-produksi.