1. GİRİŞ

Envoy, modern cloud‑native altyapıların omurgasını oluşturan yüksek performanslı, açık kaynaklı bir L4/L7 proxy'dir. Lyft tarafından geliştirilen ve daha sonra CNCF topluluğuna hızla yayılan Envoy, service mesh, API gateway, edge proxy ve reverse proxy kullanım senaryolarında temel bir yapıtaşı haline geldi. Özellikle Istio, Consul ve AWS App Mesh gibi projelerin data plane'inde Envoy tercih edilerek konfigürasyonun merkezi ve dinamik bir control plane üzerinden yönetilmesi sağlanır.

Neden bugün konuşuluyor?

• Dağıtık sistemlerde L7 kontrollü trafik yönetimi, gözlemlenebilirlik ve güvenlik artık zorunluluk.
• Envoy'un xDS API'leri ile dinamik konfigürasyon sağlanması, cloud‑native otomasyonların geliştirilmesini hızlandırdı.
• WASM destekli extensibility ile custom logic, düşük gecikmeyle proxy katmanında çalıştırılabiliyor.

Kimler için önemli?

• Platform mühendisleri ve SRE'ler — trafik kontrolü, güvenlik ve ölçekleme.
• API Gateway ve service mesh üreticileri.
• Geliştiriciler — performans kriterleri ve network davranışını anlamak isteyen backend ekipleri.

Hangi problemleri çözüyor?

• İleri seviye L7 routing (header/path tabanlı yönlendirme), retries, timeouts, rate‑limit ve circuit breaking.
• Uçtan uca gözlemlenebilirlik: access log, metrics ve tracing entegrasyonu.
• mTLS ve sertifika tabanlı workload identity ile güvenli servisler arası iletişim.

2. KAVRAMSAL TEMELLER

2.1 Envoy nedir — temel kavramlar

Envoy, modern proxy ihtiyaçlarına cevap veren, event‑driven, çok‑iş parçacıklı (multi‑threaded) bir proxy'dir. Hem kernel seviyesinde TCP/UDP (L4) hem de HTTP/HTTP2/gRPC (L7) trafiğini yönetebilir. Envoy'un temel hedefleri; düşük gecikme, yüksek throughput, zengin L7 yetenekleri ve dinamik konfigürasyondur.

2.2 Mimari bileşenler

• Listener: Envoy'un dış dünyayla bağlandığı ve gelen bağlantıları kabul ettiği ağ noktası. Listener, bir veya daha fazla filter chain içerir.
• Filter chain: Listener'dan geçen trafiğe uygulanan sıralı işlemciler (network ve HTTP filtreleri). TLS terminasyon, rate limit, auth, routing burada uygulanır.
• Cluster: Envoy'un upstream (hedef) servisleri tanımladığı mantıksal grup. Load balancing, health checking ve connection pooling buraya bağlıdır.
• Endpoint: Cluster içindeki gerçek IP:port adresi (pod, instance vb.).
• xDS: Envoy'un dinamik konfigürasyon aldığı discovery service API seti (LDS, RDS, CDS, EDS, SDS vb.).

2.3 Terminoloji

• Filter: Envoy'un pipeline'ında trafiği işleyen modül (network filter, HTTP filter, listener filter).
• Bootstrap config: Envoy'un başlangıçta okuduğu statik ayarlar; control plane erişimi, admin interface ve temel yapılandırmalar burada yer alır.
• Admin API: Envoy'un runtime durumunu sorgulamak veya bazı çalışma zamanlı ayarları değiştirmek için kullanılan HTTP arayüz.
• Hot restart: Envoy'in konneksiyonları kesmeden yeni bir prosesle güncellenmesini sağlayan mekanizma.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ, VERİ AKIŞI VE xDS

3.1 Başlangıç: bootstrap ve control plane bağlantısı

Envoy başlarken bootstrap konfigürasyonunu okur; bu dosya veya yönetilen bir kaynak (ör. Kubernetes ConfigMap) olabilir. Bootstrap içinde xDS sunucularının adresleri, admin interface ve statik listener'lar tanımlanır. Eğer dinamik konfigürasyon kullanılıyorsa Envoy, xDS endpoint'lerine bağlantı kurar ve LDS/RDS/CDS/EDS/SDS gibi kaynakları dinlemeye başlar.

3.2 xDS: dynamic discovery service

xDS, Envoy'un konfigürasyonu dinamik olarak almasını sağlayan API ailesidir. Temel xDS bileşenleri:

• LDS (Listener Discovery Service): Envoy'un hangi portları dinleyeceğini ve hangi filter chain'leri kullanacağını bildirir.
• RDS (Route Discovery Service): HTTP kural setleri ve route tabloları burada tutulur (VirtualHost, Route gibi kavramlar).
• CDS (Cluster Discovery Service): Upstream cluster yapılandırmalarını tanımlar (load balancing, circuit breaker ayarları).
• EDS (Endpoint Discovery Service): Her cluster için gerçek endpoint listesi (IP:port) ve sağlık bilgileri sağlar.
• SDS (Secret Discovery Service): TLS sertifikaları ve gizli anahtarların dinamik dağıtımı için kullanılır.

3.3 Filter chain ve HTTP pipeline

Envoy'da listener seviyesinde tanımlanan filter chain, gelen bağlantıya uygulanan network filtrelerinin sırasıdır. Network filtreleri TLS terminasyon, PROXY protocol, veya HTTP connection manager (HCM) gibi işlevleri kapsar. HCM ardından HTTP filtre zincirini çalıştırır: örneğin, JWT auth filter, rate limit filter, ext authz (authorization) ve yönlendirme. HTTP filtreleri istekleri işleyip, gerekli metadata'yı ekleyerek route kararına ve akhirnya uygun cluster'a yönlendirir.

3.4 Load balancing ve health checking

Envoy, bir cluster içindeki endpoint'lere gelişmiş load balancing algoritmaları uygular: round_robin, least_request, ring_hash, maglev gibi. Sağlık denetimleri (active/passive health checks) ile kötü durumda olan endpoint'ler trafikten otomatik olarak çıkarılır. Ayrıca circuit breaker, outlier detection gibi mekanizmalarla cascading failure'ların önüne geçilir.

3.5 Observability: metrics, logging, tracing

Envoy, Prometheus formatında zengin metrikler, access log'lar ve tracing span'ları üretir. Öne çıkan noktalar:

• RED metrikleri: request rate, errors, duration (latency histogramları)
• Access log: metoda, host'a, status code'lara göre ayrıntılı HTTP erişim kayıtları
• Distributed tracing: Envoy, trace context propagation (traceparent, x‑trace headers) ile span'lar üretebilir ve tracing backend'ine export edebilir (Jaeger, Zipkin, OTEL).

4. WASM VE EXTENSIBILITY

4.1 Neden WASM?

Envoy, filtre yeteneklerini genişletmek için C++ plugin geliştirme zorunluluğunu ortadan kaldırmak üzere WebAssembly (WASM) tabanlı uzantıları destekler. WASM, güvenli sandbox ile düşük gecikmeli custom logic çalıştırma imkânı verir; politika, authz, header enrichment veya telemetry adapter'ları WASM modülleri olarak dağıtılabilir.

4.2 WASM kullanım örnekleri

• Custom authentication/authorization adaptörü (örneğin özel token doğrulama kuralları)
• Header manipülasyonu ve request enrichment
• İş kurallarına göre dinamik yönlendirme kararları
• Telemetry exporter'ları: özel metrik veya log formatına dönüştürme

4.3 Performans ve güvenlik hatırlatmaları

WASM, esnek olsa da kötü yazılmış modüller latency ve bellek kullanımını olumsuz etkileyebilir. Bu nedenle WASM modüllerinin CPU ve memory limitleri, execution time budget ve sandbox politikaları ile sınırlandırılması önemlidir. Ayrıca WASM modüllerinin güvenilir kaynaklardan alınması ve imzalanması güvenlik açısından tavsiye edilir.

5. GERÇEK DÜNYA KULLANIMLARI

5.1 Edge proxy ve API gateway

Envoy, ingress gateway olarak Nginx veya HAProxy yerine tercih edilir; çünkü L7 özellikleri, HTTP/2 ve gRPC desteği, dinamik konfigürasyon ve zengin observability sağlar. TLS terminasyon, path/host tabanlı routing, WAF entegrasyonu ve rate limiting tipik kullanım örnekleridir.

5.2 Service mesh data plane

Istio, Consul ve AWS App Mesh gibi projeler Envoy'u data plane olarak kullanır. Her pod'a enjekte edilen Envoy sidecar, servisler arası trafiği yönetir; control plane ise xDS aracılığıyla komut gönderir.

5.3 gRPC ve HTTP/2 yük dengeleme

Envoy, HTTP/2 ve gRPC için gelişmiş routing ve load balancing desteği sunar; istemci tarafı load balancing logic'ini ortadan kaldırır ve server streaming/bi‑directional streaming senaryolarında stabilize edici davranış gösterir.

5.4 Observability backbone

Envoy, distributed tracing ve metrik üretimi sayesinde uygulama performans kokpitinin merkezine yerleşir. RED metrikleri ve access log'lar SRE ekiplerinin incident tespitinde birincil veri kaynaklarıdır.

6. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Zengin L7 yetenekleri: routing, retries, timeouts, fault injection, circuit breaking.
• Dinamik konfigürasyon: xDS sayesinde anlık politika değişiklikleri ve hedef güncellemeleri.
• Performans: event‑driven ve multi‑threaded mimari ile yüksek throughput.
• Extensibility: WASM ile custom logic eklenebilmesi.

Sınırlamalar

• Konfigürasyon karmaşıklığı: xDS ve Envoy config modelini doğru anlamak zaman alır.
• Kaynak overhead: sidecar modelinde her pod'a ek proxy konulması hafif de olsa ek maliyet getirir.
• Debug zorluğu: Envoy konfigürasyon hataları bazen beklenmeyen routing davranışlarına neden olur; istioctl/admintools gibi araçların kullanımı gerekir.

7. ALTERNATİFLER VE KARŞILAŞTIRMA

8. EN İYİ PRATİKLER

Production kullanımı

• Bootstrap config ve xDS yapılandırmasını versiyonlayın; değişiklikleri CI/CD ile yönetip canary rollout yapın.
• Admin API'yi güvenli hale getirin; yalnızca yetkili operatör erişimi verin.
• Access log ve metric toplama stratejisini planlayın; yüksek trafikte full access log maliyeti ağır olabilir.

Performans optimizasyonu

• Filter chain'i sadeleştirin: gereksiz filtreleri kaldırarak pipeline gecikmesini azaltın.
• Connection pooling ve HTTP/2 reuse ayarlarını optimize edin.
• Tracing sampling oranını iş hedefleriyle uyumlu belirleyin; %100 tracing genelde gereksizdir.

Güvenlik

• SDS ile sertifikaları dinamik ve güvenli dağıtın; sertifika rotasyonunu otomatikleştirin.
• mTLS uygulamalarında PERMISSIVE ile başlayıp, gözlem sonrası STRICT moda geçin.
• WASM modüllerini imzalama ve doğrulama ile dağıtın.

9. SIK YAPILAN HATALAR

• xDS kaynaklarını aşırı granüler tanımlamak — çok fazla update ve kontrol trafiği oluşur.
• Access log'ları yüksek trafikte detaylı tutmak — disk ve I/O maliyeti yükselir.
• WASM modüllerini test etmeden prod'a almak — latency ve bellek sorunları yaratır.
• Admin API'yi açık bırakmak ve güvenlik kontrollerini ihmal etmek.

10. GELECEK TRENDLER

