Kubernetes di Produksi: Mode Kegagalan yang Sering Terjadi di Dunia Nyata

Pendahuluan

Kubernetes sering diposisikan sebagai platform yang otomatis membuat sistem menjadi tahan gangguan. Kenyataannya jauh lebih rumit. Ia memang memberi abstraksi kuat untuk scheduling, rollout, dan service discovery, tetapi juga memperkenalkan lapisan kegagalan baru yang tidak ada pada sistem yang lebih sederhana.

Di produksi, outage jarang terjadi karena “Kubernetes mati total”. Gangguan biasanya berasal dari interaksi antarlapisan: DNS cluster melambat, CNI bermasalah, admission webhook time out, atau volume attach tersendat. Semua itu bisa terjadi ketika kubectl get nodes masih tampak sehat.

Memahami mode kegagalan nyata jauh lebih penting daripada sekadar hafal objek YAML.

Konsep Utama

Control plane sehat tidak berarti platform sehat

API server yang responsif dan node berstatus Ready hanya menjawab sebagian kecil dari kesehatan cluster. Traffic pengguna masih bisa gagal jika CoreDNS overload, dataplane CNI mengalami regresi, ingress controller gagal reload, IP pool habis, atau webhook admission memblok pembuatan pod baru.

Tekanan resource bersifat non-linear

Tekanan memori dan CPU jarang muncul sebagai satu kegagalan besar. Satu burst workload bisa memicu eviction, pod berpindah node, cache dingin, retry meningkat, dan latency menyebar ke mana-mana. Gejalanya terlihat acak, padahal akar masalahnya adalah kapasitas yang dirancang terlalu tipis.

Komponen kecil sering menjadi titik kritis

CoreDNS, CSI controller, admission webhook, dan service mesh control plane sering dianggap komponen pendukung. Dalam banyak insiden justru komponen-komponen inilah yang menjadi pengali blast radius.

Arsitektur / Cara Kerja

Kesehatan cluster harus dilihat sebagai tumpukan beberapa lapisan:

1. control plane untuk API dan scheduling
2. worker node untuk runtime container
3. jaringan cluster melalui CNI dan dataplane
4. DNS cluster untuk service discovery
5. storage layer untuk persistent workload
6. admission dan policy controller

Masalahnya, setiap lapisan punya control loop sendiri. Scheduler mencoba memenuhi desired state. HPA menaikkan replika. CSI meng-attach volume. Service mesh memprogram sidecar. Jika satu lapisan melambat atau memberi sinyal yang salah, lapisan lain dapat memperparah kondisi.

Studi Kasus / Masalah Nyata

DNS cluster melambat dan aplikasi tampak rusak acak

Ini salah satu pola paling umum. Gejalanya tampak seperti aplikasi tidak stabil: timeout sporadis, error koneksi, retry meningkat, CPU naik. Setelah diperiksa lebih dalam, ternyata CoreDNS mengalami tekanan tinggi atau upstream internal lambat.

Penyebab umumnya:

• cache miss terlalu tinggi
• resource limit terlalu kecil
• query berulang akibat pola koneksi aplikasi
• upstream resolver tidak stabil

Admission webhook membuat pemulihan ikut gagal

Saat service bermasalah, tim ingin rollback atau restart. Jika webhook admission sedang lambat atau tidak tersedia, aksi pemulihan itu sendiri gagal. Cluster kehilangan kapasitas sekaligus kehilangan kemampuan untuk sembuh.

Setiap komponen admission perlu dianggap sebagai layanan kritis:

• redundant
• punya timeout yang realistis
• punya failure policy yang dipahami
• punya jalur break-glass

Storage issue sering lambat didiagnosis

Gangguan storage jarang muncul dramatis di awal. Pod bisa tetap Running, tetapi request melambat karena IO tertahan. StatefulSet terlihat sehat, padahal volume attach sangat lambat. Banyak tim salah fokus ke aplikasi atau jaringan karena gejalanya tidak jelas.

Best Practices

Pantau DNS, CNI, dan storage sebagai lapisan tier-1

Metrik seperti latency DNS, cache hit ratio, conntrack saturation, retransmission, dan volume operation latency harus terlihat jelas. Banyak outage besar bisa dipersempit jauh lebih cepat bila tiga lapisan ini diobservasi dengan baik.

Set request dan limit berdasarkan data

Jangan menyalin angka dari contoh. Gunakan data steady-state, puncak beban, dan karakteristik workload yang nyata.

Uji jalur pemulihan, bukan hanya deploy normal

Rollback, restart massal, reschedule setelah node drain, dan failover stateful perlu diuji. Sistem yang tampak sehat saat deploy biasa belum tentu mudah dipulihkan saat komponen pendukung ikut bermasalah.

Perlakukan upgrade sebagai dependency graph

Upgrade Kubernetes tidak boleh dianggap satu tombol. Evaluasi urutan versi cluster, node image, CNI, CSI, ingress, dan admission stack dengan hati-hati.

Kesalahan Umum

• menganggap managed Kubernetes berarti tanggung jawab operasi mengecil drastis
• memantau node health tetapi mengabaikan DNS, CNI, dan storage
• memasang terlalu banyak webhook sinkron tanpa memikirkan mode gagal
• meng-upgrade banyak komponen fondasi dalam satu jendela perubahan
• membiarkan tim aplikasi men-debug sendiri masalah lapisan cluster tanpa tooling memadai

Kesimpulan

Kubernetes di produksi bukan hanya platform container, melainkan kumpulan control loop yang saling memengaruhi. DNS, jaringan, storage, admission, dan kapasitas menentukan apakah cluster mampu menyerap gangguan atau justru memperbesar blast radius. Tim yang memahami mode kegagalan nyata akan jauh lebih siap membangun guardrail dan prosedur pemulihan yang masuk akal.