Overview #

Kubernetes bukan satu program tunggal — ia adalah sekumpulan komponen yang masing-masing punya tanggung jawab yang sangat spesifik dan terbatas. Desain ini disengaja: setiap komponen bisa gagal, direstart, atau diperbarui secara independen tanpa menjatuhkan seluruh sistem. Memahami arsitektur Kubernetes berarti memahami siapa melakukan apa, dan bagaimana mereka berkoordinasi.

Gambaran Besar #

Sebuah cluster Kubernetes terbagi menjadi dua lapisan besar: Control Plane dan Worker Node. Keduanya berkomunikasi melalui satu titik sentral: API Server.

┌────────────────────────────────────────────────────────────────┐
│                        Kubernetes Cluster                      │
│                                                                │
│  ┌──────────────────────────────────────────┐                  │
│  │              Control Plane               │                  │
│  │                                          │                  │
│  │  ┌─────────────┐    ┌─────────────────┐  │                  │
│  │  │  API Server │◄───│      Etcd       │  │                  │
│  │  └──────┬──────┘    └─────────────────┘  │                  │
│  │         │                                │                  │
│  │  ┌──────┴──────┐    ┌─────────────────┐  │                  │
│  │  │  Scheduler  │    │   Controller    │  │                  │
│  │  └─────────────┘    │    Manager      │  │                  │
│  │                     └─────────────────┘  │                  │
│  └──────────────────────────────────────────┘                  │
│                            │ API                               │
│           ┌────────────────┼────────────────┐                  │
│           ▼                ▼                ▼                  │
│  ┌──────────────┐ ┌──────────────┐ ┌──────────────┐            │
│  │ Worker Node 1│ │ Worker Node 2│ │ Worker Node 3│            │
│  │              │ │              │ │              │            │
│  │  kubelet     │ │  kubelet     │ │  kubelet     │            │
│  │  kube-proxy  │ │  kube-proxy  │ │  kube-proxy  │            │
│  │  runtime     │ │  runtime     │ │  runtime     │            │
│  │  [Pod] [Pod] │ │  [Pod] [Pod] │ │  [Pod]       │            │
│  └──────────────┘ └──────────────┘ └──────────────┘            │
└────────────────────────────────────────────────────────────────┘

Setiap komponen punya peran yang sangat terdefinisi, dan komunikasi antar komponen hampir seluruhnya melewati API Server — bukan langsung satu sama lain.

Komponen Control Plane #

Control plane adalah “otak” cluster. Ia membuat semua keputusan global tentang cluster — di mana Pod dijadwalkan, apa yang perlu diperbaiki, bagaimana state yang diinginkan dicapai.

API Server (kube-apiserver) — satu-satunya pintu masuk ke cluster. Semua operasi — dari kubectl apply hingga kubelet yang melaporkan status — melewati API Server. Ia memvalidasi request, mengautentikasi pengguna, dan menyimpan hasilnya ke Etcd.

Etcd — database key-value terdistribusi yang menyimpan seluruh state cluster. Setiap resource Kubernetes — Pod, Deployment, Service, ConfigMap — disimpan di sini. Etcd adalah sumber kebenaran tunggal; jika Etcd rusak tanpa backup, cluster kehilangan seluruh state-nya.

Scheduler (kube-scheduler) — memutuskan di node mana sebuah Pod baru akan dijalankan. Scheduler tidak menjalankan Pod — ia hanya memilih node, lalu menulis keputusan tersebut ke API Server. Kubelet di node terpilih yang kemudian mengeksekusi.

Controller Manager (kube-controller-manager) — menjalankan banyak control loop secara paralel. Setiap controller bertanggung jawab untuk satu aspek state cluster: Deployment controller memastikan jumlah replica benar, Node controller mendeteksi node yang down, Job controller memastikan Job selesai dieksekusi.

Komponen Worker Node #

Worker node adalah “otot” cluster — mesin yang benar-benar menjalankan beban kerja.

kubelet — agen utama Kubernetes di setiap node. Kubelet watch API Server untuk Pod yang dijadwalkan ke nodenya, lalu menginstruksikan container runtime untuk menjalankan container sesuai spesifikasi. Kubelet juga melaporkan kondisi node dan Pod kembali ke API Server.

kube-proxy — mengelola aturan networking di level node. Ketika sebuah Service dibuat, kube-proxy menulis aturan iptables atau ipvs yang meneruskan traffic ke Pod yang tepat.

Container Runtime — software yang benar-benar menjalankan container. Kubernetes berkomunikasi dengan runtime melalui antarmuka standar bernama CRI (Container Runtime Interface). Runtime yang paling umum di produksi modern adalah containerd.

