Peta Arsitektur

Topik ini memetakan struktur sebuah kluster Kubernetes, yaitu pembagian tugas antara control plane sebagai pusat keputusan dan Node, yaitu mesin pekerja, sebagai tempat beban kerja dijalankan. Setelah topik ini dibaca, nama-nama seperti kube-apiserver, etcd, kubelet, dan kube-proxy memiliki tempat yang jelas pada peta besar, sehingga keluaran perintah diagnosis dan pesan error lebih mudah ditafsirkan. Peta ini juga menjadi rujukan saat membaca dokumentasi Kubernetes, yang selalu menyebut komponen-komponen tersebut.

Dua bagian utama kluster#

Setiap kluster Kubernetes terbagi menjadi dua bagian dengan tugas yang berbeda. Control plane, yang terdiri atas sekumpulan proses pengelola, mengambil keputusan global seperti penempatan Pod dan pemulihan keadaan. Node pekerja memproses instruksi dari control plane, menjalankan beban kerja, dan melaporkan statusnya kembali. Pembagian ini membuat keputusan terkumpul di satu tempat, sedangkan eksekusi tersebar ke semua mesin. Diagram berikut merangkum kedua bagian tersebut beserta komponen di dalamnya, dan bagian sesudahnya merinci tugas masing-masing komponen.

Pada kluster produksi, komponen control plane umumnya dijalankan sebagai beberapa replika pada mesin yang berbeda agar kegagalan satu mesin tidak menghentikan pengelolaan kluster. Pada kluster lab seperti minikube, komponen control plane dan beban kerja justru berbagi satu Node yang sama, sehingga peta di atas tetap berlaku meskipun secara fisik semuanya berada di satu tempat. Yang konsisten pada kedua bentuk adalah pembagian tugasnya, bukan penempatan fisiknya, dan pemahaman ini berguna sebelum membaca rincian setiap komponen.

Komponen control plane#

Control plane memuat empat komponen utama yang saling melengkapi. Satu komponen menjadi pintu masuk, satu menyimpan keadaan, satu memilih tempat untuk Pod baru, dan sisanya menjaga keadaan tetap sesuai tujuan. Keempatnya dapat dijalankan sebagai proses terpisah pada beberapa mesin maupun sebagai Pod statis (static Pod) pada satu mesin, tergantung cara kluster dipasang.

kube-apiserver#

kube-apiserver adalah satu-satunya komponen yang mengekspos API kluster, sehingga seluruh komunikasi masuk dan keluar control plane melewatinya. Perintah kubectl, dasbor, serta komponen control plane lain semuanya berbicara dengan kluster melalui komponen ini. Sebelum memproses permintaan, kube-apiserver memverifikasi identitas pengirim, memeriksa hak aksesnya, lalu memvalidasi bentuk objek yang diminta. Karena seluruh perubahan keadaan melewati satu pintu, aturan akses dan validasi cukup ditegakkan di satu tempat. kube-apiserver juga satu-satunya komponen yang membaca dan menulis etcd secara langsung, sehingga alat tambahan seperti sistem pemantauan cukup menyimak aliran API tanpa menyentuh penyimpanan internal.

etcd#

etcd adalah penyimpanan key-value terdistribusi yang menyimpan seluruh keadaan kluster. Daftar Node, spesifikasi Pod, data konfigurasi, hingga status setiap objek tersimpan di sini sebagai satu-satunya sumber kebenaran. Komponen lain tidak membaca etcd secara langsung, melainkan selalu melewati kube-apiserver, sehingga akses terhadap data kluster tetap terkendali. Apabila pertanyaannya adalah keadaan sebenarnya dari sebuah objek, jawabannya selalu berada di etcd, bukan di memori komponen lain. Karena datanya krusial, kluster produksi menjalankan etcd dengan jumlah replika ganjil agar tetap tersedia ketika satu mesin gagal, dan pencadangan data etcd menjadi salah satu tugas pemeliharaan paling penting.

kube-scheduler#

