Arsitektur Kubernetes terdiri dari dua bagian besar: control plane yang bertugas mengatur seluruh cluster, dan worker node tempat aplikasi kamu benar-benar berjalan. Control plane berisi kube-apiserver, etcd, scheduler, dan controller-manager. Worker node berisi kubelet, kube-proxy, dan container runtime seperti containerd. Semua komunikasi antar komponen lewat satu pintu, yaitu kube-apiserver.

Kalau di dua bagian sebelumnya kita sudah install Minikube dan paham posisi Kubernetes dibanding Docker, sekarang saatnya membuka kap mesinnya. Artikel ini bagian ketiga dari seri Belajar Kubernetes dari Nol. Kita akan bedah tiap komponen, lihat langsung wujudnya di Minikube, lalu telusuri perjalanan satu perintah kubectl apply dari terminal sampai container menyala di node.

Prasyarat Sebelum Mulai

Kamu butuh Minikube yang sudah jalan. Di seri ini saya pakai Minikube v1.36.0 dengan Kubernetes v1.33 dan driver Docker. Kalau belum install, kembali dulu ke bagian pertama seri. Kalau masih bingung kenapa Kubernetes perlu banyak komponen padahal Docker terlihat sederhana, baca dulu Belajar Kubernetes #2: Perbedaan Docker dan Kubernetes. Bagian itu menjelaskan kenapa orkestrasi butuh “otak” terpisah dari mesin yang menjalankan container.

Pastikan cluster hidup:

minikube status

Output yang diharapkan:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Gambaran Besar: Control Plane vs Worker Node

Bayangkan cluster Kubernetes sebagai sebuah kantor. Control plane adalah lantai manajemen. Worker node adalah lantai produksi tempat pekerjaan dikerjakan. Manajemen tidak pernah mengerjakan produksi langsung. Mereka hanya mencatat pesanan, memutuskan siapa mengerjakan apa, lalu memantau hasilnya.

+--------------------- CONTROL PLANE ---------------------+
|                                                          |
|   +----------------+        +---------------------+     |
|   | kube-apiserver |<------>|        etcd         |     |
|   |  (pintu masuk) |        |  (penyimpan state)  |     |
|   +-------+--------+        +---------------------+     |
|           ^                                              |
|           |                                              |
|   +-------+--------+        +---------------------+     |
|   | kube-scheduler |        | controller-manager  |     |
|   +----------------+        +---------------------+     |
|                                                          |
+---------------------------+------------------------------+
                            |
              semua lewat apiserver (HTTPS)
                            |
+--------------------- WORKER NODE ------------------------+
|                                                           |
|   +---------+     +------------+     +----------------+  |
|   | kubelet |---->| containerd |---->| container app  |  |
|   +---------+     +------------+     +----------------+  |
|                                                           |
|   +------------+                                          |
|   | kube-proxy |  (mengatur lalu lintas jaringan)         |
|   +------------+                                          |
|                                                           |
+-----------------------------------------------------------+

Di production, control plane biasanya punya server sendiri, bahkan tiga server sekaligus supaya tahan gangguan. Worker node bisa puluhan sampai ribuan. Di Minikube, semuanya dijejalkan ke satu mesin. Praktis untuk belajar, tapi konsepnya tetap sama persis.

Komponen Control Plane dan Tugasnya

kube-apiserver, Resepsionis Satu Pintu

Semua permintaan ke cluster masuk lewat kube-apiserver. Perintah kubectl, laporan dari kubelet, keputusan scheduler, semuanya. Tidak ada komponen yang boleh saling bicara langsung. Persis resepsionis kantor yang memvalidasi tamu, mencatat keperluan, lalu meneruskan ke bagian yang tepat. Apiserver juga yang memeriksa autentikasi dan otorisasi, jadi dia sekaligus satpamnya.

etcd, Lemari Arsip Cluster

etcd adalah database key-value yang menyimpan seluruh kondisi cluster. Berapa replika yang diminta, pod apa berjalan di node mana, isi ConfigMap, semuanya ada di sini. Hanya apiserver yang boleh membuka lemari arsip ini. Kalau etcd hilang tanpa backup, cluster kehilangan ingatannya. Aplikasi mungkin masih jalan sebentar, tapi cluster tidak lagi tahu apa yang seharusnya dia kelola.

kube-scheduler, Manajer Penempatan