1. WASM ekosisteminin büyümesi: Daha fazla policy ve telemetry adapter'ı WASM ile dağıtılacak.
2. eBPF + Envoy hibrit modeller: L4 işleme kernel tarafında, L7 policy ve routing Envoy'da olacak hibrit mimariler yaygınlaşacak.
3. AI destekli trafik optimizasyonu: Telemetry verilerinden otomatik canary kararları ve timeout tuning yapılacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Envoy neden xDS kullanır?

   xDS, Envoy'un konfigürasyonunu dinamik olarak almasını ve control plane ile senkronize çalışmasını sağlar. Bu sayede servis keşfi, routing ve sertifika yönetimi merkezi ve anlık olarak güncellenebilir.

2. 2. WASM performans maliyeti nedir?

   WASM modülleri genel olarak hızlıdır ancak kötü yazılmış kod veya sık I/O işlemleri latency ekleyebilir. Resource limitleri ve time budget ile kontrol altına alınmalıdır.

3. 3. Envoy sidecar modelinin dezavantajı nedir?

   Her pod'a eklenen proxy, bellek ve CPU tüketimini artırır; bu da toplam cluster maliyetini etkileyebilir. Ambient veya sidecar‑less yaklaşımlar bu overhead'i azaltmayı amaçlar.

4. 4. xDS'nin güvenliği nasıl sağlanır?

   xDS trafiği TLS ile şifrelenmeli ve mutual auth kullanılarak control plane ile Envoy arasında güvenli bağlantılar kurulmalıdır. SDS kullanarak sertifikatların güvenli dağıtımı önerilir.

5. 5. Envoy nasıl ölçeklenir?

   Envoy, çoklu worker thread'leri ve connection pooling ile yatay ölçeklenir. Listener ve cluster düzeyindeki ayarlar, thread sayıları ve resource limits tuning ile optimize edilebilir.

6. 6. Admin API'yi güvenli hale nasıl getiririm?

   Admin API yalnızca lokalde bind edilip, yönetim ağı veya bastion üzerinden erişilecek şekilde yapılandırılmalıdır. Ayrıca auth proxy veya firewall kuralları ile korunmalıdır.

7. 7. Envoy ile gRPC trafiği nasıl optimize edilir?

   HTTP/2 connection reuse, max concurrent streams ve HTTP/2 flow control parametreleri optimize edilmelidir. Ayrıca appropriate load balancing (least_request veya ring_hash) seçimleri önemlidir.

8. 8. Envoy konfigürasyon hatalarını nasıl tespit ederim?

   Envoy admin API, config_dump ve /config_dump uç noktası ile runtime konfigürasyon incelenebilir. Ayrıca control plane tarafında validate/parse adımları ile deploy öncesi analiz yapılmalıdır.

Anahtar Kavramlar

Envoy

High‑performance L4/L7 proxy; service mesh ve API gateway senaryolarında sık kullanılan bir data plane bileşeni.

xDS

Envoy'un dinamik konfigürasyon almak için kullandığı discovery service API seti (LDS, RDS, CDS, EDS, SDS).

Filter Chain

Listener seviyesinde trafiğe uygulanan filtrelerin sırası — TLS, auth, routing gibi işlemler burada yapılır.

Cluster

Envoy'un upstream hedef grubunu tanımlayan mantıksal yapı; load balancing ve sağlık kontrolü burada yönetilir.

WASM

Envoy için güvenli, sandbox edilmiş extensibility mekanizması; custom filter ve adapter'lar WASM modülleriyle sağlanır.

Öğrenme Yol Haritası

1. 0–1 ay: Envoy temel kavramları: listener, cluster, endpoint, filter chain ve bootstrap konfigürasyonları öğrenin.
2. 1–3 ay: xDS API'leri ve control plane entegrasyonlarını (istio/consul) deneyimleyin; admin API ve config_dump ile debug pratiği yapın.
3. 3–6 ay: Envoy filtreleri, WASM modülleri geliştirme ve performans tuning üzerine çalışın. gRPC/HTTP2 trafiği için optimizasyon uygulayın.
4. 6–12 ay: Service mesh senaryoları, multi‑cluster deployment, eBPF hibrit modelleri ve production observability/alerting süreçlerini kurun.