VM’lerde Envoy için Elchi vs Istio.

Kubernetes workload’ları için sidecar veya ambient data plane’li bir service mesh istiyor ve VM’leri o mesh’e katmak istiyorsanız Istio’yu seçin. Envoy, Linux VM’lerde veya appliance’larda edge, gateway ya da yük dengeleme katmanı olarak çalışıyorsa; tam Envoy API’sini tipli formlarla, aynı anda birden fazla Envoy sürümünü ve denetlenen bir yayınlama akışını istiyorsanız Elchi’yi seçin.

Demo isteyin Ücretsiz seviyeyi deneyin

Kriter kriter Elchi ve Istio

Envoy’u Kubernetes dışında çalıştıran ekipler için Elchi ve Istio karşılaştırması. Istio bilgileri istio.io’dan alınmıştır; Kaynaklar bölümüne bakın.
Kriter	Elchi	Istio
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.	Kubernetes etrafında kurgulanmıştır. VM’ler mesh’e workload olarak katılır: VM kılavuzu istiod’u bir Kubernetes cluster’ına kurar ve VM’lere bir east-west gateway üzerinden açar. VM entegrasyonu Beta durumundadır; kılavuz Debian ve CentOS 8 paketleri sunar.
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 kaynakları: VirtualService, DestinationRule, Gateway, ServiceEntry ve Sidecar; ayrıca Istio’nun ileride varsayılan yapmayı planladığı Kubernetes Gateway API. Envoy yapılandırmasını Istio üretir; EnvoyFilter üretileni özelleştirir.
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).	Yükseltmeler revision olarak yapılır: her revision tam bir istiod control plane’idir, workload’lar istio.io/rev etiketiyle ona geçer ve mevcut pod’lar yeni proxy için yeniden başlatılır.
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.	Değişiklikler Kubernetes kaynakları olarak uygulanır; inceleme ve geçmiş sizin Git/CI sürecinizde ve Kubernetes API’sinde tutulur. Yerleşik bir taslak-ve-yayınla adımı yoktur.
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 değildir. Proxy, WasmPlugin (WebAssembly filtreleri) veya EnvoyFilter ile genişletilebilir; WAF sizin seçip ekleyeceğiniz ve işleteceğiniz bir filtredir.
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.	DNS tabanlı GSLB yoktur. Locality failover mesh içinde yapılandırılır.
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.	API envanteri özelliği yoktur; ayrı bir araç gerekir.
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.	VM’de: istio-sidecar .deb veya .rpm paketi, cluster’dan kopyalanan sertifikalar, token ve mesh config; systemctl ile başlatılır. Kubernetes’te: sidecar’lar veya ambient mod.
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.	Mesh kaynaklarını kimin değiştirebileceğini Kubernetes RBAC ve namespace’ler belirler.
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).	Bir Kubernetes cluster’ında istiod ve gateway’ler; VM’ler için istiod’u açan bir east-west gateway ve her VM’de sidecar paketi.

Aynı proxy için iki farklı iş

Istio da Elchi de Envoy çalıştırır, ama onu farklı yerlere koyar. Istio bir service mesh’tir: her workload’un yanına bir proxy koyar (ambient modda ztunnel ve waypoint proxy’leri kullanır) ve Kubernetes kaynaklarıyla yapılandırılır. Sanal makineler bu mesh’e WorkloadGroup ve WorkloadEntry kaynaklarıyla temsil edilen workload’lar olarak katılır; control-plane trafikleri cluster’daki bir gateway üzerinden geçer.

Elchi bir service mesh değildir. Envoy’u seçtiğiniz sunucularda edge, gateway veya yük dengeleme katmanı olarak yönetir. Her sunucuda çalışan elchi-client agent, Envoy’u systemd servisleri olarak çalıştırır ve control plane’e tek bir dışa doğru bağlantıyla bağlanır. Data plane tarafında Kubernetes cluster’ı gerekmez; Envoy API’sini, onu üreten üst seviye bir soyutlama yerine doğrudan düzenlersiniz.

Ne zaman Istio’yu seçmelisiniz

Servislerinizin çoğu Kubernetes’te çalışıyor ve aralarında mesh özellikleri istiyorsunuz: workload başına proxy, servisten servise trafik politikası ve cluster genelinde tek bir model.
Zaten Istio çalıştırıyorsunuz ve kapsamanız gereken VM’ler o mesh’in parçası olması gereken workload’lar; pod’ları ve VM’leri birlikte seçen Kubernetes servisleriyle adreslenecekler.
UI tabanlı bir iş akışı yerine Git’te incelenen Kubernetes kaynaklarını ve Gateway API’yi tercih ediyorsunuz.
Çekirdeği için ticari lisans gerektirmeyen açık kaynak (Apache 2.0) bir proje istiyorsunuz.

Elchi ne zaman uygun

Envoy, Linux VM’lerde, bare metal’de veya appliance’larda edge, ingress ya da API gateway katmanınız ve sırf onu yönetmek için bir mesh eklemek ihtiyacınızdan fazlası.
Ekipler listener, route, cluster ve TLS’i xDS veya YAML yazmadan değiştirmeli; her değişiklik doğrulanmalı, taslak/yayınla akışından geçmeli ve audit trail’e yazılmalı.
Birden fazla Envoy sürümünü çalıştırmanız ve listener’ları trafik kaybetmeden sürümler arasında taşımanız gerekiyor.
WAF (Shield), DNS tabanlı GSLB ve trafikten çıkarılan bir API envanterini ayrı araçlar yerine aynı control plane’de istiyorsunuz.
Upstream’lerinizin bir kısmı Kubernetes servisleri: discovery agent, endpoint’lerini edge sunucularınızdaki Envoy cluster’larına senkronlar.

Devamını okuyun

Bu sayfadaki iddiaların dayandığı Elchi dokümanları ve sözü geçen ürünler.

Dokümantasyon

Ürünler

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.

Demo isteyin Ücretsiz seviyeyi deneyin

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.

Son inceleme: 13 Kasım 2026