Anti-Pattern Production #

Sebagian besar insiden pemadaman layanan (outages) di lingkungan produksi Kubernetes jarang sekali disebabkan oleh kegagalan sistem luar yang tidak terduga atau bug eksternal yang belum pernah diidentifikasi sebelumnya. Mayoritas kegagalan sistem justru berasal dari akumulasi pola konfigurasi berbahaya (anti-patterns) yang diabaikan selama proses pengembangan dengan dalih “nanti akan diperbaiki saat sempat”. Ketika kluster kita tumbuh menjadi besar dan beban lalu lintas pengguna meningkat, celah-celah kecil ini akan terpicu secara bersamaan, mengakibatkan kegagalan berantai (cascade failures) yang sulit diisolasi. Sebagai penutup dari seluruh seri panduan Kubernetes ini, artikel ini merangkum tujuh anti-pattern produksi paling kritis yang sering dijumpai di kluster tingkat lanjut yang sudah mature, membedah dampak operasional riilnya secara mendalam, serta menyajikan solusi mitigasi taktis yang siap diterapkan untuk mengamankan stabilitas kluster produksi kita.

Anti-Pattern 1: Ketiadaan PodDisruptionBudget (PDB) #

Ketika tim platform atau administrator kluster melakukan aktivitas pemeliharaan terencana (seperti melakukan pembersihan node/drain node untuk memperbarui versi sistem operasi host), Kubernetes akan memindahkan Pod ke Node lain. Tanpa adanya PodDisruptionBudget (PDB), Kubernetes tidak akan mempedulikan seberapa banyak replika pod aplikasi kita yang sedang aktif melayani pengguna.

# File: templates/deployment.yaml
# ANTI-PATTERN: Deployment aplikasi kritis produksi tanpa disertai PDB
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-gateway
  namespace: prod-apps
spec:
  replicas: 3
  # JANGAN: Ketiadaan PDB di manifest rilis Helm Anda!

Memahami Perilaku Voluntary Disruptions #

Kubernetes membedakan gangguan menjadi dua jenis:

• Involuntary Disruptions (Tidak Terhindarkan): Kegagalan hardware fisik Node, jaringan terputus, atau kerusakan disk. Ini tidak dapat dicegah oleh PDB.
• Voluntary Disruptions (Disengaja/Terjadwal): Pembersihan Node (kubectl drain) oleh admin, penghapusan Node oleh Cluster Autoscaler, atau penggusuran manual Pod. PDB dirancang khusus untuk melindungi aplikasi dari skenario ini.

Ketika administrator menjalankan perintah pembersihan Node:

$ kubectl drain node-worker-1 --ignore-daemonsets --delete-emptydir-data

Perintah drain akan melakukan cordon (menandai node tidak boleh menerima Pod baru) secara otomatis sebelum melakukan penggusuran (eviction). Tanpa adanya PDB, jika ketiga pod payment-gateway di atas berada di node-worker-1 dan node-worker-2, Kubernetes akan menghancurkan pod tersebut secara simultan. Akibatnya, kapasitas layanan kita akan drop menjadi 0% selama proses pembuatan pod pengganti di node baru sedang berjalan, memicu downtime transaksi instan bagi pengguna.

Solusi Konstruktif #

Selalu definisikan objek PDB bersamaan dengan Deployment aplikasi kritis di rilis manifest kita.

# File: templates/pdb.yaml
# BENAR: Menetapkan anggaran gangguan minimum untuk ketersediaan tinggi
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-gateway-pdb
  namespace: prod-apps
spec:
  # Opsi 1: Menjamin minimal 2 pod selalu sehat saat ada pemeliharaan node
  minAvailable: 2 
  
  # Opsi 2: Atau membatasi maksimal pod yang boleh down bersamaan
  # maxUnavailable: 1 
  
  selector:
    matchLabels:
      app: payment-gateway

Anti-Pattern 2: Mengaktifkan HPA Tanpa Alokasi Requests #

HPA dirancang untuk melakukan penskalaan pod secara dinamis berdasarkan persentase pemakaian CPU atau memori. Namun, anti-pattern yang sering terjadi adalah tim memasang HPA tanpa mendefinisikan blok resources.requests di tingkat kontainer Deployment.

