Pengenalan Kubernetes (2)

Nano Yulian
5 min readNov 11, 2019

--

Bismillah, artikel kali ini merupakan lanjutan dari artikel sebelumnya yaitu Pengenalan Kuberntes (1). Arsitektur Kubernetes dan penjelasan terkait komponen-komponen di dalamnya akan menjadi bahasan kita kali ini.

(Gambar diambil dari edx.org course : LinuxFoundationX: LFS158xIntroduction to Kubernetes )

Seperti yang sudah dijelaskan pada artikel sebelumnya bahwa komponen utama pada kubernetes yaitu Master Node, Worker Node, dan Distributed Key-Value Store. Seperti yang terlihat pada gambar di atas, masing-masing komponen utama memiliki komponen-komponen pembentuk dan peran tersendiri di dalamnya. Apa dan seperti apa peran dan fungsi dari komponen-komponen tersebut, berikut penjelasan detailnya :

A. Master Node

Master Node merupakan salah satu komponen yang menyediakan lingkungan kerja bagi komponen-komponen didalamnya yang fungsi utamanya adalah mengelola keadaan dan kondisi cluster, bisa dikatakan komponen-komponen di dalam master node adalah otak dibalik semua operasi didalam sebuah cluster. Sebagian besar komponen yang ada didalam master node sering disebut sebagai komponen control plane dan merupakan agen-agen dengan peran yang sangat vital dalam manajemen cluster. Komponen yang termasuk di dalamnya antara lain (Api-Server, Controller, dan Scheduler). Sedangkan, etcd berperan sebagai tempat data (data store) yang menyimpan konfigurasi ataupun status terkini dari cluster terkait.

Untuk berkomunikasi dengan kluster Kubernetes, pengguna mengirim permintaan ke node master melalui alat Command Line Interface (CLI), Dasbor Antarmuka Pengguna Web (Web UI), atau Antarmuka Pemrograman Aplikasi (API).

Hal penting yang perlu diingat adalah bagaimana menjaga komponen control plane tetap berjalan dalam kondisi apapun. Tidak berjalannya control plane pada master node bisa mengakibatkan downtime, layanan terhadap klien terganggu, dan mungkin saja mengakibatkan kerugian terhadap bisnis. Untuk menjaga hal tersebut, biasanya master node akan direplika atau diduplikasi dan ditambahkan ke dalam cluster, konfigurasi ini biasa disebut High-Availability (HA) mode. Biasanya pada mode ini hanya salah satu dari master node (dari sekian replika master node) yang secara aktif mengelola cluster, tetapi proses sinkronisasi terhadap control plane tetap dilakukan di semua master node replika yang telah dibuat. Konfigurasi pada mode ini menambah daya tahan kepada komponen control plane sebuah cluster, jika suatu saat salah satu replika master node yang aktif mengalami kegagalan.

Untuk mempertahankan status pada cluster kubernetes, semua data yang menyimpan konfigurasi cluster disimpan pada etcd. etcd adalah implementasi dari komponen distributed key-value store yang hanya menyimpan data konfigurasi pada cluster terkait, dan tidak menyimpan data beban kerja client. etcd dapat dikonfigurasi langsung pada master node yang ada (stacked) atau bisa secara eksternal (external etcd) terpisah pada mesin lain untuk mengurangi peluang kehilangan data dengan memisahkannya dari control plane.

A.1. Master Node : API Server

Semua tugas-tugas administratif dikoordinasi oleh API Server atau sering disebut kube-apiserver. kube-apiserver termasuk komponen control plane dan merupakan komponen utama yang berjalan diatas master node. kube-apiserver menginterupsi semua permintaan layanan dengan arsitektur RESTful style baik dari pengguna, operator, dan agen eksternal lainnya, untuk selanjutnya dilakukan validasi dan memproses permintaan layanan tersebut. Selama proses tersebut berlangsung, kube-apiserver membaca status terkini dari cluster kubernetes dari etcd, dan setelah beberapa eksekusi, kube-apiserver akan menyimpan kembali status terakhir dari cluster pada etcd.

kube-apiserver berperan sebagai perantara terhadap komponen control plane lainnya dan menjadi satu-satunya komponen yang bisa berkomunikasi kepada etcd untuk membaca atau menyimpan informasi terkait kondisi dari cluster.

kube-apiserver sangat mungkin untuk dikonfigurasi dan dimodifikasi. komponen ini juga mendukung tambahan API server lain yang sudah dikustom, saat API server utama menjadi proxy terhadap semua API server lainnya (secondary) yang sudah dimodifikasi dan menyalurkan semua permintaan yang masuk (RESTful calls) kepada mereka berdasarkan aturan yang sudah ditentukan/dikustom sebelumnya.

A.2. Master Node : Scheduler

