Belajar Site Reliability Engineer - Kubernetes Reliability

#Pendahuluan

Kubernetes sudah menjadi platform de facto untuk menjalankan workload, tetapi ada kesenjangan besar antara "berhasil deploy" dan "reliable": cluster yang berjalan tanpa strategi resource, autoscaling, dan disruption tolerance akan terlihat sehat di hari biasa, lalu ambruk saat yang pertama kali tidak bisa dihindari — node direboot untuk patch, satu AZ mati, atau traffic melonjak 3x.

Episode ini menerapkan prinsip SRE yang sudah kalian pelajari (headroom, forecasting, autoscaling sebagai pengaman) pada K8s: empat pengaturan yang menentukan bertahan atau tidaknya workload — requests/limits, HPA, PodDisruptionBudget, dan multi-AZ. Episode 10 adalah titik di mana teori SRE mulai "mendarat" di platform nyata.

#Resource Requests & Limits: Bahasa yang Jujur

#Requests adalah Janji Scheduler

Request adalah jumlah resource yang dijamin untuk pod — scheduler memakainya untuk memutuskan di node mana pod diletakkan, dan kubelet memastikan pod mendapat setidaknya itu. Limit adalah batas atas yang dipaksa: CPU di-throttle, memory di-OOM-kill jika melampaui.

Deployment dengan requests & limits

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: demo
          image: demo:2.4.1
          resources:
            requests:
              cpu: 500m
              memory: 256Mi
            limits:
              cpu: "1"
              memory: 512Mi

#Kesalahan Umum yang Harus Dihindari

• Tanpa requests — scheduler menganggap pod "gratis", pod menumpuk di satu node, node overload tanpa disadari.
• Requests terlalu tinggi — cluster boros: node penuh oleh janji yang tidak dipakai, pod lain menganggur menunggu.
• Limits tanpa requests — K8s menganggap requests = limits saat keduanya tidak setelaras, bisa memicu throttle tak terduga.

#HPA: Autoscaling yang Berbasis Fakta

HPA sudah disinggung di episode 8; di K8s inilah ia diwujudkan. Aturan praktis yang sering dilanggar:

1. Basiskan pada metrik yang mewakili beban sebenarnya, bukan hanya CPU. Untuk API, gabungkan CPU dengan metrik request rate atau latency.
2. Perhatikan jumlah replica min/max — min harus cukup untuk baseline + satu node hilang; max dibatasi agar tidak membebani downstream.
3. Stabilisasi — HPA punya fitur stabilizationWindowSeconds agar tidak naik-turun panik.

HPA multi-metrik

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: demo-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo
  minReplicas: 3
  maxReplicas: 12
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: 200

#PodDisruptionBudget: Tetap Hidup Saat Dunia "Normal"

Node reboot, drain untuk maintenance, atau update — ini bukan kegagalan, ini disruption yang dijadwalkan. Tanpa persiapan, drain satu node bisa mengambil 3 dari 3 pod service kritis. PodDisruptionBudget (PDB) memastikan kube-scheduler hanya mengganggu workload sesuai batas yang diizinkan.

PDB: min 2 pod selalu hidup

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: demo-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: demo

PDB bukan alat recovery — ia alat kesopanan: maintenance akan menunggu sampai kuota disruption tersedia, sehingga drain node tidak pernah menurunkan ketersediaan service di bawah SLO.

#Kombinasi yang Benar dengan Replikasi & Disruption

Agar PDB bermakna, pastikan:

• replicas ≥ 3 untuk service kritis (PDB minAvailable: 2 bisa menahan 1 disruption).
• Anti-affinity / topology spread — pod tersebar antar node dan AZ, bukan menumpuk di satu node.
• Rolling update dengan maxUnavailable: 0 dan maxSurge: 1 untuk service yang harus selalu tersedia.

#Multi-AZ: Kegagalan Zona Bukan Lagi Akhir Cerita

Di cloud, AZ (availability zone) adalah unit kegagalan: satu AZ mati (listrik, jaringan) tanpa sinyal. Workload yang andal harus bertahan kehilangan satu AZ:

Topology spread antar AZ

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 6
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: demo

maxSkew: 1 memaksa distribusi pod merata antar zona — dari 6 pod, maksimal selisih 1 per zona. Ini melengkapi PDB: PDB menjaga jumlah minimum saat disruption, topology spread memastikan pod tidak menggantung di satu zona yang sama.

#Praktik: Hardening Reliability Cluster

Terapkan checklist berikut ke cluster kalian — ini jadi baseline "cluster yang sehat" yang dirujuk episode-episode berikut:

1. Audit resource: semua Deployment punya requests/limits yang didasarkan pengukuran, bukan kosong.
2. HPA multi-metrik untuk semua service stateless yang menerima traffic.
3. PDB untuk setiap Deployment dengan replicas ≥ 2; minAvailable sesuai kebutuhan SLO.
4. Topology spread antar node dan AZ untuk service kritis.
5. Verifikasi dengan simulasi: drain satu node (kubectl drain), amati bahwa SLO service tidak terpengaruh.

Verifikasi distribusi pod per zona

kubectl get pods -o wide -l app=demo
kubectl top pods -l app=demo

Hasil yang sehat: pod tersebar merata, utilization jauh dari limit, dan drain node tidak menjatuhkan service.

#Penutup

Pada episode 10 ini, kalian telah meng-hardening reliability cluster Kubernetes.

Inti yang harus dibawa pulang:

• Requests/limits ditentukan dari pengukuran; requests yang kosong adalah node overload yang tak terdeteksi.
• HPA berbasis metrik nyata dengan stabilisasi; ingat posisinya sebagai pengaman jangka pendek.
• PDB melindungi workload dari disruption terencana — maintenance harus antri sesuai kuota.
• Multi-AZ hanya lengkap bila seluruh jalur (LB, DB, DNS) redundan.
• Verifikasi semuanya dengan simulasi drain node, bukan sekadar membaca konfigurasi.

Di episode 11 selanjutnya, kita beralih dari platform ke proses: release reliability — canary, blue-green, progressive delivery, dan feature flags, lengkap dengan praktik canary deployment yang aman. Sampai jumpa di episode 11!