Gambaran Umum Kubernetes

Docker Swarm cukup untuk banyak kasus orkestrasi container, tapi begitu skala cluster membesar dan kebutuhan penjadwalan makin kompleks (autoscaling berbasis metrik custom, self-healing yang lebih granular, atau integrasi dengan berbagai cloud provider sekaligus), Sysadmin/DevOps Engineer di lapangan lebih sering bertemu Kubernetes sebagai standar de facto orkestrasi container di industri. Bab ini membahas gambaran umum Kubernetes, mulai dari asal-usul dan komponen intinya, perbedaan mendasar dengan Docker, posisinya di tengah ekosistem orkestrasi container yang lebih luas, sampai jalur praktis memindahkan workload dari Docker Compose ke manifest Kubernetes. Pembahasan di bab ini murni bersifat pengenalan; instalasi cluster production, konfigurasi objek Kubernetes secara mendalam, atau penulisan manifest YAML yang kompleks tidak termasuk cakupan bab ini.

39.1 Apa Itu Kubernetes

Sebelum membandingkan Kubernetes dengan Docker, penting memahami dulu apa sebenarnya Kubernetes dan dari mana asalnya. Bagian ini membahas sejarah singkat Kubernetes, komponen arsitektur utamanya, dan cara mencoba clusternya secara lokal untuk keperluan belajar.

39.1.1 Sejarah dan Asal-Usul dari Borg

Kubernetes adalah platform orkestrasi container open source yang mengotomasi deployment, scaling, dan pengelolaan aplikasi yang berjalan dalam container di banyak host sekaligus. Konsep intinya, seperti Pod, Service, dan Label, diturunkan dari Borg, sistem cluster manager internal yang sudah dipakai Google selama bertahun-tahun untuk menjalankan workload dalam skala sangat besar di data center mereka sendiri.

Google mengumumkan Kubernetes sebagai proyek open source pada Juni 2014, membuka akses ke sebagian besar pengalaman dan desain yang sebelumnya cuma dipakai secara internal lewat Borg. Setahun kemudian, bertepatan dengan rilis Kubernetes versi 1.0, Google menyumbangkan proyek ini sebagai teknologi awal pembentukan Cloud Native Computing Foundation (CNCF) di bawah Linux Foundation, dengan Kubernetes sebagai proyek pertama yang dinaungi CNCF. Sejak itu, Kubernetes dikembangkan secara terbuka oleh komunitas lintas perusahaan, bukan lagi dikendalikan sepihak oleh Google saja, dan nama "Kubernetes" sendiri sering disingkat K8s (angka 8 mewakili delapan huruf antara "K" dan "s").

39.1.2 Komponen Arsitektur Utama

Sebuah cluster Kubernetes terdiri dari dua kelompok komponen: control plane yang mengambil keputusan global soal cluster (misalnya menjadwalkan workload baru atau mendeteksi node yang mati), dan node yang menjalankan workload container yang sebenarnya. Control plane biasanya terdiri dari beberapa komponen inti berikut, sesuai dokumentasi resmi Kubernetes mengenai arsitektur cluster:

• kube-apiserver: pintu masuk utama komunikasi ke cluster, tempat semua perintah (baik dari kubectl maupun komponen internal lain) masuk lewat REST API.
• etcd: penyimpanan key-value terdistribusi yang menyimpan seluruh data konfigurasi dan status cluster secara konsisten.
• kube-scheduler: memutuskan node mana yang paling cocok menjalankan sebuah Pod baru, berdasarkan ketersediaan resource dan aturan penempatan yang berlaku.
• kube-controller-manager: menjalankan berbagai controller yang terus memantau status cluster dan menyesuaikannya supaya sesuai kondisi yang diinginkan (misalnya menambah replika Pod yang mati).

Setiap node pekerja menjalankan komponen kubelet, agen yang memastikan container di dalam Pod benar-benar berjalan sesuai spesifikasi yang diberikan control plane, serta kube-proxy yang mengatur aturan jaringan supaya trafik bisa sampai ke Pod yang tepat. Unit terkecil yang bisa dijadwalkan Kubernetes bukan container secara langsung, melainkan Pod, yaitu satu atau lebih container yang berbagi network namespace dan storage yang sama, selalu dijadwalkan bersama ke node yang sama pula.

39.1.3 Mencoba Cluster Lokal untuk Belajar

Menyiapkan cluster Kubernetes production butuh perencanaan matang, tapi untuk belajar dan eksperimen, Developer maupun Sysadmin/DevOps Engineer bisa memakai cluster lokal berskala kecil seperti minikube atau kind (Kubernetes in Docker), yang menjalankan Kubernetes lengkap di satu mesin lewat container atau virtual machine. Docker Desktop juga menyediakan opsi mengaktifkan Kubernetes satu node langsung dari pengaturannya, tanpa instalasi tool tambahan.

Setelah salah satu opsi tersebut aktif, verifikasi cluster sudah berjalan lewat CLI resmi Kubernetes, kubectl.

kubectl cluster-info

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

Output di atas menandakan kubectl berhasil terhubung ke control plane cluster yang sedang aktif. Kalau perintah ini gagal dengan pesan koneksi ditolak, penyebab paling umum di lapangan adalah cluster lokal belum benar-benar aktif (misalnya minikube start belum dijalankan) atau konteks kubectl yang aktif menunjuk ke cluster lain; cek konteks yang sedang dipakai lewat kubectl config current-context sebelum menelusuri masalah lebih jauh.

39.2 Docker vs Kubernetes

Docker dan Kubernetes sering disandingkan seolah dua pilihan yang saling menggantikan, padahal keduanya beroperasi di lapisan berbeda dan justru lazim dipakai bersamaan. Bagian ini menjelaskan perbedaan cakupan keduanya, hubungan Kubernetes dengan container runtime, dan pemetaan konsep antara Docker Compose dengan objek-objek Kubernetes.

39.2.1 Perbedaan Cakupan dan Peran

Docker, secara spesifik Docker Engine, adalah platform untuk membangun dan menjalankan container di satu host, lengkap dengan tooling untuk membuat image lewat Dockerfile, mengelola volume, dan mengatur jaringan container. Kubernetes berada satu lapisan di atasnya: Kubernetes tidak membangun image atau mendefinisikan cara container dijalankan dari nol, melainkan mengorkestrasi container yang sudah jadi (biasanya sudah dalam bentuk image OCI yang dibangun dengan tool seperti Docker) di banyak node sekaligus, lengkap dengan penjadwalan, self-healing, dan scaling otomatis.

Workflow membangun image lewat docker build tetap relevan dan lazim dipakai meskipun deployment akhirnya berjalan di atas Kubernetes; Kubernetes menggantikan peran Docker Engine sebagai orkestrator runtime container di banyak host, bukan menggantikan tooling build image. Perbandingan ini mirip dengan Docker Swarm yang sudah dibahas di bab tersendiri, hanya saja Kubernetes menawarkan fitur orkestrasi yang jauh lebih kaya (autoscaling berbasis metrik, strategi deployment yang lebih beragam, dan ekosistem plugin yang luas) dengan konsekuensi kurva belajar dan kompleksitas operasional yang juga lebih tinggi dibanding Swarm.

39.2.2 Container Runtime dan Container Runtime Interface

Kubernetes sendiri tidak menjalankan container secara langsung; ia berkomunikasi dengan container runtime di tiap node lewat antarmuka standar bernama Container Runtime Interface (CRI). Dulu Kubernetes punya komponen khusus bernama dockershim untuk menjembatani Docker Engine (yang API-nya tidak sepenuhnya kompatibel dengan CRI) supaya tetap bisa dipakai sebagai runtime, tapi komponen ini resmi dihapus dari kubelet mulai Kubernetes versi 1.24, sesuai catatan rilis resmi Kubernetes.

Sejak dockershim dihapus, cluster Kubernetes umumnya memakai containerd atau CRI-O sebagai container runtime, keduanya sudah mengimplementasikan CRI secara native tanpa perlu komponen jembatan tambahan. Menariknya, containerd sendiri sebenarnya adalah komponen inti yang sejak lama juga dipakai Docker Engine di baliknya untuk menjalankan container; jadi meskipun Docker Engine sebagai keseluruhan platform sudah tidak dipakai langsung sebagai runtime CRI, komponen intinya tetap hidup di banyak cluster Kubernetes modern. Image yang dibangun dengan docker build tetap bisa dijalankan tanpa masalah di cluster Kubernetes manapun, karena formatnya sudah mengikuti spesifikasi OCI yang didukung universal oleh containerd maupun CRI-O.

39.2.3 Pemetaan Konsep Compose ke Objek Kubernetes

Developer yang sudah terbiasa dengan Docker Compose akan menemukan banyak konsep yang punya padanan di Kubernetes, meski penamaan dan detail perilakunya berbeda. Tabel berikut merangkum pemetaan kasarnya.

Perlu dicatat, istilah "Service" muncul di kedua sisi tabel dengan makna yang berbeda: Service di Docker Compose adalah satu definisi container beserta konfigurasinya, sedangkan Service di Kubernetes adalah objek jaringan yang menyediakan alamat stabil untuk mengakses sekumpulan Pod. Kemiripan istilah ini kerap membingungkan Developer yang baru pindah dari Compose ke Kubernetes, jadi baik dipahami sejak awal supaya tidak salah asumsi saat membaca manifest Kubernetes.

