Hizmet keşfi, yük dengeleme ve konfigürasyon yönetiminin hangi bölümü uygulamaya, hangi bölümü platforma ait olmalıdır?

Spring Cloud, Eureka ve Consul gibi çözümler bu sorumlulukları uygulama seviyesine yaklaştırır. Kubernetes DNS ve Kubernetes Service temel ağ yeteneklerini altyapı seviyesinde sunar. Istio gibi Service Mesh ürünleri ise merkezi trafik politikaları, gözlemlenebilirlik ve servisler arası güvenlik katmanı ekler.

Doğru seçim yalnızca servis sayısına bağlı değildir. Ekip sayısı, kullanılan programlama dilleri, dağıtım ortamı, güvenlik gereksinimleri ve organizasyonun platform işletme kapasitesi birlikte değerlendirilmelidir.

Kısa cevap: Hangi sorumluluk kime verilmeli?

Kubernetes üzerinde çalışan yeni sistemler için genel mimari öneri şöyledir:

• Hizmet keşfi: Kubernetes Service ve DNS
• Temel yük dengeleme: Kubernetes ağ katmanı
• Gelişmiş L7 trafik politikaları: İhtiyaç varsa Istio
• İş anlamı taşıyan retry, fallback ve idempotency: Uygulama
• Dağıtım konfigürasyonu: ConfigMap ve GitOps
• Dinamik uygulama konfigürasyonu: Gerekiyorsa Spring Cloud Config veya Consul
• Hassas bilgiler: KMS veya harici secret manager

Kubernetes dışında çalışan veya VM, container ve farklı veri merkezlerini birlikte kullanan hibrit sistemlerde Consul güçlü bir alternatiftir. Tamamen Java tabanlı daha küçük yapılarda Eureka da yeterli olabilir.

Aynı sorumluluğu hem Spring Cloud hem Kubernetes tarafında kalıcı olarak çözmek ise genellikle gereksiz karmaşıklık yaratır.

Service Discovery nedir?

Service discovery, bir servisin iletişim kuracağı diğer servislerin güncel ağ adreslerini bulmasını sağlar.

Mikroservis instance’ları ölçekleme, yeniden başlatma veya hata nedeniyle sürekli değişebilir. Bu nedenle uygulamaların sabit IP adreslerine bağlanması sürdürülebilir değildir. Bir servis kataloğu veya kararlı platform adresi gerekir.

Spring Cloud Eureka ile hizmet keşfi

Eureka modelinde uygulamalar açılırken kendilerini merkezi registry’ye kaydeder ve düzenli heartbeat gönderir. İstemciler, çağırmak istedikleri servisin instance listesini Eureka’dan alır.

Güncel Spring Cloud mimarisinde Eureka hizmet keşfini sağlarken istemci tarafı yük dengeleme Spring Cloud LoadBalancer tarafından gerçekleştirilir. Varsayılan seçim round-robin’dir; farklı seçim stratejileri de uygulanabilir. Spring Cloud Netflix, Spring Cloud LoadBalancer

Bu yaklaşım özellikle şu koşullarda anlamlıdır:

• Sistem ağırlıklı olarak Spring Boot kullanıyorsa
• Servisler VM veya bare metal üzerinde çalışıyorsa
• Kubernetes’e geçiş henüz tamamlanmadıysa
• Uygulama seviyesinde instance metadata’sına göre seçim gerekiyorsa

Eureka’nın temel dezavantajı, discovery bilgisini uygulama çalışma zamanının bir parçası hâline getirmesidir. Her servis registry istemcisi taşır; kütüphane sürümleri ve cache davranışları sistemin ağ davranışını etkiler.

Consul ile hizmet keşfi

Consul; servis kataloğu, sağlık kontrolleri, HTTP API ve DNS tabanlı keşif sunar. Spring Cloud Consul kullanan uygulamalar HTTP API üzerinden kayıt olabilirken Java dışındaki uygulamalar aynı kataloğa DNS aracılığıyla erişebilir. Spring Cloud Consul

