1. GİRİŞ

Mikroservis mimarisi uygulamaları küçük, bağımsız servislere ayırarak geliştirme ve dağıtım hızını artırır. Ancak servis sayısı onlardan yüzlere, binlere çıktığında servisler arası iletişim, güvenlik, gözlemlenebilirlik ve trafik yönetimi ciddi operasyonel sorunlara dönüşür. Service mesh, bu sorunları uygulama kodundan bağımsız bir altyapı katmanıyla çözen mimari bir yaklaşımdır. Servisler arası tüm ağ trafiğini şeffaf biçimde yakalar, yönetir, güvenlik altına alır ve izlenebilir kılar.

Neden bugün konuşuluyor?

• Mikroservis ve konteyner kullanımı artıkça servisler arası iletişim karmaşıklığı katlanarak büyüyor.
• Zero‑trust güvenlik modeli, her servis çağrısında kimlik doğrulama ve şifreleme gerektiriyor; service mesh bu gereksinimi altyapı düzeyinde karşılıyor.
• Gözlemlenebilirlik talebi artıyor; servisler arası latency, hata oranı ve trafik dağılımını anlamak için uçtan uca telemetry gerekiyor.

Kimler için önemli?

• Platform mühendisleri ve SRE ekipleri
• Backend geliştiriciler — servisler arası güvenlik ve retry mantığını koddan çıkarmak isteyenler
• Güvenlik ekipleri — mTLS ve policy enforcement sorumluları

Hangi problemleri çözüyor?

• Servisler arası güvenli iletişim (mTLS, authorization policy)
• Trafik yönetimi: canary, blue‑green, traffic splitting, circuit breaker, retry, timeout
• Uçtan uca observability: her servis çağrısı için metrik, log ve trace üretimi
• Uygulama kodundan ağ kaygılarını soyutlama — geliştirici deneyimi iyileştirmesi

2. KAVRAMSAL TEMELLER

2.1 Service mesh nedir?

Service mesh, mikroservisler arasındaki ağ iletişimini yöneten, güvenlik altına alan ve izleyen özel bir altyapı katmanıdır. Genellikle her servisin yanına yerleştirilen bir sidecar proxy aracılığıyla çalışır. Uygulama kodu değiştirilmeden trafik kontrolü, güvenlik ve telemetry sağlanır.

2.2 Temel bileşenler

• Data plane: Sidecar proxy'ler (genelde Envoy) aracılığıyla servisler arası trafiği yakalayan ve ileten katman.
• Control plane: Proxy'leri yapılandıran, sertifika dağıtan ve politika uygulayan merkezi yönetim bileşeni (Istio'da istiod, Linkerd'de destination/identity controller).
• Sidecar proxy: Her pod'un yanında çalışan, gelen ve giden tüm trafiği şeffaf biçimde yakalayan proxy (Envoy, linkerd2‑proxy).
• mTLS (mutual TLS): İki servis arasında karşılıklı kimlik doğrulama ve şifreleme sağlayan mekanizma.

2.3 Terminoloji

• Traffic splitting: Trafiğin belirli yüzdelerle farklı servis sürümlerine yönlendirilmesi (canary, A/B).
• Circuit breaker: Hatalı downstream servise yapılan çağrıları keserek cascading failure'ı önleyen mekanizma.
• Retry / timeout: Başarısız isteklerin otomatik tekrarı ve zaman aşımı yönetimi.
• Authorization policy: Hangi servisin hangi servise erişebileceğini belirleyen kural seti.
• Ingress / egress gateway: Mesh'e giren ve mesh'ten çıkan trafiği yöneten özel proxy'ler.

2.4 Sidecar vs sidecar‑less (ambient) modeller

Geleneksel service mesh'ler her pod'a bir sidecar proxy ekler. Bu, kaynak tüketimi ve latency overhead'i getirir. Yeni nesil yaklaşımlar (Istio Ambient Mesh gibi) sidecar olmadan, node‑level proxy veya ztunnel ile L4 güvenlik sağlayıp isteğe bağlı L7 proxy (waypoint proxy) ekleme seçeneği sunar. Bu model kaynak verimliliği ve operasyonel basitlik açısından önemli bir evrimdir.

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

3.1 Data plane: sidecar proxy akışı

Sidecar proxy modeli şu şekilde çalışır: Kubernetes'te bir pod oluşturulduğunda, mutating webhook aracılığıyla pod'a otomatik olarak bir sidecar container (Envoy veya linkerd2‑proxy) enjekte edilir. Pod'un iptables kuralları, tüm gelen ve giden trafiği bu proxy üzerinden geçirecek şekilde yapılandırılır. Böylece uygulama kodu hiçbir değişiklik olmadan mesh'in trafik yönetimi, güvenlik ve telemetry özelliklerinden faydalanır.

Proxy, gelen her isteği alır; control plane'den aldığı konfigürasyona göre hedefe yönlendirir, retry/timeout uygular, mTLS ile şifreler ve metrik/trace verisi üretir. Aynı şekilde, hedef pod'daki sidecar proxy gelen trafiği alır, TLS sonlandırır ve isteği uygulama container'ına iletir.

3.2 Control plane: merkezi yönetim

Control plane, data plane proxy'lerine konfigürasyon ve sertifika dağıtır. Istio'da istiod bileşeni pilot (trafik kuralları), citadel (sertifika yönetimi) ve galley (konfigürasyon doğrulama) işlevlerini tek bir binary'de birleştirir. Linkerd'de ise destination controller (service discovery, trafik politikaları) ve identity controller (mTLS sertifikaları) bu işlevi yerine getirir. Control plane, kullanıcının tanımladığı VirtualService, DestinationRule, AuthorizationPolicy gibi CRD'leri okuyup proxy konfigürasyonlarına çevirir.

3.3 mTLS ve kimlik yönetimi

Service mesh'te her servisin bir SPIFFE kimliği (workload identity) vardır. Control plane her proxy'ye kısa ömürlü X.509 sertifikası verir; proxy'ler bu sertifikalarla karşılıklı TLS handshake yapar. Böylece her servis çağrısında hem istemci hem sunucu kimliği doğrulanır ve trafik şifrelenir. Sertifika rotasyonu otomatiktir; uygulama kodunda herhangi bir TLS yönetimi gerekmez.

3.4 Trafik yönetimi ve resilience

Service mesh, trafik yönetimi için zengin bir kural seti sunar:

• Traffic splitting: Trafiğin %90'ı v1'e, %10'u v2'ye — canary deploy.
• Header‑based routing: Belirli header'lara göre farklı sürümlere yönlendirme.
• Circuit breaker: Consecutive 5xx hata sayısı aşıldığında downstream'e istek göndermeyi durdurma.
• Retry ve timeout: Başarısız istekleri belirli koşullarda tekrarlama; maksimum bekleme süresi belirleme.
• Rate limiting: Servis başına veya endpoint başına istek sınırı uygulama.

3.5 Observability: metrik, log ve trace

Her sidecar proxy otomatik olarak request latency, error rate, request count gibi RED (Rate, Errors, Duration) metrikleri üretir. Bunlar Prometheus ile scrape edilip Grafana'da görselleştirilebilir. Ayrıca trace context propagation ile distributed tracing (Jaeger/Zipkin/Tempo) entegrasyonu sağlanır. Bu sayede uygulama koduna ek instrumentation eklemeden servisler arası çağrı zinciri izlenebilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix ve büyük ölçekli traffic management

