Kubernetes v1.36 Route Sync Metriği: CCM’de Yeni Bir Pencere
Şunu söyleyeyim, Geçen ay bir telekom müşterimizde garip bir konuşma döndü. Bulut altyapı ekibi AWS tarafında rate limit yüzünden resmen saçını başını yoluyordu. “Hocam, biz hiçbir şey yapmıyoruz, node sayımız aylardır sabit, ama API çağrıları niye bu kadar yüksek?” diye sordular. Cevap aslında çoğu kişinin gözünden kaçan bir yerdeydi: Cloud Controller Manager içindeki route controller, ortada değişiklik olmasa bile her 10 saniyede bir senkronizasyon yapıyor — itiraf edeyim, beklentimin üstündeydi —
İşte tam burada işin rengi değişiyor. Kubernetes v1.36 ile birlikte CCM’e yeni bir alpha metriği geldi: route_controller_route_sync_total. Adı uzun, evet. Ama doğru kullanınca baya iş görüyor; çünkü neyin ne kadar sık döndüğünü net gösteriyor.
Bu yazıda bu metriği niye umursamanız gerektiğini, hangi feature gate ile anlam kazandığını ve Türkiye’deki kurumsal Kubernetes operatörleri için nasıl bir A/B test akışı çıkarabileceğinizi anlatacağım. Lafı gevelemeden girelim.
Hikâye Aslında Burada Başlıyor: Polling vs Watch
Kubernetes’in route controller’ı uzun süre çok düz bir mantıkla çalıştı (bizzat test ettim). Belirli aralıkta — varsayılan 10 saniye — node listesini alıyorsun, bulut sağlayıcının route table’ı ile karşılaştırıyorsun, fark varsa düzeltiyorsun, yoksa da bir sonraki türü bekliyorsun. Klasik polling loop. Kulağa temiz geliyor, ama biraz fazla mekanik dürüyor.
Pratikte işe tablo başka. Düşünün; 200 node’lu, üretimde ayda bir kez node ekleyip çıkardığınız sakın bir cluster var elinizde. Buna rağmen route controller her 10 saniyede bir AWS, Azure ya da GCP API’sine “n’aber, değişen bir şey var mı?” diye soruyor. Günde 8.640 senkronizasyon ediyor bu iş; hepsi aynı cevabı alıyor: yok kardeşim, değişen bir şey yok.
Dürüst olmak gerekirse, Hani kapınızı sürekli çalıp “evde mısın?” diye soran biri olsa nasıl bakarsınız? İşte cloud provider API’leri de aşağı yukarı öyle hissediyor.
Bir şey dikkatimi çekti: Kubernetes v1.35 ile gelen CloudControllerManagerWatchBasedRoutesReconciliation feature gate bu yaklaşımı epey değiştiriyor. Polling yerine watch kullanıyor; yanı API server’da node nesneleri üzerinde gerçekten bir değişiklik olduğunda tetiklenen event-driven bir yapı geliyor. Node eklenince çalışıyor, çıkınca çalışıyor, güncellenince çalışıyor; geri kalan zamanda uyuyor.
“Watch tabanlı reconciliation zaten Kubernetes’in başka yerlerinde standart sayılırdı. Route controller’ın buraya biraz geç gelmesi tuhaf dürüyor açıkçası — ama gelmiş olması yine de iyi.”
Yeni Metriğin Anlamı: Önce Ölç, Sonra Aç
İnanın, Şimdi asıl meseleye gelelim. v1.36’nın getirdiği route_controller_route_sync_total, counter tipinde bir metrik. Yanı azalmaz; sadece artar. Her senkronizasyon olduğunda sayı biraz daha yukarı gider.
Evet, doğru duydunuz.
Peki bu neden önemli? Çünkü önceki feature gate’i — watch-based olanı — production’da açmadan evvel gerçekten işinize yarayıp yaramadığını görmek istersiniz. Bence bu doğru yönde atılmış adım; ama kurumsal yapılarda her feature gate’i ölçmeden açmak riskli olur. SRE ekiplerinin gözü kapalı feature gate açtığını çok gördüm, sonra geri dönüş aşamasında işler gereksiz yere uzuyor.
Beklenen Davranış: Sayıların Dili
Eh, Feature gate kapalı iken (varsayılan durum), counter düzenli biçimde artar. Hiçbir şey olmasa bile:
# 10 dakika sonra, hiçbir node değişikliği olmadan
route_controller_route_sync_total 60
# 20 dakika sonra, hâlâ değişiklik yok
route_controller_route_sync_total 120Buna karşılık feature gate açık olduğunda tablo ciddi biçimde değişir:
# 10 dakika sonra, node değişikliği yok
route_controller_route_sync_total 1
# 20 dakika sonra, hâlâ yok — counter sabit
route_controller_route_sync_total 1
# Yeni node eklendi — counter artıyor
route_controller_route_sync_total 2Aradaki fark net mi? Stabil cluster’da sayı neredeyse yerinde sayıyor (en azından benim deneyimim böyle). Bu da cloud provider API’sine giden çağrıların doğrudan azalması demek oluyor. Neyse ki diyelim burada; çünkü maalesef değil artık.
A/B Testi Nasıl Yapılır? Pratik Rehber
İşin garibi, Logosoft’taki bir bankacılık müşterisinde geçen yıl benzer bir gözlemlenebilirlik çalışması yapmıştık (konu farklıydı ama yöntem aynıydı). Şu akışı öneririm:
- Baseline ölçümü: Feature gate kapalıyken metriği Prometheus’a kazıyın. En az 24 saat veri toplayın; mümkünse bir hafta tutun ki iş günü ve hafta sonu farkını da görün.
- Test cluster’ında etkinleştirme: Production’a hiç dokunmayın önce. Staging veya test cluster’da CCM’e
--feature-gates=CloudControllerManagerWatchBasedRoutesReconciliation=trueekleyin. - Karşılaştırma: Aynı süre boyunca metriği toplayın ve rate olarak bakın — yanı
rate(route_controller_route_sync_total[5m]). - Cloud provider tarafı: AWS CloudTrail, Azure Activity Log veya GCP Audit Logs üzerinden ilgili API çağrılarını paralel izleyin. Sayılar birbirini destekliyor mu bakın.
- Production rollout: Sonuçlar tatmin ediciyse kanarya yaklaşımıyla açın. Tek seferde neredeyse tüm cluster’lara yaymayın; acele etmeye gerek yok.
Bunu da not düşeyim: Bu metrik alerta/alpha, yanı işim değişebilir, davranış kayabilir ya da bayağı kaldırılabilir. Production dashboard’larınızı buna sıkıca bağlarsanız ileride başınız ağrıyabilir. Ben olsam Grafana’da ayrı bir “experimental” panel açar ve oraya koyarım.
Türkiye’deki Kurumsal Yapılar İçin Ne Anlama Geliyor?
Şahsen, Açık konuşayım; Türkiye’de Kubernetes adopsiyonu konusunda iki uç var gibi dürüyor bana göre.
Bir tarafta tam managed servisleri (AKS, EKS) kullanan. CCM’in iç işleyişine çok bakmayan ekipler var.
Onlar için bu metrik şu an doğrudan görünür değil; çünkü AKS gibi managed kontrol düzlemlerinde CCM’i sız yönetmiyorsunuz.
Microsoft’un bu feature gate’i ne zaman ve nasıl açacağına dair takvim de henüz net değil.
Ben şahsen 1.37 ya da 1.38 civarında stable’a yaklaşmadan AKS tarafında görmeyiz diye düşünüyorum.
Ama %100 doğru olmayabilir tabiî. Bu konuyla ilgili Microsoft Sovereign Private Cloud: Azure Local ile Ölçek Büyürken Kontrolü Kaybetmemek yazımıza da göz atmanızı tavsiye ederim.
Daha öbür tarafta self-managed Kubernetes işleten ekipler var; özellikle finans, telekom ve kamu tarafında bunu çok görüyoruz (eh, fena değil). Veri egemenliği ya da regülasyon sebebiyle on-prem veya hibrit yapılarda kendi cluster’larını kuruyorlar. İşte bu kesim için yeni metrik düzden uygulanabilir, yanı direkt kullanılabilir durumda.
Bunu da unutmayalım: Türkiye’de bulut maliyetlerini TL bazında düşününce her API çağrısı zamanla anlam kazanıyor.
AWS’in dakikada koyduğu limit küçük görünebilir. DescribeRouteTables gibi basit çağrılar bile toplandığında can sıkabiliyor.
50+ cluster işleten bir telekom düşünün; hepsi aynı API’yi her 10 saniyede dövüyor.
Watch tabanlı yaklaşımla o yükün ciddi kısmı eriyor.
Küçük Ekipler vs Enterprise: Farklı Öncelikler
Şunu söyleyeyim, Eğer 3-5 kişilik startup ekibindeyseniz, bu metriği tek başına izlemek için koca Prometheus stack kurmak biraz ağır kaçabilir.
Daha basit yol şu: feature gate’i staging’de açın, bir hafta gözlemleyin, sorun çıkmıyorsa production’a alın.
Hayat biraz kolaylaşıyor böylece. C++’ta Copilot’u Konuşturmak: VS Code İçin Akıllı İpuçları yazımızda bu konuya da değinmiştik.
Bir dakika — bununla bitmedi. Daha fazla bilgi için Java OpenJDK Nisan 2026 Güncellemesi: Bellek, Güvenlik ve Sürprizler yazımıza bakabilirsiniz.
Büyük kurumlarda işe hikâye başka türlü ilerliyor.
Bir finans kurumunda compliance ekibi “bu değişiklik ne işe yaradı, kanıtla” diye soracaktır.
Tam burada metriğin değeri ortaya çıkıyor. Before/after kıyasını somut sayılarla gösterebiliyorsunuz. Microsoft Agent Framework ile .NET’te Ajan Kurmanın İncelikleri yazımızda bu konuya da değinmiştik.
Küçük Bir Karşılaştırma Tablosu Koyalım mı?
| Kriter | Polling (Default) | Watch-Based (Feature Gate) |
|---|---|---|
| Senkronizasyon Tetikleyici | Sabit interval (10sn) | User event’i / node event’i |
| Zaten Sakın Cluster’da API Yükü | Daha yüksek | Epey düşük |
| Nod ekleme tepkisi | Sıklıkla 0-10 saniye gecikme | Anlık sayılır |
| Düzey / Olgunluk Seviyesi | Piyasada oturmuş durumda | Bazı yerlerde beta gibi düşünülmeli (v1.36) |
| Kenar Senaryo Riski | Düşük sayılır | Müşteri bağlantısı koparsa yeniden bağlanma senaryolarına dikkat etmek lazım |
| Tavsiye Edilen Senaryo | Daha dinamik cluster’lar | Daha stabil ya da yarı-stabil cluster’lar |
Eğer API server ile CCM arasındaki watch connection koparsa ve resync mekanizması düzgün toparlayamazsa,
route table tutarsız kalabilir.
Bu yüzden Kubernetes v1\.36’da CCM logging seviyesini ilk birkaç hafta biraz daha yukarıda tutmanızı öneririm\-\-özellikle canlıya yeni aldıysanız\-\-.
Ilk Denediğimde Başıma Gelen Şeyler Var Ya…
Bunu lab ortamında ilk denediğimde Prometheus scraper metriği bulamadı.
Loglara bakınca anladım ki CCM’in \-\-bind-address\ parametresi \`127\.0\.0\.1\`e set edilmişti;
dolayısıyla cluster içinden erişim yoktu.
Çözüm aslında basit:
\-\-bind-address=0\.0\.0\.0\ yapıyorsunuz
(ya da network policy’nızı düzgün ayarlıyorsunuz).
Ama on-prem self-managed cluster işletiyorsanız ServiceMonitor veya PodMonitor objesini de tanımlamanız gerekiyor,
önü atlamayın.
Üstelik şöyle de karışabiliyor:
Metriğin Prometheus tarafına doğru etiketlerle gelmesi için Kube State Metrics‘le karıştırmamak lazım;
bu metrik doğrudan CCM’in /metrics\ endpoint’inden geliyor,
kube-state-metrics ile alakası yok.
Geçen hafta tam olarak bu noktada kafa karışıklığı yaşadık,
hani insan ilk anda başka yere bakabiliyor. Entra Agent ID GA: Sponsor Grup Tipi Kuralları Değişti yazımızda bu konuya da değinmiştik.
Diğer Kubernetes v1\.36 Yenilikleriyle Birlikte Düşünmek
yazımda anlattığım pod-level resource yönetimi sidecar’lı yapılarda kaynak hesabını sadeleştiriyor.
Aynı şekilde controller staleness konusu da ilginç;
Kubernetes v1\.36 Controller Staleness\: Bayat Cache Sorunu Bitti mi?
yazımda detaylandirdim.
Watch-based reconciliation’ın getirdiği ekosistem değişikliği bununla yakından bağlantılı.
Bellek tarafında işe
Kubernetes v1\.36 Memory QoS\: Katmanlı Bellek Koruması Geldi
yazımı tavsiye ederim\-\-orada cgroup v2 üzerinden gelen yeni katmanlı koruma mekanizması anlatılıyor.
Sıkça Sorulan Sorular
Bu metrik AKS, EKS veya GKE’de kullanılabiliyor mu?
Doğrudan değil, yanı managed Kubernetes servislerinde CCM’i sız yönetmediğiniz için bu metriğe erişiminiz kısıtlı kalıyor. AKS özelinde mesela Microsoft, Kubernetes versiyon adopsiyonunu genellikle 1-2 minör version geride takip ediyor. Aslında self-managed kümeleriniz varsa hemen kullanabilirsiniz.
route_controller_route_sync_total metriği hangi label’larla geliyor?
Alpha seviyesinde basit bir counter olarak geliyor. Şu an cloud provider ya da region bazlı detaylı label’lar yok açıkçası. Beta’ya geçişte muhtemelen ek label’lar eklenecek — bence KEP-5237 issue’şunu takip etmekte fayda var.
Watch-based reconciliation feature gate’i production’da güvenli mi?
Bi saniye — v1.35’te alpha, v1.36’da beta seviyesinde. Beta varsayılan olarak açık geliyor ama feature gate ile yönetebiliyorsunuz. Tecrübeme göre “güvenli” diyebilmek için en az birkaç sürüm beta’da kalması. Community feedback’ının olumlu seyretmesi lazım. Acelesi olmayan ekiplere şahsen 1.37 veya 1.38’i bekleyin derim.
Polling interval’ını artırarak da API yükünü azaltamaz mıyım?
Teorik olarak evet, --route-reconciliation-period flag’i ile interval’ı artırabilirsiniz. Ama bu sefer node değişikliklerine reaksiyon süreniz uzuyor, yanı bir trade-off var. Sız hiç denediniz mi? Watch-based yaklaşım hani her iki tarafı da iyileştiriyor — bu yüzden aslında daha mantıklı bir çözüm.
Bu metrik üzerinden alarm tanımlamak mantıklı mı?
Bence şu an için hayır. Alpha seviyesinde alarm kurmayın. Bunun yerine dashboard’a ekleyip gözlem amaçlı izleyin. Beta’ya geçince. Peki bunu neden söylüyorum? Bir-iki sürüm stabilite gördüğünüzde alarmlama yapabilirsiniz — mesela “rate sıfırın altına düşerse uyar” gibi anomali bazlı kurallar o zaman mantıklı oturuyor.
Şimdi gelelim işin can alıcı noktasına.
Kaynaklar ve İleri Okuma
Kubernetes Resmî Blog: New Metric for Route Sync in the Cloud Controller Manager
KEP-5237: Watch-based Route Reconciliation in Cloud Controller Manager
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.
Yorum gönder