Consul’un Eureka’ya göre en önemli avantajı platform ve dil bağımsızlığıdır. VM, container, Kubernetes ve farklı veri merkezlerinin birlikte bulunduğu yapılarda ortak bir servis kataloğu oluşturabilir.

Bunun karşılığında Consul cluster’ının yüksek erişilebilir biçimde kurulması, izlenmesi, yükseltilmesi ve güvenliğinin sağlanması gerekir.

Kubernetes Service Discovery

Kubernetes’te Pod IP adresleri geçicidir. Uygulamaların bağlandığı kararlı kimlik Service nesnesidir.

CoreDNS, Kubernetes servisleri için DNS kayıtları oluşturur. Kubernetes de bir servise bağlı güncel Pod listesini EndpointSlice nesneleri üzerinden takip eder. Böylece uygulama http://orders gibi kararlı bir servis adına bağlanabilir. Registry SDK’sı, heartbeat veya istemci tarafında instance listesi yönetmesi gerekmez. Kubernetes Service, Kubernetes DNS

Bu modelin başlıca avantajları şunlardır:

• Programlama dilinden bağımsızdır.
• Uygulamayı discovery kodundan arındırır.
• Pod yaşam döngüsü ile endpoint yönetimini aynı kontrol düzlemine bağlar.
• Platform genelinde standart servis adresleme modeli oluşturur.
• Kubernetes kullanılıyorsa ek registry işletme ihtiyacını ortadan kaldırır.

Bu nedenle Kubernetes üzerinde çalışan yeni bir sistemde yalnızca hizmet keşfi için Eureka kurmak çoğunlukla gereksizdir.

Spring Cloud LoadBalancer ve Kubernetes Service farkı

Spring Cloud LoadBalancer ile Kubernetes Service aynı sorunu farklı katmanlarda çözer.

İstemci tarafı yük dengeleme

Spring Cloud LoadBalancer modelinde uygulama:

1. Discovery sisteminden instance listesini alır.
2. Uygun instance’ı seçer.
3. İsteği doğrudan o instance’a gönderir.

Bu model, istemcinin metadata, bölge veya özel iş bağlamına göre hedef seçmesine olanak tanır. Buna karşılık seçim mantığı her uygulamanın içine dağılır.

Altyapı tarafı yük dengeleme

Kubernetes Service modelinde uygulama tek bir servis adresine bağlanır. Trafiğin uygun Pod’a aktarılması kube-proxy veya kullanılan ağ altyapısı tarafından gerçekleştirilir.

Bu yaklaşım uygulamayı sadeleştirir ve farklı dillerde yazılmış servisler arasında standart davranış sağlar. Ancak temel Kubernetes Service; HTTP header’ına göre yönlendirme, yüzdesel canary veya request-level circuit breaking gibi gelişmiş L7 politikaları sunmaz.

Ayrıca uzun süre açık kalan HTTP/2 veya gRPC bağlantıları dikkatle değerlendirilmelidir. DNS ya da endpoint kümesi değişse bile connection pool aynı backend’e trafik göndermeyi sürdürebilir.

Istio trafik yönetimine ne ekler?

Istio, Kubernetes service discovery mekanizmasının yerine geçmez. Kubernetes servis ve endpoint bilgisini kullanır; bunun üzerine programlanabilir bir trafik katmanı ekler.

Istio ile merkezi olarak şu politikalar uygulanabilir:

• Ağırlıklı ve sürüm bazlı yönlendirme
• Canary ve aşamalı dağıtım
• HTTP header veya path bazlı routing
• Timeout ve retry
• Circuit breaking
• Sağlıksız instance’ları havuzdan çıkarma
• Trafik yansıtma
• Servisler arası mTLS
• Kimlik tabanlı erişim politikaları
• Ortak trafik metriği ve erişim kayıtları

Istio’nun trafik modeli Envoy proxy’leri kullanır. Sidecar modelinde her Pod’un yanında bir proxy çalışır. Ambient modelde temel L4 işlevleri node seviyesinde sağlanabilir; L7 özellikleri gerektiğinde waypoint proxy devreye girer. Istio Traffic Management, Istio veri düzlemi modelleri