# File: k8s/production-hpa-conflicted.yaml
# HPA terkonfigurasi dengan target CPU 60%
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: customer-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: customer-api
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

# JANGAN: Deployment target tidak memiliki requests.cpu!
spec:
  template:
    spec:
      containers:
      - name: customer-api
        resources:
          # Limits didefinisikan, namun requests CPU dikosongkan!
          limits:
            cpu: "1000m"
            memory: "512Mi"

Konsekuensi Operasional dan Kegagalan Logika HPA #

HPA bekerja dengan menghitung persentase utilitas berdasarkan rumus:

$$\text{Persentase Utilitas CPU} = \left( \frac{\text{Penggunaan CPU Aktif}}{\text{Requests CPU}} \right) \times 100%$$

Ketika requests.cpu tidak didefinisikan, pembagi dalam rumus di atas bernilai null. Akibatnya, HPA Controller di dalam kube-controller-manager akan melemparkan kesalahan FailedGetResourceMetric karena tidak dapat menghitung persentase utilitas dari Pod.

Jika kita memeriksa status HPA menggunakan perintah:

$ kubectl get hpa customer-api-hpa

Maka kolom TARGETS akan menampilkan nilai <unknown>/60% selamanya. Ketika terjadi lonjakan lalu lintas yang masif, HPA akan lumpuh (scale paralysis), tidak memicu pembuatan replika baru, dan membiarkan pod tunggal kita mengalami crash akibat beban berlebih.

Solusi Konstruktif #

Pastikan blok resources.requests.cpu dideklarasikan secara eksplisit di manifest kontainer sebelum mengaktifkan HPA.

# BENAR: Konfigurasi Deployment dengan requests lengkap
spec:
  containers:
  - name: customer-api
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "1000m"
        memory: "512Mi"

Anti-Pattern 3: Menyetel minReplicas: 1 untuk Layanan Kritis #

Menyetel parameter minReplicas: 1 pada spesifikasi HPA di produksi demi menekan pengeluaran biaya sewa VM seminimal mungkin di luar jam sibuk (misal di malam hari).

# File: k8s/production-hpa.yaml
# ANTI-PATTERN: minReplicas: 1 di tingkat produksi
spec:
  minReplicas: 1 # JANGAN: Potensi single point of failure!
  maxReplicas: 15

Konsekuensi Operasional #

• Ketiadaan High Availability: Ketika HPA melakukan penskalaan turun menjadi 1 pod di malam hari, pod tunggal tersebut bertindak sebagai single point of failure. Jika pod tersebut crash akibat galat jaringan Node atau OOMKilled, sistem akan mati total selama beberapa puluh detik sampai pod pengganti siap.
• Downtime Rolling Update: Saat kita melakukan update rilis aplikasi di malam hari dengan konfigurasi default maxUnavailable: 25% (atau minimal 1 pod), Kubernetes terpaksa mematikan satu-satunya pod yang berjalan sebelum menyalakan pod versi baru, memicu kegagalan transaksi bagi pengguna selama proses rilis.

Solusi Konstruktif #

Selalu setel batas minimal replika (minReplicas) ke angka minimal 2 (rekomendasi 3 untuk multi-AZ) pada kluster produksi guna menjamin kestabilan layanan 24/7.

Anti-Pattern 4: Cadangan Backup Tanpa Uji Restorasi #

Mengoperasikan jadwal pencadangan etcd kluster atau snapshot database harian ke bucket S3, lalu berasumsi kluster aman tanpa pernah menguji validitas file cadangan tersebut.

ANTI-PATTERN: "File cadangan menumpuk di S3, kluster dijamin aman."
  1. Velero backup terjadwal sukses mengirimkan file .tar.gz ke S3.
  2. Database pg_dump berjalan setiap hari jam 1 pagi.
  3. Namun, tim tidak pernah menguji proses restorasi file tersebut.

Konsekuensi Operasional #

Ketika terjadi bencana sesungguhnya di kluster (misalnya peretasan etcd atau kerusakan volume data), tim mencoba memulihkan data, namun proses gagal total karena:

