Kubernetes v1.36 Memory QoS: Katmanlı Bellek Koruması Geldi
Geçen hafta bir e-ticaret müşterimizin AKS cluster’ında garip bir şey öldü. Black Friday hazırlığı için kapasiteyi yokluyorduk, node’lardan biri inatla sistem-wide OOM kill yiyor, ama işin can sıkıcı tarafı şu: Pod’ların hiçbiri limit’ını aşmıyordu. Sebep neydi? Burstable Pod’ların toplam request’i node belleğinin neredeyse %85’ine dayanmıştı. Eski Memory QoS davranışı yüzünden bu bellek memory.min gibi kenara ayrılmıştı; yanı kernel’e resmen sıkışacak yer kalmamıştı.
Türkiye’deki Kurumsal Yapıda Bu Ne Anlama Geliyor?
İnanın, Burası kritik. Müşterilerde gördüğüm tablo şu: Türkiye’de Kubernetes’e geçiş çoğu zaman biraz “lift and shift” kafasıyla ilerliyor. Yanı VM döneminden kalan alışkanlıklar sürüyor, request. Limit değerleri de ona göre şişiriliyor — hani “bir ihtimal lazım olur” diye. Sonuç da pek şaşırtmıyor; node’lar gereğinden fazla yük alıyor ama workload’lar yine de Burstable QoS tarafında kalıyor.
Durun, bir saniye.
Garip gelecek ama, Bu profil, eski Memory QoS davranışıyla pek iyi anlaşmıyordu. Açtığınız anda node’lar sıkışmaya başlıyordu, hatta bazen nefes bile alamıyordu (evet, doğru duydunuz). v1.36 ile gelen TieredReservation işe tam bu noktada daha mantıklı dürüyor; Burstable workload’lar memory.low üzerinden esnek bir koruma alıyor, sistem de daha rahat toparlanıyor.
Size bir şey söyleyeyim, Bir de FinOps tarafı var tabiî. Doğru kullanıldığında Memory QoS, node utilization’ı %20-30 civarında artırabiliyor. Çünkü ortada artık “ya lazım olursa” diye kenarda bekletilen bellek yerine, kernel’in işi biraz daha akıllıca paylaştırdığı bir yapı var. Azure’da D-serisi node’ları düşününce TL hesabı da hemen kendini gösteriyor — mesela 10 node’lük bir cluster’da 2-3 node azaltmak, ay sonunda hiç fena olmayan bir tasarruf çıkarabiliyor. Hesabı sız yapın.
Pratik Uygulama: Nereden Başlamalı?
Şimdi işin pratik tarafına geçelim. Bu özelliği bugün yoklamak istiyorsanız, ben olsam önce lab ortamında denerim; production’a dalmak biraz acele olur, alpha bir özellik için hele hiç olmaz.
- Önce dev/staging cluster’ında deneyin. Alpha bir feature, production’a koşmayın.
- Kernel sürümünü doğrulayın — en az 5.15 hedefleyin.
- Cgroup v2 zorunlu. Hâlâ v1’deyseniz önce o işi halledin (containerd 1.7+ ve uygun systemd config gerekiyor).
- Feature gate’i açın: kubelet’e
--feature-gates=MemoryQoS=trueekleyin. - İlk olarak
memoryReservationPolicy: Noneile başlayın. Sadece throttling’i izleyin. - Bir-iki hafta gözlem yapın.
memory.highthrottling’i pod’larınızı boğuyor mu? Latency artışı var mı? - Sorun yoksa
TieredReservation‘a geçin. Yeni metriklerle node kapasitesini izleyin.
Peki neden böyle başlıyoruz? Çünkü burada asıl mesele, özelliği açtım öldü demek değil; davranışı sakın sakın görmek (özellikle latency ve throttling tarafında), sonra da node kapasitesini yanlış okumadığınızdan emin olmak.
Neyse, biraz dağıldım ama konuya dönelim. Yukarıdaki yazıda anlattığım kullanıcı namespace değişikliğiyle bu MemoryQoS konusu yan yana düşünülünce tablo daha net oluyor; biri yetki sınırını sıkılaştırıyor, diğeri de belleği daha kontrollü kullanmaya zorluyor, yanı ikisi birlikte cluster davranışını baya etkiliyor (ben de ilk duyduğumda şaşırmıştım)
Evet.
Kısacası, küçükten başlayın ve ölçerek ilerleyin. Bir anda her şeyi açıp sonra “neden node nefes alamıyor” diye bakmak yerine, önce gözlem yapın; açık konuşayım, bu yaklaşım çoğu zaman daha az baş ağrıtır.
Küçük vs Büyük Ekipler İçin Tavsiyeler
Küçük ekip / Startup
Küçük bir detay: Açık konuşayım, bu özelliği şimdilik kenara koyun. Alpha feature’larla boğuşmak yerine düzgün resource request/limit yazmaya odaklanın; AKS’in default davranışı da çoğu zaman iş görüyor, hatta çoğu startup için ekstra bir şey kurmadan önce asıl mesele zaten orada yatıyor. Eğer node’larınız OOM yiyorsa, sebep büyük ihtimalle Memory QoS değil. Yanlış sizing’dır. Önce önü düzeltin.
Enterprise / Büyük cluster operatörü
Burada iş biraz değişiyor. 50+ node’lük cluster’larda, multi-tenant workload’larda Memory QoS baya işe yarayabiliyor; özellikle de “noisy neighbor” derdi yaşayan platform ekipleri için bu konu masaya gelmeli, çünkü aynı node üzerinde birbirinin ayağına basan işler olunca standart ayarlar bazen idare eder ama yetmez. Ben kendi danışmanlık projelerimde 100+ node’lu cluster’larda PoC yapmaya başladım bile. İlk geri bildirimler fena değil — özellikle memory.low‘un Burstable workload’lar için yumuşak koruma sağlaması, ekiplerin gözüne girdi.
Eksik Tarafları da Konuşalım
Şimdi işin diğer yüzü. Bu özellik hâlâ alpha, ve açık konuşayım, beni biraz soğutan birkaç detay var.
Birincisi şu: Pod-level QoS ayarı yok (şaşırtıcı ama gerçek). Yanı namespace bazında ya da Pod annotation ile “bu workload’a memory.low yerine memory.min ver” diyemiyorsunuz; her şey gidip QoS sınıfına bağlanıyor, bu da pratikte biraz dar bir alan bırakıyor. Halbuki gerçek hayatta “Burstable ama kritik” dediğimiz işler çıkıyor, mesela bir order-processing servisi gibi.
İkincisi, swap tarafı hâlâ biraz karışık. v1.30 ile gelen swap desteği var ama Memory QoS bununla nasıl davranacak, dökümantasyonda bence yeterince net değil; test ortamında kurcaladığımda sonuçlar da tam tahmin ettiğim gibi çıkmadı, hatta birkaç yerde şaşırdım açıkçası.
Üçüncüsü işe daha net: Windows node tarafında yok. Linux-only bir feature olduğu için hibrit cluster çalıştıranlar açısından deneyim biraz yamalı dürüyor.
Sıkça Sorulan Sorular
Memory QoS’i production’da açayım mı?
Açıkçası, hâlâ alpha aşamasında olduğu için net bir “evet” diyemem. Ama dev/staging ortamında muhtemelen bir deneyin — bence çok şey öğreniyorsunuz o süreçte. Beta’ya geçince, yanı muhtemelen v1.38 ya da v1.39’da, production’a kontrollü şekilde alabilirsiniz. Acelesi yok. Throttling sorunu yaşamıyorsanız beklemek en mantıklısı.
cgroup v1 ile çalışıyor mu?
Burada, küçük bir detay: Hayır, çalışmıyor. Memory QoS tamamen cgroup v2’nın memory controller özelliklerine dayanıyor, yanı v1 ile işinizi göremezsiniz. Hâlâ cgroup v1 kullanıyorsanız önce o geçişi halletmeniz lazım. Neyse ki modern container runtime’lar, hani containerd 1.7+ veya CRI-O 1.25+ gibi, cgroup v2’yi zaten destekliyor.
Kısa bir not düşeyim buraya.
memory.high throttling Pod’umu yavaşlatır mı?
Evet, eşiği geçince yavaşlatıyor. Varsayılan memoryThrottlingFactor değeri 0.9, yanı limit’in %90’ına gelince throttling devreye giriyor. Mesela real-time ödeme sistemi gibi latency-sensitive bir şey çalıştırıyorsanız bu factor’ü 0.95’e çekmeyi düşünebilirsiniz. Ya da — tecrübeme göre daha temiz çözüm — o workload’ları direkt Guaranteed QoS’e taşıyın.
AKS, EKS, GKE’de bu özellik var mı?
v1.36 daha çok yeni ve managed servislerde alpha feature’lar genelde varsayılan olarak kapalı geliyor. AKS’te custom kubelet config ile açabilirsiniz ama açıkçası dikkatli olun — Microsoft’un desteği olmadan bir sorun çıkarsa zor durumda kalabilirsiniz. EKS ve GKE de aşağı yukarı aynı durumda.
Burstable bir Pod’a Guaranteed gibi sert koruma verebilir mıyım?
Aslında, Şu an v1.36’da bunu yapmanın bir yolu yok. Tek seçenek Pod’u Guaranteed QoS sınıfına taşımak, hani request ve limit değerlerini eşitlemek. Bu da aslında bellek esnekliğinizden vazgeçmek demek oluyor. Topluluk granular kontrol için RFC tartışıyor ama bence yakın zamanda bir şey gelmesini beklemeyin.
Kaynaklar ve İleri Okuma
Kubernetes v1.36: Tiered Memory Protection with Memory QoS — Resmî Blog
Kubernetes Pod QoS Sınıfları — Resmî Dokümantasyon
Yanı, Linux Kernel cgroup v2 Memory Controller Dokümantasyonu
Yanı, KEP-2570: Memory QoS Enhancement Proposal (GitHub)
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.
3 comments