39.3 Ekosistem Orkestrasi Container

Kubernetes bukan satu-satunya pemain di ranah orkestrasi container, meski saat ini posisinya paling dominan. Bagian ini membahas posisi Kubernetes di antara alternatif orkestrator lain, ragam distribusi dan layanan terkelola yang tersedia, serta tooling pendukung yang lazim dipakai bersamanya.

39.3.1 Kubernetes, Swarm, dan Alternatif Lain

Docker Swarm, yang sudah dibahas di bab tersendiri, tetap jadi pilihan valid untuk cluster berskala kecil sampai menengah yang mengutamakan kesederhanaan setup, karena sudah terintegrasi langsung ke Docker Engine tanpa instalasi komponen tambahan. Kubernetes lebih cocok untuk kebutuhan orkestrasi yang lebih kompleks: multi-tenant, autoscaling berbasis metrik custom, integrasi native dengan berbagai cloud provider, atau ekosistem plugin (networking, storage, security) yang jauh lebih luas.

Selain Swarm dan Kubernetes, ada juga HashiCorp Nomad sebagai orkestrator yang lebih ringan dan tidak terbatas pada workload container saja (bisa juga menjadwalkan proses biner atau virtual machine), meski adopsinya di industri jauh lebih kecil dibanding Kubernetes. Di lapangan, keputusan memilih orkestrator biasanya bukan soal fitur mana yang "lebih canggih" secara mutlak, melainkan soal kecocokan dengan ukuran tim, kompleksitas workload, dan sumber daya operasional yang tersedia untuk merawat clusternya.

39.3.2 Distribusi dan Layanan Kubernetes Terkelola

Menjalankan Kubernetes sendiri dari nol (biasanya lewat tool seperti kubeadm) memberi kontrol penuh atas konfigurasi cluster, tapi juga menuntut Sysadmin/DevOps Engineer merawat sendiri seluruh komponen control plane, termasuk upgrade versi dan pemulihan kalau ada komponen yang bermasalah. Sebagai alternatif, penyedia cloud besar menawarkan layanan Kubernetes terkelola yang mengurus sebagian besar beban operasional control plane, seperti Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), dan Azure Kubernetes Service (AKS).

Untuk kebutuhan edge computing atau lingkungan dengan resource terbatas, ada juga distribusi Kubernetes yang lebih ringan seperti k3s, yang memangkas beberapa komponen non-esensial dari distribusi Kubernetes standar supaya bisa berjalan di perangkat dengan spesifikasi lebih rendah. Di sisi lain, platform seperti OpenShift dari Red Hat membungkus Kubernetes dengan tooling tambahan (CI/CD terintegrasi, developer console, kebijakan keamanan bawaan) untuk kebutuhan enterprise. Pemilihan di antara opsi-opsi ini biasanya bergantung pada kesiapan tim mengurus operasional cluster sendiri versus anggaran yang tersedia untuk memakai layanan terkelola.

39.3.3 Tooling Pendukung di Sekitar Kubernetes

Ekosistem Kubernetes juga diramaikan berbagai tooling pendukung yang lazim dipakai berdampingan dengan cluster inti. Helm berfungsi sebagai package manager untuk Kubernetes, membungkus sekumpulan manifest YAML jadi satu paket bernama chart yang bisa di-install, di-upgrade, atau di-rollback dengan satu perintah, mirip fungsi package manager pada distribusi Linux tapi khusus untuk resource Kubernetes.

Kustomize menyediakan cara mengelola variasi konfigurasi antar environment (misalnya staging vs production) tanpa duplikasi manifest, lewat mekanisme overlay yang menimpa sebagian konfigurasi dasar. Untuk observabilitas visual, tool seperti Lens atau k9s menyediakan antarmuka (baik GUI maupun berbasis terminal) untuk memantau dan mengelola resource cluster tanpa harus mengetik perintah kubectl satu per satu. Seluruh tooling ini bersifat opsional; sebuah cluster Kubernetes tetap bisa dijalankan dan dikelola sepenuhnya lewat kubectl saja, tapi tooling tambahan ini terbukti mempercepat workflow sehari-hari terutama begitu jumlah manifest dan environment yang dikelola makin banyak.

39.4 Jalur Migrasi dari Docker Compose ke Kubernetes

