Kubernetes v1.36: Workload-Aware Scheduling Yeni Boyutta

Geçen hafta bir telekom müşterimizde AI eğitim cluster’ı tasarlarken ekipten genç bir mühendis şunu sordu: “Hocam, 64 GPU’lu bir training job’ı Kubernetes’e atıyoruz, neden bazen 60 pod ayağa kalkıp 4’ü pending’de kalınca tüm iş çakılı kalıyor?”. Klasik mesele. Klasik cevap da belli: gang scheduling yoksa, ya hep ya hiç mantığı bir yerde duvara tosluyor.

İşte tam burada Kubernetes v1.36 ile gelen workload-aware scheduling güncellemeleri devreye giriyor. v1.35’te temel atılmıştı, şimdi iş biraz daha oturmuş durumda. Lafı gevelemeden söyleyeyim — bu sürüm, batch ve AI/ML iş yüklerini Kubernetes’te düzgün koşturmak isteyenler için baya önemli bir dönemeç.

Kısa bir not düşeyim buraya.

Önce Şu Workload API’yi Doğru Anlayalım

v1.35’te Workload nesnesi hem şablon hem de runtime state’i aynı yerde tutuyordu. Yanı aynı obje hem “ben böyle bir grup pod istiyorum” diyordu, hem de “şu an grubun 3 üyesi running, 1’i pending” bilgisini taşıyordu. Kağıt üstünde sade dürüyor ama pratikte… eh, işler öyle yürümüyor.

Hani, Şöyle düşünün: 500 replikalı bir batch job’ınız var. Her status update’i tek bir Workload nesnesine yazmaya kalkarsanız, etcd tarafında write contention görmeniz işten bile değil. Logosoft’ta bir bankacılık projesinde benzer bir mimarı yüzünden API server’ın yığıldığını görmüştük — o yüzden bu ayrıştırma bana oldukça mantıklı geliyor.

Kısa bir not düşeyim buraya.

v1.36’da gelen yeni model şu: Workload artık sadece bir static template. PodGroup işe runtime’da yaşayan, replika başına shard edilebilen ayrı bir nesne. API grubu da değişti: scheduling.k8s.io/v1alpha2. v1alpha1 büyük ölçüde rafa kalktı, yanı eski yamaları bir gözden geçirmek lazım.

Yeni Workload Tanımı Nasıl Görünüyor?

apiVersion: scheduling.k8s.io/v1alpha2
kind: Workload
metadata:
name: training-job-workload
namespace: ml-prod
spec:
podGroupTemplates:
— name: workers
schedulingPolicy:
gang:
# 4 pod aynı anda çalışamıyorsa hiçbiri başlamaz
minCount: 4

Bu template’ten controller’lar (mesela Job controller) runtime’da PodGroup instance’ları üretiyor. Her PodGroup kendi status’ünü ayrı tuttuğu için yatay ölçeklenme daha rahat hâle geliyor. Scheduler artık Workload’u sürekli watch etmek zorunda da değil — doğrudan PodGroup’a bakıyor. Küçük gibi duran bu detay aslında scheduler’ın CPU yükünü ciddi azaltan bir hamle.

Gang Scheduling: Ya Hep Ya Hiç Mantığı

Araya gireyim: AI/ML eğitimi yapanların en iyi bildiği konu bu zaten. Distributed training’de 8 worker’dan biri ayağa kalkamazsa, bir düşüneyim… diğer 7’si boş yere CPU/GPU yakıyor. Default-scheduler işe pod pod bakıp kaynak varsa atadığı için bu senaryoda patlıyor.

v1.36’daki PodGroup scheduling cycle, tam olarak bunu toparlamak için tasarlanmış. Scheduler artık PodGroup’u atomik bir blok gibi değerlendiriyor. Yanı ya grup üyelerinin hepsi için yeterli node bulunuyor. Topluca bind ediliyor, ya da hiçbiri yerleşmiyor; beklemede kalıyorlar. Daha fazla bilgi için Microsoft SQL ile Agentic AI Güvenliği: Katman Katman Savunma yazımıza bakabilirsiniz.

