KodelokaGagasan Inti: Keadaan yang Diinginkan
Banyak orang mengira Kubernetes adalah "Docker Compose versi besar". Itu keliru dan menyesatkan. Docker Compose menjalankan perintah: nyalakan kontainer ini. Kubernetes bekerja dengan cara yang berbeda secara mendasar.
Anda mendeklarasikan keadaan yang diinginkan ("saya ingin 3 replika aplikasi ini berjalan"). Kubernetes terus-menerus membandingkannya dengan keadaan sebenarnya, lalu mengambil tindakan untuk menutup selisihnya. Selamanya. Ini disebut loop rekonsiliasi.
┌──────────────────┐
│ Keadaan diinginkan│ ← Anda tulis di YAML
│ replika: 3 │
└────────┬─────────┘
│ dibandingkan terus-menerus
▼
┌──────────────────┐ selisih? ┌────────────┐
│ Keadaan sebenarnya│ ─────────────────────>│ Ambil │
│ replika: 2 │ │ tindakan │
└──────────────────┘ <──────────────────── └────────────┘
buat 1 pod lagi
Konsekuensi praktisnya besar: bila Anda menghapus pod secara manual, Kubernetes akan membuatnya lagi. Bukan karena "bandel", tetapi karena Anda pernah menyatakan ingin 3 replika dan Anda tidak pernah mencabut pernyataan itu.
Komponen Control Plane
| Komponen | Tugas | Bila mati |
|---|---|---|
| kube-apiserver | Satu-satunya pintu masuk. Semua komponen lain bicara lewat sini, tidak pernah langsung satu sama lain. | Tidak bisa mengubah apa pun; beban kerja yang sudah jalan tetap jalan |
| etcd | Basis data key-value yang menyimpan seluruh keadaan kluster. | Kluster kehilangan ingatannya — ini komponen paling kritis |
| kube-scheduler | Menentukan pod baru ditempatkan di node mana. | Pod baru menggantung di status Pending |
| controller-manager | Menjalankan loop rekonsiliasi untuk Deployment, ReplicaSet, Node, dan lainnya. | Tidak ada penyembuhan otomatis |
Komponen di Setiap Node
| Komponen | Tugas |
|---|---|
| kubelet | Agen yang memastikan kontainer yang seharusnya berjalan di node ini benar-benar berjalan. Ia menjalankan probe kesehatan dan melaporkan status. |
| kube-proxy | Mengatur aturan jaringan agar Service bisa menjangkau pod. |
| container runtime | Yang benar-benar menjalankan kontainer — containerd atau CRI-O. |
Sejak Kubernetes 1.24, dockershim dihapus. Kubernetes kini berbicara langsung ke runtime lewat antarmuka CRI, biasanya containerd. Ini tidak berarti image Docker tidak bisa dipakai — format image-nya standar OCI dan tetap berjalan normal. Yang berubah hanya komponen yang menjalankannya di balik layar. Konsekuensi nyata: perintah docker ps di node tidak lagi menampilkan kontainer Kubernetes; gunakan crictl ps.
Pod: Satuan Terkecil
Kubernetes tidak menjalankan kontainer secara langsung — ia menjalankan Pod. Pod adalah satu atau beberapa kontainer yang:
- Berbagi alamat IP yang sama — antar kontainer di dalamnya bisa saling menghubungi lewat
localhost. - Berbagi volume.
- Selalu dijadwalkan ke node yang sama, dan hidup-mati bersama.
Jarang, dan harus ada alasan kuat. Polanya disebut sidecar: pengumpul log yang membaca berkas yang ditulis kontainer utama, proxy service mesh, atau penyegar sertifikat. Aturannya: kalau dua kontainer bisa diskalakan secara terpisah, mereka harus berada di Pod yang berbeda.
Kapan Kubernetes Tidak Sepadan
Kubernetes menyelesaikan masalah skala dan keberagaman. Bila Anda punya satu aplikasi dengan trafik sedang, sebuah VM dengan systemd atau layanan PaaS akan jauh lebih murah, lebih mudah, dan lebih andal. Kubernetes menuntut Anda memahami jaringan, penyimpanan, RBAC, manajemen sumber daya, dan siklus upgrade — semua itu adalah pekerjaan penuh waktu.
Mulai memikirkan Kubernetes bila: ada banyak layanan dengan siklus rilis berbeda, kebutuhan penskalaan otomatis yang nyata, banyak tim yang butuh isolasi, atau Anda memang sudah punya orang yang mengerti mengoperasikannya.