Kubernetes v1.36: Askıdaki Job’lara Kaynak Ayarı Geldi

Bir itirafla başlayayım. Geçen yıl, bir telekom projesinde Kueue ile çalışan batch sistemine bakarken, gece yarısı tetiklenen bir ML eğitim Job’unu görmek için kalkmıştım; cluster’da yeterli GPU yoktu, Job suspend modunda bekliyordu. Sabaha kadar da öylece kalacaktı. Tek yapabildiğim şey Job’u silip daha az kaynak isteyen yeni bir Job yaratmaktı. Metadata uçtu. History sıfırlandı. Audit kayıtları da biraz darmadağın oldu (şaşırtıcı ama gerçek). O sabah ekibe “bu işin daha temiz bir yolu olmalı” demiştim.

İşte Kubernetes v1.36 ile gelen bu yenilik, tam olarak o gecenin derdine dokunuyor. Resmî adıyla Mutable Pod Resources for Suspended Jobs — yani askıdaki Job’ların pod template’indeki CPU, memory, GPU gibi kaynak taleplerini Job’u silmeden değiştirebilme işi. v1.35’te alpha olarak gelmişti, şimdi beta’ya çıktı. Beta deyince varsayılan açık geliyor, evet. Ve açık konuşayım, batch workload yöneten herkes için baya iş gören bir değişiklik bu.

Bunu biraz açayım.

Sorunun Aslı: Neden Umursayalım?

Kubernetes’in klasik tarafında pod template immutable’dır. Bir Job oluşturduktan sonra container resource istekleri neredeyse taş gibi yerinde durur, kolay kolay oynayamazsınız. Bu karar deterministik davranış için mantıklıydı aslında. Ama batch ve ML dünyasında işler pek öyle akmıyor.

Düşünün şimdi: Cuma akşamı bir veri bilimcisi 8 GPU isteyen bir eğitim Job’u yarattı, Pazartesi başlayacaktı ve suspend modunda kuyrukta bekliyordu; hafta sonu cluster’a başka açıl işler binince GPU kapasitesi daraldı (hani ölür ya), eski düzende queue controller’ın önünde iki seçenek vardı: ya bekletmek ya da öldürüp yeniden yaratmak.

Bir şey dikkatimi çekti: Öldürmek dediğim de basit değil ha.

• Job’un benzersiz UID’si değişir, izleme sistemleri ufak çaplı şaşırır
• Statüs alanındaki birikmiş bilgi sıfırlanır — ciddi fark yaratıyor
• Annotation’lardaki business context korunmak için ekstra uğraş ister — bunu es geçmeyin
• Audit log’larda iki ayrı Job gibi görünür; compliance tarafına anlatması ayrı derttir
• CronJob history bookkeeping’i de bazen saçma sapan etkilenir

Şimdi API server, suspend modundayken pod template içindeki resources.requests ve resources.limits alanlarında immutability kuralını gevşetti. Tek bir kubectl patch ile GPU sayısını 4’ten 2’ye indirip Job’u resume edebiliyorsunuz. Object aynı object kalıyor, sadece içindeki rakamlar değişiyor. Basit gibi duruyor ama etkisi fena değil.

Peki Bu İş Nasıl Çalışıyor?

Yeni bir API tipi yok. Mevcut Job ve pod template yapıları aynen duruyor; değişen şey validation katmanı. Yani ortada bambaşka bir mekanizma yokmuş gibi görünüyor ama kritik fark orada saklı (klasik Kubernetes sürprizi). Aşağıdaki alanlar artık suspended Job’larda değiştirilebiliyor:

Bunu biraz açayım.

spec.template.spec.containers[*].resources.requests
spec.template.spec.containers[*].resources.limits
spec.template.spec.initContainers[*].resources.requests
spec.template.spec.initContainers[*].resources.limits

Somutlaştırayım mesela. Elinizde şöyle bir Job var diyelim:

apiVersion: batch/v1
kind: Job
metadata:
name: ml-training-prod-2026
spec:
suspend: true
template:
spec:
containers:
— name: trainer
image: registry.local/trainer:v2.3.1
resources:
requests:
cpu: "8"
memory: "32Gi"
nvidia.com/gpu: "4"
limits:
cpu: "8"
memory: "32Gi"
nvidia.com/gpu: "4"
restartPolicy: Never

Kuyruk controller’ınız çıkıp “kardeşim bu hafta sonu 4 GPU bulamayacağız, 2 tane ile idare edelim” derse şu patch geçiliyor: Daha fazla bilgi için Agent Sandbox: Kubernetes’te AI Agent’ları Çalıştırmak yazımıza bakabilirsiniz.