Bunu Türkiye’deki şirketler açısından düşünürsek mesele netleşiyor: GPU saatleri ucuz değil. Bir A100’ün saatlik ücreti az buz değil. Pod’ların yarısı boşta beklerken diğerleri çalışırsa, o GPU saatleri resmen çöpe gidiyor. Gang scheduling sadece teknik detay değil — direkt FinOps konusu.

Volcano veya Kueue ile Karıştırmayın

Burada küçük bir parantez açayım. Bugüne kadar gang scheduling gerektiğinde Volcano, Kueue veya YuniKorn gibi üçüncü parti scheduler’lara bakıyordunuz. Peki şimdi bunlar bitti mi? Hayır, bitmedi. Çünkü v1.36’daki implementasyon hâlâ alpha seviyesinde ve üretimde kullanmak için biraz daha olgunlaşması gerekiyor bence. Ama yönün upstream tarafında sahiplenilmiş olması başlı başına değerli.

Topology-Aware Scheduling ve Preemption

Neyse ki işin en ilginç tarafı burada başlıyor gibi dürüyor. v1.36 iki yeni yetenek getiriyor: Red Hat Summit 2026: Azure OpenShift ile AI Üretime Geçti yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Kubernetes v1.36: Volume Group Snapshots Sonunda GA Oldu yazımıza bakabilirsiniz.

• Topology-aware scheduling: Pod’ları aynı rack/zone/NUMA domain’inde tutabilme imkanı veriyor; GPU-GPU iletişiminin RDMA üzerinden döndüğü senaryolarda baya işe yarıyor.
• Workload-aware preemption: Düşük öncelikli bir grubu kovarken grubun yarısını değil tamamını kovuyor; ortada yarım grup bırakmıyor.

İkinci madde özellikle dikkat çekici bence. Eski preemption mantığı pod-by-pod çalıştığı için, yüksek öncelikli bir job geldiğinde düşük öncelikli grubun rastgele birkaç pod’ünü ölduruyordu; kalan pod’lar da gang policy yüzünden zaten işe yaramıyordu. Hâlâ kaynak tüketiyordu. Saçma mı? Evet, baya saçma.

Sız ne dersiniz? Geçen yıl bir e-ticaret müşterimizde buna benzer durumda Karpenter ile node-level eviction yazmıştık — workaround olarak idare ediyordu ama bakım kısmı açık konuşayım biraz yorucuydu. Native çözüm geliyor olması insanı ister istemez sevindiriyor (inanın bana)

DRA ve ResourceClaim Entegrasyonu

Burası biraz önceki yazıya bağlanıyor aslında; Dynamic Resource Allocation’a (DRA) zaten değinmiştim: Kubernetes v1.36’da DRA: Donanım Paylaşımında Yeni Dönem başlıklı yazıya bakabilirsiniz. Şimdi v1.36 bu iki dünyayı birbirine yaklaştırıyor — ResourceClaim’ler artık PodGroup seviyesinde tanımlanabiliyor (evet, doğru duydunuz)

Peki pratikte ne oluyor? Mesela “bana 8 adet A100 lazım, hepsi aynı NVLink domain’i içinde olsun” diyebiliyorsunuz; hem DRA’nın esnekliği var hem de gang scheduling’in atomik davranışı geliyor (ikisini aynı anda almak fena fikir değil) (ki bu çoğu kişinin gözünden kaçıyor). İşin aslı burada birleşim güzel durmuş. .NET MAUI Artık CoreCLR’da: Mono’nun 24 Yıllık Yolculuğu yazımızda bu konuya da değinmiştik.

Küçük Startup mı, Büyük Enterprise mi?

Açık konuşayım; eğer elinizde sadece 3-5 node’lük basit bir cluster varsa ve batch workload’larınız çok karmaşık değilse bu özelliklerle uğraşmaya gerek olmayabilir.

Default scheduler çoğu zaman işinizi görür.
Volcano kurmak da şart değil genelde.

Ama 50+ node’lu, çok kiracılı, AI training ile inference’ı aynı cluster’da çalıştırdığınız bir ortam varsa — v1.36’yı yakından takip edin derim.
Stabil hâle geldiğinde (muhtemelen v1.,38 civarı beta çizgisine yaklaşır) ciddi fayda sağlayacak gibi dürüyor.
Emin değilim. Sanırım yön o tarafa gidiyor.
Tam da öyle.

