Istio Service Mesh: Pratikte Ne İşe Yarar, Ne Yaramaz

Istio, Kubernetes dünyasındaki en çok tartışılan araçlardan biri. Bazıları "hayat kurtarır" diyor, bazıları "overkill, operasyon yükü" diyor. Ben bir yıldır üretimde kullanıyorum. Gerçekten değer yaratan kısımları, "satılan ama kullanmadığımız" kısımları ayırmaya çalışacağım.

Ne için kurduk

2023 Kubernetes migrationında Istio'yu birincil service mesh olarak seçtik. Ana sebepler:

• Servisler arası mTLS — güvenlik ekibinin talebi. Plaintext trafik olmamalı.
• Canary deploy / traffic shifting — yeni sürümü %5 trafikle başlatabilmek
• Observability tek yerde — her servise Prometheus/Jaeger entegrasyonu yazmamak
• Rate limiting ve circuit breaking — servisler arası koruma

Bu 4 kazanım somut. Alternatif olarak bunları her servise ayrı ayrı eklemek mümkün ama maliyetli — her yeni servis için aynı boilerplate.

Gerçekten kullandıklarımız

1. mTLS (mutual TLS)

Istio'nun PeerAuthentication ve DestinationRule kaynaklarıyla tüm servisler arası trafik artık TLS encrypted. Hiçbir servis yaptığı her çağrıyı manuel SSL kurmak zorunda değil. Bu, tek başına Istio'yu haklı çıkaran özelliklerden.

Güvenlik ekibi mutlu, compliance mutlu, devlopers "farkında bile değiliz" mutlu.

2. Traffic splitting

VirtualService yapılandırmasıyla "yeni sürüme %5 trafik" demek bir YAML değişikliği. Bir önceki kurulumda (eski reverse proxy katmanı) bu günler sürerdi, Istio'yla 30 saniye.

Özellikle multiplayer oyun sunucusu gibi "regression olursa oyuncular doğrudan kaybeder" bir alanda canary deploy çok değerli.

3. Resilience politikaları

Her upstream servise DestinationRule ile connection pool, circuit breaker, outlier detection tanımlıyoruz. Örnek:

outlierDetection:
  consecutive5xxErrors: 5
  interval: 30s
  baseEjectionTime: 60s

Bu, bir servisin instance'ları arasından 30 saniye içinde 5 kere 5xx dönen bir instance 60 saniye karantinaya alınır demek. Uygulamamızda bir sürü "bir pod kötü davranıyor, neden?" tipi incident'ı bitirdi.

4. Tracing

Istio sidecar'ları otomatik olarak span ekliyor. Jaeger'a bakınca bir isteğin hangi servislerden geçtiğini görmek artık her ekipteki herkes için bir tık ötesinde.

Bu özellik, özellikle incident sırasında "bu latency nereden geliyor" sorusunun cevabını 30 dakikadan 2 dakikaya indirdi.

Kullanmadığımız / uzak durduğumuz kısımlar

1. Authorization policies (karmaşık RBAC)

Istio'nun AuthorizationPolicy'si çok zengin — "bu servis sadece şu namespace'ten gelen şu JWT'li requestlere cevap verir" gibi şeyler yazılabilir. Ama biz application layer'da zaten auth yapıyoruz, iki yerde auth mantığı iki kat hata demek.

Rule: auth app'te, network izolasyonu Istio'da. Ayrı katmanlar.

2. Weighted Distribution'ın aşırı kullanımı

Istio traffic splitting'i çok kolay olduğu için bir cazibe oluşuyor: "A/B test, C/D test, her şeyi Istio'da yönet." Dirençlendik. Uygulama mantığındaki A/B testleri uygulama katmanında yapılıyor (feature flag servisimizle). Istio sadece deployment-level traffic shifting için.

Sebep: uygulama mantığı Istio'ya girerse, Istio bir uygulama bileşeni olur ve platform ekibi her kod değişikliğinde platform çalışması yapmak zorunda kalır.

3. Ingress Gateway yerine Traefik

Istio kendi ingress gateway'ini sunuyor ama biz Traefik kullanıyoruz. Sebep: magicdigital.org ve diğer dış siteler de aynı Traefik'te duruyor. Operasyonel olarak "bir ingress katmanı" tek yerde olmak basit.

Operasyonel fiyat

Istio ücretsiz ama bedava değil.

• Control plane (istiod) — her namespace'in sidecar'larını yönetir. Orta boy cluster'da 1-2 GB RAM + 1 CPU çekiyor.
• Sidecar'lar — her pod'a bir Envoy proxy ekleniyor. Bu, pod başına ~50-100 MB RAM ek yük.
• Learning curve — VirtualService, DestinationRule, Gateway, PeerAuthentication, AuthorizationPolicy... Yeni ekip üyelerinin ilk haftası genelde Istio dökümantasyonu okuyarak geçiyor.
• Debugging karmaşıklığı — bir istek patladığında sidecar config'i doğru mu, trafik splittin yanlış mı yaptı, ona bakmak zorundasın.

Bu fiyatı ödemeye değer mi? Bizde evet — 30+ microservice var, gerçekten gerekli. Ama 5-10 servisi olan bir platformda tereddüt ederdim. Istio'nun mantığı büyük ölçekte doğru çalışır.

Ne zaman Istio, ne zaman kaçın

Istio kullan eğer:

• 15+ microservice var
• Güvenlik ekibi mTLS zorluyor
• Canary deploy'a ihtiyaç var
• Birden fazla ekip var ve standart observability istiyorsun

Istio kaçın eğer:

• Monolith ya da birkaç servisle çalışıyorsun
• Platform ekibi yok, her şeyi uygulama geliştiricileri yönetiyor
• Öğrenme süresine ayıracak 2 hafta yok
• Sidecar RAM maliyetine bütçe yok

Sonuç

Istio bize gerçek değer katıyor — ama tüm özellikleri değil. "Satış demo'suna kanmadık, kullandığımızı kullanıyoruz, uzak durduğumuzdan uzak duruyoruz." Bu disipline uyarsanız Istio üretimde huzurlu bir araç. Uymazsanız cezası büyük.

Her araç gibi, Istio da bir trade-off. Ne aldığınızı, ne ödediğinizi net bildiğinizde doğru karar kolay çıkıyor.