Ş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 —
Bir dakika — bununla bitmedi. Daha fazla bilgi için
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.
Diğer Kubernetes v1.36 Yenilikleriyle Birlikte Düşünmek
Bu metriği tek başına ele almak yerine sürümün diğer özellikleriyle birlikte okumak daha mantıklı; v1.36 gözlemlenebilirlik ve kaynak yönetimi açısından epey dolu geliyor. Mesela Kubernetes v1.36 Pod-Level Resource Managers: Sidecar Derdi Bitiyor 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, yani managed Kubernetes servislerinde CCM’i siz 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, yani bir trade-off var. Siz 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
k8s.io/cloud-provider GitHub Reposu
Kubernetes Docs: Cloud Controller Manager Konsepti
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.
CCM’de bu kadar granüler bir metriğin alpha olarak bile gelmesi güzel, özellikle büyük cluster’larda o 10 saniyelik sync döngülerinin ne kadar gürültü yarattığını düşününce. Acaba stable’a geçişi ne zaman planlanıyor, bir bilgi var mı?
Bu arada şu yazınız da güzeldi: Microsoft Sovereign Private Cloud: Azure Local ile Ölçek Büyürken Kontrolü Kaybetmemek — https://www.askinkilic.com.tr/microsoft-sovereign-private-cloud-azure-local-ile-olcek-buyu/
CCM metriklerini takip etmek her zaman zahmetliydi, bu ekleme gerçekten işe yarar görünüyor. Peki alpha aşamasından stable’a ne kadar sürede geçer dersiniz, v1.37 veya v1.38’de mi beklemeliyiz?