Service Mesh & Traffic Management: Implementasi Istio di Kluster Kubernetes
1. Target Implementasi & Prasyarat Cepat
Selamat datang di panduan Interactive 15-Minute Recipe untuk mengimplementasikan Istio Service Mesh pada kluster Kubernetes. Sebagai Web & Infrastructure Systems Architect, saya akan memandu Anda mentransformasikan arsitektur mikroservis web Anda agar memiliki visibilitas penuh, pengamanan lalu lintas zero-trust, dan kemampuan manajemen trafik tingkat lanjut berbasis Envoy Proxy.
What You Will Build:
- Kluster Kubernetes dengan Istio Control Plane (
istiod) dan Data Plane (Envoy Sidecar Injection) yang aktif. - Penerapan Traffic Shifting dan Canary Deployment (90% v1, 10% v2) menggunakan Istio
VirtualService. - Pengaktifan Mutual TLS (mTLS) secara ketat (STRICT mode) untuk seluruh komunikasi antar-pod.
- Konfigurasi Fault Injection untuk menguji ketahanan aplikasi backend (Node.js/Go/PHP) terhadap latensi tinggi dan kegagalan HTTP 500.
[!IMPORTANT] Pastikan kluster Kubernetes Anda (minikube, kind, atau managed k8s seperti EKS/GKE) memiliki minimal 2 vCPU dan 4GB RAM yang tersedia agar sidecar Envoy dapat berjalan tanpa OOM Killed.
2. Diagram Arsitektur Singkat
graph TD
Client -->|HTTP Request| Gateway[Istio Ingress Gateway]
Gateway -->|VirtualService Route| AppV1[Pod App v1 + Envoy Sidecar]
Gateway -->|Canary 10%| AppV2[Pod App v2 + Envoy Sidecar]
subgraph Service Mesh (mTLS STRICT)
AppV1 <== mTLS ==> AppV2
end
3. Langkah 1: Persiapan & Environment
Unduh CLI Istio terbaru dan instal Control Plane menggunakan profil demo yang menyediakan fungsionalitas lengkap untuk observabilitas dan manajemen trafik.
# Unduh dan ekstrak Istio CLI
curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PATH:$bin
# Instal Istio ke kluster Kubernetes dengan profil demo
istioctl install --set profile=demo -y
# Label namespace default untuk otomatis mengaktifkan Envoy sidecar injection
kubectl label namespace default istio-injection=enabled --overwrite
[!TIP] Pelabelan namespace dengan
istio-injection=enabledmemastikan setiap deployment baru di dalam namespace tersebut otomatis disisipkan sidecar container Envoy tanpa mengubah kode aplikasi Anda.
4. Langkah 2: Konfigurasi Core Stack
Deploy aplikasi web multi-versi (v1 dan v2) untuk mensimulasikan skenario Canary Deployment, lalu definisikan aturan perutean lalu lintas.
# simpan sebagai app-canary.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app-v1
spec:
replicas: 1
selector:
matchLabels:
app: web-app
version: v1
template:
metadata:
labels:
app: web-app
version: v1
spec:
containers:
- name: web
image: gcr.io/google-samples/node-hello:1.0
ports:
- containerPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app-v2
spec:
replicas: 1
selector:
matchLabels:
app: web-app
version: v2
template:
metadata:
labels:
app: web-app
version: v2
spec:
containers:
- name: web
image: gcr.io/google-samples/node-hello:2.0
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: web-app-service
spec:
ports:
- port: 80
targetPort: 8080
name: http
selector:
app: web-app
Terapkan konfigurasi deployment di atas:
kubectl apply -f app-canary.yaml
Selanjutnya, buat VirtualService dan DestinationRule untuk membagi trafik (90% ke v1, 10% ke v2):
# simpan sebagai traffic-routing.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: web-app-destination
spec:
host: web-app-service
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: web-app-vs
spec:
hosts:
- "web-app-service"
http:
- route:
- destination:
host: web-app-service
subset: v1
weight: 90
- destination:
host: web-app-service
subset: v2
weight: 10
kubectl apply -f traffic-routing.yaml
5. Langkah 3: Optimasi & Keamanan Dasar
Aktifkan enkripsi Mutual TLS (mTLS) secara ketat di seluruh kluster untuk mencegah man-in-the-middle attacks antar-mikroservis.
# simpan sebagai strict-mtls.yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: default
spec:
mtls:
mode: STRICT
kubectl apply -f strict-mtls.yaml
[!WARNING] Pastikan semua layanan di dalam namespace telah diinjeksikan sidecar Envoy sebelum mengaktifkan mode
STRICT, jika tidak, komunikasi antar-pod akan gagal karena penolakan plaintext handshake.
6. Verifikasi & Pengujian Hasil Akhir
Lakukan pengujian cepat menggunakan perintah curl dari dalam pod penunjang atau melalui port-forward untuk memastikan traffic shifting berjalan semestinya.
# Jalankan pod helper untuk melakukan uji curl ke service mesh
kubectl run curl-test --image=curlimages/curl:latest --rm -it -- sh
# Di dalam terminal pod, jalankan loop berikut berulang kali:
while true; do curl -s http://web-app-service:80; echo ""; sleep 0.5; done
Anda akan melihat respons dari v1.0 mendominasi sekitar 90% iterasi, sementara v2.0 muncul kurang lebih 10% dari total permintaan. Verifikasi juga status mTLS dengan perintah:
istioctl authn tls-check web-app-v1-xxxxx.default
7. Troubleshooting 3 Masalah Paling Umum
-
Aplikasi Timeout atau HTTP 503 Service Unavailable
- Penyebab: Envoy sidecar belum siap atau salah mengonfigurasi Container Port pada Kubernetes Service.
- Solusi: Pastikan port pada objek
ServiceKubernetes cocok secara persis dengan port aplikasi asli dan tambahkan anotasitraffic.sidecar.istio.io/includeInboundPortsjika diperlukan.
-
mTLS Gagal Mengizinkan Koneksi Lama (Plaintext)
- Penyebab: Mode
STRICTmenolak koneksi dari pod yang tidak memiliki sidecar. - Solusi: Ubah sementara ke mode
PERMISSIVEpadaPeerAuthenticationuntuk melakukan migrasi bertahap.
- Penyebab: Mode
-
Sidecar Tidak Ter-inject Otomatis
- Penyebab: Namespace belum diberi label atau komponen
istiodmengalami crashloop. - Solusi: Cek status pods di namespace
istio-systemdengankubectl get pods -n istio-systemdan pastikan labelistio-injection=enabledterpasang di namespace target.
- Penyebab: Namespace belum diberi label atau komponen