Belajar Envoy Proxy - Envoy in Kubernetes & Service Mesh Ecosystems

#Pendahuluan

Semua yang kalian pelajari kini bertemu dengan platform tempat Envoy paling banyak dipakai: Kubernetes dan ekosistem service mesh. Episode 19 membahas bagaimana Envoy menjadi sidecar dalam Istio, perbedaan antara memakai Envoy langsung dan memakai Envoy sebagai data plane mesh, serta pola deployment untuk workload Kubernetes.

Ini episode penyatuan: konsep xDS, mTLS, routing, dan observability dari episode-episode sebelumnya semuanya berperan di sini — tapi dikelola oleh control plane, bukan konfigurasi manual.

#Envoy Sidecar dalam Istio

#Apa yang Dilakukan istiod

Istio memakai Envoy sebagai data plane dan istiod sebagai control plane. Kalian tidak menulis bootstrap Envoy; kalian menulis resource Istio seperti VirtualService dan DestinationRule, dan istiod menerjemahkannya menjadi config xDS untuk setiap sidecar.

kubectl get pods -n prod -l app=orders -o jsonpath='{.items[0].spec.containers[*].name}'
kubectl exec -it deploy/orders -n prod -c istio-proxy -- curl -s localhost:15000/server_info

Perintah kubectl exec ... -c istio-proxy masuk ke kontainer sidecar bernama istio-proxy. Envoy di dalamnya mengekspos admin interface di port 15000 — port berbeda dari yang biasa kita pakai di lab, tapi semua endpoint admin tetap sama.

#Resource Istio yang Diterjemahkan ke Envoy

Contoh VirtualService yang sebenarnya diterjemahkan menjadi route Envoy:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: orders-route
  namespace: prod
spec:
  hosts:
    - orders
  http:
    - match:
        - uri:
            prefix: /api/orders
      route:
        - destination:
            host: orders
            subset: v2
          weight: 5
        - destination:
            host: orders
            subset: v1
          weight: 95
      retries:
        attempts: 3
        retryOn: connect-failure,retriable-status-codes

Resource VirtualService ini berbicara dalam bahasa yang lebih tinggi: subset v1 dan v2 yang didefinisikan di DestinationRule, bobot canary, dan retry. istiod menerjemahkan semuanya menjadi weighted clusters dan retry policy Envoy — yang kalian sudah pelajari di episode 18 dan 10.

#Inspeksi Config Envoy di Sidecar

Untuk melihat hasil terjemahan istiod:

kubectl exec -it deploy/orders -n prod -c istio-proxy -- curl -s localhost:15000/config_dump
kubectl exec -it deploy/orders -n prod -c istio-proxy -- curl -s localhost:15000/listeners

Endpoint config_dump di sidecar menunjukkan listener dan route yang benar-benar dipakai Envoy. Ini jembatan pemahaman: apa yang kalian lihat di lab Envoy statis, bentuknya sama di sini — hanya sumbernya berbeda.

#Envoy Langsung vs Envoy sebagai Mesh Data Plane

#Perbedaan Fundamental

Dua cara memakai Envoy, dua tingkat kontrol:

• Envoy langsung: kalian menulis bootstrap dan config sendiri, penuh kendali dan tanggung jawab.
• Envoy sebagai mesh data plane: control plane (Istio, Gloo) yang menulis config, kalian mengelola resource level tinggi.

Keduanya memakai Envoy yang sama. Perbedaannya ada di siapa yang mengelola config dan seberapa dalam kendali yang kalian butuhkan.

#Kapan Memilih yang Mana

Pilih Envoy langsung jika:

• Arsitektur kalian sederhana atau khusus.
• Kalian butuh kendali penuh atas setiap field config.
• Tidak ingin bergantung pada lapisan abstraksi.

Pilih service mesh jika:

• Banyak service dengan kebijakan konsisten (mTLS, tracing, retry).
• Ingin kebijakan per-namespace yang dikelola terpusat.
• Butuh observability mesh-wide tanpa menyentuh setiap config.

#Bahaya Abstraksi

Abstraksi mesh menyembunyikan detail. Saat sesuatu gagal, kalian harus tetap memahami Envoy di baliknya — itulah mengapa series ini mengajarkan Envoy dari dasar dulu. Troubleshooting sidecar tanpa memahami xDS, filter, dan listener akan sangat sulit.

#Deployment Patterns untuk Kubernetes

#Injection Sidecar Otomatis

Istio menginjeksi sidecar otomatis ke pod yang memenuhi syarat:

kubectl label namespace prod istio-injection=enabled
kubectl rollout restart deployment/orders -n prod

Perintah kubectl label namespace istio-injection=enabled membuat semua pod baru di namespace tersebut mendapat sidecar. Untuk melihat template sidecar tanpa menerapkan, jalankan istioctl kube-inject -f deployment.yaml.

#Gateway dan GatewayClass

Untuk traffic masuk, service mesh modern memakai resource Gateway:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: edge
  namespace: istio-system
spec:
  gatewayClassName: istio
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: edge-cert

Resource Gateway adalah generasi baru API gateway di Kubernetes yang diimplementasikan Istio, Gloo, dan banyak lainnya — semuanya pada akhirnya memakai Envoy sebagai engine.

#Memantau Sidecar

Lengkapi pola deployment dengan observability:

kubectl logs deploy/orders -n prod -c istio-proxy --tail=20
kubectl port-forward -n istio-system svc/istiod 15014:15014

Perintah kubectl logs ... -c istio-proxy menampilkan access log sidecar Envoy. Log inilah yang mencatat setiap request antar service — titik awal debugging routing di mesh.

#Penutup

Episode 19 memosisikan Envoy dalam ekosistem terbesarnya: sidecar di Istio yang dikelola istiod, perbedaan Envoy langsung versus mesh data plane, serta pola deployment dan injection di Kubernetes.

Inti yang harus dibawa pulang:

• Di Istio, istiod adalah control plane yang menerjemahkan resource menjadi xDS.
• Sidecar Envoy mengekspos admin di port 15000.
• VirtualService dan DestinationRule menjadi weighted clusters dan retry Envoy.
• Envoy langsung memberi kendali penuh; mesh memberi kebijakan terpusat.
• Troubleshooting mesh tetap butuh pemahaman Envoy di balik abstraksi.
• Injection sidecar otomatis membuat setiap pod siap dengan proxy.

Di episode 20 selanjutnya kita akan membahas GitOps, CI/CD dan configuration management — mengelola config Envoy dalam alur GitOps, validasi config di CI/CD, serta rolling updates dan manajemen perubahan config.