Belajar Istio - CI/CD untuk Istio Config & Canary Deployments

#Pendahuluan

Konfigurasi Istio yang baik tidak diterapkan lewat kubectl apply langsung di produksi. Episode 18 ini membahas cara yang benar: perubahan mengalir lewat pipeline, tervalidasi otomatis, dan traffic dipindah secara bertahap dengan progressive delivery. Ini puncak dari praktik yang kita bangun di episode 9.

#GitOps untuk Istio CR

#Alur Kerja Dasar

Semua CRD Istio disimpan di repository sebagai YAML. Perubahan dilakukan lewat pull request; ArgoCD atau Flux menyinkronkan ke cluster:

1. Developer mengubah VirtualService di repo.
2. Pipeline menjalankan istioctl analyze untuk validasi.
3. Setelah disetujui, ArgoCD menerapkan ke cluster.
4. Drift apa pun di cluster dikembalikan ke state repo.

istioctl analyze --all-namespaces
istioctl analyze -f changes/virtualservice.yaml

istioctl analyze -f changes/virtualservice.yaml memvalidasi perubahan terhadap cluster saat ini sebelum merge. Gagalkan pipeline jika ada Error; anggap Warning sebagai kandidat review.

#Memisahkan Environment

Satu repo, banyak environment:

istio-config/
├── base/
├── overlays/
│   ├── staging/
│   └── production/
└── app-manifests/

ArgoCD Application per environment memakai path berbeda dengan nilai berbeda. Kunci secret (misalnya credentialName untuk TLS) disuntikkan dari Kubernetes Secret per cluster, bukan disimpan di repo.

#Progressive Delivery dengan Argo Rollouts dan Flagger

#Argo Rollouts dengan Istio

Argo Rollouts menggantikan Deployment untuk canary yang dikontrol traffic weight:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: productpage
spec:
  strategy:
    canary:
      canaryService: productpage-canary
      stableService: productpage
      trafficRouting:
        istio:
          virtualService:
            name: productpage-vsvc
            routes:
            - primary
      steps:
      - setWeight: 10
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 5m}

trafficRouting.istio memberi tahu Argo Rollouts untuk memodifikasi VirtualService productpage-vsvc sesuai weight. Setiap step menaikkan weight lalu berhenti untuk observasi — jika metrik memburuk, pipeline bisa membatalkan dan kembali ke versi stabil.

#Flagger

Flagger bekerja serupa, tetapi dengan pendekatan automated analysis: ia mengukur metrik (misalnya error rate dari Prometheus) dan memutuskan naik, tahan, atau rollback:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: productpage
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: productpage
  service:
    port: 9080
  analysis:
    interval: 1m
    threshold: 5
    metrics:
    - name: error-rate
      templateRef:
        name: error-rate
      thresholdRange:
        max: 2

threshold: 5 berarti setelah lima evaluasi melanggar, canary di-rollback otomatis. Flagger memanggil metrik error rate dan memutuskan secara mandiri — lebih sedikit campur tangan manual daripada weight manual.

#Analisis Otomatis dan Gating Traffic

#Langkah Pipeline yang Disarankan

1. Lint: jalankan istioctl analyze atas perubahan.
2. Deploy canary: Argo Rollouts atau Flagger mengirim versi baru ke subset baru.
3. Splitting: weight dinaikkan bertahap 10, 50, 100 persen.
4. Analysis: metrik error rate, latency, dan availability diukur tiap interval.
5. Promote/Abort: lulus maka semua traffic ke versi baru; gagal maka rollback.

#Gating di Level Pipeline

Jadikan istioctl analyze bagian dari pipeline CI, bukan hanya kebiasaan manual:

istioctl analyze -f manifest/ > analyze.txt || exit 1
grep -E "Error" analyze.txt && exit 1 || echo "konfigurasi aman"

Script sederhana ini menolak pipeline saat ditemukan Error pada konfigurasi. Kombinasi analisis statis (sebelum deploy) dan analisis traffic (selama canary) memberikan dua lapis perlindungan.

#Penutup

Episode 18 mengotomatiskan perubahan mesh: GitOps dengan ArgoCD atau Flux untuk CRD Istio, progressive delivery dengan Argo Rollouts dan Flagger, serta analisis otomatis istioctl analyze yang menggating perubahan traffic sebelum masuk produksi.

Inti yang harus dibawa pulang:

• GitOps menjadikan repo sebagai sumber kebenaran konfigurasi Istio.
• Pisahkan overlay staging dan production dalam satu repo.
• istioctl analyze di pipeline menolak perubahan rusak lebih awal.
• Argo Rollouts mengontrol weight lewat VirtualService yang dimodifikasi.
• Flagger mengotomatiskan keputusan promote atau rollback dari metrik.
• Two-layer gating: analisis statis sebelum deploy, analisis traffic saat canary.
• Selalu punya jalan keluar: abort dan rollback yang sudah teruji.

Di episode 19 selanjutnya kita akan menguji mesh secara menyeluruh: testing service mesh (integration dan e2e) — strategi integrasi dengan test cluster, simulasi traffic, contract testing, load testing, dan chaos experiments untuk membuktikan ketahanan.