Post-Mortem & Incident Runbook: Service Mesh di Kubernetes: Mengelola Traffic Istio & Envoy

1. Alarm Tengah Malam: Saat Layanan Produksi Mulai Tumbang

Pukul 02.14 WIB. Ponsel saya berdering kencang, memecah keheningan malam dengan alarm bernada tinggi dari PagerDuty. Layar menampilkan metrik merah menyala: latensi frontend berbasis Go melonjak dari rata-rata 45 milidetik menjadi lebih dari 8 detik, diikuti oleh lonjakan error rate HTTP 503 Service Unavailable yang menyentuh angka 34%. Di saluran Slack tim infrastructure, bot pemantau sibuk mengirimkan rentetan peringatan dari klaster Kubernetes produksi kami.

[ALERT] 02:14:02 - High HTTP 503 Error Rate on service/web-frontend
[ALERT] 02:14:15 - Envoy upstream_rq_timeout on cluster outbound|8080||backend-api.production.svc.cluster.local
[ALERT] 02:14:30 - Pod restart detected: istio-proxy (Container: istio-init)

Sebagai Senior Staff Engineer yang bertugas on-call minggu ini, kepanikan bukanlah opsi. Masalah ini melibatkan arsitektur Service Mesh yang baru saja kami migrasikan minggu lalu—sebuah tumpukan kompleks yang melibatkan Istio sebagai control plane dan Envoy sebagai sidecar proxy yang menyusup ke setiap pod aplikasi. Layanan web utama kami yang melayani jutaan pengguna melalui Nginx ingress controller, berkomunikasi dengan backend Go, mengambil data dari database MySQL, serta mengandalkan Redis untuk caching, tiba-tiba lumpuh total bukan karena basis data yang down, melainkan karena lalu lintas internal mereka sendiri saling mencekik di dalam lorong mesh.

[!WARNING] Jangan pernah berasumsi bahwa migrasi service mesh selesai saat pod berhasil berjalan. Kegagalan komunikasi tersembunyi seringkali baru muncul saat connection pool mengalami kejutan beban (load spike) di tengah malam.

Mari kita bedah bagaimana jejak digital di sistem membantu kami keluar dari labirin latensi ini, dimulai dari tumpukan log yang berserakan di seluruh node klaster.

2. Jejak Digital: Menelusuri Anomali Log & Lonjakan Metrik

Tanpa membuang waktu, saya langsung membuka terminal dan mengarahkan kubectl ke namespace produksi. Langkah pertama seorang detektif infrastruktur bukanlah langsung me-restart pod, melainkan mengumpulkan bukti forensik. Saya mulai dengan memeriksa log dari kontainer sidecar istio-proxy pada layanan web-frontend yang mengalami kelambatan ekstrem.

kubectl logs -n production deployment/web-frontend -c istio-proxy --tail=100 -f

Deretan baris log mengalir deras, namun ada pola mencurigakan yang berulang kali muncul:

{
  "timestamp": "2023-10-24T02:15:10.112Z",
  "response_code": 503,
  "response_flags": "UF",
  "upstream_cluster": "outbound|8080||backend-api.production.svc.cluster.local",
  "duration": 5002,
  "bytes_received": 0,
  "bytes_sent": 0
}

Bendera respons UF (Upstream Failure) pada Envoy adalah petunjuk emas. Ini berarti Envoy di sisi klien (frontend) gagal terhubung ke Envoy di sisi pelayan (backend-api) karena batas waktu (timeout) tercapai atau koneksi ditolak secara masif. Saya kemudian melompat ke dasbor Grafana khusus Istio untuk melihat metrik Arsitektur Sidecar Proxy Envoy. Terlihat jelas bahwa connection pool untuk klaster backend-api mengalami saturasi total (pool overflow), di mana jumlah permintaan yang mengantre jauh melampaui batas maksimum yang diizinkan oleh konfigurasi default Istio.

# Konfigurasi bawaan yang menjebak: batas koneksi terlalu ketat untuk beban tinggi
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: default-backend-circuit-breaker
spec:
  host: backend-api.production.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
        maxRequestsPerConnection: 10

