Problem yang Diselesaikan #

Kubernetes tidak lahir dari ide di atas kertas. Ia lahir karena ada serangkaian masalah konkret yang membuat operasional software di skala besar menjadi sangat menyakitkan. Memahami masalah-masalah ini penting — supaya kamu tahu kapan Kubernetes relevan untuk situasimu, dan kapan tidak.

Masalah 1: Deploy Manual Tidak Skalabel #

Di awal ekosistem container, workflow yang umum terlihat seperti ini: build image, SSH ke server, jalankan docker run, selesai. Pendekatan ini bekerja dengan baik untuk satu atau dua server. Tapi bayangkan kamu punya 20 server dan 15 microservice yang harus di-deploy ulang setiap hari.

Workflow tanpa orchestrator:

Developer → build image
         → SSH ke server-1 → docker stop, docker pull, docker run
         → SSH ke server-2 → docker stop, docker pull, docker run
         → SSH ke server-3 → docker stop, docker pull, docker run
         → ... (diulang untuk setiap server dan setiap service)

Masalah:
  ✗ Rentan human error — typo di satu server bikin inkonsistensi
  ✗ Tidak ada rollback yang mudah jika deploy gagal di tengah jalan
  ✗ Downtime selama proses update berlangsung
  ✗ Tidak skalabel — 20 server sudah menyiksa, 200 server mustahil

Kubernetes menyelesaikan ini dengan deployment deklaratif. Kamu cukup bilang “update image ini ke versi baru” — Kubernetes yang mengganti container di semua node secara bertahap, dengan rollback otomatis jika ada yang gagal.

Masalah 2: Tidak Ada Pemulihan Otomatis #

Container crash. Ini bukan kondisi luar biasa — ini kondisi normal dalam sistem yang cukup kompleks. Pertanyaannya bukan “apakah container akan crash?” tapi “apa yang terjadi ketika ia crash?”

Tanpa orchestrator, jawabannya sederhana: tidak ada yang terjadi. Container mati, layanan mati, user melihat error, engineer mendapat notifikasi di jam 3 pagi.

Skenario tanpa self-healing:

[02:47] Container "payment-service" crash karena OOM
[02:47] Layanan payment tidak bisa diakses
[02:52] Alert masuk ke on-call engineer
[03:01] Engineer bangun, SSH ke server
[03:08] Container di-restart manual
[03:08] Total downtime: ~21 menit

Skenario dengan Kubernetes:

[02:47] Container "payment-service" crash
[02:47] Kubernetes mendeteksi Pod tidak sehat
[02:47] Kubernetes menjalankan Pod pengganti di node yang tersedia
[02:48] Layanan kembali normal
[02:48] Total downtime: ~60 detik (waktu startup container)

Kubernetes terus memantau kondisi setiap Pod. Jika Pod mati atau tidak merespons health check, Kubernetes langsung menggantinya — tanpa perlu intervensi manual.

Masalah 3: Resource Tidak Efisien #

Cara tradisional mengalokasikan server adalah dengan memesan server berdasarkan peak load: “aplikasi ini di saat paling ramai butuh 4 CPU”, maka kita pesan server dengan 4 CPU dan biarkan ia berjalan 24 jam sehari. Di jam-jam sepi, 3 CPU menganggur. Ini pemborosan.

Masalah ini berlipat ganda ketika kamu punya banyak microservice dengan pola traffic yang berbeda.

Tanpa bin-packing:

Server A (8 CPU):  [App 1: 4 CPU] [kosong: 4 CPU]
Server B (8 CPU):  [App 2: 2 CPU] [kosong: 6 CPU]
Server C (8 CPU):  [App 3: 3 CPU] [kosong: 5 CPU]

Utilisasi rata-rata: ~37%  ← mayoritas resource terbuang

Dengan Kubernetes bin-packing:

Server A (8 CPU):  [App 1: 4 CPU] [App 2: 2 CPU] [App 3: 2 CPU]
Server B (8 CPU):  [App 3: 1 CPU] [App 4: 5 CPU] [reserve: 2 CPU]

Utilisasi rata-rata: ~81%  ← jauh lebih efisien

