Belajar Istio - Core Traffic Management (VirtualService & DestinationRule)

#Pendahuluan

Semua workload sudah masuk mesh. Sekarang bagian yang paling menarik: mengendalikan traffic. Episode 5 ini membahas dua CRD yang paling sering kalian tulis — VirtualService dan DestinationRule — dan cara memakainya untuk routing, pembagian trafik, redirect, hingga proteksi terhadap kegagalan.

Kuasai dua resource ini dengan baik: hampir semua pola traffic management di episode berikutnya (resilience, canary, gateway) berdiri di atas VirtualService dan DestinationRule.

#Primitive Routing di VirtualService

#host, match, dan route

VirtualService mendefinisikan bagaimana traffic menuju sebuah host diarahkan. Struktur dasarnya: hosts menentukan nama service tujuan, match memilih request berdasarkan kondisi (URI, header, method), dan route menentukan destinasi akhir:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews-routing
spec:
  hosts:
  - reviews
  http:
  - match:
    - uri:
        prefix: /api/v1
    route:
    - destination:
        host: reviews
        subset: v1
  - route:
    - destination:
        host: reviews
        subset: v2

Urutan aturan penting: aturan pertama yang cocok akan dieksekusi. Request dengan prefix /api/v1 menuju subset v1, sisanya (aturan kedua tanpa match) menuju v2. match dengan uri.prefix hanyalah salah satu dari banyak kondisi — ada juga uri.exact, uri.regex, headers, dan method.

#Weight, Redirect, dan Rewrite

Weight membagi traffic tanpa kondisi:

spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

Pembagian weight: 90 dan weight: 10 mengirim 90 persen traffic ke v1 dan 10 persen ke v2 — pola kanari paling dasar.

Untuk redirect, blok http memakai redirect.uri yang memberitahu klien lokasi baru; untuk rewrite, rewrite.uri mengganti path sebelum diteruskan ke service tujuan. Keduanya bisa dikombinasikan dengan match, misalnya mengganti prefix /migrasi menjadi /api/baru sebelum masuk ke service reviews.

#DestinationRule: Kebijakan Tujuan

#Subsets

Subset adalah pembagian logis dari sebuah service, biasanya berdasarkan label versi:

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Tanpa subset, VirtualService hanya bisa mengarahkan traffic ke seluruh Pod service. Dengan subset v1 dan v2, routing menjadi sangat presisi. Aturan seleksi berbasis label yang sama dengan kubectl get pods -l version=v1.

#Connection Pool dan Outlier Detection

Connection pool mengatur kapasitas koneksi ke upstream, sedangkan outlier detection memindahkan endpoint yang tidak sehat dari pool. Keduanya hidup di trafficPolicy DestinationRule:

spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 5s
      http:
        http2MaxRequests: 1000
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 1m
      maxEjectionPercent: 50

maxConnections: 100 melindungi backend dari kelebihan koneksi, sementara consecutive5xxErrors: 5 meng-eject Pod sementara setelah 5 error 5xx — inilah dasar circuit breaker Envoy yang akan kita pakai lebih agresif di episode 7.

#Contoh Praktis: A/B dan Traffic Splitting

#A/B Berdasarkan Header

Untuk A/B testing, routing berdasarkan header lebih cocok daripada weight:

spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        x-group:
          exact: eksperimen
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

Request dengan header x-group: eksperimen masuk ke v2, sisanya ke v1. A/B testing seperti ini tidak mengubah kode aplikasi sama sekali.

#Verifikasi Hasil Routing

Lihat konfigurasi yang diterima sidecar dan gunakan curl untuk menguji:

kubectl get virtualservice reviews-routing -o yaml
istioctl proxy-config route deploy/reviews-v1 | grep reviews
kubectl exec deploy/reviews-v1 -c istio-proxy -- curl -s http://reviews:9080/

istioctl proxy-config route deploy/reviews-v1 menampilkan rute yang benar-benar diterapkan di Envoy — jembatan antara YAML Istio dan konfigurasi nyata.

#Penutup

Episode 5 membuka kekuatan traffic management Istio: VirtualService untuk routing berbasis match, weight, redirect, dan rewrite; DestinationRule untuk subset, connection pool, outlier detection, dan load balancing; plus pola A/B dan traffic splitting yang bisa langsung dipakai.

Inti yang harus dibawa pulang:

• VirtualService mengatur arah traffic; DestinationRule mengatur perilaku tujuan.
• match diproses berurutan: aturan pertama yang cocok yang dieksekusi.
• Weight membagi traffic; header match cocok untuk A/B testing.
• Subset membutuhkan label yang konsisten di Deployment.
• Connection pool melindungi backend dari kelebihan koneksi.
• Outlier detection adalah dasar circuit breaker Envoy.
• istioctl proxy-config route memverifikasi konfigurasi nyata di Envoy.

Di episode 6 selanjutnya kita akan keluar dari cluster: gateways, ingress, dan egress — membedakan ingress gateway dari egress, terminasi TLS dan routing berbasis SNI, redirect HTTP ke HTTPS, serta ServiceEntry untuk layanan eksternal.