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 MSVC Build Tools Preview Mayıs 2026: Derleyicide Sessiz Ama Kritik Güncellemeler yazımıza bakabilirsiniz.
Bana göre burada güzel olan şey şu: filtreleme işi ağın kenarında değil, merkezde çözülüyor. Küçük startup ekipleri için bu belki erken aşamada şart değil ama enterprise tarafta fark hemen hissedilir; çünkü orada sorun çoğu zaman “çalışıyor mu?” değil, “kaç milyon event’i boşuna işledik?” sorusu oluyor. Bu konuyla ilgili PowerShell Paketlerini Güvenli Yönetmek: PSResourceGet’te Yeni Dönem yazımıza da göz atmanızı tavsiye ederim.
| Ayak | Klasik client-side shard | Server-side shard |
|---|---|---|
| Ağ trafiği | Tüm replikalara tam akış gider | Sadece ilgili slice gider |
| CPU tüketimi | Yüksek, gereksiz deserialize var | Daha düşük, filtreleme upstream’de yapılır |
| Mimarı karmaşıklık | Daha basit görünür ama pahalıdır | Daha iyi ölçeklenir, fakat alpha riskleri var |
| Kullanım alanı | Düşük/orta hacimlerde idare eder | Büyük cluster ve yoğun controller senaryoları için uygun |
Kod tarafında ne değişiyor?
Bence, İlk bakışta çok büyük refactor beklemeyin; mevcut informer yapısı korunuyor gibi düşünebilirsiniz. Asıl fark ListOptions içine eklenen shard selector’da yatıyor.
Aslında — dur bir saniye — bunu uygulamak için controller mimarisini baştan aşağı değiştirmek gerekmiyor (kendi tecrübem)
import (
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/client-go/informers"
)
shardSelector := "shardRange(object.metadata.uid, '0x0000000000000000', '0x8000000000000000')"
factory := informers.NewSharedInformerFactoryWithOptions(
client,
resyncPeriod,
informers.WithTweakListOptions(func(opts *metav1.ListOptions) {
opts.ShardSelector = shardSelector
}),
)Bunu ilk gördüğümde aklıma hemen AZ-305 hazırlığında tartıştığımız dağıtık tasarım desenleri geldi: işi tüketiciye bırakmak yerine kaynağın yanında çözmek çoğu zaman daha temiz olurdu ya hani (ki bu çoğu kişinin gözünden kaçıyor). Burada da aynı mantık var. Bu konuyla ilgili Azure IaaS’te Savunma Katmanları: Güvenlik Nasıl Oturuyor? yazımıza da göz atmanızı tavsiye ederim.
Bir de şunu unutmamak lazım: desteklenen field path’ler şu an sınırlı olabilir — örneğin object.metadata.uid ve object.metadata.namespace. Bu yüzden çok özgürmüşsün gibi davranıp her şeyi buna bağlamak biraz hayal kırıklığı yaratabilir. GitHub Copilot for Eclipse Açık Kaynak Oldu: Bu Ne Değiştiriyor? yazımızda bu konuya da değinmiştik. Daha fazla bilgi için C#’ta Bellek Güvenliği Neden Şimdi Daha Önemli? yazımıza bakabilirsiniz.
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments