L
Service Mesh & Traffic Management ⏱️ Interactive 15-Minute Recipe • Literally Web ID

Service Mesh & Traffic Management: Implementasi Istio di Kluster Kubernetes

⏱️ 15 menit baca • 📅 20 Oct 2026 • 👁️ 2 views
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=enabled memastikan 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

  1. 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 Service Kubernetes cocok secara persis dengan port aplikasi asli dan tambahkan anotasi traffic.sidecar.istio.io/includeInboundPorts jika diperlukan.
  2. mTLS Gagal Mengizinkan Koneksi Lama (Plaintext)

    • Penyebab: Mode STRICT menolak koneksi dari pod yang tidak memiliki sidecar.
    • Solusi: Ubah sementara ke mode PERMISSIVE pada PeerAuthentication untuk melakukan migrasi bertahap.
  3. Sidecar Tidak Ter-inject Otomatis

    • Penyebab: Namespace belum diberi label atau komponen istiod mengalami crashloop.
    • Solusi: Cek status pods di namespace istio-system dengan kubectl get pods -n istio-system dan pastikan label istio-injection=enabled terpasang di namespace target.
🏷️ Tags: #Nginx #High Concurrency #Performance #Sysadmin #Web Server