Elchi vs Envoy Gateway.
Envoy Kubernetes’te çalışıyorsa ve yapılandırma modeli olarak Kubernetes Gateway API’yi istiyorsanız Envoy Gateway’i seçin. Envoy production’da Linux VM’lerde veya appliance’larda çalışıyorsa (Envoy Gateway’in standalone modu deneyseldir) ya da tam Envoy API’sini tipli formlarla, aynı anda birden fazla Envoy sürümünü ve yerleşik bir WAF’ı istiyorsanız Elchi’yi seçin.
Kriter kriter Elchi ve Envoy Gateway
| Kriter | Elchi | Envoy Gateway |
|---|---|---|
| Envoy nerede çalışır | elchi-client agent’ın Envoy’u çalıştırdığı Linux edge sunucular (Ubuntu 24.04) veya Elchi OS appliance’ları. Control plane; Kubernetes (Helm), Docker Swarm veya bare-metal Linux üzerine kurulur. Kubernetes servisleri discovery agent ile upstream olarak kullanılabilir. | Önce Kubernetes. Standalone mod, Envoy’u bare metal veya VM’lerde host süreci olarak çalıştırır; ancak proje bu modu deneysel olarak işaretler ve production’da kullanılmamasını söyler. |
| Yapılandırma modeli | Her Envoy sürümünün protobuf’larından üretilen tipli formlar; listener, route, cluster, endpoint, secret, filtre ve bootstrap dahil her kaynak için. Her değişiklik editörde ve sunucuda tekrar doğrulanır. Script ve CI için bir REST API ile token kapsamlı bir automation API vardır. | Kubernetes Gateway API kaynakları ve politika olarak bağlanan uzantı CRD’leri: ClientTrafficPolicy, BackendTrafficPolicy, SecurityPolicy, EnvoyExtensionPolicy, EnvoyPatchPolicy ve diğerleri. Standalone modda bir file provider bu kaynakları diskten okur. |
| Aynı anda birden fazla Envoy sürümü | Evet. Her Envoy sürümü için bir control-plane varyantı çalışır; registry her proxy’yi eşleşen varyanta yönlendirir. Listener upgrade, bağımlılıkları yeni sürüme kopyalar ve Envoy’u hot restart ile değiştirir (Elchi’nin uçtan uca testinde 20 req/s altında 0 düşen istek). | Her Envoy Gateway sürümü tek bir Envoy Proxy minor sürümüyle gelir ve onunla test edilir (v1.9 ile 1.39.x, v1.10 ile 1.40.x). Envoy minor sürümünü değiştirmek, Envoy Gateway sürümünü değiştirmek demektir. |
| Yayınlama iş akışı ve denetim | Taslak, kaydet ve yayınla; yayınlama yeni bir xDS snapshot’ı gönderir ve Envoy bunu yeniden başlatmadan uygular. Her değişiklik önce/sonra ayrıntısıyla değiştirilemez bir audit trail’e yazılır ve RFC5424 syslog ile bir SIEM’e iletilebilir. | Deklaratif: kaynakları uygularsınız (standalone modda izlenen dosyaları değiştirirsiniz). İnceleme ve geçmiş sizin Git/CI sürecinizden gelir. |
| WAF | Shield (API Security eklentisi): her edge sunucuda çalışan bir ext_proc sidecar; Coraza ve OWASP Core Rule Set yerleşiktir ve kimlik doğrulama, rate limiting, bot savunması gibi on iki motordan biridir. Politikalar detect’ten block’a kademeli geçer. | Yerleşik WAF yoktur. EnvoyExtensionPolicy; ext_proc servisleri, Wasm uzantıları veya dynamic module’ler bağlar; dokümanlarda dynamic module olarak yüklenen bir Coraza WAF örneği vardır. |
| GSLB | GSLB eklentisi: DNS tabanlı yönlendirme. Controller bir kaydın arkasındaki her IP’yi HTTP, HTTPS veya TCP ile yoklar; bir CoreDNS eklentisi yalnızca sağlıklı hedefleri döner. | Projenin kapsamında değildir. |
| API keşfi | API Discovery eklentisi: Envoy erişim log’larından pasif olarak oluşturulan bir envanter; kimlik doğrulama ve PII işaretleri, gölge endpoint’ler ve OpenAPI spec’lerinize göre sapma. İsteklerin yolunda hiçbir zaman bulunmaz. | Projenin kapsamında değildir. |
| Sunuculardaki agent ve kurulum | Her sunucudaki elchi-client controller’a dışarı doğru bağlanır (gelen bağlantı dinlemez), Envoy’u indirir, deploy edilen her listener’ı bir systemd servisi olarak çalıştırır; ağ, BGP/FRR ve log gönderimini yönetir. | Kubernetes’te Envoy Gateway, yönetilen Envoy proxy’lerini Gateway API kaynaklarından oluşturur ve yapılandırır. Standalone modda bir host infrastructure provider, Envoy Gateway’in yanında tek bir Envoy’u host süreci olarak çalıştırır. |
| RBAC ve çok kiracılılık | Projeler ekipleri, ortamları veya müşterileri birbirinden ayırır. Dört rol (Owner, Admin, Editor, Viewer), LDAP/Active Directory girişi ve TOTP iki adımlı doğrulama. | Gateway API ve uzantı kaynakları üzerinde Kubernetes RBAC ve namespace’ler. Standalone modda erişim, izlenen dosyalara erişimdir. |
| Lisans ve maliyet modeli | Ticari lisans; yönetilen client (edge node) sayısına ve ürüne göre boyutlanır: Core artı API Security, API Discovery ve GSLB eklentileri. Ücretsiz seviye: lisans gerekmeden bir yönetilen client ile Elchi Core. | Açık kaynak (Apache 2.0). |
| İşlettiğiniz bileşenler | Controller, Control-Plane ve Registry ile MongoDB, ClickHouse, VictoriaMetrics/Grafana ve bir OTel Collector; hepsi tek bir :443 ön kapının arkasında. Her edge sunucuda elchi-client (kullanılıyorsa Shield de). | Cluster’da Envoy Gateway controller’ı ve yönettiği Envoy proxy’leri; standalone modda Envoy Gateway ve Envoy sunucuda süreç olarak. |
Bir Gateway API uygulaması ve bir filo control plane’i
Envoy Gateway, Envoy projesinin Kubernetes Gateway API için geliştirdiği gateway’dir. Gateway’leri ve route’ları tanımlar, Envoy Gateway’in politika kaynaklarını onlara bağlarsınız; o da Envoy proxy’lerini buna göre oluşturup yapılandırır. Bir Kubernetes cluster’ına giren north-south trafik için bu, gateway yapılandırmasını diğer Kubernetes manifest’lerinizin yanında, üreticiden bağımsız bir API ile tutar.
Kubernetes dışında Envoy Gateway’in, Gateway API kaynaklarını dosyalardan okuyan ve tek bir Envoy’u host süreci olarak çalıştıran bir standalone modu vardır. Proje bunu deneysel ve production için uygun değil olarak belgeler. Elchi diğer uçtan başlar: Linux sunucular ve appliance’lar üzerindeki Envoy ana senaryodur; bir agent üzerinden filo olarak yönetilir ve Envoy API’si, Gateway API soyutlamaları yerine alan alan sunulur.
Ne zaman Envoy Gateway’i seçmelisiniz
- Gateway’leriniz Kubernetes içinde çalışıyor ve onları diğer Kubernetes kaynaklarınız ve GitOps araçlarınızla birlikte standart Gateway API ile yapılandırmak istiyorsunuz.
- Gateway API ve Envoy Gateway’in politika kaynakları ihtiyacınız olan özellikleri karşılıyor ve daha alt seviye Envoy alanlarıyla çalışmak istemiyorsunuz.
- Her sürümde test edilmiş tek bir Envoy minor sürümünü izlemek sizin yükseltme biçiminize uyuyor.
- Envoy topluluğundan, ticari lisans gerektirmeyen açık kaynak (Apache 2.0) bir proje istiyorsunuz.
Elchi ne zaman uygun
- Production Envoy’larınız herhangi bir Kubernetes cluster’ı dışında, Linux VM’lerde, bare metal’de veya appliance’larda çalışıyor ve onları filo olarak yönetmenin desteklenen bir yoluna ihtiyacınız var.
- Gateway API kaynaklarının ifade etmediği Envoy özelliklerine ihtiyacınız var ve bunları doğrudan Envoy API’sinden, editörde ve sunucuda doğrulanarak yapılandırmak istiyorsunuz.
- Farklı servisler bir süre farklı Envoy sürümlerinde kalmalı; listener’lar filo çapında bir yükseltme yerine hot restart ile sürümler arasında taşınmalı.
- WAF (OWASP Core Rule Set ile Shield), API keşfi ve GSLB’yi audit trail ve proje seviyesinde rollerle aynı arayüzden yönetmek istiyorsunuz.
Devamını okuyun
Bu sayfadaki iddiaların dayandığı Elchi dokümanları ve sözü geçen ürünler.
Dokümantasyon
Diğer karşılaştırmalar
Kendi filonuzda görün.
Envoy’larınızın nerede çalıştığını ve üzerlerinde neyi değiştirmeniz gerektiğini anlatın. Ürünü sizinkine benzer bir kurulumda gösterelim ya da bir yönetilen client ile ücretsiz seviyede başlamanıza yardım edelim.
Kaynaklar
Diğer projelerle ilgili bilgiler, aşağıdaki tarihte kontrol edilen resmi dokümanlarından ve depolarından alınmıştır. Elchi bilgileri Elchi dokümantasyonundan gelir.
- github.com/envoyproxy/gateway (README, license)
- Envoy Gateway: Standalone Deployment Mode
- Envoy Gateway: Compatibility Matrix
- Envoy Gateway: Gateway API Extensions
- Envoy Gateway: External Processing
- Envoy Gateway: Extensibility tasks (Wasm, dynamic modules, Coraza WAF example)
Son inceleme: