GPU’yu sayıyla değil, niteliğiyle istemek: Kubernetes’te Dynamic Resource Allocation

Bir AI/ML ekibiyle çalışıyorsanız muhtemelen şu cümleyi defalarca duymuşsunuzdur: “Pod ayağa kalkmıyor, GPU bekliyor.” Daha da can sıkıcı olanı, küme dolu görünmesine rağmen pahalı hızlandırıcıların yarısının boşta beklemesidir. Bir taraf GPU bulamazken diğer taraf elindeki kartın gücünü kullanamaz. Bu, modern Kubernetes ortamlarının en sessiz ama en pahalı problemlerinden biri.

Sorunun kökeninde, Kubernetes’in donanım hızlandırıcılarını yıllarca yönettiği yöntem yatıyor. Bir pod yıllarca yalnızca nvidia.com/gpu: 1 diyebiliyordu. Yani "bir adet GPU isterim". Hangi GPU? Ne kadar belleği olan? Tek başına mı kullanacak yoksa paylaşacak mı? Bu soruların hiçbiri bu modele sığmıyordu. İşte bu yazıda, Kubernetes'in bu probleme verdiği yeni ve kalıcı cevabı — Dynamic Resource Allocation'ı (DRA) — ele alacağım. Kavramı anlatacağım, mimarisini göstereceğim ve ne zaman buna ihtiyaç duymayacağınızı da konuşacağım.

DRA Ne Yapar?

Dynamic Resource Allocation, Kubernetes’in GPU, FPGA gibi özel donanım kaynaklarını esnek ve talebe dayalı bir şekilde yönetmesini sağlayan bir çerçevedir. Tek cümleyle: bir iş yükünün, ihtiyaç duyduğu cihazın özelliklerini tarif etmesine izin verir; hangi cihazın verileceği kararını ise scheduler’a bırakır.

Burada anahtar kelime “özellik”. Eski modelde donanım talebi bir sayıydı. DRA’da ise talep bir tarif haline gelir: “en az 20 GB belleğe sahip bir GPU isterim” gibi. İş yükü neye ihtiyaç duyduğunu söyler, scheduler da envanterdeki cihazlar arasından bu tarife uyanı bulup ayırır.

Bunu mümkün kılan iki yeni nesne var. ResourceClaim, bir iş yükünün cihaz talebini temsil eder — yani "şu niteliklere sahip bir cihaz istiyorum" beyanı. ResourceSlice ise sürücünün kümeye yayınladığı, mevcut cihazların ve niteliklerinin envanteridir. Scheduler bu ikisini eşleştirir.

DRA’nın çekirdeği, Kubernetes 1.34 sürümünde Genel Kullanıma (GA) ulaştı. Bu, çerçevenin artık kararlı olduğu, kırıcı değişiklik yapılmayacağı ve uzun vade için Kubernetes’in bir parçası sayılabileceği anlamına geliyor. 1.34 ile birlikte DRA varsayılan olarak etkin geliyor ve resource.k8s.io API grubundaki birçok API kararlı v1 sürümüne geçti.

Mimari / Nasıl Çalışır?

DRA’yı dört katmanda düşünmek, akışı kafada netleştiriyor. Aşağıdaki diyagram bu akışı gösteriyor: talep nereden çıkar, karar nerede verilir, cihaz nerede hazırlanır.

Akışı sırayla takip edelim:

Talep katmanı. Pod, bir ResourceClaim (veya tekrar kullanılabilir bir ResourceClaimTemplate) ile başlar. Burada iş yükü, ihtiyaç duyduğu cihazı niteliklerle tanımlar. Dikkat: bu bir sayı değil, bir tariftir.

Envanter katmanı. Donanım sürücüsü, node’lardaki cihazları ResourceSlice nesneleri olarak kümeye yayınlar. Scheduler'ın seçim yapabilmesi için önce "elimizde ne var" bilgisinin ortada olması gerekir; bu katman onu sağlar.

Karar katmanı. kube-scheduler devreye girer. ResourceClaim'deki tarifi, ResourceSlice'lardaki envanterle eşleştirir ve uygun cihazı ayırır. Asıl zekânın bulunduğu yer burasıdır — pod hangi node'a gideceğini değil, neye ihtiyaç duyduğunu söyler; eşleştirmeyi scheduler yapar.

Hazırlık katmanı. Cihaz ayrıldıktan sonra, ilgili node üzerindeki DRA sürücüsü cihazı pod için hazır hale getirir. Ardından cihaz pod’a bağlanır ve iş yükü onu kullanmaya başlar.

