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
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.
3 comments