Job Controller Entegrasyonu: İlk Adım

Burası biraz “başlangıç var. Yol uzun” hissi veriyor doğrusu.
Bu sürümle birlikte Job controller, yeni Workload API ile entegrasyonun ilk fazını sunuyor; yanı standart bir batch/v1 Job tanımladığınızda controller arka planda Workload + PodGroup nesnelerini üretebiliyor (feature gate açık olmak şartıyla). MSVC Build Tools 14.51 GA: Derleyici Tarafında Yeni Bir Sayfa yazımızda bu konuya da değinmiştik.

Karşılaştırma Tablosu : v1.35 vs v1.36

Maliyet Tarafı: TL Bazında Bir Düşünelim

Azure’da NC A100 v4 serisi bir node’un saatlik fiyatı hatırı sayılır rakamlarda — döviz kuruyla TL’ye çevirdiğinizde aylık olarak ciddi bir kalem olabiliyor. Bir müşterimde 4 node’lük A100 cluster’ı vardı, ayda altı haneli faturalar görüyorduk.

Eğer gang scheduling olmadan training job’larınızın %15-20’si “yarısı ayakta, yarısı pending” şeklinde takılıyorsa, o boşa giden GPU saatlerini direkt çöpe atmış gibi düşünün. Workload-aware scheduling’in olgunlaşması, bu tip kayıpları azaltacak. Bir arkadaşımın firmasında benzer bir optimizasyon sonrası aylık GPU faturasında belirgin düşüş olduğunu paylaşmıştı — abartmadan söylüyorum, fark ciddiydi.

Pratik Adımlar: Nereden Başlayayım?

Eğer bu özellikleri test etmek istiyorsanız önerim şu sıra:

1. Kubernetes v1.36 ile bir test cluster ayağa kaldırın (kind veya küçük bir AKS preview cluster yeter).
2. WorkloadAwareScheduling feature gate’ini açın.
3. Önce basit bir Job + Workload + PodGroup kombinasyonu deneyin, 4-5 replikalı.
4. Sonra preemption testi yapın: düşük öncelikli grup ayağa kaldır, üstüne yüksek öncelikli olan.
5. Logları izleyin, scheduler event’lerine bakın.
6. Topoloji constraint’lerini ekleyin ve node affinity ile etkileşimi gözlemleyin.

Ben kendi lab ortamımda ilk denediğimde scheduler pod’unda “PodGroup CRD bulunamadı” hatası aldım. Sebep: feature gate’ini açtım ama CRD’leri kurmayı unuttum. kubectl apply -f scheduling.k8s.io_v1alpha2_crds.yaml çalıştırınca düzeldi. Belgelerde bu adım net belirtilmiyor, dikkat edin.

Eksik Yanları da Konuşalım

(Yazının başında dedim ya — sadece öven yazı AI işareti.) Bu özelliklerin eksik tarafları da var. Önce şunu söyleyeyim: observability tarafı henüz ham. PodGroup’un neden schedule olmadığını anlamak için scheduler loglarına bakmak gerekiyor; güzel metric’ler yok. Prometheus’ta gang scheduling kuyruğunu izleyecek doğru düzgün bir exporter da yok şimdilik.

Sıradaki mesele: çoklu scheduler senaryoları belirsiz. Eğer cluster’ınızda hem default scheduler hem custom scheduler (mesela Volcano) varsa, hangisinin PodGroup’u sahipleneceği konusunda kafa karışıklığı çıkabilir. Production’a geçmeden önce bu sınır durumlarını test edin.

Üçüncüsü — ve bence en önemlisi — Kubernetes’in Pod-Level In-Place Resize Beta’ya Yükseldi özelliğiyle bu yeni scheduling katmanının nasıl etkileşeceği henüz tam netleşmedi; ikisini birlikte kullanmadan önce dikkatli test etmekte fayda var.

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 Storage Göçü: Planlamadan Kesime Sahadan Notlar5 Tem 2026

TFVC’de Eski Politikaları Temizleyin: Azure DevOps Uyarısı9 Mar 2026

Microsoft Agent Framework v1.0: Lokal'den Prod'a Geçiş11 May 2026

Azure Repos’ta Son Gelişmeler ve Kolaylıklar13 Mar 2026