etcd adalah sistem penyimpanan nilai kunci terdistribusi sumber terbuka yang digunakan untuk menyimpan dan mengelola informasi penting yang dibutuhkan sistem terdistribusi agar tetap berjalan. Utamanya, sistem tersebut mengelola data konfigurasi, data status, dan metadata untuk Kubernetes, platform orkestrasi kontainer populer.

Seperti semua beban kerja terdistribusi, beban kerja terkontainerisasi memiliki persyaratan manajemen kompleks yang menjadi makin kompleks seiring bertambahnya beban kerja. Kubernetes menyederhanakan proses pengelolaan beban kerja ini dengan mengoordinasikan tugas seperti konfigurasi, penyebaran, penemuan layanan, penyeimbangan beban, penjadwalan kerja, dan pemantauan kesehatan di semua klaster, yang dapat berjalan di beberapa mesin di beberapa lokasi.

Namun untuk mencapai koordinasi ini, Kubernetes memerlukan sistem penyimpanan data yang menyediakan satu sumber kebenaran yang konsisten tentang status sistem—semua klaster dan pod-nya serta instans aplikasi di dalamnya—pada titik waktu tertentu. etcd adalah sistem penyimpanan data yang digunakan untuk membuat dan memelihara versi kebenaran ini.

etcd menjalankan peran serupa bagi Cloud Foundry (tautan berada di luar ibm.com)—Platform-as-a-Service (PaaS) multicloud sumber terbuka—dan merupakan opsi yang tepat untuk mengoordinasikan sistem dan metadata penting di seluruh klaster aplikasi terdistribusi. Nama "etcd" berasal dari konvensi penamaan dalam struktur direktori Linux: Di UNIX, semua file konfigurasi sistem untuk satu sistem terdapat dalam folder bernama "/etc;" "d" singkatan dari "distributed" (terdistribusi).

Lihat video "Apa itu etcd?" untuk mempelajari lebih dalam (6:09):

Bukanlah tugas yang mudah untuk berperan sebagai tulang punggung data yang menjaga agar beban kerja terdistribusi tetap berjalan. Namun etcd dibuat untuk tugas tersebut, yang dirancang dari dasar ke atas untuk kualitas berikut:

• Direplikasi sepenuhnya: Setiap nodus di klaster etcd memiliki akses penyimpanan data lengkap.
  
  
• Sangat tersedia:etcd dirancang untuk tidak memiliki satu titik kegagalan dan dengan baik menolerir kegagalan perangkat keras dan partisi jaringan.
  
  
• Konsisten dan dapat diandalkan:Setiap data 'baca' mengembalikan data terbaru 'tulis' di semua klaster.
  
  
• Cepat:Tolok ukur etcd telah ditetapkan pada 10.000 penulisan per detik.
  
  
• Aman:etcd mendukung Transport Layer Security (TLS) otomatis dan autentikasi sertifikat klien Secure Socket Layer (SSL) opsional. Karena etcd menyimpan data konfigurasi vital yang sangat sensitif, administrator harus menerapkan kontrol akses berbasis peran dalam penyebaran dan memastikan bahwa anggota tim yang berinteraksi dengan etcd dibatasi pada level akses yang paling tidak diistimewakan yang diperlukan untuk melakukan pekerjaan mereka.
  
  
• Simpel:Aplikasi apa pun, dari aplikasi web simpel hingga mesin orkestrasi kontainer yang sangat kompleks seperti Kubernetes, dapat membaca atau menulis data pada etcd menggunakan  alat HTTP/JSON standar.

Perhatikan bahwa karena kinerja etcd sangat bergantung pada kecepatan disk penyimpanan, sehingga sangat disarankan untuk menggunakan SSD di lingkungan etcd. Untuk informasi lebih lanjut tentang hal ini dan persyaratan penyimpanan etcd lainnya, lihat "Menggunakan Fio untuk Mengetahui Apakah Penyimpanan Anda Cukup Cepat untuk etcd."

etcd dibangun dengan algoritma konsensus Raft untuk memastikan konsistensi sistem penyimpanan data di semua nodus dalam klaster—stake tabel untuk sistem terdistribusi yang toleran kesalahan.

Raft mencapai konsistensi ini melalui nodus leader terpilih yang mengelola replikasi untuk nodus lain di klaster, yang disebut follower. Leader menerima permintaan dari klien, yang kemudian diteruskan ke nodus follower. Setelah leader memastikan bahwa mayoritas nodus follower telah menyimpan tiap permintaan baru sebagai entri log, leader menerapkan entri tersebut pada mesin status lokalnya dan mengembalikan hasil eksekusi itu—sebuah 'tulis'—kepada klien. Jika follower crash atau paket jaringan hilang, leader mencoba lagi sampai semua follower telah menyimpan semua entri log secara konsisten.