kube-scheduler bertugas memilih Node bagi Pod yang baru dibuat dan belum memiliki tempat. Pilihan ditentukan berdasarkan kebutuhan sumber daya Pod, batasan penempatan, serta sisa kapasitas setiap Node. Scheduler tidak menjalankan Pod, melainkan hanya menuliskan keputusan penempatan ke API server, kemudian kubelet pada Node terpilih mewujudkannya. Pod yang tidak menemukan Node dengan sisa kapasitas cukup tetap menunggu berstatus Pending sampai kapasitas tersedia.

Simulasi berikut meniru cara kerja dasar tersebut dengan strategi sederhana, yaitu memilih Node pertama yang masih menyisakan kapasitas CPU yang cukup. Pod yang tidak muat di mana pun ditandai menunggu, persis seperti Pod berstatus Pending pada kluster nyata. Perhitungan di sini hanya menimbang CPU, sedangkan penjadwal nyata juga menimbang memori dan batasan penempatan lainnya.

# Simulasi penjadwalan dengan strategi first-fit: setiap pod ditempatkan pada
# node pertama yang masih memiliki sisa kapasitas CPU yang cukup.

nodes = {
    "node-1": {"kapasitas": 2, "sisa": 2},
    "node-2": {"kapasitas": 4, "sisa": 4},
}

# antrean pod beserta permintaan CPU-nya dalam satuan core
antrean_pod = [
    ("web-1", 1),
    ("api-1", 2),
    ("api-2", 2),
    ("cache-1", 1),
    ("batch-1", 2),
]

for nama, kebutuhan in antrean_pod:
    ditempatkan = None
    for nama_node in sorted(nodes):
        if nodes[nama_node]["sisa"] >= kebutuhan:
            nodes[nama_node]["sisa"] -= kebutuhan
            ditempatkan = nama_node
            break
    if ditempatkan is not None:
        print(f"{nama} ({kebutuhan} core) -> {ditempatkan} (sisa {nodes[ditempatkan]['sisa']} core)")
    else:
        print(f"{nama} ({kebutuhan} core) -> menunggu, tidak ada node dengan sisa kapasitas cukup")

web-1 (1 core) -> node-1 (sisa 1 core)
api-1 (2 core) -> node-2 (sisa 2 core)
api-2 (2 core) -> node-2 (sisa 0 core)
cache-1 (1 core) -> node-1 (sisa 0 core)
batch-1 (2 core) -> menunggu, tidak ada node dengan sisa kapasitas cukup

Keluaran memperlihatkan Pod pertama ditempatkan pada node-1, sedangkan Pod yang membutuhkan dua core diarahkan ke node-2 karena node-1 hanya menyisakan satu core. Pod terakhir menunggu karena sisa kapasitas seluruh Node sudah habis. Pada kluster nyata, keputusan serupa diambil dengan mempertimbangkan afinitas, taint, prioritas, dan faktor lain, tetapi prinsip membandingkan kebutuhan Pod dengan sisa kapasitas Node tetap menjadi intinya.

kube-controller-manager#

kube-controller-manager menjalankan proses-proses controller, yaitu pengendali yang mengamati keadaan dan mengambil tindakan koreksi. Setiap controller memegang satu tanggung jawab, misalnya controller Node yang memantau kesehatan Node, controller replika yang menjaga jumlah Pod, dan controller tugas yang mengelola pekerjaan berbatas waktu. Semua controller bekerja dengan pola yang sama, yaitu mengamati keadaan yang diinginkan melalui API server, membandingkannya dengan keadaan aktual, lalu melakukan tindakan bila ada selisih. Pola itulah siklus rekonsiliasi, dan kube-controller-manager menjalankan banyak siklus semacam itu secara paralel. Apabila satu Node mati, controller yang relevan menandai seluruh Pod pada Node tersebut dan menugaskan penggantinya tanpa menunggu perintah manusia.

Komponen pada Node pekerja#

Setiap Node pekerja menjalankan tiga komponen sistem beserta beban kerjanya. Tugas komponen ini bersifat pelaksana, yaitu menerima keputusan dari control plane dan memastikan container benar-benar berjalan sesuai penugasan. Dari ketiganya, hanya kubelet yang berbicara langsung dengan control plane, sedangkan komponen lain bekerja di belakangnya.

kubelet#

kubelet adalah agen yang berjalan pada setiap Node dan menjadi perwakilan control plane di mesin itu. Tugas utamanya adalah memastikan container pada setiap Pod yang ditugaskan ke Node-nya berjalan sesuai spesifikasinya. kubelet membaca spesifikasi Pod dari API server, memerintahkan container runtime menyalakan atau menghentikan container, lalu melakukan pemeriksaan berkala. Status setiap Pod dan Node dilaporkan kembali ke API server, sehingga control plane selalu memiliki gambaran terkini tentang kondisi kluster. Apabila kubelet pada satu Node berhenti, Node tersebut tidak lagi menerima penugasan Pod baru karena statusnya tidak diperbarui.

kube-proxy#

kube-proxy memelihara aturan jaringan pada Node yang memungkinkan trafik mencapai Pod di dalam kluster. Aturan ini menjadi dasar bagi Service, yaitu objek yang memberikan alamat tetap untuk sekumpulan Pod yang anggotanya sering berganti. Ketika sebuah Pod mengirim permintaan ke alamat Service, aturan yang dipasang kube-proxy mengarahkan permintaan itu ke salah satu Pod tujuan. Komponen ini berjalan pada setiap Node, sehingga pengalihan trafik dapat dilakukan dari titik terdekat tanpa melewati satu pusat tunggal. Detail penerapannya bergantung pada mode yang dipilih, tetapi hasil akhirnya sama, yaitu pengalihan yang mengikuti perubahan Pod secara otomatis.

container runtime#

container runtime adalah perangkat lunak yang benar-benar mengunduh image, membuat container, serta menjalankan dan menghentikannya, dengan contoh yang umum berupa containerd dan CRI-O. kubelet tidak menjalankan container sendiri, melainkan memanggil runtime melalui antarmuka standar bernama Container Runtime Interface (CRI). Dengan antarmuka ini, runtime dapat diganti tanpa mengubah sisi Kubernetes, sehingga kluster dapat mengikuti perkembangan teknologi container. Pemisahan tugas ini menegaskan bahwa Kubernetes mengatur keadaan, sedangkan runtime mengerjakan eksekusinya. Pada komputer lab, runtime yang sama biasanya sudah terpasang karena minikube dan kind menumpangkan kluster di atas Docker.

Pod#

Pod adalah unit terkecil yang dijadwalkan pada Kubernetes. Satu Pod berisi satu atau beberapa container yang berbagi alamat jaringan dan penyimpanan yang sama, sehingga container di dalamnya berkomunikasi seolah berada di satu mesin. Kubernetes tidak menempatkan container satu per satu, melainkan selalu menempatkan Pod, karena container dalam Pod dirancang lahir dan mati bersama sebagai satu kesatuan. Pod juga bersifat efemeral, yaitu mudah dibuat dan dihentikan, sehingga alamat dan identitasnya tidak dianggap kekal oleh sistem. Seluruh komponen yang dijelaskan sebelumnya bermuara pada satu tujuan yang sama, yaitu menjaga agar Pod berjalan sesuai keadaan yang dinyatakan.

Ringkasan#

• Control plane mengambil keputusan global melalui kube-apiserver sebagai satu-satunya pintu API, etcd sebagai penyimpanan keadaan, kube-scheduler sebagai penempat Pod, dan kube-controller-manager sebagai pelaksana rekonsiliasi.
• Node pekerja menjalankan kubelet untuk mewujudkan Pod, kube-proxy untuk aturan jaringan, dan container runtime untuk eksekusi container.
• Seluruh komunikasi antarkomponen melewati kube-apiserver, sehingga aturan akses dan validasi cukup ditegakkan di satu tempat.
• Pod adalah unit terkecil yang dijadwalkan, sehingga penempatan dan pemulihan selalu berlangsung pada tingkat Pod, bukan pada container.

Referensi#

• Arsitektur Kluster — Kubernetes Documentation — Penjelasan resmi komponen control plane dan Node pekerja beserta pembagian tugasnya.
• Konsep Dasar — Kubernetes Documentation — Ikhtisar komponen kluster yang menjadi konteks peta arsitektur ini.