• File backup ternyata korup akibat kegagalan transfer jaringan yang tidak disadari.
• Format file dump database tidak kompatibel dengan versi mayor mesin database baru yang di-upgrade di kluster DR.
• Kebijakan otorisasi IAM S3 telah kedaluwarsa sehingga kluster tidak dapat mengunduh file cadangan.

Solusi Konstruktif: Alur Kerja Uji Restorasi Berkala (DR Drill) #

Jadwalkan latihan simulasi bencana (Disaster Recovery Drills) secara berkala minimal setiap 3 bulan sekali. Uji coba proses restorasi file cadangan Velero ke namespace isolasi pengujian menggunakan pemetaan namespace:

# 1. Jalankan restore dari backup produksi ke namespace pengujian khusus
$ velero restore create dr-drill-restore-20260617 \
  --from-backup daily-prod-backup-20260617 \
  --namespace-mappings prod-apps:prod-restore-test

# 2. Verifikasi status kesehatan Pod hasil restore
$ kubectl get pods -n prod-restore-test

# 3. Verifikasi konsistensi data database dengan menjalankan query pengujian
# 4. Hapus namespace pengujian setelah verifikasi selesai untuk efisiensi biaya
$ kubectl delete namespace prod-restore-test

Anti-Pattern 5: Ketiadaan Requests/Limits (BestEffort QoS Class) #

Mengizinkan tim pengembang mengirimkan manifest aplikasi ke kluster produksi tanpa membatasi alokasi CPU dan memori di tingkat kontainer.

Dampak Nilai oom_score_adj Tingkat Kernel Host #

Kubernetes kubelet menerjemahkan alokasi requests/limits ke dalam konfigurasi kernel Linux /proc/[PID]/oom_score_adj secara internal berdasarkan kelas QoS:

Jika kontainer kita masuk ke kelas BestEffort akibat ketiadaan alokasi resources, kontainer tersebut akan langsung disapu bersih oleh OOM Killer host jika Node mengalami konsumsi RAM tinggi, memicu downtime mendadak tanpa ada toleransi waktu transisi.

Solusi Konstruktif #

Gunakan objek LimitRange di setiap namespace untuk otomatis menyisipkan batas default, dan terapkan ResourceQuota untuk membatasi konsumsi total tim pengembang.

Anti-Pattern 6: Single-Availability Zone (Single-AZ) Node Pools #

Membangun kluster produksi dengan meletakkan seluruh worker node di satu Zona Ketersediaan fisik (Availability Zone) yang sama (misal di GCP: asia-southeast1-a atau di AWS: ap-southeast-1a).

Konsekuensi Operasional #

Jika penyedia cloud mengalami kegagalan kelistrikan regional atau pemeliharaan terencana pada rack zona ap-southeast-1a, seluruh node worker kita akan mati secara bersamaan. Meskipun kita memiliki 10 replika Pod dan PDB terkonfigurasi, aplikasi kita tetap akan mati total karena ketiadaan infrastruktur fisik alternatif yang tersisa untuk menjalankan Pod.

Solusi Konstruktif #

Rancang node pools lintas zona ketersediaan fisik (minimal 3 AZ, misalnya ap-southeast-1a, ap-southeast-1b, dan ap-southeast-1c) dan gunakan properti topologySpreadConstraints pada manifest Pod untuk menyebarkan replika secara merata.

# BENAR: Konfigurasi sebaran lintas AZ di Deployment
spec:
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "topology.kubernetes.io/zone"
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: core-api

Anti-Pattern 7: Kluster yang Tidak Pernah Di-upgrade (Upgrade Debt) #

Membiarkan kluster produksi berjalan menggunakan versi Kubernetes yang sudah usang dan dinyatakan End-Of-Life (EOL) oleh komunitas (misalnya masih menjalankan v1.22 di tahun 2026).

Bahaya Deprecated APIs #

Kubernetes secara berkala menghapus versi API yang usang (deprecated APIs). Sebagai contoh:

• API extensions/v1beta1 untuk Ingress telah dihapus sejak v1.22 dan digantikan oleh networking.k8s.io/v1.
• API policy/v1beta1 untuk PodSecurityPolicy dihapus sejak v1.25.

Jika kita menunda upgrade terlalu lama (misal dari v1.22 langsung melompat ke v1.29), kita tidak dapat melakukan upgrade langsung secara instan karena perbedaan API yang terlalu jauh. Kita harus melakukan upgrade bertahap minor version demi minor version, memotong dan memodifikasi manifest aplikasi kita di setiap tahapan, memicu risiko kesalahan konfigurasi manusia yang sangat tinggi selama proses transisi.

Solusi Konstruktif #

Jadwalkan pemeliharaan peningkatan versi kluster secara berkala minimal sekali atau dua kali setahun. Manfaatkan fitur Release Channels pada managed Kubernetes (seperti GKE Regular Channel) untuk mengotomatiskan proses evaluasi dan peningkatan versi kluster secara bertahap dan teruji di lingkungan staging terlebih dahulu.

Checklist Pencegahan Anti-Pattern Produksi #

Gunakan checklist ini sebagai panduan audit akhir sebelum menyatakan kluster Anda siap untuk operasional skala besar:

HARDENING KETERSEDIAAN LAYANAN (HA):
  □ Setiap pod aplikasi kritis di produksi memiliki minimal 3 replika aktif.
  □ Objek PodDisruptionBudget (PDB) terkonfigurasi untuk membatasi downtime saat drain node.
  □ HPA disetel dengan nilai 'minReplicas' minimal 2 (atau 3) untuk menghindari cold-start outage.
  □ preStop lifecycle hook 'sleep 10' terpasang pada kontainer untuk mencegah HTTP 502 saat rolling update.

MANAJEMEN SUMBER DAYA & AUTOSCALING:
  □ Seluruh kontainer memiliki spesifikasi requests dan limits yang jelas (menghindari QoS BestEffort).
  □ HPA terkonfigurasi hanya pada kontainer yang memiliki spesifikasi 'requests.cpu' terdefinisi.
  □ VPA dan HPA tidak memantau metrik yang sama pada satu Deployment untuk mencegah 'scale war'.
  □ LimitRange terpasang di setiap namespace aktif untuk menyisipkan nilai default otomatis.

DISASTER RECOVERY & INFRASTRUKTUR:
  □ Latihan simulasi bencana (DR Drills) dijalankan secara rutin ke namespace terisolasi minimal setiap 3 buku.
  □ Backup database relasional dilakukan menggunakan dump native (pg_dump) demi konsistensi data.
  □ File backup disimpan secara terenkripsi di S3 dengan fitur Object Lock (WORM) aktif.
  □ Worker node pools disebar merata di minimal 3 Availability Zones (Multi-AZ).
  □ Versi minor Kubernetes kluster ditingkatkan secara berkala dan tidak tertinggal > 2 minor version.

Ringkasan #

• PDB Melindungi Drain Node — Jangan biarkan aktivitas maintenance infrastruktur memadamkan aplikasi; wajib buat PDB (minAvailable / maxUnavailable) untuk setiap deploy produksi.
• HPA Butuh Requests — Selalu nyalakan parameter requests pada CPU/Memori kontainer agar HPA tidak stuck dalam status <unknown> saat membaca metrik.
• Hindari minReplicas: 1 — Jaga minimal replika HPA di angka 2 untuk menghindari matinya aplikasi saat pod tunggal crash atau mengalami pergantian versi.
• Uji Restore Anda secara Teratur — Ingatlah bahwa file backup di S3 tidak ada nilainya jika kita tidak pernah melatih tim untuk merestorasinya secara sukses di kluster.
• Matikan QoS BestEffort — Amankan Node fisik dari ancaman kelaparan memori (memory starvation) dengan melarang pod berjalan tanpa parameter resources deklaratif.
• Gunakan Multi-AZ Node Pools — Lindungi kluster dari krisis infrastruktur regional dengan menyebarkan worker node pools merata lintas Availability Zones.
• Lakukan Upgrade Berkala — Cegah penumpukan upgrade debt dengan meningkatkan versi minor Kubernetes secara teratur guna menutup celah CVE keamanan kluster.