Belajar Istio - Sidecar Injection & Workload Onboarding

#Pendahuluan

Istio sudah terinstall. Pertanyaan berikutnya: bagaimana membuat workload masuk ke mesh? Episode 4 ini menjawabnya — mulai dari sidecar injection, cara mengontrol scope traffic per Pod, hingga cara membawa workload di luar Kubernetes (VM) menjadi bagian dari mesh.

Ini episode yang sangat praktis. Setelah selesai, kalian akan bisa mengaktifkan mesh untuk seluruh namespace dengan satu label, memeriksa bahwa sidecar benar-benar tersuntik, dan memahami kapan memakai injection manual.

#Automatic vs Manual Injection

#Injection Otomatis via Label Namespace

Cara paling umum adalah memberi label pada namespace. Saat Pod baru dibuat, webhook sidecar injector di istiod secara otomatis menambahkan container istio-proxy ke dalam Pod tersebut.

kubectl label namespace default istio-injection=enabled
kubectl apply -f deploy-aplikasi.yaml
kubectl get pods

kubectl label namespace default istio-injection=enabled mengubah label namespace. Perhatikan: label ini hanya berlaku untuk Pod yang baru dibuat — Pod yang sudah ada tidak berubah sampai di-restart. Setelah deploy, cek bahwa Pod punya dua container:

kubectl get pods -o jsonpath="{.items[*].spec.containers[*].name}"
kubectl get pods -l app=aplikasi -o jsonpath="{.items[0].spec.containers[*].name}"

Output harus berisi nama aplikasi diikuti istio-proxy. Jika hanya satu container, injection gagal — biasanya karena namespace tidak berlabel atau webhook tidak berjalan.

#Manual dengan istioctl kube-inject

Kadang injection otomatis tidak diinginkan, misalnya saat kalian ingin memverifikasi hasil secara eksplisit atau bekerja di pipeline yang memakai manifest statis:

istioctl kube-inject -f deploy-aplikasi.yaml | kubectl apply -f -

istioctl kube-inject -f deploy-aplikasi.yaml menambahkan container sidecar langsung ke dalam manifest sebelum diterapkan. Cara ini memberi kontrol penuh, tetapi berarti manifest di repository tidak lagi sama dengan yang dijalankan — hati-hati saat melakukan GitOps.

#Label Revisi dan Multi-Revisi

Untuk menghindari label istio-injection=enabled yang mengikat semua workload ke istiod default, gunakan label revisi. Ini wajib dipahami untuk upgrade dan canary:

kubectl label namespace default istio-injection- istio.io/rev=1-22-1 --overwrite

kubectl label namespace default istio.io/rev=1-22-1 membuat Pod baru memakai sidecar dari revisi 1-22-1. Kelebihan besar label revisi: kalian bisa menjalankan dua versi istiod bersamaan dan memindahkan workload secara bertahap — pola yang kita pakai untuk canary install di episode 3.

#Sidecar CRD untuk Membatasi Scope

Tanpa pengaturan tambahan, setiap sidecar menangkap semua traffic egress dan ingress di Pod-nya. Saat jumlah service besar, ini memboroskan resource. Sidecar CRD membatasi scope traffic sebuah workload:

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
  namespace: default
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

Sidecar dengan hosts: ["./*"] membatasi egress ke namespace yang sama plus istio-system. Efeknya: peta service di sidecar menyusut drastis, konfigurasi xDS berkurang, dan memori Envoy lebih hemat — topik yang akan kita dalami di episode 14.

#WorkloadEntry dan WorkloadGroup

#WorkloadEntry untuk VM

Mesin virtual atau workload non-Kubernetes juga bisa masuk mesh lewat WorkloadEntry — representasi sebuah endpoint di luar cluster:

apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  name: vm-produksi-1
  namespace: default
spec:
  address: 192.168.10.21
  labels:
    app: legacy-service
  serviceAccount: vm-legacy
  network: network-1

Field serviceAccount menentukan identitas workload, sedangkan network penting untuk arsitektur multi-network yang akan kita bahas di episode 16. WorkloadEntry ini kemudian bisa menjadi target routing dari VirtualService seperti Pod biasa.

#WorkloadGroup untuk Auto-registration

Saat workload VM banyak, mendefinisikan satu per satu terasa melelahkan. WorkloadGroup memungkinkan VM mendaftarkan dirinya secara otomatis:

apiVersion: networking.istio.io/v1
kind: WorkloadGroup
metadata:
  name: vm-pool-prod
  namespace: default
spec:
  template:
    serviceAccount: vm-legacy
    network: network-1

VM menjalankan istioctl proxy dan mendaftarkan dirinya ke WorkloadGroup saat bergabung. Ini adalah dasar mesh expansion yang akan kita rinci di episode 10.

#Penutup

Episode 4 membuat workload benar-benar masuk mesh: injection otomatis lewat label namespace, injection manual dengan istioctl kube-inject, migrasi bertahap dengan label revisi, penghematan konfigurasi via Sidecar CRD, dan onboarding workload di luar Kubernetes lewat WorkloadEntry dan WorkloadGroup.

Inti yang harus dibawa pulang:

• Label istio-injection=enabled mengaktifkan injection untuk Pod baru.
• istioctl kube-inject memberi kontrol manual tetapi mengubah manifest.
• Pod yang sudah ada tidak ter-inject sampai di-restart.
• Label istio.io/rev memisahkan workload per revisi istiod.
• Sidecar CRD membatasi scope traffic dan memangkas konfigurasi xDS.
• WorkloadEntry mewakili satu VM; WorkloadGroup memungkinkan auto-registration.
• Verifikasi selalu dengan memeriksa container istio-proxy di Pod.

Di episode 5 selanjutnya kita akan mengatur traffic management inti dengan VirtualService dan DestinationRule — routing berdasarkan host dan subset, pembagian trafik dengan weight, redirects dan rewrites, connection pool, outlier detection, serta contoh A/B dan traffic splitting yang siap dipakai.