Bu mimarinin getirdiği birkaç somut yeteneği de eklemek gerekir. Cihaz paylaşımı artık daha ince taneli yapılabiliyor — örneğin bir GPU’nun belirli bir bellek dilimi güvenli şekilde tahsis edilebiliyor. Ayrıca cihaz sağlık durumu doğrudan Pod status üzerinden raporlanabiliyor; yani arızalı bir cihazı tespit etmek için derin log kazısına gerek kalmıyor. Bir de extended resource eşlemesi var: yöneticiler DRA tarafından yönetilen kaynakları, geliştiricilerin alışık olduğu basit istek söz dizimiyle tüketilebilir hale getirebiliyor.

Gerçek Dünyada Nerede Kullanılır?

DRA’nın asıl değer kazandığı yer, donanımın pahalı ve heterojen olduğu ortamlardır. Genel senaryolarla bakalım.

İlki, AI/ML iş yükleri. Bir küme içinde farklı GPU modellerinin bir arada bulunması artık istisna değil, kural. Bir eğitim işi yüksek bellekli bir kart isterken, çok sayıda küçük inference servisi tek bir kartı paylaşmak isteyebilir. DRA, her iş yükünün ihtiyacını ayrı ayrı tarif etmesine izin verdiği için, doğru işi doğru karta oturtmayı mümkün kılar.

İkincisi, kaynak verimliliği. Eski sayı temelli modelde bir GPU’yu istemek, çoğu zaman onu tümüyle kaplamak demekti. Bu da kullanımı düşük, faturayı yüksek bırakırdı. İnce taneli paylaşım, pahalı hızlandırıcıların boşta kalma süresini azaltır.

Üçüncüsü, heterojen donanım yönetimi. GPU’nun yanı sıra FPGA veya başka özel cihazlar barındıran kümelerde, her cihaz tipini ayrı ayrı device-plugin mantığıyla yönetmek yerine, hepsini ortak bir tarif diliyle ifade edebilirsiniz.

Ne Zaman DRA Değil?

DRA güçlü bir çerçeve, ama her küme için doğru cevap olmayabilir. Dengeli bakmak gerekirse:

Eğer kümenizde hiç özel donanım yoksa — yalnızca CPU ve bellekle çalışan standart iş yükleri varsa — DRA size somut bir fayda getirmez. CPU ve bellek zaten Kubernetes’in yerleşik kaynak modeliyle yönetiliyor; DRA bu tabloya bir şey eklemez, sadece karmaşıklık getirir.

İhtiyacınız gerçekten basitse, yani “bir GPU, tamamı bana ait, paylaşım yok” diyorsanız, eski device-plugin modeli hâlâ çalışıyor ve daha az kavramla aynı işi görüyor. DRA’nın getirdiği ResourceClaim, ResourceSlice, sürücü mimarisi gibi kavramlar, basit bir senaryoda öğrenme eğrisini gereksiz yere dikleştirir.

Bir nokta daha: DRA sürücüsü yazmak, klasik device-plugin yazmaktan daha karmaşıktır. Eğer kendi donanımınız için sürücü geliştirecekseniz, ekosistemin henüz olgunlaşmakta olduğunu ve bu yolun bir öğrenme maliyeti taşıdığını hesaba katmalısınız. Network’e bağlı, tahsis öncesi görünmeyen kaynaklar gibi bazı senaryolar da hâlâ geliştirme aşamasında.

Kısacası DRA, donanımın pahalı, çeşitli ve paylaşılması gereken olduğu yerlerde parlar. Donanımın olmadığı ya da ihtiyacın “bir tane ver, gerisi önemli değil” kadar basit olduğu yerlerde ise eski yöntem fazlasıyla yeterlidir.

Kapanış

DRA’nın özü, donanım talebini bir sayıdan bir tarife dönüştürmesidir. Pod artık “bir GPU” demiyor; “şu niteliklere sahip bir cihaz” diyor ve eşleştirmeyi scheduler’a bırakıyor. Kubernetes 1.34 ile çekirdeğin GA olması, bu modelin artık production ortamları için güvenle benimsenebileceği anlamına geliyor.

Bir sonraki yazıda, bu kavramı somutlaştırmak için bir ResourceClaim ve ResourceClaimTemplate'in nasıl yazıldığını, GPU'lu basit bir iş yükünü DRA ile nasıl ayağa kaldırdığınızı adım adım göstereceğim. Kavramı anladıktan sonra, onu çalışırken görmek her şeyi yerine oturtur.