Kubernetes scheduler otomatis menempatkan container ke node yang punya resource tersedia, berdasarkan request dan limit yang kamu deklarasikan. Hasilnya: utilisasi server meningkat, biaya infrastruktur turun.

Masalah 4: Scaling Manual Lambat #

Traffic aplikasi tidak selalu konstan. Ada jam sibuk, ada hari sibuk, ada event yang tiba-tiba membuat traffic melonjak. Menangani ini secara manual berarti: memantau traffic, memutuskan kapan perlu tambah server, pesan server (butuh waktu), deploy container, lalu buka traffic.

Siklus scaling manual:

[12:00] Traffic mulai naik
[12:05] Engineer mendeteksi, mulai proses scaling
[12:12] Server baru tersedia
[12:18] Deploy dan konfigurasi selesai
[12:18] Total waktu respons: ~18 menit

Selama 18 menit itu: sebagian user mengalami slowdown atau error.

Dengan Horizontal Pod Autoscaler Kubernetes:

[12:00] Traffic mulai naik, CPU utilization melewati threshold
[12:01] Kubernetes otomatis menambah Pod baru
[12:02] Pod siap menerima traffic
[12:02] Total waktu respons: ~2 menit

Kubernetes mendukung autoscaling berbasis metric (CPU, memory, atau custom metric). Saat load turun, Kubernetes juga otomatis mengurangi jumlah Pod — sehingga resource tidak terbuang di jam sepi.

Masalah 5: Kompleksitas Networking Multi-Service #

Microservice berarti banyak service yang perlu berkomunikasi satu sama lain. Dalam model tradisional, kamu harus menyimpan IP address setiap service di konfigurasi, dan memperbarui konfigurasi itu setiap kali service berpindah server atau di-restart.

Masalah service discovery tanpa Kubernetes:

App A → butuh alamat App B untuk panggil API
      → simpan IP 192.168.1.45 di konfigurasi

[Server App B crash, container restart di server lain]
→ IP berubah menjadi 192.168.1.67
→ App A masih pakai 192.168.1.45 → connection refused
→ Harus update config manual → restart App A → downtime lagi

Kubernetes memiliki sistem networking built-in. Setiap service mendapat DNS name yang stabil — bukan IP. Ketika Pod berpindah atau restart, DNS name tetap sama. Service discovery menjadi transparan.

Apa yang Tidak Diselesaikan Kubernetes #

Penting untuk jujur: Kubernetes bukan solusi untuk semua masalah infrastruktur.

Kubernetes TIDAK menyelesaikan:
  ✗ Arsitektur aplikasi yang buruk — aplikasi monolith yang tidak dirancang
    untuk di-scale horizontal tidak akan tiba-tiba skalabel karena Kubernetes
  ✗ Keamanan aplikasi — Kubernetes menyediakan tools keamanan, tapi tidak
    mengamankan kode aplikasi kamu secara otomatis
  ✗ Database management — menjalankan database stateful di Kubernetes
    butuh pemahaman mendalam dan desain yang cermat
  ✗ Kompleksitas operasional — Kubernetes justru menambah layer kompleksitas.
    Untuk aplikasi kecil, kompleksitas ini tidak sebanding dengan manfaatnya

Ringkasan #

Deploy manual tidak skalabel — Kubernetes mengganti SSH-dan-jalankan dengan deployment deklaratif yang konsisten di semua node.
Crash tanpa pemulihan otomatis — self-healing Kubernetes memangkas downtime dari menit ke detik tanpa intervensi manual.
Resource terbuang — scheduler Kubernetes menempatkan container secara efisien (bin-packing), meningkatkan utilisasi server secara signifikan.
Scaling manual lambat — Horizontal Pod Autoscaler bereaksi dalam hitungan menit, bukan puluhan menit seperti scaling manual.
Service discovery rapuh — Kubernetes memberi setiap service DNS name yang stabil, menghilangkan ketergantungan pada IP yang berubah.
Kubernetes bukan obat universal — ia tidak memperbaiki arsitektur aplikasi yang buruk dan justru menambah kompleksitas untuk sistem kecil.

← Sebelumnya: Apa itu Kubernetes? Berikutnya: Alternatif Kubernetes →