Scheduler (atau kube-scheduler) berperan untuk menetapkan (assign) objek-objek baru, seperti pods ke node tertentu. Selama proses scheduling, semua keputusan dibuat berdasarkan status dan kondisi cluster dan permintaan/persyaratan dari objek baru yang akan ditetapkan. scheduler mengambil informasi pada etcd, melalui perantara kube-apiserver, yang berisi informasi terkait sumber daya apa saja yang dibutuhkan untuk setiap worker node di dalam cluster. Scheduler juga menerima keterangan kebutuhan dan konfigurasi apa saja yang dibutuhkan terkait objek-objek baru yang akan dijalankan melalui kube-apiserver. Keterangan kebutuhan tersebut termasuk kumpulan aturan terkait user dan operator, contohnya scheduling bekerja pada node yang memiliki label disk==ssd (pasangan key/value). Scheduler juga bertanggung jawab terkait bagaimana Quality of Service (QoS) dari kebutuhan objek, data locality, affinity, anti-affinity, taints, toleransi, dsj.

Scheduler juga sangat mungkin dikustomisasi dan dikonfigurasi. Perlu diperhatikan jika suatu objek tertentu menggunakan kustom scheduler, maka hal tersebut perlu secara eksplisit diterangkan/ditulis pada data konfigurasi objek tersebut, jika tidak maka objek tersebut akan menggunakan default scheduler yang ada.

Peran scheduler akan semakin bertambah penting dan akan semakin kompleks jika kita menerapkan multi-node kubernetes cluster. Tetapi jika hanya menggunakan single-node Kubernetes cluster, tugas dari scheduler menjadi simpel.

A.3. Master Node : Controller Managers

Controller Managers adalah komponen yang berjalan pada master node, berperan dalam mengontrol dan memberikan regulasi (aturan) terkait kondisi cluster kubernetes. Controllers akan selalu melakukan monitoring secara terus menerus dan membandingkan antara kondisi cluster yang diinginkan (sesuai data konfigurasi object) dengan kondisi terkini cluster (diambil dari etcd data store via perantara kube-apiserver). Jika ada kasus ketidaksesuaian kondisi, maka aksi-aksi akan dilakukan terhadap cluster tersebut sampai kondisi cluster sesuai dengan apa yang diinginkan.

Terdapat 2 jenis controller yaitu kube-controller-manager dan cloud-controller-manager :

kube-controller-manager akan menjalankan controllers yang harus bertanggung jawab melakukan aksi tertentu saat suatu node mengalami masalah, memasitikan bahwa jumlah pod sudah sesuai, membuat endpoints, service accounts, dan API access tokens.

cloud-controller-manager akan menjalankan controllers yang harus berinteraksi dengan infrastruktur saat menggunakan provider cloud saat node mengalami masalah, mengelola volumes dr penyedia layanan cloud, dan mengelola routing dan load balancing.

A.4. Master Node : etcd

etcd adalah distributed key-value data yang digunakan untuk mempertahankan kondisi dari cluster kubernetes. Data baru akan ditulis ke dalamnya dengan menambahkannya, data yang tidak pernah diganti di dalam data store. Data yang sudah lama/usang akan dikompres untuk meminimalkan ukuran dari data store.

Dari semua komponen control plane, hanya kube-apiserver yang bisa berkomunikasi dengan etcd data store.

etcd CLI management tool memiliki fitur untuk melakukan backup, snapshot, dan restore yang bisa secara sederhana diterapkan untuk single etcd instance cluster kubernetes (direkomendasikan hanya untuk lingkungan pengembangan, bukan production). Untuk tahapan dan lingkungan production , sangatlah disarankan untuk mereplika data store dalam HA mode, untuk ketahanan data konfigurasi cluster.

Beberapa tools bootstrapping cluster kubernetes, secara default, akan menerapakan aturan stacked etcd master nodes, dimana data store berjalan bersamaan dan berbagi sumberdaya kepada komponen control plane lainnya pada master node yang sama. Untuk tujuan isolasi data store dari komponen control plane, proses bootstrapping juga bisa dikonfigurasi melalui external etcd, dimana data store disediakan pada host tersendiri yang terpisah, untuk menghindari kegagalan etcd. kedua konfigurasi baik stacked maupun external etcd semuanya mendukung konfigurasi HA. etcd berbasis Raft Concencus Algorithm yang mengizinkan kumpulan mesin bekerja sebagai grup yang koheren (kompak) yang dapat bertahan dari kegagalan beberapa anggotanya. Pada waktu tertentu, salah satu simpul dalam grup akan menjadi master, dan sisanya adalah para pengikut. Setiap node dapat diperlakukan sebagai master.

(Gambar diambil dari edx.org course : LinuxFoundationX: LFS158xIntroduction to Kubernetes )

Sepertinya sudah kepanjangan ya padahal baru Master Node :), mungkin sampai sini dulu, terkait penjelasan komponen pada Worker Node Insya Allah akan dilanjutkan pada artikel berikutnya “Pengenalan Kubernetes (3)”. Trims.

(Mohon Maaf jika ada kesalahan dalam definisi, sumber, dan penulisan, Mohon koreksinya.)

Referensi :

  1. https://courses.edx.org/courses/course-v1:LinuxFoundationX+LFS158x+2T2019/course/
  2. https://kubernetes.io/

--

--