Aplikasi yang sudah berjalan mulus dengan Docker Compose di satu server tidak selalu perlu buru-buru dipindah ke Kubernetes. Bagian ini membahas kapan migrasi tersebut relevan dipertimbangkan, cara mengonversi Compose file jadi manifest awal Kubernetes, dan penyesuaian manual yang biasanya masih dibutuhkan setelah proses konversi.

39.4.1 Kapan Migrasi Dibutuhkan

Docker Compose tetap jadi pilihan yang solid untuk development lokal maupun deployment skala kecil yang cukup berjalan di satu host. Migrasi ke Kubernetes biasanya baru relevan dipertimbangkan Sysadmin/DevOps Engineer ketika muncul kebutuhan konkret seperti: aplikasi harus tersebar di banyak node sekaligus untuk menahan beban trafik yang terus naik, dibutuhkan autoscaling otomatis berdasarkan metrik resource, atau organisasi butuh strategi deployment lanjutan (seperti canary release atau blue-green deployment) yang tidak tersedia langsung di Docker Compose.

Migrasi yang dilakukan tanpa kebutuhan konkret semacam ini justru berisiko menambah kompleksitas operasional tanpa manfaat sepadan, karena merawat cluster Kubernetes (baik self-managed maupun terkelola) tetap menuntut pemahaman konsep tambahan dibanding sekadar menjalankan docker compose up di satu server. Jujur soal biaya operasional tambahan ini penting supaya keputusan migrasi benar-benar didasarkan pada kebutuhan skala, bukan sekadar mengikuti tren.

39.4.2 Konversi Compose File dengan Kompose

Kompose adalah tool resmi di bawah proyek Kubernetes yang mengonversi docker-compose.yml menjadi manifest Kubernetes awal, mengurangi sebagian besar pekerjaan menulis manifest dari nol. Setelah kompose terpasang, jalankan perintah berikut di direktori yang berisi Compose file yang akan dikonversi.

kompose convert -f docker-compose.yml -o k8s/

Perintah ini menghasilkan berkas manifest terpisah untuk tiap service (umumnya berupa Deployment dan Service) di dalam direktori k8s/. Terapkan manifest yang dihasilkan ke cluster yang sedang aktif lewat kubectl.

kubectl apply -f k8s/

Verifikasi Pod hasil konversi sudah berjalan dengan status Running lewat perintah berikut.

kubectl get pods

Kalau ada Pod yang berstatus CrashLoopBackOff atau ImagePullBackOff setelah manifest diterapkan, periksa detail penyebabnya lewat kubectl describe pod NAMA_POD dan kubectl logs NAMA_POD; penyebab paling umum di lapangan adalah image yang tidak bisa diakses cluster (misalnya image lokal yang belum di-push ke registry yang bisa dijangkau node) atau environment variable wajib yang belum didefinisikan ulang di manifest hasil konversi.

39.4.3 Penyesuaian Manual Pasca-Konversi

Manifest hasil kompose convert adalah titik awal yang baik, bukan hasil akhir yang siap dipakai langsung di production. Beberapa penyesuaian manual yang hampir selalu dibutuhkan meliputi: menambahkan readiness probe dan liveness probe supaya Kubernetes tahu kapan sebuah Pod benar-benar siap menerima trafik atau perlu di-restart (padanan konsep HEALTHCHECK di Dockerfile, tapi dikonfigurasi terpisah di level manifest Kubernetes), menentukan resource requests dan limits CPU/memori supaya scheduler bisa menempatkan Pod secara efisien dan mencegah satu Pod menghabiskan seluruh resource node, serta memindahkan kredensial sensitif dari environment variable biasa ke objek Secret alih-alih membiarkannya tertulis polos di manifest.

Volume yang tadinya berupa bind mount atau named volume di Compose juga perlu dipetakan ulang ke PersistentVolumeClaim yang sesuai dengan kelas storage yang tersedia di cluster tujuan, karena mekanisme storage di Kubernetes tidak otomatis identik dengan pemetaan folder host seperti bind mount. Begitu juga dengan port mapping: kalau service perlu diakses dari luar cluster lewat domain tertentu, biasanya dibutuhkan objek Ingress tambahan yang tidak otomatis dihasilkan dari konversi ports: biasa. Meninjau ulang setiap manifest hasil konversi baris demi baris, alih-alih langsung menerapkannya mentah-mentah ke cluster production, tetap jadi langkah wajib sebelum aplikasi benar-benar dianggap siap berjalan di atas Kubernetes. Di lapangan, kesalahan yang paling sering luput justru bukan pada Deployment atau Service, melainkan pada bagian resource requests/limits dan probe yang dibiarkan kosong karena memang tidak pernah ada padanannya di Compose file, sehingga gampang terlewat saat tim buru-buru menuntaskan migrasi.