Jika nodus follower gagal menerima pesan dari leader dalam interval waktu yang ditentukan, pemilihan diadakan untuk memilih leader baru. Follower menyatakan dirinya sebagai kandidat, dan follower lainnya memberikan suara kepadanya atau segala nodus lainnya berdasarkan ketersediaannya. Setelah leader baru terpilih, ia mulai mengelola replikasi, dan proses itu pun berulang. Proses ini memungkinkan semua nodus etcd untuk memelihara rangkaian sistem penyimpanan data dengan ketersediaan tinggi yang direplikasi secara konsisten.

etcd disertakan di antara komponen Kubernetes inti dan berfungsi sebagai sistem penyimpanan nilai utama primer untuk membuat klaster Kubernetes toleran kesalahan yang berfungsi. Server API Kubernetes menyimpan tiap data status klaster di etcd. Kubernetes menggunakan fungsi "watch" etcd untuk memantau data ini dan mengonfigurasi ulang sendiri ketika terjadi perubahan. Fungsi "watch" menyimpan nilai yang merepresentasikan status klaster aktual dan ideal dan dapat memulai respons ketika menyimpang.

Untuk ikhtisar tingkat tinggi tentang bagaimana Kubernetes mengelola klaster, layanan, nodus pekerja, silakan lihat video kami "Penjelasan Kubernetes":

etcd dibuat 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 pada skala masif. Mereka awalnya membangun etcd di Raft untuk mengoordinasikan beberapa salinan Container Linux secara bersamaan, guna memastikan waktu aktif aplikasi yang tidak terputus.

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

Basis data lain telah dikembangkan untuk mengelola informasi koordinat di antara klaster aplikasi terdistribusi. Dua yang paling sering dibandingkan dengan etcd adalah ZooKeeper dan Consul.

ZooKeeper

ZooKeeper awalnya dibuat untuk mengoordinasikan data konfigurasi dan metadata di seluruh klaster Apache Hadoop. (Apache Hadoop (tautan berada di luar ibm.com)  adalah kerangka sumber terbuka, atau koleksi aplikasi, untuk menyimpan dan memproses data dalam jumlah besar pada klaster perangkat keras komoditas.) ZooKeeper hadir lebih awal dari etcd, dan pelajaran yang didapat dari bekerja dengan ZooKeeper memengaruhi desain etcd.

Alhasil, etcd memiliki beberapa kapabilitas penting yang tidak dimiliki ZooKeeper. Contohnya, tidak seperti ZooKeeper, etcd dapat melakukan hal berikut:

• Memungkinkan rekonfigurasi dinamis keanggotaan klaster.
  
  
• Tetap stabil saat melakukan operasi baca/tulis di bawah beban tinggi.
  
  
• Mempertahankan model data kontrol konkurensi multiversi.
  
  
• Menawarkan pemantauan utama andal yang tidak pernah menghentikan peristiwa tanpa memberikan notifikasi.
  
  
• Menggunakan primitif konkurensi yang memutus koneksi dari sesi.
  
  
• Mendukung berbagai bahasa dan kerangka kerja (ZooKeeper memiliki protokol Jute RPC kustom sendiri yang mendukung ikatan bahasa yang terbatas).

Consul

Consul adalah solusi jejaring layanan untuk sistem terdistribusi, yang kapabilitasnya berada di antara etcd dan jaring layanan Istio untuk Kubernetes. Seperti etdc, Consul (tautan berada di luar ibm.com) menyertakan sistem penyimpanan nilai utama terdistribusi berdasarkan algoritma Raft dan mendukung antarmuka pemrograman aplikasi (API) HTTP/JSON. Keduanya menawarkan konfigurasi keanggotaan klaster dinamis, tetapi Consul tidak mengontrol dengan kuat terhadap beberapa versi konkuren dari data konfigurasi, dan ukuran basis data maksimum yang dapat dikerjakannya dengan andal lebih kecil.

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

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

Namun etcd memiliki toleransi kesalahan yang lebih baik, failover yang lebih kuat, dan kapabilitas ketersediaan data berkelanjutan, dan yang paling penting, etcd mempertahankan semua data yang disimpan ke disk, yang pada dasarnya mengorbankan kecepatan untuk keandalan yang lebih besar dan jaminan konsistensi. Karena alasan ini, Redis lebih cocok berfungsi sebagai sistem caching memori terdistribusi daripada untuk penyimpanan dan informasi konfigurasi sistem terdistribusi.