Apa yang dimaksud dengan etcd?

Seperti halnya semua beban kerja terdistribusi, beban kerja kontainer memerlukan manajemen yang kompleks, dan kompleksitas ini semakin meningkat seiring dengan bertambahnya skala beban kerja tersebut. Kubernetes menyederhanakan pengelolaan beban kerja dengan mengoordinasikan berbagai tugas, seperti konfigurasi, penerapan, penemuan layanan, penyeimbangan beban, penjadwalan pekerjaan, dan pemantauan kondisi di seluruh klaster yang berjalan di banyak mesin dan lokasi yang berbeda.

Untuk mencapai koordinasi ini, Kubernetes memerlukan penyimpanan data yang menyediakan sumber kebenaran yang konsisten mengenai status sistem—termasuk semua klaster, pemalut, dan instansi aplikasi—pada suatu titik waktu tertentu. etcd adalah penyimpanan data yang digunakan untuk menyimpan dan memelihara sumber kebenaran ini.

etcd memiliki peran yang sama pada Cloud Foundry— sebuah platform sumber terbuka multicloud Platform-as-a-Service (PaaS)— dan merupakan solusi ideal untuk mengoordinasikan sistem serta metadata penting di seluruh klaster aplikasi terdistribusi. Nama "etcd" berasal dari konvensi penamaan di struktur direktori Linux: Pada sistem UNIX, semua berkas konfigurasi sistem disimpan dalam folder bernama "/etc"; sedangkan "d" adalah singkatan dari "distributed".

Bukan tugas mudah untuk berfungsi sebagai tulang punggung data yang menjaga agar beban kerja terdistribusi tetap berjalan. Namun, etcd dibangun khusus untuk tugas ini, dirancang dari dasar dengan kualitas-kualitas berikut:

• Direplikasi sepenuhnya: Setiap node dalam klaster etcd memiliki salinan lengkap dari penyimpanan data.
  
  
• Sangat tersedia: etcd dirancang tanpa satu titik kegagalan, sehingga dapat mentolerir kegagalan perangkat keras dan partisi jaringan dengan baik.
  
  
• Konsisten dan dapat diandalkan: Setiap data yang dibaca akan mengembalikan versi terbaru dari data yang telah ditulis di seluruh klaster.
  
  
• Cepat: etcd telah diuji dengan benchmark mencapai 10.000 penulisan per detik.
  
  
• Aman: etcd mendukung autentikasi sertifikat klien menggunakan Transport Layer Security (TLS) secara otomatis, serta menyediakan lapisan soket aman (SSL) sebagai opsi. Karena etcd menyimpan data konfigurasi yang penting dan sensitif, administrator harus menerapkan kontrol akses berbasis peran dan memastikan bahwa anggota tim yang berinteraksi dengan etcd hanya diberikan akses minimum yang diperlukan untuk menyelesaikan tugas mereka.
  
  
• Sederhana: Aplikasi apa pun, dari aplikasi web sederhana hingga mesin orkestrasi kontainer kompleks seperti Kubernetes, dapat membaca atau menulis data ke etcd menggunakan alat HTTP/JSON standar.

Perlu dicatat bahwa kinerja etcd sangat bergantung pada kecepatan disk penyimpanan, sehingga sangat disarankan untuk menggunakan SSD di lingkungan etcd.

etcd dibangun menggunakan algoritma konsensus Raft untuk memastikan konsistensi penyimpanan data di semua node dalam klaster—sebuah dasar yang penting untuk sistem terdistribusi yang tahan terhadap kegagalan.

Raft mencapai konsistensi ini melalui pemilihan node pemimpin yang mengelola replikasi data ke node lainnya dalam klaster, yang disebut pengikut. Pemimpin menerima permintaan dari klien dan kemudian meneruskannya ke node pengikut. Setelah pemimpin memastikan bahwa sebagian besar node pengikut telah menyimpan permintaan baru sebagai entri log, pemimpin menerapkan entri tersebut ke mesin status lokalnya dan mengembalikan hasil—'penulisan'—kepada klien. Jika pengikut mengalami kerusakan atau paket jaringan hilang, pemimpin mencoba lagi hingga semua pengikut telah menyimpan semua entri log secara konsisten.

Jika sebuah node pengikut gagal menerima pesan dari pemimpin dalam interval waktu yang ditentukan, sebuah pemilihan diadakan untuk memilih pemimpin baru. Pengikut menyatakan dirinya sebagai kandidat, dan pengikut lain memilihnya atau node lain berdasarkan ketersediaannya. Setelah pemimpin baru terpilih, ia mulai mengelola replikasi, dan prosesnya berulang. Proses ini memungkinkan semua node etcd untuk mempertahankan cakupan penyimpanan data yang sangat tersedia dan direplikasi secara konsisten.

