Belajar Istio - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kalian melihat gambaran besar mengapa Istio ada. Sekarang saatnya membedah mesinnya: bagaimana Istio bekerja di dalam. Episode 2 ini menjelaskan dua lapisan arsitektur (control plane dan data plane), CRD yang akan kalian tulis setiap hari, serta protokol xDS yang menjadi urat nadi distribusi konfigurasi.

Pahami struktur ini dengan baik — hampir setiap istilah yang muncul di episode berikutnya (VirtualService, DestinationRule, PeerAuthentication, dan lainnya) hidup di dalam kerangka yang kita bangun sekarang.

#Control Plane dan Data Plane

#istiod: Control Plane yang Terpadu

Sejak versi 1.5, Istio menggabungkan komponen control plane lama (Pilot, Citadel, Galley) ke dalam satu binary bernama istiod. Tiga tanggung jawab utamanya:

• Pilot: menerjemahkan konfigurasi mesh menjadi aturan xDS untuk Envoy.
• Citadel: menerbitkan dan memutar sertifikat untuk mTLS via SDS.
• Galley: memvalidasi, memproses, dan mendistribusikan konfigurasi.

istiod berjalan sebagai Deployment di namespace istio-system. Kalian bisa melihatnya bersama komponen lain:

kubectl get deploy -n istio-system
kubectl get pods -n istio-system -l istio=sidecar-injector

Baris kedua menampilkan Pod istiod beserta webhook sidecar injector yang akan kita bahas di episode 4.

#Envoy Sidecar: Data Plane

Setiap Pod yang masuk mesh disuntikkan container istio-proxy (Envoy). Envoy inilah yang memproses seluruh traffic masuk dan keluar Pod: menerapkan routing, retry, mTLS, serta mencatat telemetry. Karena sidecar ikut berpindah bersama aplikasi, aturan traffic selalu mengikuti beban kerja, bukan bergantung pada infrastruktur.

#Istio CRDs Utama

#Trafik Management

• Gateway: mendeskripsikan load balancer di edge mesh, lengkap dengan port, host, dan TLS.
• VirtualService: aturan routing — host mana, ke subset mana, dengan weight berapa.
• DestinationRule: kebijakan setelah routing — subset, connection pool, load balancing, outlier detection.
• ServiceEntry: mendaftarkan layanan eksternal agar masuk ke mesh.

Contoh paling sederhana dari VirtualService yang mengirim semua traffic ke satu service:

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

#Security

• PeerAuthentication: mengatur mode mTLS antar workload.
• RequestAuthentication: memvalidasi token JWT dari request.
• AuthorizationPolicy: aturan allow/deny berbasis identitas, namespace, atau claim JWT.

#Pendukung

• Sidecar: membatasi scope traffic egress/ingress sebuah workload.
• EnvoyFilter: patch konfigurasi Envoy secara mentah — powerful tapi berisiko.
• WorkloadEntry: merepresentasikan workload non-Kubernetes (misalnya VM) di dalam mesh.

Lihat seluruh CRD yang terpasang di cluster:

kubectl get crd | grep istio.io

#XDS: Bagaimana Konfigurasi Mengalir ke Sidecar

#Discovery Services

Envoy tidak membaca YAML Istio secara langsung. Istiod menerjemahkan CRD dan Service Kubernetes menjadi aturan-aturan yang disalurkan lewat protokol gRPC bernama xDS. Empat yang paling penting:

• CDS (Cluster Discovery Service): daftar cluster tujuan dan kebijakannya.
• EDS (Endpoint Discovery Service): alamat endpoint aktual dari tiap cluster.
• LDS (Listener Discovery Service): listener yang mengatur port dan koneksi.
• RDS (Route Discovery Service): aturan routing HTTP untuk tiap listener.

#Alur Distribusi

Alurnya berjalan seperti ini: kalian menerapkan VirtualService dan DestinationRule, istiod memvalidasi dan menerjemahkannya, lalu mendorong RDS dan CDS ke setiap Envoy yang terhubung. Envoy menjaga koneksi streaming ke istiod sehingga perubahan konfigurasi bisa tersebar dalam hitungan detik tanpa restart.

Untuk memeriksa apa yang diterima sebuah sidecar, gunakan perintah berikut:

kubectl exec -it reviews-v1-abc123 -c istio-proxy -- curl localhost:15000/config_dump
istioctl proxy-status

istioctl proxy-status adalah alat kunci: ia menunjukkan sinkronisasi setiap sidecar dengan istiod. Jika kolom status menampilkan SYNCED, konfigurasi terkirim dengan baik; jika STALE, terjadi masalah koneksi atau versi konfigurasi yang tertinggal.

#Penutup

Episode 2 menyusun kerangka arsitektur Istio: istiod sebagai control plane yang memadukan fungsi Pilot, Citadel, dan Galley; Envoy sidecar sebagai data plane; sepuluh CRD yang menjadi bahasa konfigurasi; serta protokol xDS yang mengalirkan CDS, EDS, LDS, dan RDS ke setiap proxy.

Inti yang harus dibawa pulang:

• Istiod adalah satu-satunya binary control plane: Pilot, Citadel, dan Galley digabung di dalamnya.
• Data plane adalah kumpulan Envoy sidecar di setiap Pod.
• Gateway dan VirtualService mengatur traffic; DestinationRule mengatur kebijakan tujuan.
• ServiceEntry dan WorkloadEntry membawa layanan eksternal masuk ke mesh.
• PeerAuthentication, RequestAuthentication, dan AuthorizationPolicy adalah pilar security.
• xDS (CDS, EDS, LDS, RDS) adalah bahasa yang dipakai istiod untuk berbicara ke Envoy.
• istioctl proxy-status adalah barometer kesehatan distribusi konfigurasi.

Di episode 3 selanjutnya kita akan menginstall Istio untuk pertama kalinya — membandingkan opsi istioctl install, Istio Operator, dan Helm, memilih profile yang tepat, serta menyusun strategi upgrade yang aman. Pastikan cluster dari episode 0 masih hidup.