Istio’nun avantajları

• Farklı dillerdeki servisler için ortak ağ politikası sağlar.
• Trafik davranışı uygulama sürümünden bağımsız değiştirilebilir.
• Canary ve progressive delivery süreçlerini kolaylaştırır.
• mTLS ve servis kimliğini merkezi hâle getirir.
• Gözlemlenebilirlik standardı oluşturur.
• Politika yönetimini platform ekibinde toplar.

Istio’nun maliyetleri

• Yeni bir kontrol ve veri düzlemi işletilir.
• Proxy’ler CPU, bellek ve belirli ölçüde gecikme ekler.
• Hata ayıklama süreci daha karmaşık hâle gelir.
• Yanlış bir merkezi politika çok sayıda servisi etkileyebilir.
• Proxy ve kontrol düzlemi yükseltmeleri dikkatle yönetilmelidir.
• Platform ekibinde Service Mesh uzmanlığı gerekir.

Dolayısıyla Istio, “mikroservis kullanıyoruz” gerekçesiyle kurulacak bir bileşen değildir. Sağladığı merkezi politika değeri, işletme maliyetini geçtiğinde kullanılmalıdır.

Konfigürasyon yönetimi: Spring Cloud Config mi ConfigMap mi?

Konfigürasyon yönetimi, service discovery ve trafik yönetiminden ayrı ele alınmalıdır. Istio uygulamanın iş konfigürasyonunu yönetmez.

Spring Cloud Config

Spring Cloud Config, uygulama ayarlarını merkezi bir servis üzerinden sunar. Git deposu kullanıldığında değişiklik geçmişi, sürümleme ve ortam bazlı konfigürasyon yönetimi elde edilir.

Şu durumlarda güçlüdür:

• Uygulamalar Kubernetes dışında da çalışıyorsa
• Spring profile modeli yoğun kullanılıyorsa
• Uygulama ve ortam bazlı konfigürasyon hiyerarşisi gerekiyorsa
• Konfigürasyonun deployment’tan bağımsız yenilenmesi isteniyorsa

Dezavantajı, Config Server’ın uygulama başlangıcında ek bir bağımlılığa dönüşmesidir. Dinamik refresh sırasında bütün bean’lerin ve bağlantı havuzlarının yeni değerlerle güvenli biçimde çalışacağı da garanti değildir.

Consul Config

Spring Cloud Consul Config, Consul KV üzerinden uygulama ayarlarını yükleyebilir. Config Watch, ilgili değerlerde değişiklik algılandığında Spring refresh olayı oluşturabilir. Spring Cloud Consul Config

Discovery için zaten Consul kullanılan hibrit sistemlerde operasyonel açıdan çekici olabilir. Ancak aynı Consul cluster’ının hem discovery hem konfigürasyon için kullanılması hata alanını büyütür. Consul kesintisinin iki kritik fonksiyonu birden etkilemesi hesaba katılmalıdır.

Kubernetes ConfigMap

Kubernetes ConfigMap, hassas olmayan uygulama ayarlarını container imajından ayırır. Değerler ortam değişkeni veya volume içindeki dosyalar olarak Pod’a aktarılabilir.

Volume olarak bağlanan ConfigMap güncellemeleri zaman içinde Pod’a yansıtılabilir; fakat uygulamanın dosyayı yeniden okuması gerekir. Ortam değişkeni olarak verilen ConfigMap değerleri otomatik güncellenmez ve Pod yeniden başlatılmalıdır. Kubernetes ConfigMap

Birçok üretim sistemi için kontrollü rolling restart, dinamik context refresh’ten daha güvenlidir. Yeni konfigürasyon yeni Pod’larda doğrulanır; readiness kontrolü başarısız olursa rollout durdurulabilir.

Kubernetes Secret yeterli mi?

Kubernetes Secret nesnesi kullanmak tek başına güvenli secret yönetimi anlamına gelmez. Secret verileri varsayılan olarak etcd içinde şifrelenmeden saklanabilir.

Üretim ortamında şu kontroller gerekir:

• Encryption-at-rest
• Sıkı RBAC
• Secret erişim kayıtları
• Düzenli rotasyon
• Tercihen KMS veya harici secret manager entegrasyonu

Kubernetes Secret güvenlik önerileri

Retry ve circuit breaker uygulamada mı mesh’te mi olmalı?

Bu sorumluluk bütünüyle tek bir katmana verilemez.

Mesh şu teknik kararları üstlenebilir:

• Bağlantı kurulamazsa farklı endpoint denemek
• Belirli hata kodlarında sınırlı retry yapmak
• Sağlıksız instance’ı geçici olarak havuzdan çıkarmak
• Ağ seviyesinde timeout standardı uygulamak

Uygulamada kalması gereken kararlar ise şunlardır:

• Bir ödeme isteği güvenle tekrar edilebilir mi?
• İşlem idempotent mi?
• Hangi fallback iş açısından kabul edilebilir?
• Kısmi başarı nasıl yönetilmeli?
• Telafi işlemi gerekiyor mu?

Mesh, bir HTTP isteğinin teknik olarak tekrar edilebilir göründüğünü anlayabilir; fakat tekrarın ikinci kez tahsilat yaratıp yaratmayacağını bilemez.

Ayrıca uygulama ve mesh bağımsız retry yaptığında deneme sayıları çarpılır. Uygulamadaki üç deneme ile mesh’teki üç deneme, tek kullanıcı isteğini dokuz downstream çağrısına dönüştürebilir. Retry bütçesi uçtan uca tasarlanmalıdır.

Proje ölçeğine göre mimari tercih

Servis sayıları kesin sınır değildir. Ekip sayısı, teknoloji çeşitliliği, güvenlik gereksinimi ve dağıtım sıklığı daha belirleyicidir.

Küçük projeler: 1–2 ekip ve yaklaşık 3–10 servis

Kubernetes üzerinde çalışılıyorsa:

• Kubernetes DNS ve Service kullanın.
• ConfigMap ve kontrollü rolling deployment tercih edin.
• Istio kurmayın.
• Timeout, idempotency ve iş fallback’lerini uygulamada yönetin.

Bu ölçekte Service Mesh’in işletme ve öğrenme maliyeti genellikle faydasından büyüktür.

VM veya karma altyapıda çalışılıyorsa:

• Tamamen Java tabanlı sistemlerde Eureka kullanılabilir.
• Birden fazla dil veya çalışma ortamı varsa Consul tercih edilebilir.
• Discovery ihtiyacı tek başına Kubernetes’e geçiş gerekçesi olmamalıdır.

Orta ölçekli projeler: 3–8 ekip ve yaklaşık 10–50 servis

Kubernetes’i varsayılan discovery ve temel load-balancing katmanı yapın. Yeni servislerin ayrıca Eureka’ya kaydolmasını istemeyin.

Istio’yu şu ihtiyaçlar somutlaştığında değerlendirin:

• Takımlar arasındaki retry ve timeout farklılıkları üretim olaylarına yol açıyorsa
• Merkezi canary dağıtımı gerekiyorsa
• Servisler arası mTLS zorunluysa
• Polyglot yapı ortak ağ telemetrisi gerektiriyorsa
• Merkezi erişim politikaları yönetilecekse

Mesh’e geçiş kritik servis veya namespace’lerle kademeli olarak başlatılabilir.

Büyük projeler: 8’den fazla ekip, 50+ servis veya çoklu cluster

Bu ölçekte her uygulama ekibinin aynı ağ politikalarını farklı kütüphanelerle uygulaması sürdürülemez hâle gelebilir.

Önerilen sorumluluk dağılımı:

Mesh’in anlamlı olmasını sağlayan yalnızca servis sayısı değildir. Merkezi güvenlik, çoklu dil desteği, yüksek dağıtım sıklığı ve çapraz takım standardizasyonu operasyon maliyetini karşılayacak düzeye ulaşmalıdır.

Kaçınılması gereken yaklaşım: Çift sahiplik

Geçiş dönemi dışında şu kombinasyonlardan kaçınılmalıdır:

