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.

Eskiden böyle durumda iki yol vardı. Ya tüm container’lara integer CPU verirdin (sidecar’a iki core ayırmak gibi biraz tuhaf bir iş), ya da Guaranteed QoS’u kenara iterdin. İkisi de iç açmıyor. Bakın, peki neden?

Neyse. Kubernetes v1.36 ile gelen Pod-Level Resource Managers alpha özelliği, tam da bu sıkıntının üstüne geliyor. Bu yazıda hem teknik tarafına bakacağım hem de Türkiye’deki kurumsal müşterilerde bunun neye denk geldiğini, yanı pratikte gerçekten iş görüp görmediğini anlatacağım.

Önce Sorunu Net Görelim

Modern Kubernetes pod’ları artık tek container’dan ibaret değil. Hatta açık konuşayım, tek container’lı pod görmeyeli epey öldü. Genelde bir ana uygulama var, yanında da iki üç sidecar dolaşıyor; işte düzen böyle oturdu (buna dikkat edin)

Performans-hayati workload’larda (ML training, yüksek frekanslı trading, düşük gecikmeli veritabanları) ana uygulamanın NUMA-aligned ve özel CPU/bellek slice’larına ihtiyacı oluyor. Bu yoksa gecikme tarafı biraz saçmalıyor, tahmin edilebilir davranış alamıyorsunuz; ama yan container’ların böyle bir derdi pek yok, bir log forwarder’ın 100 milicore ile gayet yaşadığını ben defalarca gördüm.

Eski dünyada ne oluyordu? Ana container’a NUMA hizalı core verebilmek için pod’un tamamı Guaranteed QoS olmak zorundaydı. Bu da şuna çıkıyordu: her container için integer CPU yazacaksın, memory request ile limit’i de eşitleyeceksin; sonra sidecar’a 2 core ayırıp orada boş yere bekleteceksin ya da bu yükü kabul etmeyip ana uygulamayı Burstable’a iteceksin — exclusive CPU gidiyor, NUMA pinning gidiyor, performans da hâliyle el sallayıp uzaklaşıyor.

Durun, bir saniye.

Bir bankacılık projesinde tam bu yüzden 40 node’lük bir cluster’da hesap yaptığımızda, sırf sidecar’lara verilen gereksiz exclusive CPU toplamı aylık ciddi rakamlara ulaşıyordu. Az değil, baya para gidiyordu.

Pod-Level Resource Managers Ne Getiriyor?

Şöyle söyleyeyim, Yeni özellikle birlikte kubelet, kaynak işini container bazından pod bazına kaydırabiliyor. Yanı spec.resources alanını pod seviyesinde yazıyorsun, kubelet de bunu tek parça gibi görüyor; işte olayın özü bu, fazla süs yok.

İki feature gate açman gerekiyor:

• PodLevelResources — pod seviyesinde resource tanımı için
• PodLevelResourceManagers — Topology, CPU ve Memory Manager’ların pod-aware çalışması için

Sonuçta ortaya hibrit bir kaynak modeli çıkıyor. Ana container exclusive çalışıyor, NUMA ile hizalanıyor, sidecar’lar işe pod’un kalan bütçesinden paylaşımlı havuzda dönüyor; hepsi aynı NUMA node’unda kalabiliyor. Izolasyon seviyesi aynı olmuyor, yanı kafa karıştıran tarafı da burada biraz var (inanın bana)

Evet.

Topology Manager Scope: Pod vs Container

Bi saniye — Burada küçük ama hayatı bir nokta var, atlamayalım. Topology Manager’ın iki scope’u var: container ve pod. Pod-level resources özelliği devreye girince pod scope daha anlamlı hâle geliyor,. Kubelet artık tüm pod’u tek bir NUMA bütçesi gibi ele alıyor; açık konuşayım, bu yaklaşım çoğu senaryoda daha temiz dürüyor (ki bu çoğu kişinin gözünden kaçıyor)

Yanı, Peki neden? Container scope’ta her container ayrı ayrı NUMA hizalanıyordu ve bazen aynı pod içindeki container’lar farklı NUMA node’larına düşüyordu, bu da performans tarafında can sıkabiliyordu; pod scope’ta bu dağınıklık azalıyor, hatta bazı yerlerde baya toparlıyor.

Yanı, Neyse, çok dağıttım, konumuza dönelim. Yanı özetle container bazlı düşünürsen ayrışma artıyor, pod bazlı düşünürsen kubelet bütün resmî birlikte görüyor; bu kadar mı? Tam olarak değil (buna dikkat edin). Ana fikir bu.

Pratik Örnek: Latency-Sensitive Database

İtiraf edeyim, Diyelim elinizde bir PostgreSQL pod’u var. Ana DB container’ının yanında bir metrics exporter ve bir backup agent çalışıyor. Toplam bütçe 8 core ve 16Gi bellek. Sız de “DB 6 core’u alsın, kalan 2 core sidecar’lar arasında ortak dursun” diyorsunuz. Basit gibi dürüyor, ama işin içine latency girince olay biraz kıvrılıyor.

