Belajar Istio - Configuration Management & Validation

#Pendahuluan

Seiring mesh tumbuh, jumlah CRD Istio bertambah: VirtualService di sana, DestinationRule di sini, AuthorizationPolicy di namespace lain. Tanpa disiplin, konfigurasi menjadi tidak terkendali — dan kesalahan konfigurasi yang nyaris tak terlihat bisa membuat traffic diam-diam salah rute. Episode 9 ini membahas cara memvalidasi, memeriksa, dan mengelola konfigurasi Istio dengan benar.

#istioctl analyze: Validasi Konfigurasi

#Perintah Dasar

istioctl analyze memindai seluruh konfigurasi mesh dan mencari masalah:

istioctl analyze -n default

istioctl analyze -n default memeriksa konfigurasi di namespace default. Ia menangkap berbagai masalah: VirtualService yang merujuk host yang tidak ada, DestinationRule tanpa subset yang dipakai, sampai konfigurasi yang melanggar aturan validasi istiod. Untuk seluruh cluster tanpa filter namespace:

istioctl analyze --all-namespaces

Output memiliki tingkat keparahan: Info, Warning, dan Error. Jangan menutup mata terhadap Warning — banyak di antaranya (misalnya host tidak ditemukan) menandakan konfigurasi yang tidak akan bekerja seperti yang kalian harapkan.

#Analisis Sebelum Apply

Bentuk paling berharga: menganalisis sebelum konfigurasi benar-benar diterapkan:

istioctl analyze -f routing-baru.yaml

istioctl analyze -f routing-baru.yaml memvalidasi manifest terhadap state cluster saat ini. Menjalankan ini di pipeline CI (episode 18) jauh lebih murah daripada menemukan bug routing di produksi.

#Proxy Status dan Config Dump

Validasi statis hanya sebagian cerita. Kalian juga perlu memastikan konfigurasi benar-benar sampai ke Envoy:

istioctl proxy-status
istioctl proxy-config cluster productpage-abc123
istioctl proxy-config listener productpage-abc123

istioctl proxy-status menampilkan kolom sinkronisasi setiap sidecar dengan istiod. Jika ada workload STALE atau NOT SENT, selidiki koneksi sidecar ke istiod. proxy-config cluster dan proxy-config listener menunjukkan konfigurasi xDS yang nyata di sebuah proxy — bukti terakhir apakah CRD diterjemahkan dengan benar.

#EnvoyFilter: Kapan dan Bagaimana

EnvoyFilter memungkinkan kalian mem-patch konfigurasi Envoy secara mentah. Ini alat paling kuat sekaligus paling berbahaya di Istio:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: tambah-header
  namespace: istio-system
spec:
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.http_connection_manager
            subFilter:
              name: envoy.filters.http.router
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.lua
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
          inlineCode: |
            function envoy_on_request(request_handle)
              request_handle:headers():add("x-added-by", "mesh")
            end

Praktik terbaik yang wajib dipegang:

• Hindari EnvoyFilter bila CRD level tinggi sudah cukup. Routing, retry, dan mTLS semua punya CRD sendiri.
• Pasang di namespace istio-system dengan configPatches yang se-spesifik mungkin agar tidak mengenai proxy lain.
• Setiap filter harus punya owner dan alasan tertulis di Git.
• Selalu uji di staging; EnvoyFilter yang salah bisa membuat traffic mati total.

#GitOps untuk Istio CR

#Prinsip Dasar

GitOps menempatkan konfigurasi Istio di repository sebagai sumber kebenaran, lalu operator seperti ArgoCD atau Flux menyinkronkannya ke cluster:

• Semua CRD Istio disimpan sebagai YAML di repo.
• Perubahan dilakukan lewat pull request, bukan kubectl apply langsung.
• Operator membandingkan state cluster dengan repo dan memperbaiki drift.
• Riwayat perubahan terekam otomatis di Git.

#Drift dan Rollback

Manfaat terbesar GitOps adalah manajemen drift: jika seseorang mengubah konfigurasi langsung di cluster, operator akan mengembalikannya sesuai repo. Rollback pun sederhana — revert commit di repo, operator menormalkan kembali. Ini melengkapi strategi backup yang akan kita bahas di episode 21.

Struktur repo yang disarankan:

istio-config/
├── base/          # CRD dan konfigurasi dasar mesh
├── environments/
│   ├── staging/
│   └── production/
└── apps/
    ├── productpage/
    └── reviews/

Memisahkan environments dari apps memungkinkan aturan yang berbeda untuk staging dan produksi tanpa menduplikasi seluruh konfigurasi.

#Penutup

Episode 9 menjaga kesehatan konfigurasi mesh: validasi dengan istioctl analyze sebelum dan sesudah apply, pemeriksaan sinkronisasi dengan proxy-status, penggunaan EnvoyFilter yang disiplin, serta GitOps untuk mengelola perubahan dan drift.

Inti yang harus dibawa pulang:

• istioctl analyze menangkap masalah konfigurasi secara statis.
• Analisis file sebelum apply mencegah kesalahan masuk ke cluster.
• proxy-status dan proxy-config membuktikan konfigurasi sampai ke Envoy.
• EnvoyFilter powerful tapi berisiko; pakai CRD level tinggi dulu.
• Setiap EnvoyFilter butuh owner, alasan, dan catatan versi.
• GitOps membuat konfigurasi terdokumentasi, drifft terkelola, dan rollback mudah.
• Pemisahan environments dan apps menjaga staging dan produksi tetap bersih.

Di episode 10 selanjutnya kita akan memperluas mesh: service discovery dan external services — ServiceEntry dengan endpoint statis atau DNS, pola WorkloadEntry dan WorkloadGroup, serta mesh expansion untuk menghubungkan VM dan jaringan eksternal ke dalam mesh.