Şunu açık konuşayım: Kubernetes’in cloud controller manager tarafı, çoğu operatörün pek dönüp bakmadığı bir köşe. Çalışıyor, route’lar geliyor, node’lar ekleniyor; tamam, buraya kadar sorun yok gıbı duruyor. Ta ki bir gün cloud provider’ın API rate limit’ine takılana kadar. İşte v1.36 ile gelen route_controller_route_sync_total metriği, tam da bu sessiz yere bir el feneri tutuyor.
Vallahi, Geçen ay bir telekom müşterimizde, AKS ortamında değil. Bare-metal bir küme üzerinde tam da bu sıkıntıyı yaşadık. Provider tarafı sürekli throttle yiyordu, biz de “neden bu kadar çağrı atıyoruz” diye kafayı kurcalıyorduk. O zamanlar bu metrik yoktu; log eşeleyerek tahmin yürüttük, biraz şans, biraz tecrübe yanı. Şimdi geriye dönüp bakınca, bu küçük sayacın aslında ne kadar can sıkıcı bir boşluğu kapattığını daha net görüyorum.
Önce kısa bir hatırlatma: CCM route controller ne iş yapar?
Cloud Controller Manager’ın route controller bileşeni, basitçe söyleyeyim, küme içindeki pod CIDR’larının bulut sağlayıcının route table’ına yazılmasından sorumlu. Yanı bir node geldiğinde “şu IP bloğu şu node’a gitsin” demek için VNET’e, VPC’ye veya bulut tarafındaki route mekanizmasına çağrı atar.
İşin aslı şu: bu controller, klasik hâliyle sabit aralıklı bir loop şeklinde çalışıyordu. Yanı node’lar değişmiş mi değişmemiş mi, her X saniyede bir “haydi senkronize edelim” diyordu. Küçük kümelerde mesele değil. Tahmin eder mısınız? Ama 500+ node’lu bir ortamda, hele de aynı subscription’da onlarca küme varsa, provider API’sını boş yere yoruyorsunuz.
Peki neden?
v1.35’te gelen watch-based reconciliation
Kubernetes v1.35’te CloudControllerManagerWatchBasedRoutesReconciliation diye bir feature gate geldi. Adı uzun, mantığı basit: sabit interval yerine, node objelerini watch et. Sadece bir node eklendi, silindi veya güncellendi mi — o zaman senkronizasyon yap. Yoksa boşa çağrı atma.
Kağıt üstünde fena değil. Pratikte? Hmm, işte burada ufak bir boşluk vardı. Feature gate’i açtığınızda, “gerçekten daha az çağrı atılıyor mu” sorusunu net biçimde doğrulamak kolay değildi; audit log’lardan biraz tahmin yürütüyorduk, provider tarafının API metriklerine bakıyorduk (arada başka trafik de karışıyordu),. Elimizde doğrudan tek bir sinyal yoktu.
İşte yeni metrik: route_controller_route_sync_total
v1.36 alpha ile gelen sayaç bu. Çok sade bir counter,. Route’lar provider ile ne zaman senkronize edilirse bir artıyor, başka da numarası yok gıbı duruyor. Ama işin garibi şu: bu kadar basit görünen şey, A/B test tarafında baya iş görüyor.
Feature gate kapalıyken ne görüyorsunuz?
Varsayılan davranış interval-based loop. Şey, burada node değişmese bile sistem belli aralıklarla sayacı artırıyor; yanı ortam sakın kalsa da arka planda düzenli bir trafik dönüyor, biraz gereksiz. Öyle çalışıyor:
# 10 dakika sonra, hiçbir node değişikliği yok
route_controller_route_sync_total 60
# 20 dakika sonra, hâlâ değişiklik yok
route_controller_route_sync_total 120Şahsen, Yanı dakikada bir tık artıyor. Boşa giden 120 çağrı var burada, açık konuşayım; stabil bir kümede bunun pek tadı tuzu yok, hatta biraz israf kokuyor.
Durun, bir saniye.
Feature gate açıkken durum şu
# 10 dakika, değişiklik yok
route_controller_route_sync_total 1
# 20 dakika, hâlâ değişiklik yok — sayaç durdu
route_controller_route_sync_total 1
# Yeni bir node geldi — sayaç hareketlendi
route_controller_route_sync_total 2Fark hemen belli oluyor. Stabil kümelerde sayaç resmen uyukluyor; yeni bir olay gelene kadar kıpırdamıyor bile. Peki neden? Çünkü artık sürekli dönen loop yerine gerçekten bir şey olduğunda tetikleniyor.
Bunu nasıl A/B test edersiniz? Pratik rehber
Kendi deneyimimden konuşuyorum, Eğer ortamınızda birden fazla küme varsa, işi şansa bırakmadan gerçek bir karşılaştırma yapmak için şöyle ilerleyin: önce feature gate kapalı bir kümeyi baz alın, sonra aynı yapıya yakın başka bir kümede gate’i açın, üstüne de CCM’yi yeniden başlatın; biraz zahmetli görünüyor. Işin aslı, farkı net görmek istiyorsanız bu adım lazım.
- Baseline ölçümü: Feature gate kapalı bir kümede 24 saat boyunca
route_controller_route_sync_totaldeğerini Prometheus’a kazıyın. Sonrarate(route_controller_route_sync_total[5m])ile dakika başı senkron sayısına bakın. Kısa gıbı duruyor ama burada asıl mesele, gün içindeki dalgalanmayı da görmek; yoksa tek bir anlık sayı sızı yanıltır. - Feature gate’i açın: Tercihen aynı yapıdaki başka bir kümede (veya stage ortamında) gate’i etkinleştirin. CCM’yi yeniden başlatın. Evet, restart kısmı bazen can sıkıyor, ama ölçümün temiz çıkması için bunu atlamamak gerekiyor. — ciddi fark yaratıyor
- 24 saat daha bekleyin: Aynı metriği toplayın. Bu arada hemen paniklemeyin; ilk birkaç saatte gördüğünüz değerler oynayabilir, çünkü küme zaten boş durmuyor.
- Karşılaştırın: Node değişikliği sayısıyla orantılı bir düşüş görmeniz lazım. Stabil bir prod kümesinde %90+ düşüş normal. Daha azsa da hemen “bozuk” demeyin; önce node hareketi var mı, provider tarafında ekstra gürültü var mı ona bakın.
Hızlıca tabloya dökeyim, kafanızda daha iyi otursun:
Şimdi gelelim işin can alıcı noktasına.
| Senaryo | Sabit interval (default) | Watch-based (gate açık) |
|---|---|---|
| Stabil küme, 24 saat | ~8.640 senkron | ~5-20 senkron |
| Aktif scale eden küme | ~8.640 senkron | ~200-500 senkron |
| Karma chaos test günü | ~8.640 senkron | ~1.000+ senkron |
| Provider API yükü | Yüksek, sabit | Olay bazlı, düşük |
Aslında, Burası önemli. Bu rakamlar benim son üç — ki bu tartışılır — ayda farklı müşterilerde gözlemlediğim ortalamalar; yanı herkes için birebir aynı çıkacak diye bir şey yok, hatta açık konuşayım bazı ortamlarda tablo baya sapabiliyor çünkü küme büyüklüğü, node oynaklığı. Ölçeklenme davranışı sonuçları doğrudan değiştiriyor.
Küçük bir detay: Peki neden? Çünkü sabit interval yaklaşımı her şeyi belli aralıklarla dürtüyor, watch-based taraf işe olay olursa çalışıyor; yanı biri sürekli konuşan arkadaş gıbı, diğeri gerektiğinde mesaj atan biri gıbı davranıyor.
Şunu söyleyeyim, Tam da öyle. Daha fazla bilgi için Service Bus + Azure Functions: Backoff ve Circuit Breaker yazımıza bakabilirsiniz.
Şunu fark ettim: Eğer sizdeki sayıların oranı yukarıdaki kadar sert düşmüyorsa, önce metrik toplama süresine ve kümenin gerçek hareketliliğine bakın; sonra tekrar ölçün. Şey, çoğu zaman sorun kodda değil ortamda oluyor.
Türkiye’deki kurumsal yapılar açısından ne anlama geliyor?
Açık konuşayım: Türkiye’de çoğu kurumsal müşteri hâlâ AKS ya da managed Kubernetes servislerini kullanıyor. Yanı CCM’ye doğrudan dokunmuyorlar, bulut sağlayıcısı zaten işi üstleniyor. Peki bu metrik kimin işine yarıyor?
İki grup geliyor aklıma. Birinçisi self-managed Kubernetes çalıştıran kurumlar. Bankacılıkta, savunmada, telekomda bunu sık görüyorum; KVKK. Regülasyon yüzünden on-prem ya da private cloud üzerinde kendi CCM’lerini koşturanlar var (ben de ilk duyduğumda şaşırmıştım). İşte bu ekip için metrik baya işe yarıyor. Çünkü kendi cloud provider entegrasyonlarını yazıyorlar (mesela OpenStack, VMware veya custom bir katman), üstüne bir de route controller’ın nasıl davrandığını izlemek zorunda kalıyorlar. Agent Framework + AGT: Üretimde Yönetişim Şart yazımızda bu konuya da değinmiştik.
İkincisi multi-tenant SaaS firmaları. Bir İstanbul merkezli fintech vardı, geçen yıl danışmanlığını verdik. Müşteri başına bir küme açıyorlardı, izolasyon için yanı. Onlarca AKS instance vardı, hepsi aynı subscription’da dönüyordu. Azure tarafında Microsoft.Network API’sine throttle yemeye başlamışlardı (inanın bana). Tam da şu route sync işleri yüzünden. O an bu feature devrede olsaydı, sadece feature gate’i açıp problemin yarısını halletmiş olurduk gıbı geliyor.
Durun, bir saniye.
Bir kurumsal müşteride yaptığımız ölçümde, watch-based reconciliation’a geçince Azure ARM API çağrı sayısı saatte 60’tan 4-5’e düştü. Provider tarafındaki rate limit alarmları… sustu. Bazen iyileştirme dediğin şey, sadece “boşa konuşmayı kes” demek oluyor.
Küçük ekipler için söylenecek bir şey var mı?
Araya gireyim: Küçük ekipseniz, mesela 3-10 node’lük bir küme çalıştırıyorsanız, açıkçası bu metrik sizin için “yapsanız iyi ölür. Yapmazsanız da dünya yıkılmaz” kategorisinde duruyor. Çağrı sayısındaki fark provider tarafında öyle ahım şahım bir değişiklik yaratmaz, faturanız da zaten düşük kalır. Ama yine de feature gate’i açmak iyi bir alışkanlık; hani sonra büyüyünce uğraşmazsınız. Kubernetes v1.36 Workload API: PodGroup Devri Başladı yazısında da değindiğim gıbı, v1.36 genel olarak “verimlilik” sürümü öldü. Küçük şeyler birikiyor.
Prometheus tarafında ne yapmalıyız?
Metrik işi burada baya net. CCM’nın /metrics endpoint’inden alıyorsunuz, format da standart Prometheus formatı. Ben kendi monitoring stack’imde aşağıdaki alert’i kullandım. Açık konuşayım, bunu kopyala-yapıştır yapmayın, önce kendi ortamınıza göre biraz kurcalayın:
- alert: RouteSyncRateAnomaly
expr: |
rate(route_controller_route_sync_total[10m])
>
avg_over_time(rate(route_controller_route_sync_total[10m])[1h:5m]) * 3
for: 15m
labels:
severity: warning
annotations:
summary: "Route sync rate son 1 saatlik ortalamanın 3 katına çıktı"
description: "Watch-based mode açıkken bu kadar sync, node oynaklığı veya bir bug işareti olabilir"Bu alert’in olayı şu. Normalde watch-based mode açıkken sakın kalması gereken sayaç bir anda zıplarsa, ya altyapıda gerçekten bir hareket vardır ya da CCM tarafında garip bir şey dönüyordur. İkisini de görmek istersiniz, çünkü biri operasyon, diğeri yazılım kokusu veriyor. GPT-5.5 Microsoft Foundry’de: Sahadan İlk Değerlendirme yazımızda bu konuya da değinmiştik.
Evet.
Grafana dashboard önerisi
Üç panel çoğu zaman yetiyor, hatta bazen fazla bile geliyor gıbı hissediyorsunuz. Birinçisi rate(route_controller_route_sync_total[5m]), yanı dakika başı senkron hızını gösteren grafik; ikincisi node ekleme ve silme event’lerini bunun üstüne bindiren görünüm (sebep-sonuç ilişkisini yakalamak için), üçüncüsü de provider API çağrı sayısı, mesela Azure’da Activity Log’dan, AWS’te işe CloudTrail’den çekebileceğiniz veri. Üçü aynı anda gözünüzün önüne gelince sistemin nabzını tutabiliyorsunuz, hani ekran sadece rakam göstermiyor, resmen hikâye anlatıyor.
Bilmem anlatabiliyor muyum, Peki neden? Çünkü tek metrikle bakınca insan kolayca yanlış yere sapıyor. Ama bu üçlü birlikte durunca, “tamam burada node oynuyor” mu diyorsunuz, yoksa “yok ya bu CCM bir şeylere takılmış” mı diyorsunuz, o daha hızlı anlaşılıyor.
Hani, Tam da öyle. Daha fazla bilgi için vcpkg Nisan 2026 Güncellemesi: Paralel Build Kilitleri Geldi yazımıza bakabilirsiniz.
Tökezlenecek noktalar — sahadan birkaç not
Bu feature için her şey pürüzsüz değil, açık konuşayım. Birkaç gerçek dünya tuzağı var, onları da araya sıkıştırayım. Işin güzel tarafı kadar can sıkan tarafı da oluyor, hele prod’a yakın yerlerde insan bir anda “hmm, burada ne kaçırdım?” diye kalıyor. Daha fazla bilgi için Copilot Code Review Metrikleri: Yorum Tipine Göre Kırılım yazımıza bakabilirsiniz.
- Cold start probleminin gizli versiyonu: CCM yeniden başladığında, watch-based mode tüm node’ları bir kerede işliyor. Yanı metrik bir anda 0’dan 50’ye fırlıyor. Bu normal, ama alert kurarken hesaba katın; yoksa sabaha karşı gereksiz alarm sesiyle uyanırsınız. (bu kritik)
- API server’a yük binmesi: Watch-based yaklaşım provider API’sını baya rahatlatıyor ama kube-apiserver tarafına biraz daha yük bindiriyor (node watch). Küçük kümelerde pek dert değil, fakat 5000+ node’lu ortamlarda iş değişiyor, orada bir durup bakmak lazım.
- Test ortamında flaky görünüyor: İlk denediğimde ben de “neden hiç metrik üretmiyor” diye az kalsın panikliyordum. Meğer kümede gerçekten node hareketi yokmuş — metrik doğru çalışıyormuş, ben yanlış beklentiyle bakıyormuşum. Sayaç sıfırda kalabilir ve bu bazen gayet iyi bir şeydir.
- Alpha aşamasında label değişikliği riski: Şu an metrik sade duruyor, ama ileride
providerveyazonegıbı label’lar gelebilir. Dashboard’ları buna göre esnek tutun; sonra tek tek panel düzeltmekle uğraşmayın.
Evet, bir detay daha var. Feature gate’i açtıktan sonra eğer custom bir cloud provider hayata geçirmeu kullanıyorsanız, provider’ınızın Routes() interface’ının gerçekten doğru çalıştığından emin olun; eski interval-based mode hataları biraz maskeliyordu çünkü her dakika tekrar deniyordu,. Watch-based mode’da bir senkron başarısız olduysa sonraki node değişikliğine kadar yeniden deneme gelmeyebiliyor. İşte şaşırtıcı semptomlar bazen buradan çıkıyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Bak şimdi, Peki neden? Çünkü davranış değişti. Önceden sistem “bir daha denerim” diyordu; şimdi o kadar cömert değil.
Tam da öyle.
Peki feedback nereye?
SIĞ Cloud Provider topluluğu bu işte baya hareketli. Kubernetes Slack’te #sig-cloud-provider kanalına bir uğrayın derim; ben de arada oradayım, yanı boşluk buldukça bakıyorum. Bir de GitHub tarafı var, KEP-5237 issue’su açık duruyor, oraya da yorum bırakabilirsiniz.
Bir şey dikkatimi çekti: Açık konuşayım — alpha bir özellikte feedback gerçekten kıymetli oluyor. Küçük bir testbed’ınız varsa, gate’i açıp birkaç hafta izleyin, sonra ne gördüyseniz yazın; çünkü bu tarz “sessiz” optimizasyonlar çoğu zaman yeterince denenmediği için GA’ya geçişi uzuyor. Açık Kaynağa İlk Katkı: GitHub’da Başlangıç Rehberi yazımda anlattığım gıbı, böyle küçük ama elle tutulur katkılar açık kaynakta bazen en çok iş gören şeyler oluyor.
Sıkça Sorulan Sorular
Bu metrik sadece belirli cloud provider’larda mı çalışıyor?
Hayır, çalışıyor. Metrik k8s.io/cloud-provider içindeki ortak route controller koduna eklendiği için aslında tüm provider hayata geçirmelarında kullanabiliyorsunuz. AWS, Azure, GCP, OpenStack ya da custom — hiç fark etmiyor. Önemli olan tek şey CCM’nın v1.36 sürümünü çalıştırıyor olmanız.
Feature gate’i prod’da açmak güvenli mi?
Watch-based reconciliation hani v1.35’ten beri var, yanı epeydir olgunlaşıyor. Ama bence her zaman önce stage ortamında 1-2 hafta test etmek lazım (kendi tecrübem). Hele bir de de custom cloud provider yazıyorsanız, Routes() implementasyonunuzun doğru hata yönetimi yapıp yapmadığına bakın. Açıkçası bu metrik tam da bunu doğrulamak için var zaten.
Metrik alpha — ne zaman GA ölür?
Net bir tarih yok açıkçası. Ama alpha → beta → GA döngüsü Kubernetes’te genelde 2-3 minor sürüm sürüyor. Yanı v1.38 ya da v1.39 civarında beta görmeyi bekliyorum. GA için belki bir yıl daha. Bu süreçte label yapısı değişebilir, o yüzden bence dashboard’larınızı esnek kurun.
Hiç senkron olmaması bir sorun mu, yoksa iyi mi?
Stabil bir kümede sıfır senkron tamamen beklenen bir şey. Yanı feature gate açık ve kümeniz haftalardır aynı node’larla çalışıyorsa, sayacın hiç artmaması aslında mükemmel (ben de ilk duyduğumda şaşırmıştım). Bunu sorun olarak değil, başarı göstergesi olarak okuyun. Tabi node ekledikten sonra hâlâ artmıyorsa, o zaman dert.
AKS gıbı managed servislerde bu feature gate’i açabilir mıyım?
Doğrudan açamıyorsunuz, çünkü managed servislerde CCM’yi Microsoft yönetiyor. Ama tecrübeme göre AKS roadmap’ine bakacak (belki yanılıyorum ama) olursanız, bu tür altyapı iyileştirmeleri genellikle 1-2 sürüm gecikmeyle otomatik olarak geliyor. Yanı siz hiçbir şey yapmadan, bir gün metrik elinize geçiyor.
Kaynaklar ve İleri Okuma
Kubernetes Blog: New Metric for Route Sync in the Cloud Controller Manager
Araya gireyim: KEP-5237: Watch-Based Route Reconciliation
kubernetes/cloud-provider GitHub Reposu
Kubernetes Cloud Controller Manager Resmî 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.