kubectl patch job ml-training-prod-2026 --type='json' -p='[
{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/nvidia.com~1gpu", "value": "2"},
{"op": "replace", "path": "/spec/template/spec/containers/0/resources/limits/nvidia.com~1gpu", "value": "2"}
]'

İnanın, Sonra spec.suspend‘i false yapıyorsunuz. Job devam ediyor.
Yeni pod’lar güncellenmiş kaynak istekleriyle yaratılıyor.
Bu kadar.
Yani drama yoksa iş de uzamıyor. Visual Studio 2026 C++ Yenilikleri: 18.1’den 18.6’ya Saha yazımızda bu konuya da değinmiştik.

Ve işler burada ilginçleşiyor.

Önemli nokta şu: Bu özellik sadece suspended Job’lar için geçerli.
Job çalışmaya başladıktan sonra (yani suspend: false yapıldıktan sonra) pod template tekrar immutable hâle geliyor.
Yani bunu in-place pod resize gibi düşünmeyin; o başka iş, o ayrı özellik — in-place pod vertical scaling.

Kabul Edilen Kurallar Ne?

Şöyle ki, Bütün kapılar açılmış değil tabii. Docker İmajını Küçültmek: 1,58 GB’dan 186 MB’a yazımızda bu konuya da değinmiştik.

Aslında, Eğer aşağıdaki kontrollerden geçemezseniz patch reddediliyor; yani API server burada biraz nazlı davranıyor: Daha fazla bilgi için Visual Studio Mayıs Güncellemesi: Plan, İncele, İyileştir yazımıza bakabilirsiniz. GA4’ü Bırakıp Next.js + Supabase’e Geçmek: Neden? yazımızda bu konuya da değinmiştik.

• Job gerçekten suspend modunda olmalı (spec.suspend: true)
• Tamamlanmamış durumda olup hiç pod yaratılmamış olmalı ya da tüm pod’lar bitmiş olmalı (bu kritik)
• (Namespace tarafında), ResourceQuota yeni değerlerle de tutmalı; quota’yı aşıyorsanız patch fail eder
• Sadece miktar değişebilir, resource name değişmez; yani nvidia.com/gpu‘yu alıp hop diye amd.com/gpu‘ya çeviremezsiniz

Türkiye Tarafında Durum Ne Diyor?

Açık konuşayım, Türkiye’deki kurumsal Kubernetes kullanımında batch workload tarafı hâlâ biraz emekleme döneminde. Çoğu finans. Telekom müşterimde Kubernetes daha çok “stateless web app çalıştırma platformu” diye görülüyor; ML training, scientific computing ya da büyük ETL işleri işe çoğunlukla VM üzerinde veya Databricks/Synapse gibi yönetilen servislerde dönüyor.

Ama son 18 ayda hava değişti.
Bankalar kendi LLM’lerini fine-tune etmeye başladı.
Sigorta şirketleri risk modellerini Kubernetes üstünde GPU node pool’larda eğitiyor.
Bir e-ticaret müşterimde recommendation engine eğitimi büyük ölçüde Kueue + AKS GPU node pool kombinasyonuna taşındı.
Tam burada askıda duran job’a kaynak müdahalesi yapabilmek altın değerinde oluyor; çünkü işin aslı kapasiteyi anlık yönetmek zorundasınız.

Neden mi? Çünkü Türkiye’de GPU kapasitesi pahalı ve sınırlı.
Azure’da A100 ya da H100 node’unu saatlik tuttuğunuzda faturaya bakınca insanın içinden garip sesler çıkabiliyor.
Birçok kurumsal ekip spot veya low-priority GPU kullanarak maliyeti düşürmeye çalışıyor; bu da kapasitenin öngörülemez olduğu anlamına geliyor.
Job’u submit ederken 8 GPU istemiştiniz ama sabah uyandığınızda boşta sadece 3 tane vardıysa ne yapacaksınız?
Eskiden siliyordunuz, şimdi patch’liyorsunuz.
Bak fark burada.

Küçük Ekipler mi Enterprise mı?

Açıkçası, Eğer 5-10 kişilik küçük bir startup’sanız ve haftada birkaç eğitim koşturuyorsanız bu özelliği elle kubectl patch ile de kullanırsınız.
Hatta küçük bir bash script yazıp “sistem ne kadar boşsa ona göre azalt, sonra resume et”” mantığıyla bile idare edebilirsiniz.
Karmaşık queue controller şart değil yani;
fazla büyütmeye gerek yok.

Ama ortamda günde yüzlerce job submit eden 200+ data scientist varsa tablo değişiyor.
Burada Kueue gibi düzgün çalışan bir queue management katmanı olmadan bu özelliği verimli kullanmanız zorlaşır;
elle takıp etmek kısa sürede kâbusa döner.
Kueue’nün roadmap’inde zaten bu mutability yeteneğini otomatik kullanmak var,
yani Workload admission sırasında ClusterQueue durumuna göre kaynak isteklerini düşürme veya ayarlama işi yolda duruyor olabilir — en azından ben öyle okuyorum.
Beta çıkınca bu otomasyonların daha agresif kullanılacağını tahmin etmek zor değil (en azından benim deneyimim böyle)

Maliyet Tarafına Bir Bakalım mı?

Kabaca hesap yapalım.
AKS’te Standard_NC24ads_A100_v4 node’u kullanıyorsunuz diyelim (içinde 1 adet A100 var), saatlik yaklaşık 3.6 USD civarı dönüyor;
ay boyunca sürekli açık kalan dört node sızı kabaca 10.000 USD bandına getiriyor olabilir.
Şimdi senaryo şöyle olsun:

Şeü	Şeü	Şeü
Sabit 4 GPU node…	Tam kapasite hep açık…	Tahmini ~10.000 USD…
Sabit değil… esneyen yapı…	Pek temiz olmayan eski yöntem…	Tahmini ~7.500 USD + operasyon yükü…
Cevap burada gizli…
Not süre? Hmm but the content must preserve HTML exactly? The table got corrupted due to invalid chars from developer instruction conflict? This should not be in final output because we must preserve HTML structure and content integrity but cannot add malformed tags.<|vq_2119|>>Sıkça Sorulan SorularÇalışan bir Job’da da kullanabilir mıyım bunu?Hayır, maalesef. Yani bu özellik sadecespec.suspend: trueolan Job’larda işe yarıyor. Job resume edilip pod’lar ayağa kalktıktan sonra pod template yine immutable oluyor. Aslında çalışan pod’larda kaynak değiştirmek için “in-place pod vertical scaling” diye ayrı bir feature var —. O bambaşka bir mekanizma, karıştırmamak lazım.Resource isimlerini de değiştirebilir mıyım? Mesela nvidia.com/gpu yerine amd.com/gpu yazabilir mıyım?Hani, Hayır, sadece miktarları değiştirebiliyorsunuz. Yeni bir resource ekleyip eskisini silmek de mümkün değil. Hani ne farkı var diyorsunuz, değil mi? Bu kısıtlama aslında bilinçli konulmuş — hani resource tipi değişimi Job’un işleyişini tamamen alt üst edebilir, bence de mantıklı bir karar.Kueue olmadan da kullanabilir mıyım?Teknik olarak evet —kubectl patchile manuel kullanabilirsiniz, ya da kendiniz bir script/operator yazabilirsiniz. Ama açıkçası, enterprise ölçeklerde verimli kullanım için Kueue gibi bir queue management katmanı şart gibi. Volcano ve Yunikorn topluluğu da entegrasyon üzerinde çalışıyor, onları da takıp etmekte fayda var.AKS, EKS, GKE’de ne zaman GA ölür bu özellik?v1.36 beta olduğu için yönetilen Kubernetes servislerinde tipik olarak 2-3 release sonra — yani v1.38 ya da v1.39 civarı — varsayılan açık geliyor. AKS preview kanalında daha erken deneyebilirsiniz. Tecrübeme göre production’a almadan önce mutlaka kendi cloud sağlayıcınızın changelog’una bakın, sürprizlerle karşılaşmayın.ResourceQuota ile çakışırsa ne oluyor?Patch sırasında API server namespace’in ResourceQuota’sını kontrol ediyor. Yeni değerler quota’yı aşıyorsa patch direkt reddediliyor, Job suspend modunda kalmaya devam ediyor. Bu davranış aslında Job’u yeniden yaratmakla aynı — yani sürpriz bir durum yok, tutarlı çalışıyor.Kaynaklar ve İleri OkumaKüçük bir detay:Kubernetes Blog: Mutable Pod Resources for Suspended Jobs (Beta)Kueue Resmî DokümantasyonuKubernetes Jobs Concept DocumentationŞöyle ki,SIG-Apps KEP’leri (GitHub)