Alur Request: Dari kubectl ke Container #

Memahami alur lengkap saat kamu menjalankan kubectl apply membantu menyatukan semua komponen di atas:

$ kubectl apply -f deployment.yaml

1. kubectl membaca file YAML dan mengirim HTTP request ke API Server

2. API Server:
   ├── Autentikasi: siapa yang mengirim request ini?
   ├── Otorisasi: apakah mereka punya izin?
   ├── Validasi: apakah manifest-nya valid?
   └── Simpan Deployment ke Etcd → kirim respons ke kubectl

3. Deployment Controller (di Controller Manager):
   ├── Watch API Server, mendeteksi Deployment baru
   ├── Hitung: butuh 3 Pod, sekarang ada 0
   └── Buat 3 Pod object → kirim ke API Server → disimpan ke Etcd

4. Scheduler:
   ├── Watch API Server, mendeteksi 3 Pod baru tanpa node assignment
   ├── Untuk setiap Pod: evaluasi semua node, pilih yang paling sesuai
   └── Tulis node assignment ke Pod object → API Server → Etcd

5. Kubelet (di setiap node yang terpilih):
   ├── Watch API Server, mendeteksi Pod yang assigned ke nodenya
   ├── Instruksikan container runtime: pull image, buat container
   └── Jalankan container, laporkan status ke API Server

Perhatikan bahwa tidak ada komponen yang berbicara langsung satu sama lain. Semuanya melewati API Server dan Etcd. Ini yang membuat sistem ini sangat toleran terhadap kegagalan komponen individual.

Prinsip Desain yang Mendasari #

Beberapa keputusan desain di arsitektur Kubernetes punya implikasi yang dalam:

Watch, bukan Poll. Komponen seperti kubelet dan controller tidak terus-menerus bertanya ke API Server “ada yang baru?”. Mereka membuka koneksi persistent dan menerima notifikasi saat ada perubahan. Ini jauh lebih efisien dan scalable.

Level-driven, bukan edge-driven. Controller tidak bereaksi terhadap “event” perubahan — mereka selalu membandingkan current state dengan desired state dan mengambil tindakan yang diperlukan. Jika sebuah event terlewat (misalnya karena restart), controller akan tetap menghasilkan keputusan yang benar saat ia berjalan kembali.

Optimistic concurrency. Saat dua komponen mencoba mengubah resource yang sama secara bersamaan, Kubernetes menggunakan mekanisme versi resource (resource version) untuk mendeteksi konflik. Yang kalah harus retry — bukan menggunakan lock yang bisa menyebabkan deadlock.

API sebagai kontrak. API Server adalah satu-satunya antarmuka yang stabil. Komponen internal, external tools, dan operator custom semuanya menggunakan API yang sama. Ini memungkinkan ekosistem yang kaya berkembang di atas Kubernetes.

Mengapa Arsitektur Ini Penting bagi Developer #

Memahami arsitektur Kubernetes membantu menjelaskan banyak perilaku yang awalnya terasa membingungkan:

"Kenapa Pod tidak langsung muncul setelah kubectl apply?"
  → Karena ada pipeline: API Server → Controller → Scheduler → Kubelet
  → Setiap langkah butuh waktu, terutama image pull

"Kenapa state cluster kadang tampak tidak konsisten sebentar?"
  → Karena watch-based propagation punya latensi kecil
  → Eventually consistent, bukan instantly consistent

"Kenapa kubectl describe menampilkan 'Events'?"
  → Komponen-komponen menulis event ke API Server sebagai audit trail
  → Event adalah cara paling mudah mendiagnosis apa yang terjadi

Ringkasan #

Dua lapisan utama — control plane membuat keputusan, worker node mengeksekusi; keduanya berkomunikasi melalui API Server.
Empat komponen control plane — API Server (pintu masuk), Etcd (sumber kebenaran), Scheduler (penempatan Pod), Controller Manager (penjaga desired state).
Tiga komponen worker node — kubelet (agen utama), kube-proxy (networking), container runtime (menjalankan container).
Semua melalui API Server — tidak ada komponen yang berkomunikasi langsung satu sama lain; pola ini membuat sistem toleran terhadap kegagalan parsial.
Watch, bukan poll — komponen mendapat notifikasi perubahan secara real-time, bukan terus-menerus bertanya; lebih efisien dan scalable.
Level-driven control loop — controller selalu membandingkan current vs desired state; bukan bereaksi terhadap event yang bisa terlewat.

← Sebelumnya: Kontrak Infrastruktur Berikutnya: Control Plane →