Kubernetes 1.37'de DRA genişletilmiş kaynaklar GA oldu; GPU pod'ları eski istek biçimini koruyabiliyor

Kubernetes v1.37, DRA genişletilmiş kaynakları (extended resources) genel kullanıma (GA) taşıdı. Oleksandr Kuryzhev'in dev.to'daki uygulamalı rehberi, bunun GPU filoları için neyi değiştirdiğini ele alıyor: node'lar, tek bir workload manifestine dokunulmadan eski device plugin modelinden bir Dynamic Resource Allocation (DRA) driver'ına taşınabiliyor.

Köprü nasıl çalışıyor

Klasik modelde her node'daki bir device plugin, kubelet'e sahip olduğu kaynak birimlerinin sayısını bildirir ve scheduler yalnızca anlaşılmaz bir tamsayı görür. Bir H100'ü T4'ten ayıramaz; topoloji veya bölümlendirme (partition) hakkında hiçbir görüşü yoktur. DRA bu sayıyı yapılandırılmış veriyle değiştirir: driver'lar gerçek cihazları ve özniteliklerini tanımlayan ResourceSlice objelerini yayınlar, scheduler ise belirli cihazları ResourceClaim objeleri üzerinden tahsis eder; eşleştirme bir DeviceClass veya claim içindeki CEL selector'larla yapılır.

Genişletilmiş kaynaklar özelliği iki dünyayı birbirine bağlar. Rehbere göre bir DeviceClass, nvidia.com/gpu gibi bir genişletilmiş kaynağı adlandırabilir; bir pod limitlerinde bu adı istediğinde, scheduler pod adına bir claim oluşturur, eşleşen sınıftan bir cihaz tahsis eder ve sonucu pod'un status'üne kaydeder. Pod yazarları hiçbir fark görmezken platform ekibi altta DRA'nın tahsis modelini kazanır. Yazar, alan adlarını tam yama sürümünüzde kubectl explain deviceclass.spec ile doğrulamanızı öneriyor.

Ekiplerin hata yaptığı yerler

Rehber dört yaygın hata modu belirliyor:

• Her iki yığını aynı GPU'larda çalıştırmak. Device plugin DaemonSet'i hâlâ çalışırken bir DRA driver'ı kurmak, her ikisinin de aynı fiziksel cihazları duyurması anlamına gelir ve sistem fazla söz verebilir. Pod'lar container başlangıcında başarısız olabilir veya bir cihaz için çekişebilir. Belgelenen kural şudur: bir cihaz aynı anda yalnızca bir mekanizma tarafından yönetilir.
• İlk günden her manifesti ResourceClaim'lere yeniden yazmak. Dönüştürme yalnızca seçim veya paylaşım gerektiren workload'lar için gerekir; köprü, çoğu pod'un değişmeden kalabilmesi için tam olarak var.
• Bunu her cluster'a doğrudan takılabilir bir çözüm sanmak. Karışık sürümlü node havuzları, eski kubelet'ler veya genişletilmiş kaynak eşlemesi olmayan driver'lar, Pending durumunda takılı pod'lar üretir. Yalnızca Kubernetes sürümünü değil, driver'ın sürüm notlarını da kontrol edin.
• Muhasebe tarafını unutmak. Kotalar, maliyet panoları ve uyarılar çoğunlukla node allocatable nvidia.com/gpu değerini okur; bir havuz DRA'ya geçtiğinde bu, doğru kaynağı olmaktan çıkabilir.

Önerilen geçiş süreci

Önerilen yaklaşım, bir kere etiketlenmiş bir node havuzunu geçirmektir: havuzu cordon edip drain edin, node affinity ile device plugin DaemonSet'inin dışında bırakın, üreticinin DRA driver'ını kurun, DeviceClass'ı oluşturun, ardından node'ları uncordon edin. NVIDIA'nın driver'ı nvidia-dra-driver-gpu Helm chart'ı olarak dağıtılıyor.

DeviceClass, driver'la eşleşen bir CEL selector'ı (NVIDIA durumunda gpu.nvidia.com) eski kaynak adını DRA destekli tahsise bağlayan bir extendedResourceName alanıyla eşleştirir. Doğrulama üç kontrolle yapılır: kubectl get resourceslices her GPU node'u için slice'ları listelemeli, kubectl get resourceclaims pod'un namespace'inde tahsis edilmiş bir claim göstermeli ve pod'un YAML'ı claim'i status'ünde kaydetmiş olmalı. Pending'de takılı bir pod genellikle eksik bir extendedResourceName veya hiçbir şeyle eşleşmeyen bir CEL ifadesine işaret eder.

İleri desenler ve sınırlar

Bir havuz DRA üzerinde çalışmaya başladıktan sonra biçimler karıştırılabilir. Çoğu pod eski isteği korurken, belirli bir GPU modeli, MIG profili veya paylaşımlı cihaz gerektiren birkaç pod, cihaz öznitelikleri üzerinde CEL selector içeren açık bir ResourceClaimTemplate kullanır. Rehber, selector yazmadan önce bir driver'ın gerçekte yayınladığı öznitelikleri kubectl get resourceslices -o yaml ile incelemeyi öneriyor. Birden fazla DeviceClass, GPU katmanlarını da ifade edebilir; böylece politika node etiketleri ve taint'lerden, namespace'ler ve RBAC üzerinden yönetilen bildirimsel objelere taşınır. Rehber ayrıca v1.37'nin Workload/PodGroup gang scheduling özelliğini beta olarak sunduğunu, bunun dağıtık eğitim pod'larının bir küme halinde zamanlanmasını sağladığını, ancak feature gate'lerinin ve DRA ile etkileşiminin önce doğrulanması gerektiğini not ediyor.

Köprünün sınırları var: yalnızca basit "bir türden N cihaz" durumunu kapsıyor ve aynı cihaz için eski isteği zengin seçimle birleştirmek test gerektiriyor. Paylaşım ihtiyacı olmayan, özdeş bütün-cihaz GPU'lardan oluşan küçük bir filo için device plugin makul bir seçim olmaya devam ediyor. Performans konusunda rehber, maliyetlerin büyümediğini yer değiştirdiğini savunuyor: scheduler CEL selector'ları değerlendiren bir DynamicResources plugin'i çalıştırıyor ve her pod bir claim objesi üretiyor; bu yüzden kısa ömürlü pod'ları olan büyük filolar, API server obje sayılarını ve etcd boyutunu izlemeli ve bir havuzu geçirmeden önce ve sonra scheduler_pending_pods gibi metrikleri karşılaştırmalı.

Neden önemli

ML platform ekipleri çoğu zaman GPU'ları sayıya göre isteyen yüzlerce eğitim manifesti elinde tutar; device plugin modeli ise bu ekiplerin giderek artan şekilde ihtiyaç duyduğu model bazlı seçim, MIG dilimleri ve paylaşımlı cihazları ifade edemez. DRA genişletilmiş kaynakları kademeli bir geçiş yolu sunar: altyapıyı node havuzu havuzu taşıyın, riskli bir filo geneli manifest yeniden yazımından kaçının, sonra zengin tahsimi işe yaradığı yerlerde seçmeli olarak benimseyin. Bu, GPU filolarında DRA benimsenmesinin başlıca pratik engelini ortadan kaldırıyor ve topoloji farkındalı ile bölümlendirilmiş GPU zamanlaması gibi özellikleri büyük patlamalı bir geçiş olmadan erişilebilir kılıyor.