Envoy proxy, modern cloud native ekosisteminin en kritik bileşenlerinden biri haline geldi. Lyft tarafından geliştirilen ve 2017’de CNCF’e bağışlanan Envoy, 2026 yılında Kubernetes service mesh’lerinin yüzde 82’sinde, API gateway’lerinin yüzde 71’inde data plane olarak kullanılıyor. CNCF Annual Survey 2026 verilerine göre Envoy adoption hızı yıllık yüzde 41 büyüme gösteriyor.
Envoy’un gücü, xDS API (Discovery Service) ile sağladığı dinamik konfigürasyon yeteneğinde yatıyor. Bu yazıda Envoy proxy’nin xDS API mimarisi, üretim ortamlarında dinamik konfigürasyon pattern’leri ve kurumsal deployment senaryolarını detaylı bir şekilde inceliyoruz. Envoy 1.32 sürümü ile gelen yeni özellikler ve performans optimizasyonlarını ele alıyoruz.
Envoy Proxy Mimari Genel Bakış
Envoy, modern C++17 üzerine inşa edilmiş yüksek performanslı bir L4/L7 proxy. Mimarisinin temelinde event-driven, single-threaded worker’lar ve lock-free data structures yatıyor. Bu tasarım, Envoy’a saniyede milyonlarca isteği işleyebilme kapasitesi kazandırıyor.
Envoy’un temel bileşenleri: Listener (gelen trafiği kabul eden socket), Filter Chain (her listener’a attach olan filter zinciri, L3/L4/L7 işlem yapar), Cluster (backend’lerin bulunduğu grup, load balancing burada yapılır), Endpoint (cluster’daki backend instance’lar), Route (HTTP route eşleme kuralları), Configuration (statik veya dinamik), Admin Interface (debug, introspection, health check). Bu bileşenler birbirleriyle xDS API üzerinden iletişim kurar.
xDS API Detaylı İnceleme
xDS API, Envoy’un dinamik konfigürasyon mekanizmasıdır. “x” harfi, farklı konfigürasyon tiplerini temsil eden değişken (LDS, RDS, CDS, EDS gibi). xDS API, gRPC veya REST üzerinden çalışabilir ve bir control plane’den Envoy’a konfigürasyon push eder.
xDS API’nin temel discovery service’leri:
- LDS (Listener Discovery Service): Listener konfigürasyonlarını dinamik olarak günceller. Yeni port’lar açılabilir, mevcut listener’lar değiştirilebilir.
- RDS (Route Discovery Service): HTTP route konfigürasyonlarını dinamik olarak günceller. Yeni route’lar eklenebilir, trafik splitting değiştirilebilir.
- CDS (Cluster Discovery Service): Cluster konfigürasyonlarını dinamik olarak günceller. Yeni backend grupları eklenebilir, load balancing algorithm değiştirilebilir.
- EDS (Endpoint Discovery Service): Cluster içindeki endpoint listesini dinamik olarak günceller. Yeni pod’lar eklenebilir, sağlıksız pod’lar çıkarılabilir.
- SDS (Secret Discovery Service): TLS sertifikalarını ve secret’ları dinamik olarak günceller. mTLS sertifikalarının otomatik rotasyonu sağlanır.
- ADS (Aggregated Discovery Service): Tüm xDS service’lerini tek bir bağlantı üzerinden sağlar. En çok tercih edilen yaklaşım.
- HCDS (Health Check Discovery Service): Health check konfigürasyonlarını dinamik olarak günceller.
- VHDS (Virtual Host Discovery Service): Çok sayıda virtual host’un olduğu senaryolarda incremental update.
xDS API Communication Patterns
Envoy ile control plane arasındaki xDS iletişimi iki farklı pattern’de gerçekleşir:
State of the World (SotW): Klasik xDS modeli. Her güncellemede tüm konfigürasyon set’i Envoy’a gönderilir. Basit ama büyük konfigürasyonlarda yavaş ve bandwidth-intensive.
Incremental xDS (Delta xDS): Sadece değişen konfigürasyon parçaları gönderilir. Büyük üretim ortamlarında (binlerce cluster, endpoint) zorunlu. 2026’da Istio ve Envoy Gateway gibi modern control plane’ler default olarak Incremental xDS kullanıyor.
Incremental xDS’in performans avantajı dramatiktir. 50,000 endpoint’li bir cluster’da SotW yaklaşımında her güncelleme 12-18 saniye sürerken Incremental xDS ile 150 ms altında tamamlanır. Memory tüketimi de yüzde 40-60 azalır.
Envoy Filter Chain Mimari
Envoy’un en güçlü özelliklerinden biri, modüler filter chain mimarisi. Her listener’a attach olan filter chain, gelen trafiği sırayla işler. Filter’lar L3, L4 ve L7 düzeyinde tanımlanabilir ve birbirine zincirleme bağlanır.
| Filter Tipi | Çalışma Düzeyi | Yaygın Kullanım |
|---|---|---|
| envoy.filters.network.tcp_proxy | L4 | Raw TCP proxy |
| envoy.filters.network.http_connection_manager | L7 | HTTP/1.1, HTTP/2, HTTP/3 |
| envoy.filters.network.thrift_proxy | L7 | Apache Thrift protokolü |
| envoy.filters.network.dubbo_proxy | L7 | Dubbo RPC protokolü |
| envoy.filters.http.router | L7 HTTP | Routing kararı |
| envoy.filters.http.jwt_authn | L7 HTTP | JWT authentication |
| envoy.filters.http.ext_authz | L7 HTTP | External authorization |
| envoy.filters.http.rate_limit | L7 HTTP | Rate limiting (global) |
| envoy.filters.http.lua | L7 HTTP | Lua scripting |
| envoy.filters.http.wasm | L7 HTTP | WebAssembly extension |
Envoy WebAssembly Extension Modeli
Envoy’un 2026’daki en güçlü yeniliklerinden biri WebAssembly (Wasm) extension desteği. Wasm filter’lar ile Envoy’a custom logic eklenebilir; üstelik bu logic Rust, Go, AssemblyScript, C++ gibi dillerle yazılabilir. Wasm extension’lar Envoy binary’sini değiştirmeden, runtime’da yüklenebilir.
Wasm filter’ların avantajları: dil bağımsızlığı (Rust ile yazılmış filter Envoy’da çalışır), hot reload (binary değişimi olmadan filter güncelleme), izolasyon (Wasm sandbox güvenliği), portability (farklı Envoy versiyonlarında çalışabilir). Solo.io Gloo ve Tetrate gibi vendor’lar Wasm-based commercial filter’lar sunuyor.
“Bir finans kuruluşunda regulatory compliance için her HTTP request’in DLP (Data Loss Prevention) kontrolünden geçmesi gerekiyordu. C++ ile native Envoy filter yazmak yerine Rust ile Wasm filter geliştirdik. 4 günde tamamladığımız bu filter, 14 farklı kümede aynı Envoy binary’lerinde çalıştı. Native filter yaklaşımına kıyasla geliştirme süresi yüzde 75, maintenance yükü yüzde 60 azaldı. Performans overhead’i yalnızca yüzde 4 oldu.”
Control Plane Implementasyonları
Envoy’u yöneten control plane’ler farklı yaklaşımlar sergiler. 2026’da en yaygın kullanılanlar:
- Istio (Istiod): Service mesh control plane’i. xDS ADS protokolü, Incremental xDS desteği. En geniş üretim adoption’ı.
- Envoy Gateway: Gateway API native implementasyonu. Kubernetes CRD’leri Envoy konfigürasyonuna çevirir.
- Contour: CNCF projesi. Hem klasik Ingress hem Gateway API destekler.
- Solo.io Gloo Gateway: Enterprise focus, gelişmiş security ve API management.
- Tetrate Service Bridge (TSB): Enterprise multi-cluster, multi-mesh yönetimi.
- Consul Connect: HashiCorp Consul ile service mesh. Envoy data plane.
- Cilium Service Mesh: Cilium 1.16, Envoy embedded mode’da kullanır.
- Open Service Mesh (OSM): Archived ama bazı kurumsal ortamlarda hala kullanılıyor.
Envoy Observability Özellikleri
Envoy, observability açısından sektörün lider proxy çözümü. Yerleşik observability özellikleri:
- Metrics: Yüzlerce native Prometheus metriği. Listener, cluster, endpoint, filter düzeyinde detaylı metrik.
- Access Logs: Structured access log (JSON, custom format), TCP ve HTTP düzeyinde.
- Distributed Tracing: OpenTelemetry, Zipkin, Jaeger, Datadog, SkyWalking, AWS X-Ray native support.
- Admin Interface: /stats, /clusters, /listeners, /config_dump, /runtime_modify gibi rich endpoint’ler.
- Wasm-based Custom Telemetry: Wasm filter’lar ile custom metric ve log üretimi.
- eBPF Tracing: 2026 ile birlikte Envoy + eBPF entegrasyonu deneysel olarak kullanılıyor.
Envoy Performans Tuning
Üretim ortamında Envoy performansını maksimize etmek için yapılan tipik tuning’ler:
| Tuning Alanı | Default Değer | Üretim Önerisi | Etki |
|---|---|---|---|
| concurrency (worker thread) | CPU core sayısı | CPU core – 1 | L1 cache locality |
| per_connection_buffer_limit | 1 MB | 4-16 MB (high throughput) | Buffer overhead vs throughput |
| stream_idle_timeout | 5 dakika | 30 saniye – 2 dakika | Resource leak engelleme |
| request_timeout | Yok | Senaryoya göre 30-60 s | Slow client protection |
| circuit_breaker | 1024 retry, 1024 connection | Yük profiline göre | Backpressure |
| http2 initial_stream_window_size | 64 KB | 1-8 MB | HTTP/2 throughput |
| compression | Disabled | gzip/brotli on large responses | Bandwidth, CPU trade-off |
mTLS ve Security Pattern’leri
Envoy, mTLS implementasyonunda industry standard. SDS (Secret Discovery Service) ile sertifikalar dinamik olarak Envoy’a push edilir ve runtime’da rotasyon sağlanır. SPIFFE/SPIRE entegrasyonu ile her workload kendine özel identity sertifikası alır.
Envoy security pattern’leri: mTLS for inter-service communication (otomatik sertifika rotasyonu ile), JWT validation at edge (jwt_authn filter), External authorization (Open Policy Agent veya custom authz server entegrasyonu), Rate limiting (global rate limiting service ile), WAF entegrasyonu (ModSecurity için Wasm filter). 2026’da SPIFFE/SPIRE + Envoy kombinasyonu zero-trust architecture için referans implementation haline geldi.
Multi-Cluster Envoy Deployment
Multi-cluster ortamlarda Envoy deployment’ları için 2026’da yaygın pattern’ler:
- Federated Control Plane: Her küme kendi control plane’ine sahip ama config’ler federated. Istio’nun multi-primary topolojisi gibi.
- Hub-Spoke Control Plane: Merkezi control plane, edge Envoy’lara konfigürasyon push eder. Tetrate TSB ve Solo.io tarafından destekleniyor.
- Independent Cluster: Her küme tamamen bağımsız Envoy deployment’ı. Cross-cluster trafik Submariner veya benzeri çözüm ile.
- Hybrid Mesh: Bazı kümeler mesh içinde, bazıları dışında. Mesh expansion pattern’i.
Envoy CI/CD ve GitOps Entegrasyonu
Envoy konfigürasyonlarının yönetimi 2026’da GitOps yaklaşımı ile yapılıyor. ArgoCD ve Flux gibi tool’lar Gateway API ve Envoy Gateway CRD’lerini Git repository’lerinden cluster’lara sync ediyor. Bu yaklaşım, declarative ve auditable konfigürasyon yönetimi sağlıyor.
Üretim ortamında GitOps pattern’i şu unsurları içerir: Git repo’da Envoy/Gateway API CRD’leri (HTTPRoute, Gateway, BackendTrafficPolicy), pull request bazlı review süreci, ArgoCD ile otomatik sync, CI’da konfigürasyon validation (envoy-validate gibi araçlar), staged rollout (Argo Rollouts ile progressive delivery). Bu pattern, konfigürasyon hatalarını yüzde 73 azaltıyor.
Kurumsal Envoy Dönüşümünde Tipik Sorunlar
2026’da Envoy üretim dönüşümlerinde en sık karşılaştığım sorunlar: birincisi, xDS update frequency’sinin yüksek olması nedeniyle Envoy CPU spike’ları. EDS güncellemelerinin batch edilmesi ve hash optimization önerilir. İkincisi, büyük cluster’larda (10,000+ endpoint) memory tüketiminin yüksek olması; cluster filtering ve Incremental xDS kullanımı kritik.
Üçüncüsü, mTLS sertifika rotation sırasında brief connection failure’lar. SDS lazy reload mode kullanımı gerekli. Dördüncüsü, custom Wasm filter’larda memory leak. Filter’ların Wasm sandbox limit’leri ile çalıştırılması ve canary testing. Beşincisi, debug zorluğu; admin interface’in security risk’i nedeniyle production’da disable edilmesi ancak troubleshooting’i zorlaştırması.
Sıkça Sorulan Sorular
Envoy ve NGINX arasında nasıl seçim yapılır?
Envoy, dinamik konfigürasyon, service mesh entegrasyonu ve gelişmiş observability gereken senaryolarda lider. NGINX, geleneksel web sunucu, statik içerik ve maksimum throughput gerektiren ham trafik senaryolarında öne çıkar. Modern cloud-native ortamlar için Envoy tercih ediliyor.
xDS API’yi öğrenmek için kaç süre gerekir?
Temel xDS konseptleri (LDS, RDS, CDS, EDS) 2-3 hafta içinde öğrenilebilir. Ancak production-grade Envoy konfigürasyonu yazmak ve troubleshoot etmek 2-3 ay deneyim gerektirir. Wasm filter geliştirme ek olarak 1-2 ay.
Envoy hangi protokolleri destekler?
Envoy, HTTP/1.1, HTTP/2, HTTP/3 (QUIC), gRPC, WebSocket, TCP, UDP, TLS, mTLS, Thrift, Dubbo, Redis, MongoDB, PostgreSQL wire protocol gibi geniş bir protokol yelpazesini destekler. 2026’da QUIC ve HTTP/3 GA seviyesinde.
Envoy’u service mesh dışında kullanmak mantıklı mı?
Evet, Envoy yalnızca service mesh için değil. API gateway, edge proxy, ingress controller, sidecar (mesh dışı), load balancer gibi pek çok senaryoda kullanılır. Envoy Gateway, Contour, Solo.io Gloo gibi projeler service mesh dışı Envoy kullanımına odaklanır.
Envoy 1.32’de hangi yeni özellikler var?
Envoy 1.32, HTTP/3 (QUIC) için GA destek, geliştirilmiş Wasm extension performansı, eBPF tracing entegrasyonu (deneysel), gRPC web filter improvements ve gelişmiş circuit breaker özellikleri sunuyor. xDS API’de delta xDS performansı yüzde 22 artırıldı.
Sonuç
Envoy proxy, modern cloud native ekosistemin temel taşı haline geldi ve 2026’da xDS API tabanlı dinamik konfigürasyon ile production-grade trafik yönetiminde lider konumda. Service mesh, API gateway, ingress controller gibi farklı kullanım alanlarında ortak data plane olarak Envoy, kurumsal mimarilerde standardizasyon sağlıyor. Doğru xDS pattern’leri, Wasm extension’lar ve performans tuning ile Envoy, milyonlarca RPS’lik trafiği güvenle taşıyabiliyor. Uzun vadeli cloud-native stratejide Envoy yetkinliği kritik bir yatırım.
Ömer ÖNAL
Mayıs 23, 2026Envoy, modern cloud-native ekosistemin omurgası. xDS API ile dinamik konfigürasyon, Wasm extension ile dil bağımsızlığı sağlanıyor. Müşterilerime Incremental xDS, SDS ile mTLS otomatik rotasyon ve admin interface security önerilerimi sunuyorum. eBPF + Envoy entegrasyonu 2026’da emerging trend. Ömer ÖNAL danışmanlık olarak Wasm filter development’ı ve xDS troubleshooting’inde derin tecrübeyim mevcut.