Perbedaan Docker dan Kubernetes sebenarnya sederhana. Docker adalah alat untuk membungkus aplikasi menjadi container dan menjalankannya di satu mesin. Kubernetes adalah alat untuk mengatur banyak container di banyak mesin sekaligus: menyalakan ulang container yang mati, menambah salinan saat trafik naik, dan membagi beban antar container. Keduanya bukan pesaing. Docker bekerja di level “bagaimana satu container dibuat dan dijalankan”, Kubernetes bekerja di level “bagaimana ratusan container dikelola bersama”.

Artikel ini bagian kedua dari seri Belajar Kubernetes dari Nol. Kita tidak akan berhenti di teori. Di bagian praktik nanti, kamu akan menghapus pod nginx secara paksa dan melihat sendiri Kubernetes menghidupkannya lagi tanpa disuruh. Itu cara paling cepat memahami kenapa orkestrasi itu ada.

Prasyarat Sebelum Mulai

Tutorial ini melanjutkan setup dari Belajar Kubernetes #1: Kubernetes Adalah + Install Minikube. Pastikan Minikube v1.36 sudah terpasang dan cluster bisa jalan dengan minikube start. Versi Kubernetes yang dipakai Minikube saat artikel ini ditulis adalah v1.33. Kalau kamu belum paham konsep container sama sekali, mampir dulu ke seri Belajar Docker, karena semua contoh di sini menganggap kamu sudah pernah menjalankan docker run.

Rekap Singkat: Apa yang Docker Kerjakan

Container adalah cara mengemas aplikasi beserta semua dependensinya menjadi satu paket yang bisa jalan di mana saja. Docker mempopulerkan konsep ini lewat tiga hal: Dockerfile untuk mendefinisikan isi paket, image sebagai hasil build yang siap didistribusikan, dan Docker Engine yang menjalankan image tersebut menjadi container.

Untuk satu server, Docker sudah sangat cukup. Kamu build image, push ke registry, tarik di server, jalankan. Selesai. Ditambah docker compose, kamu bahkan bisa mengelola beberapa container sekaligus, misalnya aplikasi Laravel plus MySQL plus Redis, semuanya didefinisikan dalam satu file YAML.

Di Mana Docker Saja Mulai Kewalahan

Masalah muncul ketika aplikasi tumbuh melewati satu mesin. Coba bayangkan beberapa situasi ini:

Container mati jam 2 pagi. Docker punya restart policy seperti --restart unless-stopped, tapi itu hanya bekerja selama mesinnya masih hidup. Kalau servernya sendiri yang tumbang, tidak ada yang memindahkan container ke server lain.
Trafik naik mendadak. Kamu perlu menambah salinan aplikasi di beberapa server. Dengan Docker murni, kamu SSH ke tiap server satu per satu, jalankan container, lalu atur load balancer manual.
Deploy versi baru tanpa downtime. Prosedurnya manual: nyalakan container versi baru, cek sehat, alihkan trafik, matikan versi lama. Salah urutan sedikit, user kena error.
Container perlu saling menemukan. Aplikasi di server A perlu tahu alamat database di server B. IP berubah tiap kali container dibuat ulang, jadi hardcode alamat bukan pilihan.

Semua masalah di atas bisa diselesaikan dengan skrip buatan sendiri. Banyak tim melakukannya, sampai skripnya jadi lebih rumit daripada aplikasinya. Kubernetes lahir untuk menstandarkan solusi masalah-masalah ini.

Kenapa Perlu Orkestrasi: Empat Kemampuan Inti

Orkestrasi artinya ada satu sistem yang terus mengawasi kondisi container dan mencocokkannya dengan kondisi yang kamu inginkan. Kamu tidak lagi memberi perintah “jalankan container ini”, melainkan mendeklarasikan “saya mau 3 salinan aplikasi ini selalu hidup”. Sisanya urusan Kubernetes.

Scaling: menambah salinan dengan satu perintah

Di Kubernetes, menambah salinan aplikasi dari 1 menjadi 5 cukup satu perintah, dan Kubernetes yang memutuskan container baru ditaruh di mesin mana. Tidak perlu SSH ke server satu per satu.

Self-healing: container mati dihidupkan sendiri

Kubernetes membandingkan jumlah container yang hidup dengan jumlah yang kamu deklarasikan. Kurang satu, dia buat satu lagi. Ini bukan fitur tambahan, ini perilaku default. Kita buktikan di bagian praktik nanti.

Rolling update: ganti versi tanpa downtime