Setiap kali ada pod baru yang belum punya node, scheduler yang memutuskan pod itu jalan di mana. Dia menimbang sisa CPU dan memori tiap node, aturan afinitas, dan batasan lain. Seperti manajer yang menerima tumpukan tugas baru lalu membagikannya ke karyawan yang bebannya paling ringan dan keahliannya cocok. Penting diingat, scheduler hanya memutuskan. Dia tidak menjalankan apa pun. Keputusannya dicatat kembali lewat apiserver.

kube-controller-manager, Supervisor yang Tidak Pernah Tidur

Controller-manager berisi banyak controller kecil yang kerjanya satu: membandingkan kondisi nyata dengan kondisi yang diinginkan, lalu mengoreksi selisihnya. Kamu minta 3 replika, ternyata satu pod mati, controller membuat penggantinya. Seperti supervisor yang tiap beberapa detik keliling lantai produksi sambil membawa daftar pesanan. Ada yang kurang, dia langsung menugaskan ulang. Pola “desired state vs actual state” ini adalah jantung cara kerja Kubernetes.

Komponen Worker Node dan Alurnya

kubelet, Mandor di Tiap Node

kubelet adalah agen yang berjalan di setiap node. Dia rajin bertanya ke apiserver, “ada pod yang ditugaskan ke node saya?” Kalau ada, dia yang mengeksekusi: minta container runtime menarik image, membuat container, lalu melaporkan statusnya balik ke apiserver. kubelet juga yang menjalankan health check ke container.

Container Runtime (containerd), Tukang yang Benar-Benar Bekerja

kubelet tidak bisa menjalankan container sendiri. Dia menyuruh container runtime lewat antarmuka standar bernama CRI (Container Runtime Interface). Runtime yang paling umum sekarang adalah containerd, yang juga dipakai Minikube secara default sejak versi 1.30-an ketika memakai driver Docker. containerd yang menarik image dari registry, membuat filesystem container, dan menjalankan prosesnya.

kube-proxy, Petugas Lalu Lintas Jaringan

kube-proxy mengatur aturan jaringan di tiap node supaya traffic ke sebuah Service bisa sampai ke pod yang tepat, meskipun pod itu pindah-pindah node. Dia bekerja dengan menulis aturan iptables atau IPVS. Kita akan sering ketemu komponen ini lagi di bagian Service nanti.

Praktik: Bedah Komponen di Minikube

Teori cukup. Sekarang buktikan semua komponen itu benar-benar ada. Di Minikube, komponen control plane sendiri dijalankan sebagai pod di namespace kube-system:

kubectl get pods -n kube-system

Output yang diharapkan kurang lebih seperti ini:

NAME                               READY   STATUS    RESTARTS   AGE
coredns-674b8bbfcf-x7k2m           1/1     Running   0          15m
etcd-minikube                      1/1     Running   0          15m
kube-apiserver-minikube            1/1     Running   0          15m
kube-controller-manager-minikube   1/1     Running   0          15m
kube-proxy-9fkq4                   1/1     Running   0          15m
kube-scheduler-minikube            1/1     Running   0          15m
storage-provisioner                1/1     Running   0          15m

Semua nama yang kita bahas ada di sana. coredns dan storage-provisioner adalah komponen tambahan, nanti kita bahas di bagian lain. Sekarang masuk ke dalam node Minikube untuk melihat kubelet, karena kubelet tidak berjalan sebagai pod melainkan sebagai service di sistem operasi node:

minikube ssh

Setelah masuk, cek kubelet dan containerd:

docker@minikube:~$ pgrep -a kubelet
1123 /var/lib/minikube/binaries/v1.33.1/kubelet --bootstrap-kubeconfig=...

docker@minikube:~$ sudo crictl ps | head -5
CONTAINER      IMAGE          CREATED         STATE     NAME
a1b2c3d4e5f6   6ba9545b2183   16 minutes ago  Running   kube-apiserver
...

crictl adalah CLI untuk bicara langsung ke container runtime lewat CRI. Dari sini terlihat jelas: apiserver, etcd, dan kawan-kawannya pada akhirnya juga cuma container yang dijalankan containerd, diasuh oleh kubelet. Ketik exit untuk keluar dari node.

Terakhir, cek ke mana sebenarnya kubectl kamu mengirim perintah:

kubectl cluster-info

Output yang diharapkan:

Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Catat alamat itu. 192.168.49.2 adalah IP node Minikube, dan 8443 adalah port kube-apiserver. Angka ini akan berguna sekali di bagian troubleshooting.

Alur Lengkap Satu Perintah kubectl apply

Sekarang gabungkan semuanya. Misal kamu menjalankan kubectl apply -f deployment.yaml yang meminta 1 replika nginx. Ini yang terjadi di balik layar, urut:

kubectl membaca kubeconfig di ~/.kube/config, menemukan alamat apiserver (di Minikube: https://192.168.49.2:8443), lalu mengirim request HTTPS berisi manifest kamu.
kube-apiserver memvalidasi request itu. Autentikasi lolos, format YAML benar, lalu objek Deployment dicatat ke etcd. Sampai sini kubectl sudah menjawab “deployment.apps/nginx created”, padahal belum ada container apa pun yang jalan.
Controller-manager melihat ada Deployment baru yang butuh 1 replika tapi realitasnya 0. Dia membuat objek Pod lewat apiserver. Pod ini statusnya Pending, belum punya node.
Scheduler melihat ada pod tanpa node. Dia menilai node yang tersedia, memilih satu, lalu mencatat keputusannya lewat apiserver.
kubelet di node terpilih melihat ada pod yang ditugaskan untuknya. Dia menyuruh containerd menarik image nginx dan menjalankan container.
kubelet melaporkan status balik ke apiserver, yang menyimpannya di etcd. Status pod berubah menjadi Running, dan itulah yang kamu lihat saat menjalankan kubectl get pods.

Perhatikan polanya. Tidak ada satu pun komponen yang saling perintah langsung. Semua menulis dan membaca lewat apiserver, mirip karyawan kantor yang berkoordinasi lewat satu sistem tiket, bukan teriak-teriakan antar meja. Pola ini yang membuat Kubernetes tahan banting. Satu komponen mati, komponen lain tinggal melanjutkan dari catatan terakhir di etcd. Pemahaman alur ini juga yang kami pakai sehari-hari di Arrazy saat menelusuri masalah deployment di server klien, karena begitu tahu alurnya, kamu tahu persis komponen mana yang harus dicurigai saat sesuatu macet.

Troubleshooting: Error yang Sering Dialami Pemula

connection refused ke port 8443

The connection to the server 192.168.49.2:8443 was refused - did you specify the right host or port?

Cara membacanya: kubectl mencoba menghubungi kube-apiserver di IP node Minikube port 8443, tapi tidak ada yang menjawab. Artinya apiserver mati, dan penyebab paling umum adalah cluster Minikube-nya memang tidak sedang berjalan, misalnya setelah laptop restart. Solusinya:

minikube status
minikube start

Kalau minikube status menunjukkan host Running tapi apiserver Stopped, jalankan minikube logs untuk melihat kenapa apiserver gagal naik. Sering kali penyebabnya resource, coba minikube start --memory=4096.

connection refused ke localhost:8080

The connection to the server localhost:8080 was refused - did you specify the right host or port?

Beda dengan error sebelumnya, yang ini alamatnya localhost:8080. Itu alamat fallback kubectl saat dia tidak menemukan kubeconfig sama sekali. Biasanya karena file ~/.kube/config hilang, variabel KUBECONFIG menunjuk file yang salah, atau kamu menjalankan kubectl sebagai user lain (misalnya pakai sudo, yang home directory-nya beda). Cek dengan kubectl config view. Kalau kosong, jalankan minikube update-context atau minikube start supaya kubeconfig ditulis ulang.

Pod kube-system CrashLoopBackOff setelah laptop sleep

Kadang setelah laptop suspend lama, kubectl get pods -n kube-system menunjukkan etcd atau apiserver restart berkali-kali. Jam internal node melompat dan sertifikat internal sempat dianggap tidak valid. Solusi paling cepat untuk lingkungan belajar:

minikube stop
minikube start

Kalau masih bermasalah juga, minikube delete lalu minikube start membuat cluster baru yang bersih. Di Minikube ini aman, karena tidak ada data production di dalamnya.

Penutup dan Lanjutan Seri

Sekarang kamu tahu isi kap mesin Kubernetes: control plane sebagai lantai manajemen dengan apiserver, etcd, scheduler, dan controller-manager, lalu worker node sebagai lantai produksi dengan kubelet, containerd, dan kube-proxy. Kamu juga sudah membuktikan sendiri komponennya lewat kubectl get pods -n kube-system dan minikube ssh, plus paham perjalanan lengkap satu kubectl apply.

Bagian berikutnya, “Belajar Kubernetes #4: Perintah Dasar kubectl”, akan fokus melatih tanganmu dengan perintah kubectl yang paling sering dipakai sehari-hari. Artikelnya terbit menyusul, pantau daftarnya di halaman hub Belajar Kubernetes dari Nol.

Belajar Kubernetes #3: Arsitektur Kubernetes Cluster