Overview #

Kubernetes bukanlah sebuah aplikasi tunggal yang monolitik. Di balik kemampuannya yang luar biasa, Kubernetes sebenarnya merupakan sebuah sistem terdistribusi yang tersusun atas sekumpulan komponen mikro (microservices) independen yang masing-masing memiliki tanggung jawab sangat spesifik dan terbatas.

Desain modular ini sengaja dipilih untuk menjamin ketahanan kluster: setiap komponen dapat mengalami kegagalan, dimatikan, direstart, atau diperbarui secara independen tanpa merusak kestabilan kluster secara keseluruhan. Memahami arsitektur Kubernetes berarti memahami peran spesifik dari setiap komponen serta cara mereka saling berkoordinasi.

Lapisan Besar Kluster: Control Plane dan Worker Node #

Secara arsitektur, sebuah kluster Kubernetes terbagi menjadi dua lapisan besar yang memiliki fungsi dan komponen yang berbeda. Kedua lapisan ini berkomunikasi secara terpusat melalui API Server.

Control Plane (Otak Kluster): Bertugas mengambil keputusan global, melacak status kluster, menjadwalkan penempatan Pod, dan menjaga agar kluster tetap berada pada kondisi yang diinginkan (desired state). Komponen control plane meliputi: kube-apiserver, etcd, kube-scheduler, dan kube-controller-manager.
Worker Node (Otot Kluster): Bertugas mengeksekusi beban kerja kontainer aplikasi yang sesungguhnya. Komponen worker node meliputi: kubelet, kube-proxy, dan Container Runtime (seperti containerd).

Peta Interaksi Komponen (Alur Kerja Pipeline) #

Untuk melihat bagaimana seluruh komponen ini bekerja sama secara harmonis, mari kita bedah alur kerja lengkap yang terjadi di balik layar sejak kita mengeksekusi perintah deployment aplikasi hingga kontainer benar-benar berjalan di server.

sequenceDiagram
    actor Developer
    participant Kubectl
    participant API as kube-apiserver
    participant DB as etcd
    participant Controller as kube-controller-manager
    participant Scheduler as kube-scheduler
    participant Kubelet as kubelet (Worker Node)
    participant CRI as Container Runtime (containerd)

    Developer->>Kubectl: kubectl apply -f deployment.yaml
    Kubectl->>API: HTTP POST Request (YAML/JSON payload)
    
    Note over API: 1. Autentikasi & Otorisasi (RBAC)<br/>2. Mutating & Validating Admission Webhooks
    
    API->>DB: Tulis objek Deployment ke etcd
    DB-->>API: Konfirmasi penyimpanan data
    API-->>Kubectl: Response: Deployment Created/Updated
    
    Note over Controller: Deployment Controller mendeteksi<br/>Deployment baru via API Watch
    Controller->>API: Buat objek Pod baru (Replicas)
    API->>DB: Tulis objek Pod ke etcd
    
    Note over Scheduler: Scheduler mendeteksi Pod baru<br/>yang belum memiliki node assignment
    Scheduler->>API: Tulis Node Assignment ke Pod (Binding)
    API->>DB: Update status Pod di etcd
    
    Note over Kubelet: Kubelet di worker node terpilih<br/>mendeteksi Pod baru via API Watch
    Kubelet->>CRI: Instruksikan Container Runtime Interface (CRI)
    CRI->>CRI: Pull image dari registry & jalankan container
    CRI-->>Kubelet: Container running
    Kubelet->>API: Update status Pod: Running
    API->>DB: Update status Pod di etcd

Poin paling krusial dari alur kerja di atas adalah: tidak ada satu pun komponen yang berkomunikasi secara langsung satu sama lain. Kubelet tidak pernah berbicara langsung dengan Scheduler; Controller Manager tidak pernah menyentuh Container Runtime. Semua koordinasi, sinkronisasi, dan penyimpanan status (state) harus melewati kube-apiserver sebagai pusat kebenaran tunggal kluster.

Empat Prinsip Desain Arsitektural Kubernetes #

Arsitektur Kubernetes didasarkan pada empat prinsip desain inti yang memastikan sistem tetap skalabel, tangguh, dan dapat diandalkan di tingkat produksi:

1. Watch, Bukan Poll (Watch-based Propagation) #

Dalam sistem terdistribusi tradisional, komponen biasanya secara berkala bertanya ke server pusat (polling): “Apakah ada tugas baru untuk saya?”. Pola ini sangat tidak efisien karena memakan banyak bandwidth dan memicu beban CPU yang tinggi pada server pusat ketika jumlah node berkembang menjadi ribuan.

