Şunu en baştan söyleyeyim: Kubernetes’in scheduler tarafı yıllardır AI/ML ekiplerinin canını sıkıyordu (ben de ilk duyduğumda şaşırmıştım). Pod pod scheduling, batch işler için bayağı yetersiz kalıyor. Bir GPU eğitim job’ı için 8 pod ayağa kalkması gerekiyor, scheduler 6 tanesini yerleştirip 2 tanesini bekletirse, o 6 pod boşuna GPU tüketiyor — fatura geliyor, iş ilerlemiyor (ben de ilk duyduğumda şaşırmıştım)
v1.35’te ilk adımlar atılmıştı. Workload API geldi, temel gang scheduling de eklendi. Ama itiraf edeyim, o sürümü bir müşteride denerken kafam karışmıştı. Tek bir API objesi hem statik şablon hem runtime durum tutuyordu. Şimdi v1.36 ile işler toparlanıyor, en azından benim gözümde daha temiz bir yere gidiyor. Ve bence doğru yönde atılmış bir adım.
Çok konuştum, örnekle göstereyim.
Araya gireyim: Lafı uzatmadan gireyim konuya.
Workload API’den PodGroup API’ye Geçiş: Neden Bu Ayrım Önemli?
Yeni mimaride iki ayrı kavram var artık: Workload statik bir şablon, PodGroup işe runtime objesi. Kulağa basit geliyor ama aslında çok can alıcı bir mimarı tercih.
Önceki sürümde her şey tek bir Workload objesinin içindeydi. Statüs güncellemeleri, pod gruplarının çalışma zamanı durumu, scheduling policy… hepsi aynı yerdeydi. Büyük ölçekte (mesela 500 replicalı bir batch job düşünün) bu yapı etcd’ye sürekli yazma baskısı yaratıyordu; hani teoride idare eder gıbı duruyor. Pratikte nefes nefese kalıyor. Bir müşterimizde — adını vermeyeyim, finans sektöründen — v1.35 ile test ortamında 200 replicalı bir training job çalıştırdığımızda API server’ın CPU’su tavan yapmıştı. Sebep tam olarak buydu işte.
Şimdi scheduling.k8s.io/v1alpha2 grubu altında iki ayrı resource var. Workload sadece “şu kadar pod grubu olacak, şöyle policy uygulanacak” diyor — bir nevi blueprint. PodGroup işe asıl çalışma anındaki durumu tutuyor; yanı olayın canlı tarafı burada dönüyor diyebilirim. Böylelikle statüs güncellemeleri replica başına shard’lanabiliyor, yanı API server bir noktada boğulmuyor.
Şablon ve Runtime Ayrımı Pratikte Nasıl Görünüyor?
Bir örnekle göstereyim. Diyelim ki bir training job’ınız var, worker’ların hepsinin birden ayağa kalkması lazım (yarısı kalkıp diğerlerini beklerse GPU israfı ölür):
apiVersion: scheduling.k8s.io/v1alpha2
kind: Workload
metadata:
name: training-job-workload
namespace: ml-prod
spec:
podGroupTemplates:
— name: workers
schedulingPolicy:
gang:
minCount: 4 # 4 pod aynı anda kalkmazsa hiçbiri kalkmasınController (örneğin Job controller) bu şablona bakıp runtime PodGroup objelerini “stamp out” ediyor; yanı şablondan kopya çıkarıyor diyebiliriz, biraz kaba. Iş görüyor. İlginç, değil mi? PodGroup’un kendi statüs’u var ve içindeki pod’ların durumunu aynalayan condition’lar tutuyor.
Bence en güzel tarafı şu: Scheduler artık Workload objesini watch etmek zorunda değil. Doğrudan PodGroup’u okuyor. Bu basit gıbı gözüken değişiklik, scheduler’ın iş yükünü ciddi ölçüde düşürüyor.
PodGroup Scheduling Cycle: Atomik İşleme Devri
Kube-scheduler’a yeni bir scheduling cycle eklenmiş: PodGroup scheduling cycle. Bu da atomik workload processing yapabilmenizi sağlıyor; ya hepsi gelir ya da kimse gelmez mantığı artık scheduler’ın çekirdeğine biraz daha düzgün oturmuş durumda.
v1.35’teki gang scheduling, Pod-based framework üzerine inşa edilmişti. Çalışıyordu ama biraz iğreti duruyordu — sanki yamayla tutturulmuş gıbı. Yeni cycle bunu temizliyor gıbı görünüyor; en azından ben öyle okudum ve test ederken de hissiyat aynıydı diyebilirim (en azından benim deneyimim böyle). Scheduler artık önce “bu PodGroup’un minCount’unu karşılayacak kaynak var mı?” diye bakıyor, varsa hepsini birden yerleştiriyor, yoksa hiç dokunmuyor.
İşte tam da bu noktada devreye giriyor.
Türkiye’deki Şirketler İçin Bu Ne Anlama Geliyor?
Açık konuşayım: Türkiye’de Kubernetes üzerinde ciddi AI/ML workload çalıştıran şirket sayısı hâlâ az gıbı geliyor bana ama hızla artıyor da olabilir; sahada bazen tabloyu net görmek zor oluyor çünkü herkes kapasiteyi farklı anlatıyor.. Geçen ay bir telekom operatöründe danışmanlık verirken ekibin GPU node’larını verimsiz kullandığını fark ettim — utilization %35 civarında geziyordu.. Sebep? Yarım kalmış pod grupları GPU’ları tutuyordu.
Bu yeni yapı tam olarak bu sorunu çözmek için tasarlanmış gıbı duruyor.. Eğer kurumsal ölçekte GPU kullanıyorsanız fatura aylık 6 haneli rakamlara çıkabiliyor demektir.. Utilization’ı %35’ten %70’e çekmek doğrudan %50 maliyet düşüşü demek ölür; kaba hesap böyle çalışıyor.. TL bazında düşünürseniz A100 instance’ı Azure’da saatlik ~3-4 USD civarında.. Aylık birkaç saatlik boşa kullanım bile can sıkıyor; hele node sayısı artınca iş çığırından çıkabiliyor..
Hesap basit aslında: gang scheduling olmadan bu rakamlar uçuyor.
Topology-Aware Scheduling: İlk Adımlar
Peki neden önemli? v1.36 aynı zamanda topology-aware scheduling’in ilk iterasyonunu da getiriyor.. Bu özellik henüz ham, dürüst olayım — daha pişmesi lazım ama yön kötü değil..
Eh, Fikir şu: AI training’de pod’ların hangı node’da çalıştığı kadar o node’ların birbirine ne kadar yakın olduğu da önemli oluyor.. Aynı rack’teki node’lar arası network latency farklı rack’tekilere göre 5-10 kat daha düşük olabiliyor; sayıdan bağımsız olarak fark hissediliyor açıkçası.. Distributed training yapıyorsanız all-reduce operasyonu sırasında bu fark eğitim süresini iki katına çıkarabilir.
Scheduler artık PodGroup’u yerleştirirken topology hint’lerini dikkate alabiliyor.. Henüz çok temel bir implementasyon bu ama bence v1.38 civarında daha oturmuş hâle gelir; tabii tahmin yürütüyorum, %100 doğru olmayabilir.. Şu an üretimde kullanmadan önce iki kez düşünün derim.
Workload-Aware Preemption: Akıllı Kovma
Araya gireyim: Baya ilginç başka bir yenilik de workload-aware preemption olmuş.. Klasik preemption ne yapıyordu? Yüksek öncelikli bir pod geldiğinde düşük öncelikli bir pod’u kovuyordu; tekil bakınca mantıklı görünüyordu ama topluca bakınca biraz kör davranıyordu… Copilot Code Review Metrikleri: Yorum Tipine Göre Kırılım yazımızda bu konuya da değinmiştik.
Kendi deneyimimden konuşuyorum, Ama gang scheduling yapan bir job’da 8 pod’dan 1’ını kovarsanız ne ölür? Diğer 7’si de zaten çalışamaz hâle gelir… Yanı aslında tek pod değil bütün grup etkilenir; scheduler işe çoğu zaman bunu ilk anda anlamazdı… Bu konuyla ilgili vcpkg Nisan 2026 Güncellemesi: Paralel Build Kilitleri Geldi yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımıza bakabilirsiniz.
Şunu fark ettim: Yeni preemption mantığı bu körlüğü gideriyor gıbı… Scheduler artık “bu pod’u kovarsam hangı PodGroup’un bütünlüğünü bozarım?” sorusunu soruyor… Daha akıllıca tercihler yapıyor diyeyim; lafı gevelemeden mesele bu… Bu konuyla ilgili Docker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımıza da göz atmanızı tavsiye ederim.
Pratik Bir Senaryo
Workload-aware preemption ile bunun önü kesiliyor… Ya tüm grup kovulur (ve sonra tekrar başlar), ya da hiç dokunulmaz…
DRA ve ResourceClaim Desteği Gelmiş mi?
Ne yalan söyleyeyim, Evet gelmiş sayılır… Dynamic Resource Allocation (DRA) artık PodGroup seviyesinde de çalışabiliyor… ResourceClaim’ler tek tek değil de tüm workload için tanımlanabiliyor; böylece ortak GPU/FPGA/özel donanım talepleri daha düzenli yönetiliyor… Bu konuyla ilgili Azure Red Hat OpenShift: AI Üretimine Geçişin Hikayesi yazımıza da göz atmanızı tavsiye ederim.
Saha Testinde En Çok Ne İşe Yaradı?
Bilmem anlatabiliyor muyum, Bence en pragmatik parça şu öldü: Job controller’ın yeni API ile entegrasyonunun ilk fazı geldi…. Yanı bu iş sadece kağıt üstünde kalmıyor; Kubernetes’in kendi Job controller’ı bunu kullanmaya başlıyor…
Evet, doğru duydunuz.
Neden önemli? Çünkü herhangi bir API’nın production’a yaklaşması için çekirdek controller’lardan biri tarafından sahiplenilmesi gerekiyor…. Job controller’ın bunu yapması ekosistemin geri kalanına da yeşil ışık yakıyor diyebiliriz…
Kısacık Karşılaştırma Yapayım mı?
| Özellik | v1./35″v/1./36″ |
|---|---|
| Özellik | v1.35 |
Sıkça Sorulan Sorular
Workload API ile PodGroup API arasındaki fark ne?
Workload API aslında statik bir şablon gıbı düşünebilirsiniz — yanı pod gruplarının nasıl oluşturulacağını tanımlıyor. PodGroup API işe runtime objesi olarak çalışıyor. Hani gerçek zamanlı bilgileri tutuyor: kaç pod ayakta, durumları ne, scheduling kararları nereye gidiyor gıbı şeyler. Bence bu ayrım hem performans hem de mimarı açıdan gerçekten önemli.
v1.36’daki PodGroup API production’da kullanılabilir mi?
Açıkçası hayır, hâlâ v1alpha2 seviyesinde. Test ve POC ortamlarında rahatça deneyebilirsiniz, ama kritik production workload’ları için en az v1beta1’i beklemenizi öneririm (kendi tecrübem). Muhtemelen v1.37 veya v1.38’de o seviyeye gelir.
Halihazırda Kueue veya Volcano kullanıyorsam ne yapmalıyım?
Kısa vadede bir şey yapmanıza gerek yok, merak etmeyin. Bu external scheduler’lar yanı Kueue ve Volcano muhtemelen v1alpha2 API desteği için bir-iki sürüm daha bekleyecek. Onların migration guide’larını takıp edin ve kendi roadmap’lerine göre planınızı yapın.
Gang scheduling olmadan GPU workload’ları hiç çalışmaz mı?
Çalışır, ama verimsiz. Gang scheduling olmadığında bazı pod’lar ayaktayken diğerleri pending’de kalabiliyor — mesela ayakta olan pod’lar GPU’ları tutup iş yapmadan bekliyorlar. Bu da hem maliyet hem zaman israfı demek. Tecrübeme göre distributed training senaryolarında gang scheduling neredeyse zorunlu hâle geliyor.
Topology-aware scheduling şu an kullanılabilir mi?
Teknik olarak evet. Ama henüz çok ham, yanı production için değil. Sadece test amaçlı denemenizi öneririm — production’da kullanmak için en az birkaç sürüm daha beklemek mantıklı olacak.
Kaynaklar ve İleri Okuma
Kubernetes v1.36: Advancing Workload-Aware Scheduling (Resmî Blog)
Kubernetes Scheduling Resmî Dokümantasyonu
SIG-Scheduling KEP’leri (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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
