UNDER PRESSURE

Level 1 · Menggandakan Mesin

Sesi 15: Robot yang Menjaga Pod Tetap Hidup: Kubernetes, HPA, & Probe

Bagaimana jika sebuah server container mati mendadak jam tiga pagi, dan dalam tempo 800 milidetik penggantinya sudah aktif melayani pengguna sebelum seorang engineer pun sempat terbangun?

Sesi 15 / 343 menit baca

1. Bayangkan Jika

Sebuah pabrik memiliki 10 mesin pembuat kopi. Di atas mesin-mesin itu ada satu robot pengawas otomatis. Robot ini memegang daftar checklist: "Harus selalu ada 10 mesin yang menyala."

Jika mesin nomor 4 tersedak dan mati, robot tidak membangunkan satpam atau membunyikan alarm. Dalam hitungan detik, robot membuang mesin yang rusak ke tempat sampah, menyalakan mesin baru nomor 11 dari gudang cadangan, mencicipi kopinya untuk memastikan suhunya pas, lalu membuka pintu untuk pelanggan.

2. Apa yang Sebenarnya Terjadi

Inilah inti dari Container Orchestration (Kubernetes / OpenShift): bukan manusia yang mengelola server satu per satu, melainkan Control Loop rekonsiliasi state yang terus-menerus mencocokkan Desired State dengan Current State.

  1. Pod: - Satuan terkecil yang dijadwalkan di Kubernetes. Berisi satu atau lebih container yang berbagi alamat IP dan network namespace yang sama.
  2. ReplicaSet & Deployment: - Memastikan jumlah replika pod yang berjalan selalu sesuai deklarasi (replicas: 10). Jika 2 pod crash karena OOM (Out Of Memory), ReplicaSet seketika memerintahkan Scheduler untuk membuat 2 pod baru di Node yang tersedia.
  3. Liveness Probe vs Readiness Probe: - Liveness Probe: "Apakah pod ini masih hidup?" Jika gagal (misal: deadlock thread tak merespons), Kubernetes langsung membunuh (restart) pod tersebut. - Readiness Probe: "Apakah pod ini sudah siap menerima trafik?" Selama startup / load model belum tuntas, atau jika CPU sedang 100%, pod tidak dibunuh, melainkan hanya dikeluarkan dari daftar target Load Balancer / Service agar pengguna tidak mendapat error 502/503.
  4. HPA (Horizontal Pod Autoscaler): - Menambah atau mengurangi jumlah pod secara dinamis berdasarkan metrik CPU, Memory, atau custom RPS (misal: jika rata-rata CPU > 70%, gandakan pod dari 10 menjadi 30).
  5. Requests vs Limits: - Requests: Garansi kapasitas minimum yang harus disediakan worker Node saat menjadwalkan pod. - Limits: Batas absolut pemakaian CPU/RAM. Jika pod menembus Memory Limit, kernel Linux langsung mengirim sinyal OOMKilled (Exit Code 137).

3. Bagaimana Jika Kita Coba...

"Kita set HPA agar auto-scale sampai 200 Pod begitu ada flash sale!"

Mengapa ini sering berujung bencana di Level 2? - Database Connection Storm: Jika tiap pod membuka pool 20 koneksi database, 200 pod berarti 4.000 koneksi bersamaan yang menghantam satu database primary. Database seketika terkunci (CPU 100%, disk I/O saturated), dan seluruh sistem mati total. - Node Capacity Choke: Jika worker node fisik kehabisan RAM untuk menampung 200 pod, pod-pod baru akan macet di status Pending karena scheduler kehabisan tempat. - Menambah pod hanya memindahkan leher botol dari lapisan aplikasi ke lapisan data!

4. Nama Resminya

  • Desired State vs Current State: Prinsip rekonsiliasi deklaratif Kubernetes.
  • HPA (Horizontal Pod Autoscaler): Controller yang mengatur skala replika pod secara otomatis.
  • Kube-Scheduler: Komponen control plane yang menempatkan pod pada worker node optimal.
  • Liveness & Readiness Probes: Mekanisme health checking pod level container runtime.
  • OOMKilled (Exit Code 137): Pod dimatikan paksa karena melanggar batas memory limit.

5. Di Dunia Kita

  • Rolling Update Tanpa Downtime: Kubernetes menyalakan 1 pod versi baru, menunggu Readiness Probe sukses, baru mematikan 1 pod versi lama secara bertahap.
  • Cold Start Delay: Aplikasi Java/Spring Boot atau Python yang butuh 45 detik untuk startup bisa membuat HPA terlambat merespons lonjakan trafik mendadak (spike traffic).
  • Graceful Termination (preStop hook): Memberikan waktu bagi pod untuk menyelesaikan request yang sedang berjalan sebelum dimatikan (menghindari error 502 pada koneksi in-flight).

6. Lensa Performance Tester

Metrik dan pengujian krusial: 1. Autoscaling Reaction Time: Berapa detik jeda antara trafik melonjak hingga pod baru benar-benar menerima request (Ready)? 2. Pod Startup Latency: Waktu yang dihabiskan pod dalam fase initialization sebelum lolos Readiness Probe. 3. OOM Threshold Testing: Uji beban untuk memicu kebocoran memori (memory leak) hingga pod terkena OOMKilled di batas limit. 4. Connection Storm Impact: Berapa lonjakan koneksi DB saat HPA melipatgandakan pod dari minimum ke maksimum?

7. Pertanyaan untuk Ronde Berikutnya

Jika menambah pod dari 10 menjadi 100 semudah mengubah satu baris angka di Kubernetes, kenapa sistem kita justru sering menjadi jauh lebih lambat setelah pod ditambah?

Jawabannya adalah gerbang pembuka LEVEL 2: DATABASE ADALAH LEHER BOTOL di Sesi 16: Pods Naik, Database Tumbang.