Belajar Envoy Proxy - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Sekarang kita masuk ke otak Envoy. Episode 2 membahas konsep dasar dan arsitektur utama: lima komponen inti yang akan kalian temui di setiap konfigurasi — listener, filter chain, cluster, route, dan endpoint — serta bagaimana semuanya dirangkai dalam satu file bootstrap.

Selain komponen, kalian perlu memahami dua peran besar dalam ekosistem Envoy: control plane yang mengambil keputusan, dan data plane yang mengeksekusi. Keduanya terhubung melalui protokol xDS, bahasa yang sama yang dipakai Istio, Gloo, dan control plane lain untuk berbicara dengan Envoy. Kuasai episode ini dan semua episode berikutnya akan terasa seperti variasi dari pola yang sama.

#Lima Komponen Inti Arsitektur

#Listener dan Filter Chain

Listener adalah titik masuk traffic: dia mendengarkan di sebuah alamat dan port, misalnya 0.0.0.0:10000. Setiap listener bisa memiliki satu atau lebih filter chain — rangkaian filter yang memproses koneksi sebelum diteruskan. Untuk HTTP, filter pertama biasanya http_connection_manager yang mengubah byte TCP menjadi request HTTP yang bisa di-route.

#Route dan Virtual Host

Setelah request HTTP terbentuk, route menentukan ke mana request dikirim. Route dikelompokkan dalam virtual host, yang dipilih berdasarkan Host header atau domain. Di dalam virtual host ada aturan match: berdasarkan prefix path, exact path, atau header tertentu. Route merujuk ke cluster, yaitu kumpulan backend yang menangani request.

#Cluster dan Endpoint

Cluster adalah abstraksi dari satu layanan backend, lengkap dengan kebijakan load balancing dan health check. Di dalam cluster ada endpoints — daftar alamat IP dan port dari instance backend yang sebenarnya. Ketika Envoy memutuskan mengirim request ke cluster, dia memilih satu endpoint sesuai algoritma load balancing yang dikonfigurasi.

curl -s localhost:9901/config_dump | head -40

Perintah curl localhost:9901/config_dump menampilkan konfigurasi aktif dalam format JSON: daftar listener, filter chain, dan cluster. Inilah cara terbaik memvisualisasikan kelima komponen di atas pada Envoy yang sedang berjalan.

#Model Konfigurasi Envoy

#Bootstrap File

Semua konfigurasi Envoy dimulai dari bootstrap file: satu file YAML yang memberitahu Envoy harus mendengarkan di mana, ke cluster mana berbicara, dan bagaimana memuat konfigurasi lain. Struktur utamanya:

node:
  id: envoy-lab
  cluster: lab-cluster
static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address:
          address: 0.0.0.0
          port_value: 10000
  clusters:
    - name: service_backend
      connect_timeout: 0.25s
      type: STRICT_DNS
      lb_policy: ROUND_ROBIN
admin:
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 9901

Konfigurasi di atas berisi node sebagai identitas Envoy, static_resources untuk listener dan cluster yang ditulis langsung, serta admin untuk interface manajemen di port 9901. Blok static_resources adalah kata kunci yang membedakan config statis dari config dinamis.

#Statis vs Dinamis

Ada dua cara mengisi konfigurasi:

• Statis: semua listener, cluster, dan route ditulis langsung di bootstrap. Sederhana, cocok untuk lab dan deployment kecil.
• Dinamis: bootstrap hanya berisi petunjuk untuk mengambil konfigurasi dari control plane via xDS. Inilah yang dipakai di production dan service mesh.

Kedua model akan kita praktikkan: statis di episode 3 sampai 8, lalu dinamis di episode 9.

#Control Plane, Data Plane, dan xDS

#Dua Sisi yang Terpisah

Data plane adalah Envoy itu sendiri: proxy yang benar-benar memproses traffic. Control plane adalah komponen terpisah yang menentukan kebijakan — service apa yang ada, di alamat mana, kebijakan retry dan TLS apa yang berlaku. Control plane tidak menyentuh traffic, hanya mengirimkan konfigurasi.

Pemisahan ini memungkinkan kebijakan berubah tanpa menyentuh data plane, dan data plane diskalakan secara independen dari logic kebijakan.

#Keluarga xDS

xDS adalah kumpulan protokol yang dipakai control plane untuk mengirim konfigurasi. Lima yang paling penting:

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

docker exec envoy-lab sh -c "ls /etc/envoy"
docker logs envoy-lab 2>&1 | tail -5

Perintah docker logs envoy-lab menampilkan log startup Envoy. Saat episode 9, log yang sama akan menunjukkan proses berlangganan ke LDS, RDS, dan CDS dari control plane.

#Alur Satu Request Melalui Envoy

#Perjalanan Request

Mari rangkai seluruh komponen dalam satu alur:

1. Klien membuka koneksi TCP ke port 10000, port listener.
2. Filter chain di listener, terutama http_connection_manager, mem-parse request HTTP.
3. Envoy memilih virtual host berdasarkan header Host.
4. Route yang cocok menentukan cluster tujuan.
5. Envoy memilih satu endpoint dari cluster via algoritma load balancing.
6. Koneksi dibuat ke endpoint, request diteruskan, respons dikembalikan ke klien.

curl -s localhost:9901/stats | grep "^listener" | head -8

Statistik listener di admin interface menunjukkan berapa koneksi diterima, request diproses, dan error yang terjadi. Dengan memahami alur di atas, kalian bisa memetakan setiap angka di output tersebut ke salah satu tahap perjalanan request.

#Penutup

Episode 2 memberi kalian peta arsitektur Envoy: lima komponen inti yang dirangkai dalam bootstrap, dua model konfigurasi, dan protokol xDS yang menghubungkan control plane dengan data plane. Alur satu request kini terlihat jelas dari listener sampai endpoint.

Inti yang harus dibawa pulang:

• Listener menerima traffic, filter chain memprosesnya, route memutuskan ke mana.
• Cluster adalah abstraksi backend; endpoint adalah alamat instance nyata.
• Bootstrap file adalah titik awal semua konfigurasi Envoy.
• Config bisa statis (ditulis langsung) atau dinamis (diambil via xDS).
• xDS utama: LDS, RDS, CDS, EDS, dan SDS.
• Control plane menentukan kebijakan, data plane mengeksekusi traffic.

Di episode 3 selanjutnya kita akan membahas instalasi dan hello Envoy — mengunduh binary atau menjalankan container, menyusun konfigurasi minimum untuk HTTP proxying sederhana, dan memverifikasi traffic melewati Envoy dengan curl. Saatnya mulai menulis config dan melihat Envoy bekerja.