Kubernetes v1.36: CCM Route Sync Metriği Neyi Ele Veriyor?
Bir sayaç, ama aslında hikâye biraz daha büyük
Kubernetes tarafında bazen minicik görünen bir değişiklik, sahada baya ses çıkarıyor. Bu yeni route_controller_route_sync_total metriği de ilk bakışta “tamam işte bir counter daha” dedirtiyor. Ama işin aslı öyle değil. Bu sayaç, Cloud Controller Manager içindeki route controller’in cloud provider ile ne kadar sık konustugunu gösteriyor ve bu da doğrudan maliyet, API baskısı ve operasyonel gürültü demek.
Benim kafamda bunun karşılığı su: gereksiz yere kapıyı caliyorsaniz, bir süre sonra hem karşı taraf yoruluyor hem sız quota duvarina tosluyorsunuz. Özellikle rate-limited API’lerle çalışan yapılarda bu tarz detaylar ciddi fark yaratıyor. 2024 sonlarında bir müşteride buna benzer bir şeyi tartışmıştık; altyapı ekibi “neden aynı işi sürekli yapıyoruz?” diye soruyordu. Haklılardı.
Bu arada küçük ama önemli bir not: bu yazıdaki yenilik Kubernetes v1.36 ile geliyor ama arkadaki davranış değişimi v1.35’te tanıtılan CloudControllerManagerWatchBasedRoutesReconciliation feature gate ile başlıyor. Yanı yeni metrik tek başına olay değil; asıl mesele reconciliation yaklaşımının değişmesi.
Neden eski yöntem bazen fazla konuşuyor?
Eski modelde route controller belli aralıklarla döngüye giriyor. Node değişsin değişmesin tekrar tekrar sync yapıyor (en azından benim deneyimim böyle). Kağıt üstünde basit görünüyor, hatta bazı ekipler için güven verici bile olabilir; çünkü “döngü dönüyor mu?” sorusunun cevabı net oluyor. Gel gelelim pratikte durum biraz farklılaşıyor: cluster sabitse, node sayısı günlerce aynı kalıyorsa, sız yine de boşuna trafik uretiyorsunuz.
Işte watch-based yaklaşım burada devreye giriyor. Node tarafında gerçek bir değişiklik olunca hareket ediyor. Yanı takvimle değil, olayla çalışıyor. Açık konuşayım, ben bu modeli daha mantıklı buluyorum; çünkü bulut servisleriyle konuşurken “ihtiyaç oldukça konus” prensibi genelde daha temiz sonuç veriyor.
Geçen sene İstanbul’da bir finans müşterisinde buna çok yakın bir gözlem yaptık (kendi tecrübem). Cluster içindeki dugumler çoğunlukla sakın duruyordu ama dışarıya yapılan çağrı sayısı tahmin edilenden yüksekti. Sebep tam olarak böyle periyodik yoklamalardi. O projede ilk gördüğüm şey sunuydu: sistem çalışıyor görünüyordu ama sessizce kredi tuketiyordu…
Metrik size neyi söylüyor?
route_controller_route_sync_total, route sync işlemlerinin toplamini sayıyor. Yanı kontrol duzleminin ne kadar aktif olduğunu kabaca buradan okuyabiliyorsunuz. Mesela feature gate kapalıysa sayaç dakika dakika yükselir; açık ve cluster sakinse artış belirgin şekilde yavaşlar.
İlginç olan şu ki, Burada can alıcı nokta su: tek başına sayı yetmez, egilime bakmak gerekir — itiraf edeyim, beklentimin üstündeydi —. Ben AZ-104. AZ-305 hazırlıkları sırasında hep bunu anlatırım; izleme araçlarında mutlak değer kadar davranış da önemlidir. Bir sayı kötü görünmeyebilir ama trend yanlışsa işler kaymaya baslamistir bile.
A/B test mantığı neden işe yarıyor?
Şimdi, i̇lginç olan şu ki, Bu özellik için A/B test yapmak baya akıllı olmuş. Bir tarafta feature gate kapaliyken klasik davranışı görüyorsunuz, diğer tarafta açıkken watch-based reconciler’in etkisini ölçüyorsunuz. Böylece “bu değişiklik gerçekten işe yaradı mi?” sorusuna varsayımla değil veriyle cevap veriyorsunuz.
Şimdi gelelim işin can alıcı noktasına.
Bir kontrol döngüsünü iyileştirmenin en iyi yolu önce önü olcmekten geçiyor; olcmuyorsaniz sadece tahmin ediyorsunuz.
Sahada bunun karşılığı ne oluyor?
Bence bu metrik en çok üç yerde anlam kazanıyor: maliyet yönetimi, rate-limit baskısı ve operasyonel açıklık. Bulut saglayicisina gereksiz API çağrıları atmayı azaltınca sadece performans kazanmiyorsunuz; bazen faturada da tatlı bir hafifleme oluyor. TL bazında düşününce bu konu özellikle kur dalgalanmaları olan ortamlarda daha da can sıkıcı hâle geliyor.
Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de benimsenme hızı biraz temkinli ilerliyor, çünkü ekipler çoğunlukla “önce stabil olsun” diyorlar — haklılar da aslında. Fakat stabilite ile verimsizlik aynı şey değil. Büyük enterprise yapılarda gözlem tabanlı reconciliation gibi değişiklikler genelde önce pilot cluster’da denenmeli; küçük startup’larda işe direkt prod’a koşmak yerine staging üzerinde kısa ama net bir kiyas yapmak daha doğru olur. Daha fazla bilgi için Model Router Evals: Doğru Modeli Seçtiğini Nasıl Kanıtlarsın? yazımıza bakabilirsiniz. Daha fazla bilgi için .NET 11’de Process API’si Neden Bu Kadar Önemli? yazımıza bakabilirsiniz.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Şahsen, 2025’in sonlarına doğru Ankara’daki bir üretim ortamında yaptığımız incelemede de buna benzer bir tablo çıkmıştı: node hareketliligi düşük olduğu hâlde sync işi sürekli dönüyordu. Orada sorun büyük değildi ama gereksiz gürültü operasyon ekibini yoruyordu. Küçük problem gibi duran şeylerin gece vardiyasinda nasıl büyüdüğünü sanırım herkes bilir… Bu konuyla ilgili NuGet Paketlerini C++ Projelerinde Düzenlemek: PackageReference Dönemi yazımıza da göz atmanızı tavsiye ederim.
| Durum | Feature Gate Kapalı | Feature Gate Açık |
|---|---|---|
| Senkron davranışı | Sabit aralıklarla çalışır | Sadece node degince tetiklenir |
| API çağrı baskısı | Daha yüksek | Daha düşük |
| Düşüş hareketli cluster’larda etki | Zayıf optimizasyon | Baya iyi tasarruf sağlar |
| A/B test okunabilirliği | Sınırlı sinyal | Daha net fark verir |
Bunu nasıl değerlendiririm?
Küçük ekip mi, büyük kurum mu?
Ne yalan söyleyeyim, Küçük ekiplerde amaç genelde hızlı görünürlük olur; o yüzden sayaçlari açıp bırakmak çok zaman yeterli sanıyor. Ama burada dikkat edilmesi gereken şey su:
eğer altyapınız az sayıda node içeriyor ve değişim seyrekse,
watch-based yaklaşım size beklediğinizden fazla rahatlık verebilir. Büyük kurumsal yapılarda işe karar biraz daha katmanlidir;
önce risk analizi yapılır,
sonra kademeli yaygınlaştırma gelir,
en sonunda merkezî gözlemleme panosuna bakılır.
Çok konuştum, örnekle göstereyim.
Maliyet meselesi kucumsenmemeli
Size bir şey söyleyeyim, Bazen insanlar “bir counter yüzünden ne olacak ki?” diyor.
Aslında mesele counter değil;
counter’in anlattığı davranış.
Çok sık sync yapan sistem,
arka planda cloud provider tarafına yük bindirir,
rate limit’e yaklasir,
bazı durumlarda da başka kritik çağrıları geciktirir.
Az önce X dedim ama aslında Y daha doğru olabilir:
asıl kazançlı kısım doğrudan para değil,
operasyonel nefes alanidir. Daha fazla bilgi için Copilot cloud agent ile Kırık Actions İşini Tek Tıkta Çözmek yazımıza bakabilirsiniz.
Ben olsam ilk nereden başlarım?
Lafı gevelemeden söyleyeyim:
ilk is metric’i açıp temel çizgiyi görmek lazım.
Sonra feature gate’i kontrollü biçimde etkinlestirip kiyas alırsınız.
Ben bunu kendi lab ortamımda önce minik kümede denedim;
ardından Logosoft tarafındaki bir Azure danışmanlık işinde,
müşteri trafiğine dokunmadan önceden simülasyon yaptık.
Ilk denemede beklediğim kadar temiz cikmamisti,
çünkü bazı node event’leri düşündüğümüzden sık geliyordu.
Sorunu çözmek için gözlem süresini uzatıp anomali penceresini daralttık.
Evet, biraz uğraştırdı — itiraf edeyim, beklentimin üstündeydi —. ama deydi.
Sahada uygularken nelere dikkat ederim?
- Metrik taban çizgisi alın: Feature gate kapaliyken birkaç saatlik veri toplayın.
- Aynı yük altında test edin: Mümkünse benzer saat dilimi ve trafik paternini kullanın.
- Error loglarını kontrol edin: Sadece sayı düşmüş mu diye bakmayın, yan etkileri de izleyin.
- Kademeli açın: Önce non-prod ya da sınırlı kube ile baslayın.
Kubernetes v1.x dünyasında böyle ince ayarlar bana hep şunu hatırlatıyor: her iyileşme büyük mimarı devrim olmak zorunda değil.
Bazen tek satırlık metrik bile size bütçe savunması kazandirır.
Mesela yönetim toplantısında elinizde somut sayı varsa konuşma bambaşka akıyor;
“his” yerine veri sunmuş oluyorsunuz.
Bu arada evet, yöneticiler rakama bayılıyor! .NET ve .NET Framework Mayıs 2026 Güncellemeleri: Ne Değişti? yazımızda bu konuya da değinmiştik.
Kendi deneyimlerimde en faydalı yaklasım hep su öldü:
önce mekanizmayı anlamak,
sonra etkisini ölçmek,
en son karar vermek. AZ-500 tarafındaki güvenlik mantığında da aynısını görüyoruz;
önce sinyal var mi diye bakarsınız,
sonra aksiyon alırsınız. Buradaki metric de tam olarak o türden bir sinyal veriyor:
sessiz ama önemli bir sinyal…
Bana göre güzel yanı ne, eksik yanı ne?
Güzel yanı açıkça su:
operatör artık tahmine bakmıyor,
davranışı görebiliyor.
Bu gayet iyi bir adım.
Hatta baya işe yarar;
özellikle stale state yaşayan veya nadiren node değiştiren kumelerde ciddi fark yaratabilir.
Ekşi tarafa gelirsek… alpha olması zaten başlı başına temkin sebebi. Bir metric eklemek kolay kısım;
asıl zor olan önü düzenli kullanım alışkanlığına çevirmek. Ayrıca her ortamda aynı faydayı beklemek yanlış olur. Dinamik workload’lu kumelerde fark daha az hissedilebilir. Yanı kağıt üstünde süper,
pratikte göreceğiz artık.
Bence Microsoft’un ve Kubernetes topluluğunun burada verdiği mesaj net:
olcebiliyorsan optimize edebilirsin.
Olcemiyorsan sadece yorum yaparsın.
Ben uzun yıllardır hosting’den buluta geciş projelerinde bunu defalarca gördüm;
görünen performans ile gerçek operasyon maliyeti çoğu zaman aynı şey olmuyor.
Sıkça Sorulan Sorular
route_controller_route_sync_total metriği ne ölçüyor?
Kubernetes Cloud Controller Manager’daki route controller’ın toplam senkron çalışma sayısını ölçüyor. Yanı aslında route reconciliation davranışını takip etmek için gayet kullanışlı bir metrik bu.
Feature gate açıkken neden sayı düşüyor?
Çünkü watch-based model, hani sadece gerçekten bir node değişikliği olduğunda devreye giriyor. Klasik loop gibi sabit aralıklarla boşuna dönmüyor, dolayısıyla artış hızı doğal olarak azalıyor (evet, doğru duydunuz)
Bunu production’da hemen açmalı mıyım?
Açıkçası hayır, direkt koşmayın derim.
Önce staging ya da sınırlı bir kümede deneyin.
Bence logları ve metrik trendlerini doğrulamadan geniş yayılım yapmak gereksiz risk almak demek (şaşırtıcı ama gerçek)
Trafiğim azsa bu özellik bana fayda sağlar mı?
Açık konuşayım, Evet, mesela node değişiminin seyrek olduğu ortamlarda faydası daha belirgin hissediliyor.
Trafik az olsa bile gereksiz API çağrılarını azaltmak operasyonu epey rahatlatıyor.
Ama dinamizm yüksekse kazanç sınırlı kalabilir tabiî.
Perde arkasında ne olup bittiğini görmek için metrik yine de işe yarıyor.
Tecrübeme göre her yerde mucize beklememek lazım!
Kaynaklar ve İleri Okuma
Kubernetes Blog — New Metric for Route Sync in the Cloud Controller Manager
Bak şimdi, Kubernetes Cloud Controller Manager Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
3 comments