Kubernetes v1.36: Sharded Watch ile Ölçek Duvarını Aşmak
Aslında — hayır dur, daha doğrusu, Kubernetes tarafında bazen en can alıcı yenilikler, ilk bakışta pek gösterişli durmaz. İşte bu da onlardan biri. v1.36 ile gelen server-side sharded list and watch, özellikle binlerce Pod, çok sayıda controller replica. Yüksek event trafiği olan ortamlarda baya iş görüyor. Çünkü mesele sadece “daha fazla replica koyduk, kapasite arttı” kadar düz değil; bazen tam tersi oluyor, yük iyice katlanıyor.
İtiraf edeyim, Ben bu tip ölçek problemlerini yıllardır hem hosting tarafında hem de kurumsal bulut projelerinde gördüm. 2024’ün sonlarında bir finans müşterisinde controller katmanında CPU’nun sürekli zıpladığını fark etmiştik; olayın kökü API server’dan gelen event seliydi. Replica sayısını artırınca rahatlayacak sanmıştık, ama olmadı… Her replica aynı akışı dinleyip sonra işine yaramayan kısmı çöpe atıyordu. Yanı maliyet büyüdükçe büyüyordu.
Ve işler burada ilginçleşiyor.
İşin aslı şu: Kubernetes’te ölçeklenme sadece yatayda çoğalmak demek değil. Bazen yükü doğru yere bölmek gerekiyor. Server-side sharding tam da bunu yapıyor; filtreyi istemciye bırakmıyor, API server’ın kapısında kesiyor.
Neden klasik shard yaklaşımı yetmiyor?
Kendi deneyimimden konuşuyorum, Klasik modelde controller’lar kendi aralarında iş bölümü yapıyor. Mesela kube-state-metrics gibi araçlarda bu mantığı sık görüyoruz: her replica keyspace’in bir parçasına bakıyor ve geri kalan objeleri yok sayıyor. Kağıt üstünde mantıklı. Pratikte işe biraz can sıkan bir durum var; her replica yine de pek çok event akışını alıyor.
Bu ne demek? Network trafiği replica sayısıyla birlikte şişiyor. CPU, deserialize işlemleri için boşa gidiyor. Memory tarafında da benzer bir sürtünme oluşuyor; çünkü her pod aynı büyük veri akışını parse etmeye uğraşıyor. Açık konuşayım, bu bana hep aynı postayı beş farklı kişiye göndermeye benziyor; dört kişi. Çöp kutusuna atacaksa niye gönderiyorsun?
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Bak şimdi, 2023 yazında Logosoft tarafında bir telekom müşterisinde buna yakın bir tablo görmüştük. Controller logları temiz görünüyordu ama node’ların üzerindeki küçük “gereksiz meşguliyet” yüzünden gecikmeler artıyordu. O zaman anlamıştım: sorun yalnızca throughput değilmiş, gereksiz işlem miktarıymış.
Server-side sharding’ın olayı şu: veriyi sonradan elemek yerine daha en başta doğru parçayı doğru replice veriyorsun.
Yeni model nasıl çalışıyor?
Burada oyun alanı biraz değişiyor. Client tarafı artık “ben hangi shard’a sahibim?” bilgisini shardSelector ile API server’a söylüyor. Sonra server belirli alanın hash değerine bakıp yalnızca o aralığa düşen objeleri dönüyor. Basit gibi dürüyor ama etkisi baya hissediliyor.
Kullanılan yaklaşım deterministic 64-bit FNV-1a hash üzerine kurulu. Yanı aynı nesne adı ya da UID için sonuç her API server instance’ında aynı çıkıyor; bu da multi-replica control plane ortamlarında önemli bir tutarlılık hissi veriyor (tabi alpha olduğu için temkinli olmak şart). Daha fazla bilgi için
Sahada nerede fayda sağlar?
Geçen sene Kasım 2025’te Ankara’da bir e-ticaret platformunda gözlemlediğimiz tabloda yaklaşık otuzdan fazla controller pod’u vardı ve hepsi benzer event hacmini taşıyordu. Replica artırıldıkça iyileşme bekliyorduk ama network kullanımındaki artış yüzünden kazanç sınırlı kaldı.
Sonra ortaya çıktı ki asıl darboğaz işlem gücü değilmiş; işlenmeyen eventlerin bile taşınmasıymış.
Şimdi gelelim pratik tarafa:
- Büyük cluster: Binlerce node ve yüksek cardinality resource varsa ciddi fayda verir.
- Küçük ekip: Basit tutup client-side sharding ile devam etmek bazen daha az risklidir.
- Maliyet odaklı yapı: Azure üzerinde network ve CPU birlikte düşünülmeli; özellikle yoğun kontrol düzlemi trafiklerinde tasarruf küçümsenmez.
Bence, Bence burada enterprise ile startup arasındaki ayrım netleşiyor. Startup dünyasında “çalışsın yeter” denebilir; enterprise’da işe gözden kaçan yüzde 10 bile faturaya dönüşüyor. Hele TL bazlı bütçe planlayan kurumlarda bu tür optimizasyonlar teoriden çıkıp doğrudan FinOps konusu oluyor.
Aman ha, unutmayın: noktalar neler?
E tabi her yeni özellik gibi bunun da gölgeli tarafları var. Alpha olması nedeniyle kararlı üretim davranışı beklemek doğru olmaz. Bir de selector mantığını yanlış kurgularsanız bazı objeleri hiç görmeme riski doğabilir. Bu konuda %100 emin değilim ama sanırım en kritik nokta test kapsamını gerçek veriyle kurmak;
- Eşit dağılımı doğrulayın: Hash range gerçekten dengeli mi bakın.
- Liveness/Readiness: Shard geçişlerinde pod davranışı temiz mi ölçün.
- Error budget: İlk etapta prod yerine staging’de yoğun yük simülasyonu yapın.
- Metrikler: CPU, memory ve network üçlüsünü birlikte izleyin. (bence en önemlisi)
Kendi deneyimlerimden kısa notlar
Açıkçası, Ağustos 2024’te İstanbul’daki bir SaaS müşterisinde benzer bir problemi yanlış yerde optimize ederek çözmeye çalışmıştık.
Önce cache ekledik… sonra cache invalidation yüzünden daha kötü öldü!
Sonra olayın aslında watch trafiğinde düğümlendiğini fark ettik.
O gün şunu tekrar gördüm: bazen parlak görünen çözüm değil, sade görünen mimarı değişiklik kazanır.
Ha bu arada, başka bir projede elimize geçen hata mesajı oldukça öğreticiydi:
“too many open files” hatası sandığımız şey aslında gereksiz watch yükünün yan etkisiydi.
Çözüm olarak watcher sayısını azaltıp iş bölümünü yeniden düzenlemiştik.”
Sıkça Sorulan Sorular
Kubernetes v1.36’daki server-side sharded watch nedir?
Kısaca söyleyeyim, yanı API server’ın event akışını shard’a göre filtrelemesi bu. Böylece her controller replica tüm veriyi almak zorunda kalmıyor; hani sadece kendi parçasını görüyor.
Bu da CPU, network ve memory yükünü düşürüyor.
(kendi tecrübem)
Bunu hemen production’da kullanmalı mıyım?
Açıkçası, hayır; en azından körlemesine kullanmayın. Alpha feature olduğu için önce staging’de gerçekçi load test yapın, sonra kademeli ilerleyin.
Sadece büyük cluster’larda mı işe yarar?
Daha çok büyük cluster’larda parlıyor aslında, ama orta ölçekli yapılarda da gözle görülür bir rahatlama verebilir. Bence kaynak maliyetiniz hassassa, küçük kazanç bile anlamlı sayılır (yanlış duymadınız)
Kube-state-metrics gibi araçlara uyuyor mu?
Evet, mantık olarak uyuyor; zaten makalenin ana hedeflerinden biri de mesela buna benzer horizontal çalışan controller senaryolarını rahatlatmak. Ama tecrübeme göre entegrasyon detaylarını kendi versiyonunuzla test etmeniz şart.
Kaynaklar ve İleri Okuma
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.
2 comments