Service Mesh Gerçekten Gerekli mi? Kısa Yanıt
Service mesh, 50’den fazla mikroservise ve günde milyonlarca servisler arası çağrıya ulaşan ekipler için gerçekten gereklidir; ancak 10-15 servisli ekiplerin çoğu için 2026 yılında hâlâ gereksiz operasyonel yük getirir. Karar, servis sayısına, gözlemlenebilirlik ihtiyacına ve mTLS gibi sıfır güven (zero trust) gereksinimlerine bağlıdır. CNCF’nin 2024 anketine göre üretimde service mesh kullanımı %50 bandına ulaştı; ancak aynı katılımcıların yaklaşık üçte biri kurulumun beklenenden karmaşık olduğunu bildirdi. Bu yazıda Istio, Linkerd ve hafif alternatifleri somut performans, kaynak tüketimi ve maliyet verileriyle karşılaştırıyor, hangi durumda hangisinin doğru seçim olduğunu netleştiriyorum.
Pratikte ölçütüm şudur: Eğer Kubernetes üzerinde çalışan servis sayınız 20’yi aştıysa, ekipleriniz birbirinden bağımsız deploy yapıyorsa ve servisler arası şifreleme (mTLS) ile dağıtık izleme (distributed tracing) zorunluysa, service mesh yatırımı kendini amorti eder. Aksi halde uygulama kütüphaneleri (resilience library) veya basit bir API gateway daha düşük maliyetle aynı değeri sunar. Bu karar, daha geniş Kubernetes mimari stratejinizin bir parçası olarak ele alınmalıdır.
Service Mesh Nedir ve Hangi Sorunu Çözer?
Service mesh, mikroservisler arasındaki ağ trafiğini uygulama kodundan soyutlayan bir altyapı katmanıdır. Her servis pod’una eşlik eden bir sidecar proxy (genellikle Envoy) yerleştirilir; bu proxy trafik yönlendirme, yeniden deneme (retry), zaman aşımı, devre kesici (circuit breaker), mTLS şifreleme ve telemetri toplama görevlerini üstlenir. Böylece geliştiriciler iş mantığına odaklanırken ağ politikaları merkezî bir kontrol düzleminden (control plane) yönetilir.
Service mesh’in çözdüğü dört temel sorun vardır:
- Güvenlik: Servisler arası tüm trafiği otomatik mTLS ile şifreler, sertifika rotasyonunu yönetir. Manuel TLS yönetimi onlarca servis için sürdürülemez hale gelir.
- Gözlemlenebilirlik: Altın sinyalleri (gecikme, trafik, hata, doygunluk) kod değişikliği olmadan toplar; dağıtık tracing için span üretir.
- Trafik yönetimi: Canary deployment, mavi-yeşil dağıtım, A/B testi ve ağırlıklı yönlendirmeyi deklaratif olarak sağlar.
- Dayanıklılık: Retry, timeout, rate limiting ve circuit breaker’ı her servise tek tek kod yazmadan getirir.
Bu yetenekleri uygulama içinde Spring Cloud, Resilience4j veya benzeri kütüphanelerle de elde edebilirsiniz; ancak çok dilli (polyglot) mimarilerde her dil için ayrı kütüphane bakımı maliyetli olur. İşte service mesh bu noktada dil bağımsız bir çözüm sunar. CNCF’nin yıllık anketleri, bulut yerel (cloud native) benimsemenin olgunlaştıkça ağ katmanı soyutlamasının giderek standartlaştığını gösterir; ayrıntılı veri için CNCF yıllık anket raporları başvuru kaynağıdır.
Servis sayısı arttıkça ağ politikalarını uygulama kodunda yönetmek hata yüzeyini büyütür: her ekip retry mantığını, timeout değerlerini ve circuit breaker eşiklerini farklı uygular; sonuç tutarsız davranış ve teşhisi zor üretim olaylarıdır. Service mesh bu mantığı kontrol düzlemine taşıyarak tek bir politika kaynağı yaratır. Bu merkezîleşme, özellikle mikroservis mimarisinde onlarca ekibin koordinasyonunu kolaylaştırır ve gözlemlenebilirlik standardını yukarı çeker.
Istio: Güçlü ama Ağır
Istio, CNCF mezunu, Google ve IBM destekli en olgun service mesh’tir. Envoy proxy’yi sidecar olarak kullanır ve 2023’ten itibaren sidecar gerektirmeyen ambient mesh modunu getirerek kaynak tüketimi eleştirilerine yanıt vermeye başladı. Trafik yönetimi, güvenlik politikaları ve telemetri konusunda pazardaki en geniş özellik setini sunar.
Istio’nun gücü esnekliğindedir: VirtualService, DestinationRule ve Gateway CRD’leriyle son derece ayrıntılı trafik kuralları tanımlanır. Ancak bu esneklik öğrenme eğrisini dikleştirir. Geleneksel sidecar modunda her pod’a eklenen Envoy proxy yaklaşık 50-100 MB bellek ve gözle görülür CPU tüketir; yüzlerce pod’lu kümelerde bu birikim ciddi kaynak maliyeti yaratır.
Ambient mesh modu, sidecar yerine düğüm başına bir ztunnel bileşeni ve katman 7 işlevleri için isteğe bağlı waypoint proxy kullanarak bu yükü önemli ölçüde azaltır. 2026 itibarıyla ambient mode üretime hazır kabul edilir ve sidecar moduna göre belirgin kaynak tasarrufu sağlar. Mimari ayrıntılar için resmi Istio dokümantasyonu en güncel kaynaktır.
Istio’yu seçen ekiplerin en sık yaptığı hata, tüm özellik setini tek seferde devreye almaya çalışmaktır. Doğru yaklaşım kademelidir: önce mTLS ve temel telemetri, ardından trafik yönlendirme kuralları, en son gelişmiş politikalar. Bu sıralama hem öğrenme eğrisini yumuşatır hem de her aşamada somut değer üretir. Üretim kümelerinde kontrol düzlemi (istiod) için yüksek erişilebilirlik, yatay ölçekleme ve dikkatli kaynak rezervasyonu kritik öneme sahiptir; kontrol düzlemi darboğazı tüm veri düzlemini etkiler.
Linkerd: Hafiflik ve Sadelik
Linkerd, Buoyant tarafından geliştirilen, CNCF mezunu ikinci büyük service mesh’tir. En önemli farkı, Envoy yerine Rust ile yazılmış kendi mikro proxy’sini (linkerd2-proxy) kullanmasıdır. Bu proxy tek bir servis pod’una odaklandığı için Envoy’a kıyasla çok daha az bellek (genellikle 10-20 MB bandında) ve daha düşük gecikme getirir.
Linkerd’in felsefesi “varsayılan olarak çalışır” üzerinedir: mTLS otomatik açıktır, altın metrikler kutudan çıkar çıkmaz toplanır, kurulum dakikalar sürer. Bu sadelik, özellik genişliğinden ödün vermek anlamına gelir; Istio’nun sunduğu bazı ileri trafik kuralları Linkerd’de daha sınırlıdır veya Gateway API üzerinden gelir. Kurulum ve operasyon ayrıntıları için Linkerd resmi dokümantasyonu referans alınmalıdır.
Linkerd’in Rust proxy tercihi yalnızca bellek tasarrufu değil, güvenlik açısından da bir avantajdır: Rust’ın bellek güvenliği garantileri, proxy katmanındaki saldırı yüzeyini azaltır. Pratikte Linkerd, mTLS ve gözlemlenebilirliğin yeterli olduğu, gelişmiş trafik bölme veya çok karmaşık politika gerektirmeyen orta ölçekli ekipler için en hızlı değer üreten seçenektir. Gateway API olgunlaştıkça Linkerd’in trafik yönetimi yetenekleri de standartlaşarak genişlemektedir.
| Kriter | Istio (sidecar) | Istio (ambient) | Linkerd | Cilium Mesh |
|---|---|---|---|---|
| Proxy teknolojisi | Envoy | ztunnel + waypoint | linkerd2-proxy (Rust) | eBPF + Envoy |
| Pod başı bellek | ~50-100 MB | node başı düşük | ~10-20 MB | eBPF ile minimal |
| Öğrenme eğrisi | Dik | Orta | Düşük | Orta-yüksek |
| mTLS varsayılan | Manuel açılır | Otomatik | Otomatik | Otomatik |
| Özellik genişliği | Çok geniş | Geniş | Orta | Geniş (L3/L4 güçlü) |
| CNCF durumu | Mezun | Mezun | Mezun | Mezun (Cilium) |
Hafif Alternatifler: Cilium, Consul ve Gateway API
Service mesh kararı yalnızca Istio-Linkerd ikilisiyle sınırlı değildir. 2026’da öne çıkan alternatifler şunlardır:
- Cilium Service Mesh: eBPF tabanlı çalışarak sidecar yükünün önemli kısmını çekirdek (kernel) düzeyine taşır. Ağ politikaları (L3/L4) konusunda son derece güçlüdür ve gözlemlenebilirlik için Hubble’ı entegre eder. Sidecarsız mimarisi kaynak tüketimini ciddi biçimde düşürür.
- HashiCorp Consul: Kubernetes dışı VM’leri ve çoklu çalışma zamanlarını da kapsayan ortamlar için güçlüdür. Service discovery ve mesh’i birleştirir, hibrit altyapılarda öne çıkar. Mimari ve kurulum için Consul resmi dokümantasyonu başvuru kaynağıdır.
- Kubernetes Gateway API: Mesh gerektirmeden gelişmiş trafik yönlendirme (north-south ve giderek east-west) ihtiyaçlarını karşılar. Birçok ekip için tam mesh yerine yeterli olur.
Bu alternatifler, “mesh mi değil mi” sorusunu “ne kadar mesh” sorusuna dönüştürür. Çoğu orta ölçekli ekip için sadece mTLS ve temel gözlemlenebilirlik yeterlidir; tam Istio kurulumu gereksiz olur. Cilium’un eBPF tabanlı yaklaşımı, ağ gözlemlenebilirliği için Hubble ile birleştiğinde paket düzeyinde görünürlük sağlar; teknik ayrıntılar için Cilium dokümantasyonu başvuru kaynağıdır.
Gateway API’nin yükselişi özellikle dikkat çekicidir: Kubernetes topluluğu, eski Ingress kaynağının yerini alacak bu standartla north-south (dışarı-içeri) trafiği zaten kapsar ve giderek east-west (servisler arası) mesh işlevlerini de standardize eder. Birçok ekip için tam bir service mesh yerine Gateway API ve hedefe yönelik birkaç politika, hem operasyonel sadelik hem yeterli kontrol sunar. Bu yaklaşım, genel DevOps mimari olgunluğunuzla uyumlu şekilde kademeli ölçeklenmenizi sağlar.
Maliyet ve Performans: Sayılarla Karar
Service mesh’in görünmeyen maliyeti operasyonel yüktür. Aşağıdaki tablo tipik bir orta-büyük küme için yaklaşık yıllık toplam sahip olma maliyetini (TCO) kategorize eder. Rakamlar genel kabul gören aralıklardır; kendi ortamınızda farklılık gösterir.
| Maliyet kalemi | Sidecar mesh | Sidecarsız (ambient/eBPF) | Mesh yok (kütüphane) |
|---|---|---|---|
| Ek bellek (compute) | Yüksek | Düşük-orta | Düşük |
| Gecikme katkısı | 1-3 ms ek | <1 ms ek | İhmal edilebilir |
| Kurulum süresi | Haftalar | Günler-haftalar | Mevcut kod |
| Bakım yükü (FTE) | ~0.5-1 kişi | ~0.3-0.5 kişi | Dağıtık |
| Çok dil desteği | Tam | Tam | Dil başına ayrı |
| mTLS otomasyonu | Var | Var | Manuel |
Sidecar modelinde her servis çağrısı istemci ve sunucu tarafında ikişer proxy hop’undan geçer; bu da uçtan uca gecikmeye 1-3 ms ekleyebilir. Yüksek frekanslı, düşük gecikme gerektiren iş yüklerinde bu fark kritik olur. eBPF tabanlı Cilium veya Istio ambient mode bu hop sayısını azaltarak avantaj sağlar.
Operasyonel yük, çoğu ekibin hafife aldığı en büyük gizli maliyettir. Sidecar tabanlı bir mesh, sürüm yükseltmeleri, sertifika yönetimi, gözlemlenebilirlik altyapısı ve hata ayıklama için ciddi bir mühendislik zamanı talep eder. Aşağıdaki tablo, mesh benimseme kararında sıkça göz ardı edilen operasyonel boyutları kıyaslar:
| Operasyonel boyut | Sidecar mesh | Sidecarsız mesh | Mesh yok |
|---|---|---|---|
| Sürüm yükseltme riski | Yüksek (her pod etkilenir) | Orta (node düzeyi) | Düşük |
| Hata ayıklama karmaşıklığı | Yüksek (ek hop) | Orta | Düşük |
| Gözlemlenebilirlik kazancı | Yüksek (otomatik) | Yüksek | Manuel |
| Sertifika yönetimi | Otomatik (mesh) | Otomatik | Elle/cert-manager |
| Ekip eğitim ihtiyacı | Yüksek | Orta | Düşük |
| Geri dönüş kolaylığı | Zor | Orta | Kolay |
Karar Çerçevesi: Hangi Durumda Hangisi?
Doğru kararı vermek için ekibinizin durumunu net kriterlere oturtun. Aşağıdaki tablo karar matrisini özetler:
| Durum | Önerilen yaklaşım | Gerekçe |
|---|---|---|
| 5-15 servis, tek ekip | Mesh yok + Gateway API | Operasyonel yük değmez |
| 15-40 servis, mTLS şart | Linkerd | Hafif, hızlı kurulum |
| 40+ servis, gelişmiş trafik | Istio (ambient) | Geniş özellik, düşük yük |
| Güçlü ağ politikası ihtiyacı | Cilium | eBPF, L3/L4 üstünlüğü |
| Hibrit (VM + K8s) | Consul | Çoklu çalışma zamanı |
Genel kural: En basit çözümden başlayın. Önce Gateway API ve uygulama düzeyi dayanıklılık kütüphaneleriyle yola çıkın; gerçek bir gözlemlenebilirlik veya güvenlik sancısı oluştuğunda Linkerd ile mesh’e geçin. Istio’nun tüm gücüne ancak ölçek ve karmaşıklık bunu zorunlu kıldığında yatırım yapın.
Karar çerçevesini uygularken sıfır güven (zero trust) gereksinimlerinizi ayrı bir eksen olarak değerlendirin. Regülasyona tabi sektörlerde (finans, sağlık) servisler arası mTLS bir tercih değil zorunluluk olabilir; bu durumda servis sayısı düşük olsa bile Linkerd gibi hafif bir mesh, manuel TLS yönetiminin getirdiği riski ortadan kaldırarak değer üretir. Güvenlik mimarinizi planlarken bunu sıfır güven mimarisi hedeflerinizle birlikte ele alın.
Tipik Sorunlar ve Çözümleri
Service mesh benimseyen ekiplerin sahada en sık karşılaştığı sorunlar genellikle yanlış kapsam belirleme ve gözlem eksikliğinden kaynaklanır. Aşağıdaki maddeler en kritik tuzakları ve pratik çözümlerini özetler:
- Aşırı mühendislik: 10 servisli ekip Istio kurar ve aylarca konfigürasyonla boğuşur. Çözüm: önce Linkerd veya Gateway API ile başla, ihtiyaç kanıtlandığında ölçekle.
- Sidecar kaynak şişmesi: Yüzlerce pod’da Envoy belleği bütçeyi patlatır. Çözüm: ambient mode veya eBPF tabanlı Cilium’a geç.
- mTLS sertifika sorunları: Yanlış yapılandırılmış kök sertifika trafiği keser. Çözüm: cert-manager ile entegrasyon ve otomatik rotasyon doğrulaması.
- Gecikme regresyonu: Ek proxy hop’ları kuyrukta gecikmeyi artırır. Çözüm: yük testiyle p99 gecikmeyi mesh öncesi/sonrası ölç, gerekirse kritik yolu mesh dışında tut.
- Yükseltme kırılganlığı: Kontrol düzlemi sürüm atlamaları uyumsuzluk yaratır. Çözüm: kademeli (canary) kontrol düzlemi yükseltmesi ve staging doğrulaması.
- Gözlemlenebilirlik gürültüsü: Her span toplanırsa depolama maliyeti uçar. Çözüm: akıllı örnekleme (sampling) oranı ayarla.
Sonuç
Service mesh 2026’da bir “olmazsa olmaz” değil, ölçeğe ve gereksinimlere bağlı bir araçtır. CNCF verileri benimsemenin yaygınlaştığını gösterse de, gerçek değer ancak servis sayısı, çok dillilik ve sıfır güven gereksinimleri belirli bir eşiği aştığında ortaya çıkar. Küçük ve orta ekipler için Gateway API ve dayanıklılık kütüphaneleri çoğu zaman yeterlidir; mTLS ve gözlemlenebilirlik şart olduğunda Linkerd hafif ve hızlı bir giriş sunar; büyük ölçek ve gelişmiş trafik yönetimi gerektiğinde Istio ambient mode veya Cilium öne çıkar. Doğru strateji, en basit çözümden başlayıp ihtiyaç kanıtlandıkça katman eklemektir.
Sıkça Sorulan Sorular
Service mesh küçük ekipler için gerçekten gerekli mi?
Hayır. 5-15 servisli, tek ekibin yönettiği sistemlerde service mesh çoğunlukla gereksiz operasyonel yük getirir. Kubernetes Gateway API ve uygulama düzeyi dayanıklılık kütüphaneleri aynı değerin büyük kısmını daha düşük maliyetle sunar. Mesh yatırımı genellikle 20+ servis ve bağımsız deploy yapan birden çok ekip olduğunda kendini amorti eder.
Istio mu Linkerd mi seçmeliyim?
Hafiflik, hızlı kurulum ve düşük öğrenme eğrisi önceliğinizse Linkerd’i seçin; Rust proxy’si pod başına yaklaşık 10-20 MB bellekle çalışır. Çok geniş trafik yönetimi, gelişmiş politika ve geniş ekosistem gerekiyorsa Istio’yu, özellikle kaynak tasarrufu için ambient mode ile seçin.
eBPF tabanlı Cilium sidecar’ı tamamen ortadan kaldırır mı?
Cilium, L3/L4 işlevlerini eBPF ile çekirdek düzeyinde gerçekleştirerek sidecar yükünün büyük kısmını ortadan kaldırır. Katman 7 (HTTP düzeyi) işlevler için hâlâ bir proxy bileşeni devreye girebilir; ancak genel kaynak tüketimi sidecar mimarisine göre belirgin biçimde düşüktür.
Service mesh ne kadar gecikme ekler?
Sidecar mimarisinde her servis çağrısı istemci ve sunucu proxy’lerinden geçtiği için uçtan uca gecikmeye tipik olarak 1-3 ms eklenir. eBPF veya ambient mode mimarileri hop sayısını azaltarak bu katkıyı 1 ms altına çekebilir. Yüksek frekanslı iş yüklerinde bu farkı yük testiyle ölçmek gerekir.
mTLS için mutlaka service mesh şart mı?
Hayır, ancak mesh bunu çok kolaylaştırır. Onlarca servis için manuel TLS sertifika yönetimi ve rotasyonu sürdürülemez hale gelir. Linkerd ve Istio mTLS’i otomatik açar ve sertifikaları otomatik rotasyona sokar; bu da sıfır güven mimarisi hedefleyen ekipler için en güçlü gerekçedir.
Ömer ÖNAL
Haziran 9, 2026Sahada en sık gördüğüm hata, 10 servisli ekibin Istio’yu prestij için kurması. Önce gerçek bir sancınız olsun: mTLS zorunluluğu mu, dağıtık tracing eksikliği mi? Sancı netleşince Linkerd ile başlayın, dakikalar içinde ayağa kalkar. Istio’nun tüm gücüne ancak servis sayısı 40’ı aşıp birden çok ekip bağımsız deploy yaptığında geçin. Mesh bir hedef değil, ölçeğin getirdiği bir araçtır.