Kubernetes v1.36’da Askıya Alınan Job Kaynakları Değişiyor

⏱️ 4 dk okuma📅 9 Eylül 2026

Kubernetes v1.36 ile askıya alınmış Job nesnelerinin pod şablonundaki kaynak istekleri ve limitleri değiştirilebiliyor. Beta aşamasındaki bu özellik, kuyruk denetleyicilerinin ve küme yöneticilerinin bir Job çalışmadan veya yeniden başlatılmadan önce CPU, bellek, GPU ve genişletilmiş kaynak tanımlarını güncellemesini sağlıyor.

Yetenek ilk olarak Kubernetes v1.35’te alfa olarak sunulmuştu. Kubernetes v1.36’da ise MutablePodResourcesForSuspendedJobs özellik kapısı varsayılan olarak etkin geliyor. Bu nedenle v1.36 çalıştıran kümelerde API sunucusu için ek yapılandırma gerekmiyor.

Askıya alınan Job kaynakları neden değiştiriliyor?

Toplu işlem ve makine öğrenmesi iş yüklerinde gereken kaynak miktarı, Job oluşturulurken her zaman kesinleşmeyebilir. Uygun kaynak dağılımı kümenin mevcut kapasitesine, kuyruk önceliklerine ve GPU gibi özel donanımların kullanılabilirliğine göre değişebilir.

Bu özellikten önce bir Job’ın pod şablonundaki kaynak gereksinimleri belirlendikten sonra değiştirilemiyordu. Örneğin Kueue gibi bir kuyruk denetleyicisi, askıya alınmış bir Job’ın farklı kaynaklarla çalışmasının daha uygun olacağını belirlediğinde Job’ı silip yeniden oluşturmak zorunda kalıyordu. Bu işlem, nesneyle ilişkili meta verilerin, durum bilgilerinin veya geçmişin kaybedilmesine yol açabiliyordu.

Yeni yetenek, CronJob tarafından oluşturulan belirli bir Job örneğinin küme yoğun olduğunda daha düşük kaynaklarla ilerlemesini de sağlıyor. Böylece iş doğrudan başarısız olmak yerine, mevcut kapasiteye uygun daha sınırlı kaynaklarla başlatılabiliyor.

GPU kullanan Job için örnek akış

Kaynakta verilen örnekte, makine öğrenmesi eğitimi yapan askıya alınmış bir Job başlangıçta 4 GPU talep ediyor. Pod şablonunda CPU isteği ve limiti 8, bellek isteği ve limiti 32 Gi olarak belirtiliyor. GPU için hem istek hem limit değeri 4 olarak tanımlanıyor.

Küme kaynaklarını yöneten bir kuyruk denetleyicisi yalnızca 2 GPU’nun kullanılabilir olduğunu belirlerse Job’ın kaynak tanımları çalıştırılmadan önce güncellenebiliyor. Bu durumda CPU isteği ve limiti 4’e, bellek isteği ve limiti 16 Gi’ye, GPU isteği ve limiti ise 2’ye indiriliyor.

Kaynak güncellemesi tamamlanınca denetleyici, spec.suspend alanını false yaparak Job’ı devam ettiriyor. Yeni oluşturulan pod’lar, güncellenen kaynak istekleri ve limitleriyle başlıyor. Job’ın adı, meta verileri ve mevcut nesne geçmişi korunurken çalışacağı kaynak profili değiştirilebiliyor.

Hangi alanlar değiştirilebilir?

Kubernetes API sunucusu, pod şablonlarındaki değişmezlik kuralını yalnızca askıya alınmış Job’ların kaynak alanları için gevşetiyor. Yeni bir API türü eklenmiyor; mevcut Job ve pod şablonu yapıları, gevşetilmiş doğrulama kurallarıyla kullanılmaya devam ediyor.

Değiştirilebilen alanlar şunlar:

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

Kaynak güncellemesinin kabul edilmesi için Job’ın spec.suspend alanının true olması gerekiyor. Daha önce çalışmış ve sonradan askıya alınmış bir Job’da kaynak değişikliğine izin verilmeden önce tüm etkin pod’ların sonlanması bekleniyor. Başka bir deyişle status.active değerinin 0 olması gerekiyor.

Standart kaynak doğrulamaları geçerliliğini koruyor. Örneğin kaynak limitlerinin istek değerinden küçük olmaması gerekiyor. Genişletilmiş kaynaklar için gerekli durumlarda değerlerin tam sayı olarak belirtilmesi şartı da devam ediyor.

Beta sürümünde kullanım ve dikkat edilmesi gerekenler

Kubernetes v1.36 veya sonraki bir sürümü kullanan kümelerde özellik varsayılan olarak kullanılabilir. Kubernetes v1.35 kümelerinde ise MutablePodResourcesForSuspendedJobs özellik kapısının kube-apiserver üzerinde etkinleştirilmesi gerekiyor.

Kaynakta önerilen temel deneme akışı, askıya alınmış bir Job oluşturup kapsayıcı kaynaklarını kubectl edit veya bir denetleyici aracılığıyla güncelledikten sonra Job’ı devam ettirmeye dayanıyor:

# Create a suspended Job
kubectl apply -f my-job.yaml --server-side
# Edit the resource requests
kubectl edit job training-job-example-abcd123
# Resume the Job
kubectl patch job training-job-example-abcd123 -p
'{"spec":{"suspend":false}}'

Çalışırken askıya alınan Job’larda önemli bir sınırlama var. Job’ın etkin pod’ları tamamen sonlanmadan kaynak alanları değiştirilemiyor. status.active değeri 0’dan büyük olduğu sürece API sunucusu bu değişiklikleri reddediyor. Bu kural, çalışan pod’larla güncellenen pod şablonu arasında kaynak tutarsızlığı oluşmasını önlüyor.

Başarısız pod’lar içerebilen Job’larda pod değiştirme politikasının da dikkate alınması gerekiyor. Kaynak, podReplacementPolicy: Failed ayarının kullanılmasını öneriyor. Bu ayar, değiştirme pod’larının önceki pod’lar tamamen sonlandıktan sonra oluşturulmasını sağlayarak aynı kaynaklar için çakışma oluşmasını önlemeye yardımcı oluyor.

Dynamic Resource Allocation kullanan iş yüklerinde resourceClaimTemplates alanları değişmez kalıyor. Kaynak değişiklikleri DRA kullanımıyla ilişkiliyse claim şablonlarının ayrıca yeniden oluşturulması gerekiyor.

Geliştirme sürecine katkı

Bu özellik SIG Apps tarafından geliştirildi ve WG Batch grubunun katkılarıyla ilerledi. Her iki grup da özellik kararlı sürüme yaklaşırken geri bildirim kabul ediyor. İlgilenenler #sig-apps ve #wg-batch Slack kanalları üzerinden toplulukla iletişime geçebilir. Özelliğin takibi KEP-5440 üzerinden yapılıyor.

Kubernetes v1.36’daki bu beta değişikliği, özellikle kaynak ihtiyacı çalışma anına kadar kesinleşmeyen toplu işlem ve makine öğrenmesi iş yüklerinde Job nesnesini silip yeniden oluşturma gereksinimini ortadan kaldırıyor. Değişiklik yalnızca askıya alınmış Job’ların pod kaynak alanlarıyla sınırlı kalıyor; etkin pod’ların durumu ve DRA claim şablonlarının değişmezliği korunuyor.

Kaynaklar ve İleri Okuma

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Ç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