Belajar Istio - Testing Service Mesh (Integration & E2E)

#Pendahuluan

Konfigurasi yang valid secara statis belum tentu benar secara perilaku. Episode 19 ini membahas cara menguji mesh secara nyata — dari integrasi di test cluster, simulasi dan contract testing, load testing, sampai chaos experiments yang membuktikan sistem tetap hidup saat sesuatu rusak.

#Strategi Integrasi dengan Test Cluster

#Test Cluster yang Realistis

Setiap perubahan penting pada konfigurasi mesh harus diuji di cluster yang menyerupai produksi: versi Istio yang sama, profile yang sama, dan jumlah service yang representatif. Jenis cluster yang biasa dipakai:

• Unit/integration: cluster kecil (kind) untuk menguji satu fitur.
• Pre-prod: replika produksi untuk uji e2e penuh.
• Transient: cluster yang dibuat per pipeline dan dihancurkan setelah selesai.

kind create cluster --name mesh-e2e --config cluster-e2e.yaml
istioctl install --set profile=default -y
kubectl apply -f samples/bookinfo/

Uji kebijakan yang sama di cluster ini sebelum menyentuh staging produksi.

#Simulasi Traffic

Setelah service terpasang, hasilkan traffic nyata untuk memastikan routing bekerja:

kubectl exec deploy/productpage-v1 -c istio-proxy -- curl -s http://reviews:9080/reviews/0
kubectl exec deploy/productpage-v1 -c istio-proxy -- curl -s http://details:9080/details/0

kubectl exec ... -c istio-proxy -- curl menjalankan request dari sisi sidecar, memastikan traffic benar-benar lewat mesh dan bukan shortcut.

#Contract Testing dan Verifikasi Konfigurasi

#Contract Testing

Contract test memastikan service pemanggil dan penerima sepakat pada kontrak (path, header, payload). Ini krusial saat routing diubah: request yang valid di sisi klien harus tetap valid di sisi server. Contoh paling sederhana: snapshot virtualservice yang diharapkan lalu dibandingkan dengan yang terpasang.

#Verifikasi Sinkronisasi

Di test cluster, pastikan setiap perubahan benar-benar sampai ke proxy:

istioctl proxy-status | grep SYNCED
istioctl analyze --all-namespaces

istioctl analyze --all-namespaces menjadi gate otomatis: tidak boleh ada Error sebelum test lanjut. Kombinasi dengan proxy-status membuktikan konfigurasi tersebar.

#Load Testing dalam Konteks Mesh

#Memakai k6 atau fortio

Load testing di dalam mesh memerlukan perhatian khusus: sidecar menambah latensi dan resource. Ukur baseline tanpa mesh lalu dengan mesh agar overheadnya terlihat:

fortio load -c 100 -qps 1000 -t 60s http://productpage:9080/productpage

fortio load -c 100 -qps 1000 mengirim 1000 request per detik selama 60 detik. Perhatikan metrik: p50/p99 latency, error rate, dan istio_requests_total di Prometheus. Overhead 1-5 persen latency adalah normal; lonjakan besar menandakan tuning yang buruk (episode 14).

#Verifikasi Metrik Hasil

Setelah load test, cek distribusi hasil:

rate(istio_requests_total{destination_service="productpage.default.svc.cluster.local",response_code="500"}[5m])

Jika muncul 500 selama beban tinggi, periksa connection pool dan outlier detection — bukan langsung menaikkan resource.

#Chaos Experiments pada Network Faults

#Injeksi Kegagalan Terkontrol

Chaos experiments memakai fault injection (episode 7) untuk membuktikan sistem pulih:

1. Hidupkan fault.abort 50 persen pada satu subset.
2. Amati apakah retry dan circuit breaker bekerja.
3. Matikan fault; verifikasi traffic kembali normal.
4. Dokumentasikan hasil sebagai bukti ketahanan.

#Uji Kegagalan Infrastruktur

Selain fault di level mesh, uji kegagalan di level infrastruktur: restart istiod, matikan node, atau hentikan satu backend Pod:

kubectl delete pod -l version=v1
kubectl rollout restart deployment/reviews-v2
kubectl get pods -l app=reviews -o wide

kubectl delete pod -l version=v1 mensimulasikan kehilangan backend. Perhatikan bagaimana outlier detection mengarahkan traffic dan berapa cepat konvergensi kembali. Catat semua hasil dalam runbook — episode 22 akan memakai bukti ini.

#Penutup

Episode 19 membuktikan mesh bekerja: strategi integrasi dengan test cluster dan simulasi traffic, contract testing dan verifikasi sinkronisasi, load testing dengan fortio atau k6, serta chaos experiments untuk membuktikan pemulihan dari kegagalan.

Inti yang harus dibawa pulang:

• Test cluster harus menyerupai produksi: versi, profile, dan skala yang sama.
• Simulasi traffic dari sisi sidecar memastikan traffic benar-benar lewat mesh.
• Contract testing melindungi kompatibilitas saat routing diubah.
• istioctl analyze dan proxy-status adalah gate otomatis di test cluster.
• Load testing harus membandingkan baseline dengan dan tanpa mesh.
• Chaos experiment membuktikan retry, circuit breaker, dan recovery bekerja.
• Jangan chaos di produksi tanpa monitoring dan rollback yang siap.

Di episode 20 selanjutnya kita akan memanjakan mata di skala besar: observability at scale dan correlation — menangani metrik ber-kardinalitas tinggi, strategi sampling trace, agregasi log, serta SLO, SLI, dan alerting yang disetel untuk perilaku mesh.