Saat kamu update image ke versi baru, Kubernetes mengganti container secara bertahap. Container baru dinyalakan dulu, dicek sehat, baru container lama dimatikan. Kalau versi baru bermasalah, ada perintah rollback untuk kembali ke versi sebelumnya. Detailnya kita bahas di bagian 8 seri ini.

Service discovery: container saling menemukan lewat nama

Kubernetes memberi nama DNS internal untuk sekelompok container. Aplikasi cukup memanggil http://backend tanpa peduli container backend sedang hidup di mesin mana atau IP-nya berapa. Load balancing antar salinan juga otomatis.

Perbedaan Peran: Docker Membangun, Kubernetes Mengatur

Cara paling mudah membedakan keduanya adalah lewat pembagian kerja di alur pengembangan:

Aspek	Docker	Kubernetes
Peran utama	Membangun image dan menjalankan container	Mengatur container di banyak mesin
Lingkup	Satu mesin	Cluster berisi banyak mesin
Unit kerja	Container	Pod (berisi satu atau lebih container)
Kalau container mati	Restart di mesin yang sama, kalau restart policy diset	Dibuat ulang otomatis, bisa di mesin lain
Scaling	Manual per mesin	Deklaratif, satu perintah untuk seluruh cluster
Contoh perintah	`docker build`, `docker run`	`kubectl apply`, `kubectl scale`

Dalam praktik keduanya dipakai bersama. Alur umumnya: developer menulis Dockerfile, docker build menghasilkan image, image dipush ke registry, lalu Kubernetes menarik image itu dan menjalankannya sebagai container di cluster. Docker hidup di laptop developer dan pipeline CI, Kubernetes hidup di server produksi.

Posisi containerd setelah dockershim dihapus

Kamu mungkin pernah baca judul berita “Kubernetes membuang Docker”. Yang sebenarnya terjadi lebih teknis dari itu. Kubernetes berkomunikasi dengan container runtime lewat standar bernama CRI (Container Runtime Interface). Docker Engine tidak berbicara CRI secara native, jadi dulu Kubernetes memelihara kode perantara bernama dockershim. Sejak Kubernetes 1.24 (2022), dockershim dihapus dan Kubernetes memakai runtime yang mendukung CRI langsung, paling umum containerd.

Bagian menariknya: containerd justru komponen di dalam Docker itu sendiri. Saat kamu menjalankan docker run, yang benar-benar mengeksekusi container adalah containerd. Kubernetes hanya memotong jalur, memanggil containerd langsung tanpa lewat Docker Engine. Image hasil docker build tetap jalan normal di Kubernetes karena keduanya mengikuti standar OCI (Open Container Initiative). Jadi keahlian Docker kamu tidak ada yang terbuang.

Praktik: Membuktikan Self-Healing di Minikube

Sekarang bagian paling penting. Nyalakan cluster dulu:

minikube start

Di bagian 1 kita menjalankan nginx sebagai pod tunggal. Kali ini kita jalankan nginx lewat Deployment, yaitu objek Kubernetes yang menyimpan deklarasi “berapa salinan yang harus selalu hidup”. Detail Deployment dibahas di bagian 7, sekarang cukup pakai dulu:

kubectl create deployment web-demo --image=nginx:1.27

Output yang diharapkan:

deployment.apps/web-demo created

Cek pod yang dibuat:

kubectl get pods

NAME                        READY   STATUS    RESTARTS   AGE
web-demo-7c9b8d6f4d-x2k9p   1/1     Running   0          20s

Nama pod kamu pasti berbeda di bagian akhirnya, karena akhiran itu acak. Sekarang kita berperan jadi bencana. Hapus pod itu secara paksa (ganti nama pod sesuai output di terminalmu):

kubectl delete pod web-demo-7c9b8d6f4d-x2k9p

pod "web-demo-7c9b8d6f4d-x2k9p" deleted

Kalau ini Docker biasa, cerita selesai, container hilang. Sekarang cek lagi:

kubectl get pods

NAME                        READY   STATUS    RESTARTS   AGE
web-demo-7c9b8d6f4d-m5j7q   1/1     Running   0          8s

Pod baru dengan nama akhiran berbeda muncul dalam hitungan detik, tanpa kamu melakukan apa pun. Kubernetes melihat jumlah pod hidup (0) tidak sesuai deklarasi (1), lalu memperbaikinya sendiri. Ini self-healing yang tadi kita bahas.

Coba juga scaling. Satu perintah, tiga salinan:

kubectl scale deployment web-demo --replicas=3
kubectl get pods

NAME                        READY   STATUS    RESTARTS   AGE
web-demo-7c9b8d6f4d-m5j7q   1/1     Running   0          2m
web-demo-7c9b8d6f4d-b8w4r   1/1     Running   0          10s
web-demo-7c9b8d6f4d-t6n2c   1/1     Running   0          10s

