Setup Kubernetes Cluster Lokal dengan Minikube: Deploy Aplikasi Multi-Service dan Debugging

Belajar Kubernetes langsung di production cluster terasa berat untuk pemula. Minikube menyelesaikan masalah ini dengan menyediakan local Kubernetes cluster yang berjalan di mesin development kita sendiri. Artikel ini memandu kita membangun cluster tersebut, men-deploy aplikasi multi-service, dan melakukan debugging dengan perintah yang sama seperti di cluster sungguhan. Setiap konsep yang dipelajari di sini bisa langsung dipindahkan ke cloud provider seperti AWS, GCP, atau Azure tanpa perubahan signifikan.

Mengapa Minikube Menjadi Pilihan Utama untuk Kubernetes Lokal

Minikube adalah tool yang menjalankan Kubernetes single-node di dalam mesin lokal. Tool ini mengemas seluruh komponen control plane — API server, scheduler, dan etcd — ke dalam satu node, sehingga kita bisa mempelajari mekanisme Kubernetes tanpa membutuhkan infrastruktur cloud. Semua perintah kubectl yang kita pelajari di sini berlaku identik di environment production.

Sebelum memulai, pastikan Docker sudah terinstal karena Minikube menggunakan Docker sebagai driver container default. Komputer kita perlu minimal 2 CPU dan 2GB RAM agar cluster berjalan lancar. Instalasi dilakukan dengan mengunduh binary Minikube dan kubectl dari situs resmi, lalu verifikasi keduanya. Pada sistem berbasis macOS, kita bisa memanfaatkan Homebrew dengan perintah brew install minikube dan brew install kubectl untuk mempercepat proses instalasi:

# Verifikasi instalasi Minikube dan kubectl
minikube version
kubectl version --client

# Mulai cluster dengan driver Docker
minikube start --driver=docker

# Konfirmasi status node dalam cluster
kubectl get nodes

Perintah minikube start akan mengunduh image Kubernetes dan mem-bootstrap seluruh komponen control plane secara otomatis. Output kubectl get nodes akan menampilkan satu node dengan status Ready. Dari titik ini, kita memiliki cluster Kubernetes fungsional yang siap menerima workload. Perintah minikube status bisa digunakan kapan saja untuk memeriksa kondisi cluster secara keseluruhan. Jika mesin kita memiliki resource terbatas, opsi --cpus dan --memory pada minikube start bisa membatasi alokasi sumber daya cluster agar tidak mengganggu proses development lainnya.

Gambar: Arsitektur high-level Kubernetes — Sumber: Wikimedia Commons (CC BY-SA 4.0)

Memahami Struktur Manifest Kubernetes untuk Aplikasi Multi-Service

Kubernetes menggunakan pendekatan declarative — kita menulis file YAML yang mendeskripsikan state yang diinginkan, lalu cluster akan berusaha memenuhi state tersebut secara terus-menerus. Tiga komponen inti yang perlu kita pahami: Deployment untuk mengelola replika container, Service untuk menyediakan akses jaringan yang stabil, dan ConfigMap untuk menyimpan konfigurasi terpisah dari image.

Sebagai contoh, kita akan membangun aplikasi dua service: frontend web dan backend API. Setiap service memiliki Deployment dan Service masing-masing. Kunci keterhubungan antar service adalah label selector — Service menemukan pod yang harus dituju berdasarkan label yang didefinisikan di Deployment. Berikut manifest Deployment untuk service backend:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-api
  labels:
    app: backend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
        - name: api
          image: nginx:alpine
          ports:
            - containerPort: 80
          env:
            - name: APP_ENV
              value: development

Manifest ini mendefinisikan dua replika container Nginx dengan label app: backend. Bagian selector.matchLabels harus konsisten dengan label di dalam template, karena Service akan menggunakan label yang sama untuk merutekan traffic. Nilai environment disuntikkan melalui env sehingga konfigurasi tidak terkunci di dalam image.

Perbedaan paling penting antara manifest Deployment dan Service adalah cara keduanya mengelola lifecycle. Deployment bertanggung jawab atas jumlah replika, update, dan rollback — sedangkan Service hanya menjadi lapisan abstraksi jaringan yang menstabilkan endpoint di depan pod. Ketika pod di-delete dan diganti, IP address-nya berubah, tetapi Service tetap menjadi pintu masuk yang sama. Inilah alasan mengapa komunikasi antar service tidak pernah dilakukan melalui IP pod secara langsung.

Deploy Aplikasi Multi-Service ke Cluster Minikube

Dengan manifest yang sudah siap, kita deploy kedua service sekaligus menggunakan kubectl apply. Perintah ini bersifat idempotent — menjalankannya berulang kali tidak akan membuat resource ganda, hanya menyinkronkan state yang ada dengan yang kita definisikan.

# Deploy semua manifest dalam direktori
kubectl apply -f k8s-manifests/

# Verifikasi status deployment, pod, dan service
kubectl get deployments
kubectl get pods
kubectl get services

# Akses aplikasi dari browser
minikube service frontend-web --url

Perintah kubectl apply -f k8s-manifests/ membaca seluruh file YAML dalam direktori dan menerapkannya sekaligus. Setelah itu, kubectl get pods menampilkan pod dengan status Running — jika ada pod yang Pending atau ContainerCreating, cluster sedang menarik image. Service frontend menggunakan tipe NodePort agar bisa diakses dari luar cluster, sedangkan service backend menggunakan ClusterIP yang hanya bisa diakses oleh pod lain secara internal.

Untuk menghubungkan frontend ke backend, kita cukup memanggil nama Service sebagai hostname: http://backend-api. Kubernetes memiliki internal DNS resolver yang menerjemahkan nama Service ke IP address-nya secara otomatis. Ini berarti kita tidak perlu meng-hardcode IP address backend di dalam kode frontend. Proses service discovery ini menjadi salah satu keunggulan utama Kubernetes dibandingkan mengelola koneksi antar container secara manual. Ketika replica backend bertambah atau berkurang, nama Service tetap sama dan traffic otomatis didistribusikan ke seluruh pod yang sehat.

Gambar: Cara pod networking dan Service menyelesaikan dependensi jaringan — Sumber: Wikimedia Commons (CC BY-SA 4.0)

Debugging Container di Dalam Cluster Minikube

Saat container gagal berjalan, langkah pertama adalah mengidentifikasi status pod dan membaca log. Perintah kubectl describe pod memberikan gambaran lengkap tentang event yang terjadi, termasuk alasan kegagalan seperti CrashLoopBackOff atau ImagePullBackOff.

# Lihat log container yang bermasalah
kubectl logs <nama-pod>

# Detail event dan alasan kegagalan pod
kubectl describe pod <nama-pod>

# Masuk ke dalam container untuk inspeksi langsung
kubectl exec -it <nama-pod> -- /bin/sh

# Forward port untuk debugging akses langsung ke pod
kubectl port-forward <nama-pod> 8080:80

kubectl logs menampilkan output dari container — tempat pertama mencari error aplikasi. Jika log kosong atau container restart terus-menerus, kubectl describe pod menampilkan bagian Events yang menjelaskan alasan dari sisi cluster. Untuk pemeriksaan lebih dalam, kubectl exec membuka shell di dalam container sehingga kita bisa memeriksa file, environment variable, dan koneksi jaringan. Alur debugging yang sistematis selalu dimulai dari status pod, dilanjutkan ke log, dan diakhiri dengan inspeksi langsung di dalam container.

Kegagalan ImagePullBackOff biasanya menandakan image yang dirujuk tidak ada di registry atau nama image salah ketik. CrashLoopBackOff menandakan container berhasil dimulai tetapi langsung crash — penyebab paling umum adalah error di dalam aplikasi itu sendiri atau environment variable yang hilang. Kedua kondisi ini bisa dilihat langsung di kolom STATUS ketika menjalankan kubectl get pods.

Satu kesalahan umum pada aplikasi multi-service adalah frontend tidak bisa menjangkau backend. Kasus ini biasanya terjadi karena nama Service yang salah atau port yang tidak cocok. Kita bisa menguji koneksi dari dalam pod frontend menggunakan kubectl exec lalu menjalankan curl http://backend-api.

Best Practices dan Workflow Pengembangan dengan Minikube

Minikube dirancang untuk workflow iteratif yang cepat. Setelah mengubah manifest, kita cukup menjalankan kubectl apply -f lagi — Kubernetes akan melakukan rolling update tanpa menghentikan service. Tidak ada kebutuhan untuk me-restart cluster setiap kali kode berubah. Workflow ini sangat mirip dengan cara tim DevOps bekerja di production, sehingga kebiasaan yang terbentuk di Minikube langsung relevan ketika kita berpindah ke cluster sungguhan.

Minikube juga menyediakan addons yang memperkaya workflow development. Addon ingress memungkinkan kita menguji routing HTTP layaknya di production, sedangkan dashboard menyediakan antarmuka visual untuk memantau pod, deployment, dan service dalam browser. Mengaktifkannya cukup dengan minikube addons enable dashboard.

Penting untuk diingat bahwa Minikube adalah environment single-node dengan resource terbatas. Tool ini bukan tempat untuk uji beban atau simulasi production yang membutuhkan multi-node. Setelah selesai bekerja, bersihkan resource yang tidak terpakai dengan kubectl delete -f k8s-manifests/ dan matikan cluster dengan minikube stop untuk menghemat resource mesin. Perintah minikube delete bisa menghapus seluruh cluster beserta datanya jika kita ingin memulai dari nol.

Dengan kemampuan menjalankan Kubernetes secara lokal, kita bisa membangun kepercayaan diri terhadap konsep cluster, deployment, dan service discovery sebelum terjun ke environment production. Mulailah dari aplikasi dua service sederhana, lalu perluas dengan ConfigMap, Secret, dan Ingress seiring bertambahnya pemahaman. Setiap manifest yang kita tulis di Minikube akan berjalan identik di production, menjadikan tool ini investasi belajar yang sangat efisien untuk siapa pun yang ingin serius mendalami container orchestration.

Jika ingin memperdalam skill orchestration hingga level production, Rumah Coding menyediakan program yang membahas Docker, Kubernetes, dan deployment aplikasi nyata secara bertahap. Bergabunglah untuk belajar langsung dari praktisi yang mengelola infrastruktur di dunia kerja.