Netflix ölçeğinde yüzlerce mikroservis arasında trafik yönetimi, canary deployment ve circuit breaker kritik önemdedir. Service mesh benzeri altyapılar (veya mesh'in sağladığı yeteneklerin custom implementasyonları) sayesinde her yeni sürüm küçük bir trafik dilimiyle test edilir; hata oranı yükselirse otomatik rollback tetiklenir.

4.2 Uber ve multi‑cluster mesh

Uber gibi global ölçekli platformlar, birden fazla cluster ve region arasında tutarlı servis iletişimi, mTLS ve observability için service mesh kullanır. Multi‑cluster mesh federation sayesinde farklı bölgelerdeki servisler birbirleriyle güvenli ve şeffaf biçimde iletişim kurabilir.

4.3 Amazon / AWS — App Mesh

AWS App Mesh, Envoy tabanlı managed service mesh çözümüdür. ECS, EKS ve EC2 üzerinde çalışan servisler için trafik yönetimi ve observability sağlar. Managed çözümler operational overhead'i azaltır ancak özelleştirme ve esneklik sınırlı olabilir.

4.4 OpenAI ve model serving

AI inference platformlarında service mesh, model versiyonları arasında traffic splitting (A/B test), retry politikaları ve GPU servislerine yönelik rate limiting uygulamak için kullanılabilir. mTLS ile model endpoint'lerine yetkisiz erişim engellenir.

4.5 Stripe ve fintech güvenlik

Finansal uygulamalarda service mesh, PCI DSS ve SOC2 uyumluluk gereksinimlerini karşılamak için mTLS, authorization policy ve audit trail sağlar. Her servis çağrısının şifreli ve yetkilendirilmiş olması regülasyon açısından zorunludur.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Uygulama kodundan bağımsız güvenlik: mTLS ve authorization politikaları altyapı düzeyinde uygulanır.
• Zengin trafik yönetimi: canary, blue‑green, circuit breaker, retry — kod değişikliği olmadan.
• Otomatik observability: RED metrikleri ve distributed tracing ek instrumentation gerektirmeden.
• Tutarlı politika uygulaması: tüm servisler aynı güvenlik ve trafik kurallarına tabi olur.

Sınırlamalar

• Kaynak tüketimi: her pod'a eklenen sidecar proxy CPU ve memory overhead'i getirir.
• Latency: her istek iki ek proxy hop'u (istemci sidecar → sunucu sidecar) üzerinden geçer; bu p99 latency'ye birkaç milisaniye ekleyebilir.
• Operasyonel karmaşıklık: control plane yönetimi, sürüm yükseltmeleri, CRD yönetimi ve debug zorluğu.
• Öğrenme eğrisi: Envoy, Istio veya Linkerd konfigürasyonları derin teknik bilgi gerektirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

6.1 Service mesh çözümleri

6.2 Service mesh vs alternatif yaklaşımlar

7. EN İYİ PRATİKLER

Production kullanımı

• Service mesh'i tüm cluster'a aynı anda değil, namespace bazlı kademeli rollout ile devreye alın.
• Canary metrikleriyle mesh davranışını doğrulayın; latency ve error rate artışı izleyin.
• Control plane'i HA modda çalıştırın; istiod veya Linkerd controller'ları en az iki replica ile deploy edin.
• Sidecar injection'ı namespace label'ı ile kontrol edin; kritik sistem namespace'lerini (kube‑system) mesh dışında tutun.

Performans optimizasyonu

• Sidecar proxy kaynak limitleri (CPU/memory) dikkatle ayarlayın; varsayılanlar genelde fazla büyüktür.
• Gereksiz telemetry'yi kapatın veya sampling oranını düşürün; her endpoint için full tracing maliyetli olabilir.
• Ambient mesh veya eBPF tabanlı çözümleri değerlendirin; sidecar overhead'ini azaltabilirler.

Güvenlik

• STRICT mTLS modunu etkinleştirin; PERMISSIVE mod sadece geçiş döneminde kullanılmalıdır.
• Authorization policy'leri default‑deny prensibiyle tasarlayın; yalnızca gerekli servis iletişimlerine izin verin.
• Sertifika rotasyon sürelerini kısaltın; varsayılan 24 saat yerine daha kısa ömürler düşünün.
• Egress trafiği kontrol edin; mesh dışına çıkan trafiği egress gateway üzerinden yönetin ve loglamayı açın.

Ölçeklenebilirlik

• Büyük cluster'larda control plane'in scale davranışını izleyin; istiod memory tüketimi servis sayısıyla artar.
• Multi‑cluster senaryolarda federation veya shared control plane stratejilerini değerlendirin.
• Envoy konfigürasyon boyutunu küçültün: kullanılmayan listener, cluster ve route tanımlarını temizleyin.

8. SIK YAPILAN HATALAR

• mTLS'i PERMISSIVE modda bırakmak — güvenlik sağlanmış gibi görünür ama plaintext trafiğe izin verir.
• Tüm servislere aynı anda mesh enjekte etmek — kademeli geçiş yerine büyük patlama riski.
• Sidecar kaynak limitlerini ayarlamamak — gereksiz kaynak tüketimi veya proxy OOM crash'leri.
• Observability verilerini kullanmamak — mesh kurulur ama üretilen metrik/trace verisi analiz edilmez.
• Control plane upgrade'lerini test etmeden prod'a uygulamak — sürüm uyumsuzlukları ve konfigürasyon kayıpları.
• Authorization policy olmadan mesh çalıştırmak — mTLS tek başına yeterli değil, servis erişim kontrolü de gerekir.

9. GELECEK TRENDLER

1. Sidecar‑less (ambient) mesh: Istio Ambient Mesh ve Cilium gibi çözümlerle sidecar overhead'i kaldırılarak kaynak verimliliği artacak; ztunnel + waypoint proxy modeli yaygınlaşacak.
2. eBPF tabanlı data plane: Kernel seviyesinde network işleme ile daha düşük latency ve kaynak tüketimi sağlanacak.
3. Gateway API standardizasyonu: Kubernetes Gateway API, ingress ve mesh trafik yönetimini birleştiren standart bir arayüz olacak; VirtualService/DestinationRule gibi vendor‑specific CRD'lerin yerini alacak.
4. AI destekli trafik optimizasyonu: Telemetry verilerinden öğrenen modeller, otomatik canary kararları, timeout tuning ve anomali tespiti yapacak.
5. Multi‑cluster ve multi‑cloud mesh: Farklı cloud provider'lar ve on‑premise ortamlar arasında tutarlı mesh yönetimi olgunlaşacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Service mesh ne zaman gereklidir?

   Servis sayınız artıp servisler arası güvenlik, trafik yönetimi ve observability ihtiyacı uygulama kodunda yönetilemez hale geldiğinde service mesh değerlendirilebilir. Birkaç servislik basit mimari için genelde gerekli değildir.

2. 2. Istio mu yoksa Linkerd mi tercih etmeliyim?

   Istio daha zengin özellik seti sunar (egress gateway, advanced traffic management, WASM extension); Linkerd daha hafif ve basit kurulumludur. Karmaşık trafik kuralları ve geniş ekosistem ihtiyacı varsa Istio; basitlik ve düşük overhead öncelikse Linkerd tercih edilebilir.

3. 3. Service mesh latency'ye ne kadar etki eder?

   Her istek iki sidecar proxy'den geçer; bu genelde 1‑5 ms arası ek latency demektir. Ambient mesh veya eBPF çözümleri bu overhead'i azaltabilir.

4. 4. mTLS tek başına yeterli mi?

   mTLS şifreleme ve kimlik doğrulama sağlar, ancak yetkilendirme (authorization) sağlamaz. Hangi servisin hangi servise erişebileceğini belirlemek için authorization policy'ler gereklidir.

5. 5. Sidecar proxy ne kadar kaynak tüketir?

   Varsayılan konfigürasyonda Envoy sidecar genelde 50‑100 MB memory ve düşük CPU kullanır; ancak yüksek trafikte bu artabilir. Kaynak limitlerini uygulama profilinize göre ayarlayın.

6. 6. Ambient mesh nedir ve ne zaman kullanmalıyım?

   Ambient mesh, sidecar proxy olmadan node‑level ztunnel ile L4 güvenlik sağlayan bir modeldir. L7 özellikler gerektiğinde isteğe bağlı waypoint proxy eklenir. Kaynak verimliliği ve basitlik istiyorsanız değerlendirmeye değer.

7. 7. Service mesh olmadan zero‑trust uygulanabilir mi?

   Evet, ancak her serviste TLS, sertifika yönetimi ve authorization mantığını uygulama kodunda veya library'lerle yönetmeniz gerekir. Service mesh bu sorumlulukları altyapıya taşıyarak tutarlılık sağlar.

8. 8. Multi‑cluster mesh nasıl çalışır?

   Farklı cluster'lardaki control plane'ler federation veya shared control plane modeli ile birbirine bağlanır. Servisler cluster sınırları ötesinde keşfedilebilir ve mTLS korunur. Ancak network connectivity ve latency planlama gerektirir.

Anahtar Kavramlar

Service Mesh

Mikroservisler arası ağ iletişimini yöneten, güvenlik altına alan ve izleyen altyapı katmanı.

Sidecar Proxy

Her pod'un yanında çalışan, tüm gelen/giden trafiği yakalayan proxy (Envoy, linkerd2‑proxy).

Data Plane

Sidecar proxy'lerden oluşan, gerçek trafiği taşıyan katman.

Control Plane

Proxy'leri yapılandıran, sertifika ve politika dağıtan merkezi yönetim bileşeni.

mTLS

Karşılıklı TLS; hem istemci hem sunucu kimliğini doğrulayan ve trafiği şifreleyen mekanizma.

Ambient Mesh

Sidecar olmadan, node‑level proxy ile L4 güvenlik sağlayan yeni nesil service mesh modeli.

Öğrenme Yol Haritası

1. 0–1 ay: Service mesh kavramlarını, sidecar proxy modelini ve mTLS temellerini öğrenin. Kubernetes networking (Services, DNS, NetworkPolicy) bilgisini pekiştirin.
2. 1–3 ay: Istio veya Linkerd'i dev ortamda kurun; basit trafik kuralları (canary, retry, timeout) ve mTLS STRICT modunu deneyin. Kiali, Grafana ve Jaeger ile observability'yi keşfedin.
3. 3–6 ay: Authorization policy'ler, egress gateway, multi‑namespace mesh yönetimi ve sidecar kaynak tuning üzerinde çalışın. Canary deploy stratejilerini CI/CD pipeline ile entegre edin.
4. 6–12 ay: Multi‑cluster mesh, ambient mesh, eBPF tabanlı çözümler (Cilium) ve Gateway API standardı üzerinde deneyim kazanın. Production‑grade observability ve security audit süreçlerini kurun.