Belajar Istio - Performance Tuning & Scalability

#Pendahuluan

Mesh yang kecil terasa ringan. Saat workload membengkak ke ratusan atau ribuan, gejala mulai muncul: istiod kewalahan, sidecar memakai terlalu banyak memori, dan konfigurasi xDS mengalir lebih lambat. Episode 14 ini membahas cara mengukur, menskalakan, dan menyetel Istio agar tetap responsif di skala besar.

#Scaling Control Plane: istiod

#Horizontal Scaling dan HPA

istiod bisa diskalakan secara horizontal, tetapi konfigurasi default-nya single replica. Untuk skala besar, aktifkan HorizontalPodAutoscaler:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: istiod
  namespace: istio-system
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: istiod
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80

averageUtilization: 80 menambah replica saat CPU istiod melewati 80 persen. Jangan hanya menambah replica tanpa data — pantau dulu metriknya (bagian terakhir episode ini).

#Mengelola xDS Churn

Istiod menghabiskan CPU terutama untuk xDS churn: setiap kali ada perubahan (service dibuat, Pod restart, config berubah), istiod harus menghitung dan mengirim konfigurasi baru ke sidecar yang terpengaruh. Cara mengurangi churn:

• Hindari update Deployment yang tidak perlu — setiap restart Pod menghasilkan event discovery.
• Batasi scope sidecar dengan Sidecar CRD (episode 12).
• Naikkan interval publish bila perlu lewat env var di istiod, misalnya PILOT_PUSH_THROTTLE.

Ingat aturan praktis: semakin banyak konfigurasi yang harus dihitung ulang, semakin berat istiod. Kurangi jumlah listener dan cluster per sidecar dengan scoping.

#Sidecar Resource Sizing

#Requests dan Limits yang Realistis

Envoy memakai resource berdasarkan jumlah listener, cluster, dan traffic. Ukuran default sering terlalu kecil atau terlalu besar. Mulai dari angka ini lalu ukur dengan metrik nyata:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: productpage
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "100m"
        sidecar.istio.io/proxyCPULimit: "2000m"
        sidecar.istio.io/proxyMemory: "128Mi"
        sidecar.istio.io/proxyMemoryLimit: "1024Mi"
    spec:
      containers:
      - name: productpage
        image: istio/examples-bookinfo-productpage-v1:1.19.0

sidecar.istio.io/proxyCPU: "100m" adalah contoh annotation untuk mengatur request CPU sidecar. Verifikasi pemakaian dengan:

kubectl top pod productpage-abc123 --containers
kubectl exec productpage-abc123 -c istio-proxy -- curl localhost:15000/stats | grep -E "server.memory|server.live"

kubectl top pod --containers menunjukkan pemakaian nyata per container. Setel request dari median pemakaian normal dan limit dengan margin aman.

#Kurangi Scope untuk Hemat Memori

Sumber memori Envoy terbesar adalah jumlah listener dan cluster di konfigurasinya. Sidecar CRD yang membatasi egress (episode 12) bisa memangkas memori secara signifikan di meshes besar — sering kali ini investasi terbaik sebelum menaikkan limit.

#Jalur TCP vs HTTP dan Connection Pool

Traffic HTTP diproses dengan filter di level L7; traffic TCP mentah tidak. Jalur HTTP membawa biaya tambahan (routing, telemetry, tracing) yang tidak ada di TCP. Saat performa adalah prioritas dan kalian tidak butuh fitur L7, pertimbangkan protocol TCP di Service dan Gateway untuk layanan tersebut.

Connection pool mengatur antrean ke upstream:

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: tuning-pool
spec:
  host: productpage
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 3s
      http:
        http2MaxRequests: 2000
        maxRequestsPerConnection: 100
        idleTimeout: 10m

idleTimeout: 10m menutup koneksi idle untuk membebaskan resource. Ukur dulu lalu setel: pool yang terlalu kecil menambah latensi, terlalu besar menghabiskan resource backend.

#Observability Control Plane

Control plane juga harus diukur. Istiod mengekspos metrik di port 15014:

kubectl exec -n istio-system deploy/istiod -- curl localhost:15014/metrics | grep -E "pilot_|istio_xds" | head -20

Perhatikan metrik seperti pilot_proxy_convergence_time (waktu konvergensi konfigurasi) dan istio_xds_push_errors. Jika konvergensi membengkak, periksa churn dan ukuran mesh. Metrik ini dipakai juga untuk alerting di episode 20.

#Penutup

Episode 14 menjaga mesh tetap cepat: HPA untuk istiod dengan pemantauan xDS churn, sizing resource sidecar berbasis pengukuran, pembatasan scope untuk menghemat memori, tuning connection pool, serta metrik control plane untuk mengukur konvergensi.

Inti yang harus dibawa pulang:

• HPA istiod membantu, tetapi kurangi churn lebih dulu.
• xDS churn adalah beban utama istiod; batasi scope dan restart yang tidak perlu.
• Sizing sidecar harus dari pengukuran nyata, bukan tebakan.
• Annotation sidecar.istio.io/proxy* mengontrol resource sidecar.
• Sidecar CRD adalah penghemat memori paling efektif.
• HTTP membawa biaya L7; pilih TCP saat tidak butuh fitur L7.
• Metrik istiod (konvergensi, push errors) menentukan kesehatan control plane.

Di episode 15 selanjutnya kita akan melampaui CRD bawaan: advanced extensibility dengan EnvoyFilter dan WASM — kapan memakai EnvoyFilter dengan aman, membangun filter Proxy-WASM untuk telemetry kustom, dan contoh header enricher serta authz hook.