• Eureka ve Kubernetes’in paralel servis kataloğu olması
• Spring Cloud LoadBalancer ile Istio’nun bağımsız hedef seçmesi
• Uygulama, API gateway ve mesh’in ayrı ayrı retry uygulaması
• Timeout değerlerinin farklı katmanlarda çelişmesi
• Aynı ayarın Consul KV ve ConfigMap’te tutulması

Her teknik sorumluluk için tek bir birincil doğruluk kaynağı ve açık bir sahip belirlenmelidir.

Sonuç: Spring Cloud mu Kubernetes mi?

Spring Cloud ve Kubernetes birbirlerinin tam alternatifi değildir.

Spring Cloud uygulamaya discovery ve istemci davranışı kazandırır. Kubernetes temel platform bağlantısını ve servis yaşam döngüsünü yönetir. Istio ise ortak trafik, güvenlik ve gözlemlenebilirlik politikalarını uygulamadan ayırır.

Kubernetes kullanan yeni sistemlerde service discovery ve temel load balancing platforma bırakılmalıdır. Istio yalnızca servis sayısı arttığı için değil, ortak trafik ve güvenlik politikalarının uygulama ekipleri tarafından ayrı ayrı yönetilmesi sürdürülemez hâle geldiğinde eklenmelidir.

Kubernetes dışında veya ciddi hibrit altyapıda Consul güçlü bir seçimdir. Tamamen Java ve VM tabanlı küçük sistemlerde Eureka hâlâ yeterli olabilir. Kubernetes’e yerleşmiş bir platformda Eureka’yı kalıcı biçimde tutmak ise çoğunlukla aynı gerçeği iki kontrol düzleminde yönetmek anlamına gelir.

Sağlıklı sorumluluk ayrımı şöyledir:

• Platform, servisin nerede olduğunu bilir.
• Mesh, trafiğin teknik olarak nasıl akacağını bilir.
• Uygulama, isteğin iş açısından ne anlama geldiğini bilir.
• Konfigürasyon sistemi, uygulamanın hangi değerlerle çalışacağını bilir.

İyi mimari, bu sınırların açık olduğu ve aynı kararın birden fazla katmanda tekrar verilmediği mimaridir.

Sık sorulan sorular

Kubernetes kullanırken Eureka gerekli mi?

Çoğu yeni Kubernetes sistemi için hayır. Kubernetes Service, DNS ve EndpointSlice temel hizmet keşfi ihtiyacını karşılar. Eureka ancak Kubernetes dışındaki servislerle geçiş, özel metadata tabanlı seçim veya güçlü bir mevcut bağımlılık varsa geçici olarak anlamlı olabilir.

Kubernetes Service, Istio’nun yerini tutar mı?

Hayır. Kubernetes Service temel servis adresleme ve L4 yönlendirme sağlar. Istio ise canary, header tabanlı routing, mTLS, retry, circuit breaking ve ayrıntılı trafik gözlemlenebilirliği gibi gelişmiş politikalar ekler.

Küçük bir mikroservis projesinde Istio kullanılmalı mı?

Genellikle hayır. Birkaç servis ve tek ekipten oluşan sistemlerde operasyonel maliyet çoğu zaman kazanımdan yüksektir. Önce Kubernetes’in yerleşik özellikleri ve doğru uygulama timeout’ları kullanılmalıdır.

Consul mu Eureka mı daha uygun?

Tamamen Spring Boot kullanan sınırlı bir sistemde Eureka daha basit olabilir. Birden fazla dil, VM, container, veri merkezi veya hibrit altyapı söz konusuysa Consul daha geniş bir entegrasyon alanı sunar.

Konfigürasyon değişikliği için dinamik refresh mi rolling restart mı?

Çoğu üretim konfigürasyonu için rolling restart daha öngörülebilir ve geri alınabilir bir modeldir. Feature flag gibi anlık değişmesi gereken değerlerde kontrollü dinamik konfigürasyon tercih edilebilir.

Spring Cloud vs. Kubernetes: Service Discovery ve Trafik Yönetimi Kime Emanet Edilmeli? yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.