Selesai bereksperimen, bersihkan:

kubectl delete deployment web-demo

Kapan Kamu Tidak Perlu Kubernetes

Bagian ini jarang ditulis di tutorial, tapi penting. Kubernetes punya biaya: kurva belajar panjang, komponen yang harus dirawat, dan kebutuhan resource server yang lebih besar. Untuk banyak kasus, docker compose di satu VPS adalah pilihan yang lebih waras.

Cukup docker compose kalau: aplikasimu jalan nyaman di satu server, downtime beberapa menit saat deploy masih bisa diterima, dan timnya kecil. Di proyek sistem aplikasi yang tim Arrazy kerjakan untuk klien, sebagian besar backend Go dan Laravel memang kami jalankan dengan docker compose di satu VPS, karena skalanya belum menuntut lebih. Pindah ke Kubernetes baru masuk akal ketika kamu butuh lebih dari satu server, zero-downtime deploy jadi keharusan, atau frekuensi deploy sudah tinggi.

Aturan praktisnya: mulai dari compose, pindah ke Kubernetes saat rasa sakitnya nyata, bukan karena ikut tren.

Salah Paham yang Sering Muncul

“Kubernetes adalah pengganti Docker”

Salah. Keduanya beroperasi di lapisan berbeda dan justru saling melengkapi. Kamu tetap butuh Docker (atau alat sejenis seperti Podman dan Buildah) untuk membangun image. Yang benar-benar digantikan Kubernetes hanyalah Docker Engine sebagai runtime di node cluster, itu pun digantikan oleh containerd yang notabene bagian dari Docker sendiri.

“Docker Swarm sama dengan Kubernetes”

Keduanya memang sama-sama orkestrator, tapi bukan barang yang sama. Docker Swarm adalah orkestrator bawaan Docker, lebih sederhana dipelajari, dengan fitur yang jauh lebih terbatas. Kubernetes menang di ekosistem: autoscaling, ekstensi, tooling, dukungan semua cloud provider besar, dan lowongan kerja. Swarm masih hidup dan dipakai, tapi arah industri sudah jelas ke Kubernetes. Untuk belajar yang nilainya jangka panjang, Kubernetes pilihan yang lebih aman.

Troubleshooting: Error yang Sering Dialami Pemula

The connection to the server … was refused

Muncul saat menjalankan perintah kubectl apa pun. Penyebab paling umum: cluster Minikube belum jalan. Solusinya jalankan minikube status, dan kalau statusnya Stopped, nyalakan dengan minikube start. Kalau masih gagal, cek apakah Docker Desktop atau service Docker di mesinmu sudah hidup, karena Minikube dengan driver docker menumpang di situ.

Pod dihapus tapi tidak hidup lagi

Kamu praktik self-healing tapi pod tidak muncul kembali. Hampir pasti pod itu dibuat dengan kubectl run (pod tunggal tanpa pengawas), bukan lewat Deployment. Pod tunggal tidak punya siapa pun yang mengawasi jumlahnya. Solusinya buat lewat kubectl create deployment seperti contoh di atas, lalu ulangi eksperimennya.

Status pod ImagePullBackOff

Kubernetes gagal menarik image dari registry. Cek dua hal: nama dan tag image salah ketik (misalnya ngnix atau tag yang tidak ada), atau koneksi internet dari dalam Minikube bermasalah. Jalankan kubectl describe pod nama-pod dan baca bagian Events di paling bawah, di situ tertulis alasan persisnya.

Image hasil docker build tidak ditemukan di Minikube

Kamu build image lokal, lalu deploy ke Minikube dan kena ErrImagePull. Penyebabnya Docker di laptopmu dan runtime di dalam Minikube punya penyimpanan image terpisah. Solusi paling mudah: minikube image load nama-image:tag untuk menyalin image ke dalam cluster, atau build langsung di dalam Minikube dengan minikube image build -t nama-image:tag .

Lanjut ke Bagian Berikutnya

Kamu sekarang paham pembagian kerjanya: Docker membangun dan mengemas, Kubernetes menjalankan dan menjaga. Kamu juga sudah melihat self-healing bekerja dengan mata sendiri. Pertanyaan berikutnya, siapa sebenarnya yang mengawasi pod tadi dan memutuskan pod baru harus dibuat? Jawabannya ada di komponen-komponen cluster, dan itu bahasan “Belajar Kubernetes #3: Arsitektur Kubernetes Cluster” yang terbit menyusul. Pantau daftar terbarunya di halaman Belajar Kubernetes dari Nol.

Belajar Kubernetes #2: Perbedaan Docker dan Kubernetes