Headlamp Kueue Eklentisi: Job Neden Hâlâ Bekliyor?
Bir Kubernetes Job gönderiyorsunuz, Pod’ların görünmesini bekliyorsunuz. Dakikalar geçiyor, Job hala suspended duruyor, uygulama logu yok, hatta incelenecek bir Pod bile oluşmamış olabilir. Kueue tarafından yönetilen bir kümede bu tablo sıradan olabilir, çünkü Kueue, Job’ın istediği kaynakları kullanıp kullanamayacağına henüz karar vermemiştir. Headlamp için yayımlanan Kueue eklentisinin 0.1.0-alpha sürümü bu kararın adım adım izlenmesine imkan veriyor. Böylece “Pod neden pending?” sorusundan önce sorulması gereken “Kueue bu Workload’u admit etti mi?” sorusu, tıklanabilir bir inceleme yoluna dönüşüyor.
Önce admission ile Pod scheduling’i ayırın
Kueue ve Kubernetes scheduler birbirinden farklı sorulara yanıt verir:
- Kueue admission: Kuyruk politikası, kota, ResourceFlavor’lar, admission check’ler ve bekleyen diğer Workload’lar göz önüne alındığında bu Workload şimdi başlamalı mı?
- Pod scheduling: Workload admit edildikten ve Job devam ettikten sonra Pod’ları hangi node’lar çalıştırabilir?
İncelemenin yönünü bu ayrım belirler. Workload admit edilmemişse Headlamp’in Kueue bölümünde kalın; admit edilmiş ama Pod’lar hala Pending ise standart Job ve Pod görünümlerine geçip scheduler event’lerine bakın.
Başlamadan önce gerekenler
Bu akışı izlemek için Kueue’nun kurulu olduğu bir Kubernetes kümesi, bir Headlamp kurulumu ve Kueue eklentisinin 0.1.0-alpha sürümü gerekiyor. Kubernetes kimliğinizin de burada kullanılan Kueue kaynaklarını okuma yetkisi olmalı.
Alpha sürüm, Kueue v1beta2 Cohort, ClusterQueue, LocalQueue, ResourceFlavor ve Workload kaynakları için salt okunur görünümler sunuyor. Eklenti kendi oluşturma, düzenleme, durdurma, devam ettirme veya silme akışlarını eklemiyor; Headlamp’in standart YAML ve kaynak işlemleri ise izinleriniz elverdiği ölçüde çalışmayı sürdürüyor.
Headlamp üzerinden bekleyen bir Job’ı izleme
1. Workloads görünümünü açın
Headlamp’te Kueue → Workloads yolunu izleyin, Job’ın bulunduğu namespace’i seçin, onun için oluşturulan Workload’u bulun. Kueue, bir Job’ın kaynak talebini ve admission durumunu temsil etmek üzere bir Workload nesnesi oluşturur. Alpha eklentide owner reference’lar Kind/name biçiminde metin olarak görünüyor, henüz tıklanabilir değil. Workload adı genellikle Job adını içerdiğinden bulmanın en pratik yolu namespace filtresi ve tablo araması.
Detay sayfasını açmadan önce liste bile işe yarar bir ilk tarama sunar: LocalQueue, öncelik ve priority class, active durumu, admitted durumu, tamamlanma durumu, Admitted, Finished ya da Inadmissible gibi okunabilir güncel durum ve yaş bilgisi.
Eşleşen bir Workload yoksa devam etmeden önce üç şeyi kontrol edin: seçili namespace, Job’ın bir LocalQueue’ya gönderilip gönderilmediği ve hesabınızın Workload’ları listeleme yetkisi. Eklenti izin kontrolü yapar, mevcut kimlik bir kaynağı okuyamıyorsa erişim mesajı gösterir.
2. Status, condition ve event’leri okuyun
Workload’u açın, tam YAML yerine önce güncel durumuna ve condition‘larına bakın. Admission sorunlarında en önemli condition tipleri QuotaReserved ve Admitted‘dir.
Admitted=True: Kueue Workload’u admit etmiştir. Job devam edebilir, geriye kalanPendingPod’lar artık scheduling tarafının konusudur.QuotaReserved=FalsevePendinggibi bir reason: Kueue kota rezerve etmemiştir. Condition mesajı, rezervasyonu neyin engellediğini açıklar.Inadmissibledurumu: Workload mevcut kuyruk yapılandırmasına şu an sığmıyordur. Kapsanmayan bir kaynak, uygun olmayan ResourceFlavor, durdurulmuş bir kuyruk veya bir admission check bu sonuca yol açabilir.
Bir condition mesajı örneğin, ClusterQueue’nun CPU kotası yetersiz olduğu için Kueue’nun ResourceFlavor ataması yapamadığını bildirebilir. “Job neden hala bekliyor?” sorusunun ilk gerçek yanıtı budur, Headlamp’teki geri kalan yolculuk da bu mesajın arkasındaki yapılandırmayı açar. Events bölümünü de atlamayın; condition’lar mevcut durumu anlatır, event’ler ise son değişiklikleri ve Kueue’nun ne denediğini gösterir.
3. Talep ile atamayı karşılaştırın
Aynı detay sayfasında PodSet’leri ve kaynak taleplerini inceleyin. Eklenti istenen Pod sayısını, CPU’yu, belleği ve Kueue’nun birlikte değerlendirdiği diğer kaynakları gösterir. Bu önemlidir, çünkü parallelism: 3 olan ve Pod başına bir CPU isteyen bir Job, Kueue’dan toplamda üç CPU talep eder. Tek bir Pod template’ine bakmak Workload’u olduğundan küçük gösterir.
Kota zaten rezerve edilmişse aynı sayfa atanan ClusterQueue’yu, ResourceFlavor’ları ve admit edilmiş kaynak kullanımını da gösterir. Bu admission atamaları görünmüyorsa Workload henüz o aşamaya ulaşmamıştır.
Yazıdaki örnekte Workload üç Pod, toplam üç CPU ve toplam 600 MiB bellek talep ediyor.
4. Bağlı LocalQueue’yu izleyin
Workload detay sayfasındaki LocalQueue bağlantısını kullanın. LocalQueue, Job’ın kullandığı namespace düzeyindeki giriş noktasıdır; namespace’e bağlı Workload’ları küme kapsamındaki bir ClusterQueue’ya bağlar.
LocalQueue sayfası namespace ve bağlı ClusterQueue bilgisini, stop policy ile güncel durumu, pending/reserving/admitted Workload sayılarını, Kueue condition’larını, Kubernetes event’lerini ve aynı namespace’teki ilgili Workload’ları gösterir. Böylece iki pratik soru yanıtlanır: Job beklediğiniz kuyruğa mı girdi ve orada bekleyen tek Workload bu mu?
LocalQueue inactive ya da durdurulmuşsa beklemenin nedeni zaten bulunmuş olur. Aktifse, arkasındaki kapasiteyi incelemek için bağlı ClusterQueue’ya geçin.
5. ClusterQueue kapasitesini ve kullanımını inceleyin
ClusterQueue, bir ya da daha fazla LocalQueue’nun kullanabileceği küme düzeyindeki kotayı ve admission politikasını temsil eder. Headlamp detay sayfasında Workload talebini şunlarla karşılaştırın:
- kapsanan kaynaklar (covered resources)
- her ResourceFlavor için nominal kota
- mevcut rezervasyonlar ve kullanım
- borrowing ve lending limitleri
- pending, reserving ve admitted Workload sayıları
- queueing strategy ve stop policy
- preemption, fair-sharing, flavor-fungibility ve admission-check ayarları
- Kueue condition’ları ve Kubernetes event’leri
Örnekteki ClusterQueue iki CPU ve iki Pod slotu nominal kota sunuyor, Workload ise her ikisinden üçer istiyor. Condition mesajı ile ClusterQueue sayfası aynı hikayeyi anlatıyor: Workload sığmıyor, bu yüzden Kueue Job’ı suspended bırakıyor. Burada bir admission-kapasite sorunu var, kube-scheduler’ın node bulamadığına dair bir kanıt yok.
6. Gerektiğinde ResourceFlavor ve Cohort’a bakın
Kota her zaman tek bir havuz değildir. Bir ResourceFlavor, node etiketleri, taint’ler, toleration’lar veya topoloji ayarları üzerinden bir compute sınıfını temsil edebilir. Condition mesajı flavor atamasına işaret ediyorsa ya da Workload GPU node’ları gibi belirli bir donanım sınıfı gerektiriyorsa ClusterQueue’daki ResourceFlavor bağlantısını kullanın.
ClusterQueue bir Cohort‘a aitse o bağlantıyı da izleyin. Cohort’lar, ClusterQueue’ların kullanılmayan kotayı paylaşmasını sağlar. Headlamp sayfası üst ve alt Cohort’ları, üye ClusterQueue’ları, referans verilen ResourceFlavor’ları, kaynak gruplarını, borrowing/lending limitlerini ve fair-sharing bilgisini gösterir. Bu sayfalar daha ince bir soruyu yanıtlar: Workload kendi kotası olmadığı için mi, yeterince ödünç alamadığı için mi, yoksa uygun bir flavor atanamadığı için mi engelleniyor?
Headlamp’ten çıkmadan elde edilen tablo
Örnekteki bekleyen Job için arayüz eksiksiz bir açıklama veriyor. Workload admit edilmemiş, QuotaReserved condition’ı false ve mesaj yetersiz kotaya işaret ediyor; Workload üç CPU ve üç Pod slotu istiyor; LocalQueue aktif ve beklenen ClusterQueue’ya işaret ediyor; ClusterQueue ise yalnızca iki CPU ve iki Pod slotu sağlıyor. Kueue de kota serbest kalana veya kuyruk yapılandırması değişene kadar Job’ı suspended tutuyor.
Headlamp bu tabloda yeni bir durum üretmiyor. Eklenti, diğer istemcilerle aynı Kubernetes API nesnelerini okuyor, ilgili kaynakları ve insan tarafından okunabilir değerleri tek bir bağlantılı inceleme akışında topluyor.
Workload admit edildiyse görünüm değiştirin
Workload detay sayfası Admitted=True gösteriyor ama uygulama hala çalışmıyorsa Kueue kendi kararını tamamlamış demektir. Bundan sonrası Headlamp’in standart Kubernetes görünümlerinde:
- Workloads → Jobs bölümünde Job durumunu ve event’lerini inceleyin.
- Workloads → Pods bölümünde Job adına veya namespace’e göre filtreleyin.
- Bir
PendingPod seçip Events bölümünü okuyun.
Bu aşamada node kapasitesinin yetersizliği, node affinity, taint ve toleration’lar, topoloji kısıtları, persistent volume binding veya image-pull hataları gibi scheduler kaynaklı konulara bakılır. Yazının en işlevsel kuralı da bu devir teslim noktasıdır: admit edilmemişse Kueue kaynaklarını, admit edilmiş ama Pod’lar Pending ise Job, Pod, node ve scheduler bilgilerini inceleyin.
Tekrarlanabilir bir kontrol listesi
- Kueue → Workloads‘ı açıp doğru namespace’i seçin.
- Job’a ait Workload’u bulun.
- Okunabilir durumu,
AdmittedveQuotaReservedcondition’larını kontrol edin. - Condition mesajını ve son event’leri okuyun.
- PodSet kaynak taleplerini varsa admission atamalarıyla karşılaştırın.
- LocalQueue bağlantısını izleyip durumunu ve ClusterQueue’şunu doğrulayın.
- ClusterQueue bağlantısını izleyip kota, rezervasyon, kullanım ve politikayı karşılaştırın.
- Mesaj flavor seçimine veya paylaşılan kotaya işaret ediyorsa ResourceFlavor ya da Cohort detaylarına bakın.
- Admit edilmişse Headlamp’in Job ve Pod görünümlerine geçin.
Headlamp neyin yerine geçiyor, neyin geçmiyor?
Eklenti; script’ler, tam nesne çıktısı veya değişiklik yapma işleri için kubectl ya da kueuectl‘in yerini almıyor. Yerini aldığı şey, etkileşimli bir incelemede gereken tekrarlı ve arayüzsüz gezinme.
| Soru | Headlamp yolu | Komut satırı karşılığı |
|---|---|---|
| Workload admit edildi mi? | Kueue → Workloads → status ve conditions | kubectl describe workload <workload-name> -n <namespace> |
| Hangi LocalQueue’ya girdi? | Workload → bağlı LocalQueue | kubectl get localqueue <localqueue-name> -n <namespace> -o yaml |
| Kotayı hangi ClusterQueue sağlıyor? | LocalQueue → bağlı ClusterQueue | kubectl get clusterqueue <clusterqueue-name> -o yaml |
| Hangi flavor veya paylaşılan kota belirleyici? | ClusterQueue → ResourceFlavor veya Cohort | kubectl get resourceflavor <flavor-name> -o yaml ya da kubectl get cohort <cohort-name> -o yaml |
| Admission sonrası ne oldu? | Workloads → Jobs ve Pods → events | kubectl describe job <job-name> -n <namespace> ya da kubectl describe pod <pod-name> -n <namespace> |
Script ve GitOps akışlarında komut satırı doğru araç olmayı sürdürüyor. “Bu neden bekliyor?” diye soran bir insan içinse bağlantılı Headlamp yolu genellikle daha hızlı okunuyor.
İsteğe bağlı: senaryoyu yeniden üretmek
Eklenti deposunda yerel test için örnek Cohort, ClusterQueue, LocalQueue, ResourceFlavor ve Job manifest’leri var. Bu örnekleri Kueue kurulu bir kümeye uygulayıp Headlamp’teki Kueue bölümünü açabilirsiniz.
Yazıdaki kota uyuşmazlığını birebir yeniden üretmek için iki CPU ve iki Pod slotu olan bir ClusterQueue yapılandırın, ardından Pod başına bir CPU isteyen üç Pod’luk bir Job gönderin. Job LocalQueue’ya girer, Kueue bir Workload oluşturur, toplam talep mevcut kotadan büyük olduğu için de Workload pending kalır.
Alpha sürümün bilinen sınırları
0.1.0-alpha, admission yolunun salt okunur ilk görünümü.- Eklenti kendi oluşturma, düzenleme, duraklatma, devam ettirme veya silme akışlarını eklemiyor.
- Workload owner reference’ları metin olarak gösteriliyor, şu an gezinilebilir değil.
- Arayüz, Headlamp’in kullandığı kimliğin Kubernetes izinlerine bağlı.
- Metrikler ve görsel ilişki haritası bu sürümün özelliği değil; olası sonraki adımlar arasında.
Eklentinin mevcut amacı net: admission durumunu ve kaynak ilişkilerini incelemeyi kolaylaştırmak.
LFX Mentorship kapsamında geliştirildi
Eklenti, CNCF LFX Mentorship 2026 Term 2 kapsamında TypeScript, React, Kubernetes API’leri ve Headlamp’in eklenti sistemi kullanılarak geliştirildi. Utkarsh Raj tarafından, René Dudfield (@illume) ve Kevin Hannon (@kannon92) rehberliği ve incelemesiyle hayata geçirildi. Kaynak görünümlerini, durum sunumunu, gezinmeyi, dokümantasyonu, testleri ve ilk alpha sürümü ise Headlamp ve Kueue topluluklarından gelen geri bildirimler biçimlendirdi.
Headlamp yolunu izledikten sonra hala açıklanamayan bir pending Workload kalıyorsa, eklentiyi geliştirmek için en değerli geri bildirim tam olarak budur.
Kaynaklar ve İleri Okuma
- Why Is My Kubernetes Job Still Pending? Tracing Kueue Admission with Headlamp (Kubernetes Blog)
- Kueue resmî sitesi ve Kueue kurulum dokümantasyonu
- Kueue Workload kavramı, LocalQueue, ClusterQueue, ResourceFlavor
- Kueue: Job sorun giderme rehberi
- Headlamp Kueue eklentisinin kaynak kodu ve README dosyası · 0.1.0-alpha sürüm dokümantasyonu
- Headlamp kurulum dokümantasyonu
- Kubernetes Job dokümantasyonu
- İlgili yazı: Headlamp’e Volcano Eklentisi: Batch İşlerini Tek Ekranda İnceleme
- İlgili yazı: Kubernetes Dashboard’dan Headlamp’a: Neden Geçiş Mantıklı?
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.
Yorum gönder