[!TIP] Bendera UF dan UO (Upstream Overflow) pada log akses Envoy adalah indikator utama masalah circuit breaking atau kehabisan kapasitas connection pool. Selalu pantau metrik envoy_cluster_upstream_rq_pending_overflow di Prometheus.

Dengan bukti forensik di tangan, saatnya kita membongkar akar masalah yang sebenarnya mengapa konfigurasi standar ini berubah menjadi bencana sistemik.

3. Membongkar Biang Kerok: Akar Masalah yang Sebenarnya

Setelah menarik nafas dalam-dalam dan mencocokkan linimasa kejadian, akar masalahnya menjadi sangat jelas. Sore harinya, tim backend merilis pembaruan pada layanan Go yang memicu lonjakan 并发 (concurrency) secara tiba-tiba karena adanya proses sinkronisasi data massal yang dijadwalkan ulang. Layanan frontend mengirimkan ribuan permintaan HTTP/1.1 secara simultan ke backend-api.

Di sinilah Zero-Trust Network dengan Istio mTLS memainkan peran pedang bermata dua. Secara default, Istio memaksa enkripsi Mutual TLS (mTLS) yang ketat antar pod. Setiap jabat tangan TLS (TLS handshake) memakan sumber daya CPU tambahan pada kontainer istio-proxy yang berjalan sebagai sidecar di setiap pod.

[Client App] ---> (Localhost) ---> [Envoy Sidecar A] ===( mTLS Enkripsi )=== [Envoy Sidecar B] ---> (Localhost) ---> [Backend App]

Karena batas http1MaxPendingRequests hanya diset ke angka 10 pada DestinationRule default, Envoy segera menolak sisa permintaan yang masuk begitu antrean penuh, menghasilkan ribuan error 503. Lebih parahnya lagi, sidecar Envoy kewalahan melakukan dekripsi dan enkripsi mTLS secara bersamaan di tengah lonjakan trafik, menyebabkan peningkatan penggunaan memori yang memicu CPU throttling pada batas resource limits Kubernetes yang terlalu ketat.

[!IMPORTANT] Mengaktifkan mTLS di seluruh klaster tanpa menyesuaikan resource requests/limits pada kontainer istio-proxy dan menyetel ulang connection pool adalah resep pasti menuju bencana latensi.

Kita tidak boleh tinggal diam. Mari kita eksekusi langkah penyelamatan darurat sekarang juga untuk memulihkan kesehatan klaster dalam hitungan menit.

4. Tindakan Darurat: Menghidupkan Kembali Layanan dalam Hitungan Menit

Untuk meredakan kepanikan dan menormalkan kembali lalu lintas web, kita harus melakukan dua tindakan cepat: melonggarkan batas connection pool pada DestinationRule dan menyesuaikan alokasi sumber daya CPU/Memory untuk sidecar Envoy agar terhindar dari throttling.

Jalankan perintah one-liner darurat berikut di terminal manajemen klaster Anda untuk menerapkan penyesuaian DestinationRule secara instan:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kinds: DestinationRule
metadata:
  name: backend-api-emergency-fix
  namespace: production
spec:
  host: backend-api.production.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 2048
      http:
        http1MaxPendingRequests: 1024
        maxRequestsPerConnection: 512
    tls:
      mode: ISTIO_MUTUAL
EOF

Selanjutnya, perbarui anotasi pada deployment aplikasi untuk memberikan napas lebih lega pada kontainer istio-proxy dengan menaikkan batas sumber daya CPU dan memori:

kubectl patch deployment web-frontend -n production --type='json' -p='[
  {
    "op": "add",
    "path": "/spec/template/metadata/annotations/sidecar.istio.io~1proxyCPU",
    "value": "500m"
  },
  {
    "op": "add",
    "path": "/spec/template/metadata/annotations/sidecar.istio.io~1proxyMemory",
    "value": "512Mi"
  }
]' && kubectl rollout status deployment/web-frontend -n production

Dalam waktu kurang dari 60 detik setelah injeksi konfigurasi tersebut, grafik latensi di dasbor Grafana mulai merosot tajam kembali ke angka normal, dan tingkat error rate menyentuh angka 0%. Layanan kembali bernapas lega. Namun, pekerjaan kita belum selesai; kita harus memastikan insiden ini tidak pernah terulang kembali melalui kebijakan retrospektif yang kokoh.

5. Kebijakan Retrospektif: Menambal Celah agar Tak Pernah Terulang

Insiden tengah malam ini memberikan pelajaran berharga tentang bagaimana mengelola lalu lintas mikroservis berskala besar. Kami mengadakan sesi post-mortem keesokan harinya dan merumuskan tiga pilar arsitektur defensif baru:

1. Penerapan Canary Deployment yang Lebih Halus: Saat merilis fitur baru yang memicu lonjakan trafik, kita tidak boleh langsung melemparkan 100% beban. Kita harus memanfaatkan Canary Deployment dengan VirtualService milik Istio untuk mengarahkan trafik secara bertahap (misal: 5% -> 25% -> 100%) sambil memantau kesehatan connection pool secara real-time.

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: backend-api-canary
     namespace: production
   spec:
     hosts:
       - backend-api.production.svc.cluster.local
     http:
     - route:
       - destination:
           host: backend-api.production.svc.cluster.local
           subset: v1
         weight: 90
       - destination:
           host: backend-api.production.svc.cluster.local
           subset: v2
         weight: 10
   

2. Otomatisasi Validasi Resource Limits Sidecar: Menambahkan aturan kebijakan menggunakan OPA (Open Policy Agent) atau Gatekeeper untuk memastikan tidak ada deployment yang masuk ke klaster produksi tanpa alokasi sumber daya minimal untuk istio-proxy (minimal CPU 200m dan Memori 256Mi).

3. Penyempurnaan Retry Policy & Outlier Detection: Mengonfigurasi mekanisme circuit breaker tingkat lanjut di tingkat DestinationRule agar Envoy dapat secara otomatis mengisolasi (eject) pod backend yang bermasalah sebelum membanjiri seluruh sistem dengan kegagalan.

Agar tim on-call tidak lagi bergantung pada kebetulan untuk mendeteksi masalah serupa, kita perlu memasang sistem alarm proaktif yang terintegrasi secara cerdas.

6. Pasang Alarm: Otomasi Deteksi Dini untuk Tim On-Call

Deteksi dini adalah kunci ketenangan pikiran bagi seorang Platform Engineer. Kita harus membuat aturan peringatan (alerting rules) di Prometheus yang secara spesifik memantau kejenuhan connection pool Envoy sebelum latensi meroket ke pengguna akhir.

Berikut adalah definisi aturan Prometheus (PrometheusRule) yang wajib Anda terapkan di klaster Kubernetes Anda:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: istio-envoy-circuit-breaker-alerts
  namespace: monitoring
spec:
  groups:
  - name: EnvoyPoolSaturation
    rules:
    - alert: EnvoyUpstreamRequestPendingOverflow
      expr: rate(envoy_cluster_upstream_rq_pending_overflow[5m]) > 0
      for: 1m
      labels:
        severity: warning
      annotations:
        summary: "Envoy connection pool overflow detected (instance {{ $labels.instance }})"
        description: "Koneksi antrean Envoy mengalami overflow pada klaster {{ $labels.envoy_cluster_name }}. Segera tinjau DestinationRule connectionPool."

    - alert: IstioProxyHighCpuThrottle
      expr: rate(container_cpu_cfs_throttled_seconds_total{container="istio-proxy"}[5m]) > 0.1
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: "Istio Proxy CPU Throttling tinggi"
        description: "Kontainer istio-proxy mengalami pembatasan CPU yang parah, berisiko menyebabkan latensi tinggi dan timeout mTLS."

Dengan aturan alarm ini, sistem akan memperingatkan kita jauh sebelum lonjakan error 503 melumpuhkan bisnis utama. Pengelolaan lalu lintas menggunakan Istio dan Envoy memang memerlukan ketelitian tingkat tinggi, namun dengan arsitektur yang tangguh, observabilitas yang tajam, dan runbook yang teruji, kita dapat mengubah kompleksitas service mesh menjadi fondasi infrastruktur web yang kokoh, aman, dan dapat diandalkan.