etcd termasuk di antara komponen inti Kubernetes dan berfungsi sebagai toko nilai kunci utama untuk membuat cluster Kubernetes yang berfungsi dan toleran kesalahan. Server API Kubernetes toko data status setiap cluster di etcd. Kubernetes menggunakan fungsi "watch" etcd untuk memantau data ini dan untuk mengkonfigurasi ulang dirinya sendiri ketika perubahan terjadi. Fungsi "watch" menyimpan nilai yang mewakili kondisi aktual dan ideal dari klaster dan dapat memulai respons ketika keduanya berbeda.

Untuk gambaran umum tingkat tinggi tentang bagaimana Kubernetes mengelola cluster, layanan, node pekerja, silakan lihat video kami "Kubernetes Explained":

etcd diciptakan oleh tim yang sama yang bertanggung jawab untuk merancang CoreOS Container Linux, sistem operasi kontainer yang banyak digunakan yang dapat dijalankan dan dikelola secara efisien dalam skala besar. Mereka awalnya membangun etcd di Raft untuk mengoordinasikan beberapa salinan kontainer Linux secara bersamaan, untuk memastikan waktu aktif aplikasi tanpa gangguan.

Pada bulan Desember 2018, tim menyumbangkan etcd ke Cloud Native Computing Foundation (CNCF), sebuah organisasi nirlaba netral yang memelihara kode sumber etcd, domain, layanan yang dihosting, infrastruktur cloud, dan properti proyek lainnya sebagai sumber daya dari sumber terbuka untuk komunitas pengembangan cloud berbasis kontainer. CoreOS telah bergabung dengan Red Hat.

Basis data lain telah dikembangkan untuk mengelola informasi koordinat antara seluruh kluster aplikasi terdistribusi. Dua yang paling umum dibandingkan dengan etcd adalah ZooKeeper dan Consul.

ZooKeeper awalnya dibuat untuk mengoordinasikan data konfigurasi dan metadata di seluruh kluster Apache Hadoop. (Apache Hadoop adalah kerangka kerja sumber terbuka, atau kumpulan aplikasi, untuk menyimpan dan memproses data dalam jumlah besar pada kluster perangkat keras komoditas.) ZooKeeper lebih tua dari etcd, dan pelajaran yang dipetik dari bekerja dengan ZooKeeper memengaruhi desain etcd.

Sebagai Hasil, etcd memiliki beberapa kemampuan penting yang tidak dimiliki ZooKeeper. Misalnya, tidak seperti ZooKeeper, etcd dapat melakukan hal berikut:

• Memungkinkan konfigurasi ulang keanggotaan cluster secara dinamis.
  
  
• Tetap stabil saat melakukan operasi baca/tulis di bawah beban tinggi.
  
  
• Memelihara model data kontrol konkurensi multi-versi.
  
  
• Menawarkan pemantauan kunci yang andal yang tidak pernah menghentikan kejadian tanpa memberikan pemberitahuan.
  
  
• Gunakan primitif konkurensi yang memisahkan koneksi dari sesi.
  
  
• Mendukung berbagai macam bahasa dan kerangka kerja (ZooKeeper memiliki protokol Jute RPC khusus yang mendukung binding bahasa terbatas).

Consul adalah solusi jaringan layanan untuk sistem terdistribusi, yang kemampuannya berada di antara kemampuan etcd dan mesh layanan Istio untuk Kubernetes. Seperti etcd, Consul menyertakan penyimpanan nilai kunci terdistribusi berdasarkan algoritma Raft dan mendukung antarmuka pemrograman aplikasi HTTP/JSON. Keduanya menawarkan konfigurasi keanggotaan klaster dinamis, tetapi Consul tidak begitu kuat mengontrol beberapa versi data konfigurasi yang bersamaan, dan ukuran basis data maksimum yang dapat diandalkan lebih kecil.

Seperti etcd, Redis adalah alat sumber terbuka, tetapi fungsi dasarnya berbeda.

Redis adalah penyimpanan data dalam memori dan dapat berfungsi sebagai basis data, cache, atau perantara pesan. Redis mendukung berbagai tipe data dan struktur daripada etcd dan memiliki kinerja baca/tulis yang jauh lebih cepat.

Tetapi etcd memiliki toleransi kesalahan yang unggul, failover yang lebih kuat, dan kemampuan ketersediaan data berkelanjutan, dan, yang paling penting, etcd menyimpan semua data yang disimpan ke disk, pada dasarnya mengorbankan kecepatan untuk keandalan yang lebih besar dan konsistensi yang terjamin. Untuk alasan ini, Redis lebih cocok untuk berfungsi sebagai sistem caching memori terdistribusi daripada untuk toko dan mendistribusikan informasi konfigurasi sistem.