apiVersion: v1
kind: Pod
metadata:
name: tightly-coupled-database
spec:
resources:
requests:
cpu: "8"
memory: "16Gi"
limits:
cpu: "8"
memory: "16Gi"
initContainers:
— name: metrics-exporter
image: metrics-exporter:v1
restartPolicy: Always
— name: backup-agent
image: backup-agent:v1
restartPolicy: Always
containers:
— name: database
image: postgres:16
resources:
requests:
cpu: "6"
memory: "12Gi"
limits:
cpu: "6"
memory: "12Gi"

Burada olan şey şu aslında. Pod seviyesinde 8 CPU ve 16Gi tanımlıyorsunuz, sonra database container’ına bunun 6 core’ünü exclusive veriyorsunuz; NUMA tarafı da hizalı kalıyor, yanı gecikme açısından fena değil. Kalan 2 core ile 4Gi bellek işe pod shared pool oluyor, sidecar’lar da bu havuzda takılıyor — birbirleriyle paylaşıyorlar ama node’un geri kalanına taşmıyorlar.

Kısa bir not düşeyim buraya.

İlginç olan şu ki, Evet, can alıcı nokta bu. DB’nın çekirdeklerine kimse dokunamıyor, sidecar’lar da boşuna ayrı ayrı dedicated core tüketmiyor; biri log toplarken öteki yedek alıyor diye kaynak israfı çıkmıyor (ben de ilk duyduğumda şaşırmıştım). Açık konuşayım, burada amaç iki tarafı da memnun etmek, biraz garip ama baya işe yarıyor.

Senaryolara Göre Yaklaşım: Karşılaştırma

Şöyle ki, Bu özelliği kim nasıl kullanacak, bunu bana da çok sordular. Ben de oturup basit bir tablo çıkardım, çünkü bazen iki paragraf yazmak yerine düz bir karşılaştırma daha çok is görüyor, hele konu CPU, NUMA, sidecar ve izolasyon olunca is iyice dağılıyor.

Araya gireyim: Son satır bence kritik. Her workload için bu özelliğe atlamaniz gerekmiyor; hatta bazen hiç gerek yok, açık konuşayım. Eğer NUMA hizalamasi, exclusive CPU pinning ya da benzeri ince ayarlar sizin için dert değilse, Burstable QoS zaten işi idare ediyor.

Çok konuştum, örnekle göstereyim. Daha fazla bilgi için Gateway API v1.5: Altı Özellik Stable Oldu, Ne … yazımıza bakabilirsiniz.

Peki neden? Çünkü her senaryo aynı değil. Bir tarafta milisaniye kovalanan sistemler var, öte tarafta gayet sakın çalışan web uygulamaları; ikisini aynı kefeye koyunca kafa karışıyor. Neyse uzatmayalım, ihtiyacı olan kullansın, gerisi klasik yaklaşımla devam edebilir.

Türkiye’deki Kurumsal Müşteriler Açısından

Aslında, Şimdi işin beni en çok kurcalayan tarafına geleyim. Logosoft’ta danışmanlık verdiğim müşterilerin epey bir kısmı Kubernetes’e geçti, ama performance-critical workload dediğimiz işler hâlâ VM tarafında kalıyor; hani bulut var, container var, her şey modern görünüyor, sonra bir bakıyorsunuz kritik parça yine eski düzende dürüyor.

Sebep ne? Kısa cevap şu: kubelet bazı yerlerde yetmiyor. Uzun cevap işe biraz daha can sıkıcı, çünkü konu sadece “container çalışsın” meselesi değil (özellikle düşük gecikme, sıkı kaynak kontrolü. Yan araçların yarattığı ek yük birleşince), o noktada Kubernetes’in vaadi ile gerçek hayat arasında küçük bir boşluk oluşuyor.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Hani, Hele bir de de finans sektöründe iki senaryo öne çıkıyor: Azure DocumentDB ile Bankalarda Customer 360: D… yazımızda bu konuya da değinmiştik.

1. 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.
2. 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. VSTest Newtonsoft.Json Bağımlılığını Atıyor: Ne… yazımızda bu konuya da değinmiştik.

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. Azure Developer CLI Nisan 2026: Çok Dilli Hook … yazımızda bu konuya da değinmiştik.

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. Daha fazla bilgi için Visual Studio 2026 Insiders 3’te TypeScript 7 B… yazımıza bakabilirsiniz.

1. kubelet config’inde feature gate’leri açın: PodLevelResources=true ve PodLevelResourceManagers=true
2. API server tarafında da aynı gate’leri etkinleştirin
3. Topology Manager scope’ünü pod olarak ayarlayın
4. CPU Manager policy’sını static yapın
5. Memory Manager policy’sını Static ayarlayın
6. Test pod’unuzu yukarıdaki YAML formatında deploy edin
7. kubectl describe node ve 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.resources alanı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 pod scope çok daha mantıklı — kubelet tüm pod’u tek bir bütçe olarak değerlendiriyor. container scope’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

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Azure DevOps Server Şubat Yaması: Güvenlik ve Performans11 Mar 2026

Bulut Maliyet Optimizasyonu: Hâlâ Geçerli Prensipler19 Nis 2026

Codex Kurumsal Ölçekte: Ne Vaat Ediyor, Ne Eksik?21 Nis 2026

SELinux Volume Label Değişikliği: v1.37 Öncesi Hazırlık23 Nis 2026