Kubernetes membuang pola polling. Komponen seperti kubelet dan kube-controller-manager membuka koneksi persistent HTTP/2 (gRPC) ke kube-apiserver menggunakan fitur Watch API. Ketika ada perubahan objek di etcd, API Server akan langsung menyebarkan (push) event perubahan tersebut secara real-time ke komponen yang sedang mendengarkan. Ini membuat propagasi state sangat cepat dan hemat resource.

2. Level-driven, Bukan Edge-driven (State Reconciliation) #

Desain loop kontrol Kubernetes menggunakan pendekatan Level-driven. Artinya, komponen kontroler tidak bereaksi terhadap event perubahan sesaat (misalnya: event “Pod X mati”), melainkan secara berkala membandingkan kondisi riil kluster saat ini dengan kondisi yang dideklarasikan oleh user.

Keunggulan utama pendekatan Level-driven:

Jika terjadi gangguan jaringan dan kontroler kehilangan beberapa event pemberitahuan (edges), hal itu tidak akan merusak sistem.
Saat koneksi pulih, kontroler akan membaca ulang seluruh state dan langsung menyelaraskan perbedaan yang ada. Sistem menjadi sangat toleran terhadap kegagalan komponen parsial.

3. Optimistic Concurrency Control (OCC) #

Ketika ribuan komponen berjalan secara paralel, ada kemungkinan dua komponen mencoba mengubah objek yang sama secara bersamaan di etcd. Alih-alih mengunci objek (pessimistic locking) yang dapat memicu deadlock dan memperlambat sistem, Kubernetes menggunakan mekanisme versi resource (metadata.resourceVersion).

Setiap objek di etcd memiliki string versi unik. Ketika sebuah komponen ingin memperbarui objek, ia harus menyertakan versi terakhir yang dibacanya. Jika versi di etcd ternyata sudah berubah (karena diperbarui oleh komponen lain terlebih dahulu), request akan ditolak dengan error konflik. Komponen yang kalah hanya perlu membaca ulang versi terbaru dan mengulangi request pembaruan (retry).

4. API sebagai Kontrak Tunggal #

Di Kubernetes, API Server adalah satu-satunya antarmuka yang stabil. Komponen internal bawaan Kubernetes (seperti Scheduler) menggunakan API gRPC/HTTP yang sama dengan tools pihak ketiga (seperti kubectl atau Terraform) serta custom controller yang kita tulis sendiri. Keunggulan desain ini adalah ekosistem kluster dapat dikustomisasi tanpa batas tanpa perlu mengubah arsitektur internal Kubernetes.

Implikasi Arsitektural bagi Pengembang Aplikasi #

Memahami arsitektur internal Kubernetes membantu kita menjelaskan banyak perilaku sistem yang awalnya terasa aneh atau tidak intuitif bagi pengembang aplikasi:

Konsistensi Akhir (Eventual Consistency): Ketika kita menjalankan kubectl apply, Pod tidak langsung muncul dalam status Running seketika. Hal ini wajar karena manifes harus melewati pipeline validasi API, penghitungan replika oleh Controller, penentuan node oleh Scheduler, pengunduhan image oleh Kubelet, hingga kontainer siap dijalankan oleh runtime. Kluster Kubernetes bersifat eventually consistent, bukan instantly consistent.
Pentingnya Audit Trail (Events): Karena komponen-komponen kluster bekerja secara asinkron, cara terbaik untuk mendiagnosis kegagalan adalah dengan membaca riwayat event audit yang ditulis oleh masing-masing komponen ke API Server menggunakan perintah kubectl get events atau kubectl describe pod.

Ringkasan #

Sistem Terdistribusi Modular — Kubernetes tersusun atas komponen independen (API Server, etcd, Scheduler, Controller, Kubelet, Proxy) yang masing-masing memiliki tanggung jawab terbatas.

API-Centric Communication — Seluruh komunikasi antar komponen kluster wajib melewati API Server. Tidak ada komunikasi ad-hoc langsung antar komponen.

Alur Kerja Pipeline — Proses deployment berjalan dari Kubectl ➔ API Server ➔ etcd ➔ Controller Manager ➔ Scheduler ➔ Kubelet ➔ Container Runtime secara asinkron.

Watch over Poll — Komponen kluster mendengarkan event perubahan secara real-time melalui koneksi persistent HTTP/2 gRPC, menghemat bandwidth kluster.

Level-driven Control Loops — Kontroler membandingkan kondisi riil kluster dengan desired state secara periodik, membuat sistem sangat toleran terhadap hilangnya koneksi sementara.

← Sebelumnya: Kontrak Infrastruktur Berikutnya: Control Plane →