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

TL;DR

• Kegagalan Kubernetes di produksi hampir selalu lintas lapisan: DNS, CNI, storage, admission, atau kapasitas.
• Control plane sehat bukan bukti bahwa platform secara keseluruhan sedang sehat.
• Tim platform perlu menguji jalur pemulihan dan dependency graph, bukan hanya jalur deploy normal.

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.

Problem di Production

Mode gagal paling mahal di Kubernetes jarang muncul sebagai satu alarm besar. Mereka datang sebagai kombinasi kecil: DNS melambat, retry naik, CPU ikut meningkat, dan HPA menambah replika pada waktu yang salah. Karena gejalanya tersebar, tim mudah salah mendiagnosis dan menghabiskan waktu pada layer yang bukan sumber masalah.

Mental Model

Anggap cluster sebagai sekumpulan control loop yang saling memengaruhi. Scheduler, autoscaler, kubelet, CNI, CSI, ingress, dan webhook masing-masing mengambil keputusan sendiri. Saat satu loop melambat, loop lain dapat memperbesar masalah.

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.

Dari sudut operasi

Dari sudut operasi, sinyal paling berguna biasanya bukan hanya node health, tetapi latency DNS, CNI dataplane error, admission latency, pending volume operations, dan backlog restart pod. Sinyal inilah yang membantu membedakan apakah cluster sedang sempit kapasitas atau mengalami regressi platform.

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.

Decision point yang sering menentukan hasil

Arsitektur Kubernetes yang sehat menempatkan komponen “pendukung” seperti DNS, ingress, CSI, dan webhook sebagai dependency tier-1. Mereka perlu redundant, observable, dan memiliki timeout yang realistis agar recovery path tidak ikut macet.

Practical Implementation

Mulai dari kontrol paling sempit yang bisa langsung memberi nilai operasional. Fokusnya bukan membuat desain paling lengkap, tetapi membuat satu jalur implementasi yang dapat direview, diuji, dan dipulihkan.

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule

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.

Trade-offs

• Menambah guardrail platform membuat cluster lebih aman, tetapi juga menambah kompleksitas perubahan aplikasi.
• Managed service mengurangi beban control plane, tetapi tidak menghilangkan tanggung jawab pada DNS, CNI, dan workload behavior.
• Timeout yang longgar mencegah false alarm, tetapi bisa memperlambat recovery saat komponen benar-benar mati.

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.

Guardrail tambahan yang layak dipasang

• Menambah guardrail platform membuat cluster lebih aman, tetapi juga menambah kompleksitas perubahan aplikasi.
• Managed service mengurangi beban control plane, tetapi tidak menghilangkan tanggung jawab pada DNS, CNI, dan workload behavior.
• Timeout yang longgar mencegah false alarm, tetapi bisa memperlambat recovery saat komponen benar-benar mati.

Failure Modes

• Admission webhook lambat membuat aksi pemulihan seperti restart atau rollout ikut tersendat.
• CoreDNS atau upstream resolver overload sehingga aplikasi terlihat rusak secara acak.
• Storage latency tinggi membuat workload stateful melambat walau pod tetap berstatus Running.

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.

Pada level senior engineer, tujuan utamanya bukan hanya membuat sistem berjalan, tetapi membuat pilihan desainnya cukup jelas untuk diaudit, diubah, dan dipulihkan saat kondisi produksi memburuk.

Pada level senior engineer, tujuan utamanya bukan hanya membuat sistem berjalan, tetapi membuat pilihan desainnya cukup jelas untuk diaudit, diubah, dan dipulihkan saat kondisi produksi memburuk.