Kubernetes v1.36 Pod-Level Resource Managers: Sidecar Derdi Bitiyor
Şu an saat gece yarısını geçti, ben hâlâ bir müşterinin AKS cluster’ı üzerinde topology manager ayarlarıyla uğraşıyorum (ben de ilk duyduğumda şaşırmıştım). ML inference workload’u NUMA hizalaması istiyor. Aynı pod içinde üç yardımcı container var: log forwarder, metrics exporter, bir de service mesh sidecar’ı. Klasik dert işte.
📋 İçindekiler
-
- Risk hesaplama motorları: Genelde C++ veya Rust ile yazılmış, NUMA-aware. Bunları AKS’e taşımak istiyorsunuz ama yanında compliance için audit sidecar, log forwarder, secret rotation agent gibi 3-4 yardımcı container da geliyor; yanı asıl işi yapan çekirdek kadar çevresindeki destek katmanı da başınızı ağrıtıyor.
- Trading bağlantı katmanı: FIX protokolü konuşan, mikrosaniye hassasiyetinde uygulamalar. Şu ana kadar Kubernetes’i ciddi ciddi masaya yatırmamışlardı; çünkü gecikme artarsa işin rengi hemen değişiyor, bunu sız de biliyorsunuz.
Bu kabiliyetin GA olduğunda (muhtemelen 2-3 release sonra) bu workload’ların buluta taşınmasının önündeki teknik bahanelerden biri daha ortadan kalkıyor (bu konuda ikircikliyim). Evet, bence burada ufak bir eşik atlanıyor; Türkiye’deki orta büyüklükteki bankalar için de “şey mi yapsak acaba?” dedirten türden bir kıpırdama yaratabilir.
Ama durun. Alpha özelliği production’a koymayın. Geçen ay bir müşteride alpha bir feature gate’in patch release’te davranış değiştirdiğini gördüm; pod’lar restart loop’a girdi ve sabah kahvesi içmeden önce ekibin morali baya düştü. Hoş değildi.
Maliyet Tarafı: TL Bazında Düşünelim
Şahsen, Azure’da Standard_D16s_v5 bir node alıyorsunuz; aylık kabaca 320-380 dolar bandı. 16 vCPU var. Diyelim ki bu node üzerinde 4 tane performance-critical pod koşturuyorsunuz, her birinin içinde ana container var ve üstüne 3 sidecar eklemişsiniz.
Eski düzende, Guaranteed tarafını korumak için her sidecar’a 1 core integer vermek zorundaydınız. Basit hesapla bakınca iş komikleşiyor biraz: 4 pod × 3 sidecar × 1 core = 12 core,. Sadece sidecar’lar için ayrılmış kaynak. Bu da node’un %75’i ediyor; halbuki gerçek tüketim belki toplamda 2 core civarıdır, hatta bazı günler daha da aşağı iner.
Pod-level ile tablo biraz değişiyor. Sidecar’lar shared pool içinde ortalama 0.2-0.3 core tüketiyor, yanı aynı node’a 8-10 pod sığdırmak mümkün oluyor. Kâğıt üstünde kabaca 2x consolidation görüyorsunuz. Bu, “fatura yarıya indi” demek değil tabiî; workload profili yerine oturana kadar 2-3 ay test etmek lazım, bazen beklediğinizden sapıyor, ama yön net şekilde oraya gidiyor.
💡 Bilgi: FinOps tarafında bu tür optimize etmeları ölçmek için Azure Cost Management + Container Insights kombinasyonunu öneriyorum. Pod bazında gerçek CPU tüketimini görmeden hangi workload’un pod-level’a uygun olduğunu anlamak zor; şey gibi düşünün, gözünüz kapalı ayar yapmaya benziyor biraz.Nasıl Aktive Edilir? Adım Adım
Ne yalan söyleyeyim, Bu özellik şu an alpha, yanı default kapalı (kendi tecrübem). Test cluster’ınızda denemek için önce ortamı biraz kurcalamanız gerekiyor; çünkü işin aslı, tek bir ayar açıp geçmiyorsunuz, kubelet, API server, manager policy’ler. Node tarafı birlikte aynı hizaya gelince bu hibrit allocation davranışı ortaya çıkıyor.
- kubelet config’inde feature gate’leri açın:
PodLevelResources=truevePodLevelResourceManagers=true - API server tarafında da aynı gate’leri etkinleştirin
- Topology Manager scope’ünü
podolarak ayarlayın - CPU Manager policy’sını
staticyapın - Memory Manager policy’sını
Staticayarlayın - Test pod’unuzu yukarıdaki YAML formatında deploy edin
kubectl describe nodeve cgroup yapısını inceleyerek hibrit allocation’ı doğrulayın
Evet. Ama burada küçük bir detay var. İlginç, değil mi? AKS’te bu feature gate’leri açmak şu an mümkün değil; Microsoft yönetilen control plane’de alpha gate’leri kapatıyor, dolayısıyla bunu deneyecekseniz kendi kurduğunuz bir cluster lazım (kubeadm, kops ya da on-prem fark etmez), yoksa boşuna uğraşırsınız.
Ve işler burada ilginçleşiyor.
İnanın, Neyse, çok dağıtmayayım. Yukarıda bahsettiğim o bellek tarafı var ya, işte önü da birlikte düşünmek gerekiyor. Bu konu sadece CPU yerleşimi gibi görünse de Memory QoS ile yan yana geldiğinde tablo daha anlamlı oluyor. Bu yazıda ona da değinmiştim: Kubernetes v1.36 Memory QoS: Katmanlı Bellek Koruması Geldi
Eksikler ve Uyarılar
Açık konuşayım, Açık konuşayım, alpha bir özellikte insan biraz daha fazla sürpriz bekliyor, ama bazı taraflar hâlâ tam oturmamış gibi dürüyor. Mesela bir yandan iş görüyor, öte yandan “burada bir şey eksik galiba” dedirtiyor; özellikle de test ortamında birkaç edge case görünce insanın aklına hemen aynı soru geliyor: bu kısım production’da ne yapacak?
- Pod resize ile etkileşim: Pod’un resource’ünü in-place değiştirmek (v1.33’le gelen başka bir özellik) bu yapıyla nasıl çalışıyor, henüz net dokümante edilmemiş. Test ettim, bazı edge case’lerde shared pool yeniden hesaplanmıyor gibi.
- Init container davranışı: Sidecar olarak çalışan init container’lar (yukarıdaki örnekteki
restartPolicy: Always) shared pool’a dahil. Ama klasik init container’lar (kısa ömürlü olanlar) farklı muamele görüyor. - Observability: Pod shared pool’ünün gerçek kullanımını görmek için metrics henüz yetersiz. Prometheus tarafında container-level metrik’ler var ama “pool-level” yok.
Neyse, çok dağıtmayayım, işin özünde tablo şu: kağıt üstünde baya iyi dürüyor, pratikte işe biraz daha izlemek lazım. Evet. Beta’ya geçince tekrar kurcalayıp daha derin yazacağım, çünkü o noktada bazı şeyler ya netleşir ya da iyice belli olur; ikisi de işimize yarar aslında.
Bu Özellik Kimleri Etkileyecek?
Hızlıca segment edeyim, çünkü konu biraz dağılıyor gibi dürüyor ama aslında hedef kitle net.
- Küçük ekip / startup: Şimdilik kafanıza takmayin. Burstable QoS ile devam edin, yetiyor; hatta çoğu senaryoda gayet is görüyor, yanı ekstra bir maceraya girmenize gerek yok. (bu kritik)
- Orta ölçek SaaS: Roadmap’inize alın, GA olduğunda bir bakın derim. Maliyet optimizasyonu tarafında farkı hissedince “hmm, fena değilmiş” deme ihtimaliniz yüksek.
- Enterprise / finans / telekom: Şimdiden bir POC cluster kurun. Hangi workload’lar aday olur, tek tek ayıklayın; çünkü GA günü gelip de acele etmek istemezsiniz, orada ufak bir gecikme bile can sıkabiliyor.
- HPC / ML platform takımları: Bu sizin için beklenenden daha büyük bir adım olabilir. NUMA hizalamasini ve inference tarafındaki davranışı bilenler ne demek istedigimi anlar; bilmeyenler için işe ilk testte sürat asma ihtimali var.
Kubernetes ekosistemindeki diğer kaynak yönetimi gelişmelerini takip etmek isteyenler için Kubernetes v1.36 Controller Staleness: Bayat Cache Sorunu Bitti mi? ve Kubernetes v1.36 User Namespaces GA: Root Artık Gerçek Root Değil yazilarimi da öneririm — v1.36 release’i baya yüklü geldi, açık konuşayım.
Sıkça Sorulan Sorular
Pod-level resources ne zaman GA oluyor?
Kubernetes’te alpha’dan GA’ya geçiş genelde 3-4 release sürüyor. Yanı aslında v1.39 veya v1.40 civarında, hani yaklaşık 1-1.5 yıl içinde GA görebiliriz. Neden önemli bu? Tabiî bu bir tahmin — SIG-Node ekibi gelen feedback’e göre süreyi uzatabilir, bence bu ihtimali de göz önünde bulundurmakta fayda var.
Mevcut Guaranteed QoS pod’larım etkilenir mi?
Hayır, hiçbir şey değişmiyor. Pod-level resources tamamen opt-in bir özellik, yanı kimse sizi zorlamıyor.
spec.resourcesalanını pod seviyesinde tanımlamadığınız sürece her şey eskisi gibi çalışmaya devam ediyor. Geriye dönük uyumluluk korunuyor, açıkçası bu konuda endişelenmenize gerek yok.AKS’te kullanabilir mıyım?
Şu an maalesef hayır. Microsoft’un yönettiği AKS control plane’inde alpha feature gate’ler kapalı tutuluyor. Tecrübeme göre bu tür özellikler beta’ya geçince AKS preview kanalıyla geliyor, önü bekliyorum. Şimdilik denemek istiyorsanız kendi yönettiğiniz cluster’lara bakın — kubeadm, AKS Edge Essentials veya on-prem gibi seçenekler var.
Pod shared pool ile node-level shared pool arasındaki fark ne?
Aslında ikisi oldukça farklı şeyler. Node-level shared pool, o node’daki tüm Burstable ve BestEffort pod’ların ortak kullandığı CPU havuzu. Pod-level shared pool işe sadece o pod içindeki sidecar’ların paylaştığı, node’un geri kalanından izole küçük bir alt havuz. Bir de şu önemli fark var: NUMA hizalaması pod bazında yapılıyor, mesela bu performans açısından ciddi bir avantaj sağlayabiliyor.
Hangi Topology Manager scope’ünü seçmeliyim?
Pod-level resources kullanıyorsanız
podscope çok daha mantıklı — kubelet tüm pod’u tek bir bütçe olarak değerlendiriyor.containerscope’ta her container ayrı ayrı NUMA hizalanıyor, hani bu da sidecar’lı yapılarda dağılmaya yol açabiliyor. Bence en iyi kombinasyon pod-level + pod scope, genel öneri de bu yönde zaten (kendi tecrübem)Kaynaklar ve İleri Okuma
Kubernetes v1.36: Pod-Level Resource Managers (Alpha) — Resmî Blog
Kubernetes Topology Manager Dokümantasyonu
Pod Quality of Service Classes
KEP-2837: Pod-Level Resource Specifications
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Elif D.
Sidecar’lar için ayrı ayrı resources tanımlamak gerçekten baş ağrısıydı, özellikle Istio proxy’si olan cluster’larda limits hesaplamak kabus oluyordu. Bu değişiklik production’da ne kadar stabil çalışıyor merak ediyorum, alpha aşamasında deneyen oldu mu acaba?
Gökhan İ.
Sidecar’lar yüzünden QoS’u düşürmek zorunda kalmak gerçekten can sıkıcıydı, özellikle Guaranteed pod’larla çalışırken. NUMA hizalaması tarafı production’da nasıl davranıyor merak ediyorum, bunu test eden oldu mu acaba?
Hakan G.
Sidecar’lar için ayrı ayrı resource tanımlamak gerçekten baş ağrısıydı, özellikle Istio gibi bir şey kullanıyorsanız request/limit hesapları çığ gibi büyüyordu. Pod seviyesinde yönetim mantıklı bir adım ama NUMA hizalamasını nasıl koruduklarını merak ediyorum, biraz daha teknik detay görmek isterdim.
Yorumlar kapalı.
3 comments