Belajar Envoy Proxy - Dynamic Configuration dengan xDS

#Pendahuluan

Sejauh ini semua konfigurasi ditulis statis di bootstrap. Episode 9 mengubah cara berpikir kalian: dynamic configuration dengan xDS memungkinkan Envoy menerima listener, route, cluster, endpoint, dan bahkan sertifikat secara langsung dari control plane — tanpa restart dan tanpa turun.

Konsep ini adalah fondasi service mesh modern. Ketika Istio menambahkan service baru, Envoy sidecar tidak perlu konfigurasi manual; control plane mengirimkan perubahan lewat xDS. Kalian akan memahami lima layanan xDS, cara Envoy berlangganan, dan bagaimana control plane mengintegrasikan semuanya.

#Prinsip xDS: Lima Layanan Inti

#Satu Keluarga Protokol

xDS adalah keluarga protokol gRPC yang dipakai control plane untuk mengirim konfigurasi ke Envoy. Lima layanan intinya:

CDS (Cluster Discovery Service): mengirim definisi cluster dan kebijakannya.
LDS (Listener Discovery Service): mengirim daftar listener baru.
RDS (Route Discovery Service): mengirim route dan virtual host.
EDS (Endpoint Discovery Service): mengirim daftar endpoint per cluster.
SDS (Secret Discovery Service): mengirim sertifikat dan kunci TLS.

Hubungan antar layanan ini penting: LDS bisa merujuk RDS, CDS merujuk EDS, dan transport socket merujuk SDS. Setiap perubahan kecil di control plane menghasilkan update di salah satu layanan ini.

#SotW vs Delta

Ada dua mode pengiriman:

SotW (State of the World): control plane mengirim seluruh keadaan resource setiap kali ada perubahan.
Delta: hanya mengirim perbedaan sejak pembaruan terakhir, lebih hemat bandwidth untuk skala besar.

Sebagian besar control plane modern mendukung keduanya dan menegosiasikan mode saat koneksi pertama dibuka.

#Envoy sebagai Klien xDS

#Bootstrap dengan Dynamic Resources

Agar menjadi klien xDS, bootstrap Envoy harus berisi dynamic_resources yang menunjuk ke control plane:

Bootstrap dengan ADS ke control plane

dynamic_resources:
  lds_config:
    ads: {}
    resource_api_version: V3
  cds_config:
    ads: {}
    resource_api_version: V3
  ads_config:
    api_type: GRPC
    transport_api_version: V3
    grpc_services:
      - envoy_grpc:
          cluster_name: xds_cluster
static_resources:
  clusters:
    - name: xds_cluster
      connect_timeout: 1s
      type: STATIC
      http2_protocol_options: {}
      load_assignment:
        cluster_name: xds_cluster
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: control-plane.internal
                      port_value: 18000

Blok dynamic_resources memberitahu Envoy untuk mengambil LDS dan CDS lewat ADS (Aggregated Discovery Service) — satu stream gRPC yang membawa semua jenis resource. Cluster xds_cluster menghubungkan Envoy ke control plane di control-plane.internal:18000.

#Alur Langganan xDS

Saat Envoy start, dia membuka stream ke control plane dan berlangganan:

Envoy mengirim subscribe untuk LDS.
Control plane membalas daftar listener yang merujuk RDS.
Envoy berlangganan RDS dan CDS.
CDS memicu EDS untuk endpoint tiap cluster.
SDS dipakai saat listener atau cluster memakai transport socket dinamis.

Setiap kali control plane memutuskan ada perubahan, dia mengirim update pada stream yang sama. Envoy menerapkan perubahan itu secara live.

Melihat resource dinamis yang dimuat

curl -s localhost:9901/config_dump | grep -A2 '"@type": "type.googleapis.com/envoy.admin.v3.*Config'
curl -s localhost:9901/config_dump?resource=dynamic

Endpoint config_dump?resource=dynamic menampilkan hanya resource yang diterima dari control plane — cara cepat membedakan mana yang statis dan mana yang dinamis.

#Integrasi dengan Control Plane

#Istio, Gloo, dan Contour

Tiga control plane populer memakai xDS dengan cara berbeda:

Istio (istiod): mengelola seluruh config mesh, termasuk mTLS via SDS, dan mengirim config lengkap ke setiap sidecar Envoy.
Gloo Edge/Gateway: memakai Envoy sebagai gateway dan menerjemahkan API Gateway CRD menjadi config xDS.
Contour: control plane Envoy untuk Kubernetes, menerjemahkan Ingress dan HTTPProxy menjadi xDS.

Semua control plane ini menulis ke "bahasa" yang sama: protokol xDS yang dimengerti Envoy. Keahlian kalian membaca config Envoy berlaku di mana pun.

#Membangun Control Plane Sederhana

Untuk memahami protokol lebih dalam, kalian bisa membuat server xDS mini sendiri. Salah satu cara paling cepat:

Control plane uji dengan go-control-plane

go run github.com/envoyproxy/go-control-plane/examples/...

Library go-control-plane menyediakan implementasi server xDS dalam bahasa Go. Dengan contoh dari repository tersebut, kalian bisa melihat langsung bagaimana listener, route, dan cluster dikirim sebagai protobuf ke Envoy.

#Menguji dengan Docker

Untuk mencoba dynamic config tanpa membangun server sendiri, jalankan Envoy dengan config dinamis yang menunjuk ke control plane dockerized:

Envoy sebagai klien xDS

docker run -d --name envoy-xds \
  -v ~/envoy-lab/configs/xds-bootstrap.yaml:/etc/envoy/envoy.yaml \
  -p 10000:10000 -p 9901:9901 \
  envoyproxy/envoy:v1.31.0

Perintah docker run dengan bootstrap xDS akan membuat Envoy mencoba terhubung ke control plane. Jika gagal, lihat log docker logs envoy-xds untuk melihat stream xDS dan pesan error.

#Debugging Koneksi xDS

#Menemukan Masalah Langganan

Saat kontrol plane tidak terjangkau, Envoy tetap berjalan tapi tidak bisa memuat listener baru. Pemeriksaan pertama:

Pemeriksaan status xDS

curl -s localhost:9901/server_info
curl -s localhost:9901/config_dump?resource=dynamic | head -20

Perintah server_info menampilkan waktu koneksi terakhir dengan control plane. Jika field last_updated tidak bertambah saat config berubah, ada masalah di stream ADS — biasanya alamat control plane salah atau protokol gRPC belum aktif di cluster xDS.

#Pola yang Harus Diwaspadai

Beberapa jebakan umum saat bekerja dengan xDS:

Cluster xDS harus memakai HTTP/2, jadi jangan lupa http2_protocol_options.
Nama resource di config harus cocok persis dengan nama di control plane.
Jangan mencampur resource dinamis dan statis dengan nama yang sama.
Version info sangat membantu logging; biasakan menetapkan version_info pada update control plane.

#Penutup

Episode 9 membuka pintu dynamic configuration: lima layanan xDS, Envoy sebagai klien yang berlangganan perubahan, dan integrasi dengan control plane seperti Istio, Gloo, dan Contour.

Inti yang harus dibawa pulang:

xDS terdiri dari CDS, LDS, RDS, EDS, dan SDS yang saling merujuk.
Envoy berlangganan resource lewat satu stream ADS atau stream terpisah.
Bootstrap dynamic_resources mengganti config statis sebagai sumber utama.
ADS memungkinkan perubahan listener, route, dan cluster tanpa restart.
Istio, Gloo, dan Contour semuanya berbicara xDS ke Envoy.
config_dump?resource=dynamic membedakan resource dinamis dari statis.

Di episode 10 selanjutnya kita akan membahas rate limiting dan traffic control — filter rate limit dan external rate limit service, konfigurasi retry, timeout, dan fault injection, plus circuit breaking dan resource limits.