Kubernetes DRA GA: Cihaz Yönetiminde Yeni Dönem Başladı
Şunu en başta söyleyeyim: Kubernetes ilk çıktığı yıllarda kimse “GPU’yu bir pod’a nasıl düzgün bağlarız” diye pek kafa yormuyordu (inanın bana). CPU vardı, RAM vardı, tamam işte. Sonra işler değişti. AI iş yükleri geldi, edge senaryoları geldi, telekom tarafı ayrı dert öldü… Bir noktadan sonra donanım sadece “var” olmaktan çıktı, doğrudan planlamanın parçası hâline geldi. Klasik device plugin modeli de açık konuşayım, bu yükün altında biraz zorlandı.
Neyse. Geçtiğimiz aylarda Dynamic Resource Allocation yanı DRA nihayet GA’ya çıktı. Üretim için “tamamdır” damgasını yemiş öldü. Bunu Kubernetes’in Device Management Working Group cephesindeki üç yıllık maratonun son düzlüğü gibi okumak lazım. Kevin Klues (NVIDIA), Patrick Ohly (Intel) ve John Belamaric (Google) — bu işin arkasındaki üç işim bunlar.
Aslında, Ben de Azure tarafında AKS ile uğraşan biri olarak, bu değişikliğin Türkiye’deki kurumsal ekiplere ne getireceğini epey süredir izliyorum. Bugün lafı gevelemeden, bu yeni cihaz yönetimi dünyasını ve pratikte neye yaradığını anlatayım dedim.
Neden Eski Device Plugin Modeli Yetmedi?
Klasik device plugin modeli aslında kötü değildi. 2017-2018 civarında gayet iş görüyordu. Node üstünde bir plugin çalışıyor, kubelet’e “bende şu kadar GPU var” diyordu; kubelet de bunu scheduler’a iletiyordu. Bitti gitti. Basit.
Araya gireyim: Ama sonra hayat karıştı. GPU’lar bölünebilir hâle geldi (MIG partisyonlarını hatırlayın), bazı pod’lar artık “2 GPU ver” demek yerine “aynı NVLink üzerinde duran 2 GPU ver” demeye başladı, üstüne FPGA’ler geldi, SmartNIC’ler geldi, DPU’lar geldi… Yanı donanım tek parça kaynak olmaktan çıkıp paylaşılabilir ve topolojiye bağlı bir şeye dönüştü.
Şöyle ki, Eski model bu talebi karşılayamazdı çünkü scheduler’ın gördüğü şey sadece bir sayaçtı: nvidia.com/gpu: 4. Peki hangi 4? Aynı NUMA node’unda mı? Aynı switch’in arkasında mı? Topolojisi ne? Cevap yoktu. Kubelet biliyor olabilir, ama scheduler karar verdiğinde çoğu zaman iş işten geçmiş oluyordu.
Kısa bir not düşeyim buraya.
NP-Hard Meselesi ve Scheduler’ın Sıkıntısı
Size bir şey söyleyeyim, İşin matematiği burada devreye giriyor. Karmaşık donanım kısıtlarıyla optimal yerleştirme yapmak — literatürdeki adıyla NP-hard bir problem. Yanı “kesin çözüm” ölçek büyüdükçe iyice can sıkıyor. Böyle durumlarda akıllı veri modelleri gerekiyor; yoksa scheduler el yordamıyla dolaşıyor.
DRA tam burada sahneye çıkıyor: sayaç yerine yapısal parametreler koyuyor, deklaratif kısıtlar sunuyor ve scheduler’ın karar vermeden önce donanımın topolojisini görebilmesini sağlıyor. Kağıt üstünde bakınca basit dürüyor. Pratikteyse üç yıl süren ciddi bir mühendislik işi.
DRA Aslında Ne Yapıyor?
Bak şimdi, en kolay yol bunu storage tarafındaki PVC/PV modeline benzetmek. Storage’da nasıl PersistentVolumeClaim yazıyorsanız. Arkada CSI driver işi yürütüyorsa, DRA tarafında da benzer parçalar var:
- ResourceClaim: Pod’un “bana şöyle bir cihaz lazım” dediği nesne
- DeviceClass: Cihaz sınıfının şablonu (mesela “A100 GPU’lar” gibi) — bunu es geçmeyin
- ResourceSlice: Node üzerindeki mevcut donanımın yapısal envanteri
- DRA Driver: Donanımı hazırlayan ve pod’a bağlayan bileşen
Küçük bir detay: Fark şu: eskiden “1 GPU ver” diyordunuz; şimdi “8 GB’dan fazla belleği olan, aynı NUMA node’unda duran 2 GPU ver, tercihen NVLink ile bağlı olsunlar” diyebiliyorsunuz. Bu dil biraz daha gerçek hayata benziyor açıkçası.
“Scheduler artık kör değil. Cihazın ne olduğunu, hangi topolojide durduğunu, kiminle konuştuğunu biliyor. Bu, AI iş yükleri için oyunu değiştiren şey.” — sahadan bir gözlem
Kodla Bakınca Daha Netleşiyor
Bence, Kod olarak görünce olay daha iyi oturuyor. Şöyle bir tanım düşünün:
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
name: gpu-claim-training
spec:
devices:
requests:
— name: gpu
deviceClassName: nvidia-a100
selectors:
— cel:
expression: "device.attributes['memory'].quantity >= '40Gi'"
count: 2
constraints:
— requests: ["gpu"]
matchAttribute: "resource.nvidia.com/nvlinkDomain"
Bir şey dikkatimi çekti: Burada olan şey şu aslında: iki GPU istiyorum, her biri en az 40Gi belleğe sahip olsun ve ikisi aynı NVLink domain’inde bulunsun diyorum. Tahmin eder mısınız? Eski dünyada bunu YAML içinde ifade etmek baya zahmetliydi; node label’lar, affinity kuralları, taint/toleration derken ortaya spagetti çıkıyordu. Daha fazla bilgi için
Peki neden sorun öldü? Cluster autoscaler bu modelde resmen tökezliyordu diyelim. “Bu pod’a yer var mı, yeni node açsam mı?” sorusuna cevap almak için driver’a danışmak gerekiyordu ve bu da ölçekte performans sıkıntısı çıkarıyordu. O yüzden 2023-2024 arasında tasarım ciddi biçimde yeniden ele alındı ve structured parameters yaklaşımı ortaya çıktı.
Şöyle ki, Yeni modelde pek çok donanım envanteri ResourceSlice olarak API server’da dürüyor; scheduler karar verirken kimseyi dürtmüyor, önündeki veriye bakıyor sadece. Bu değişiklik autoscaler tarafını da rahatlatmış öldü ve GA yolunu açtı.
Peki Türkiye’deki Kurumsal Ekipler İçin Ne Anlama Geliyor?
Sahada gördüğüm kadarıyla Türkiye’de Kubernetes üzerinde GPU çalıştıran kurumların önemli kısmı hâlâ device plugin modelinde ilerliyor. AKS’e NVIDIA device plugin’i kuruyorsun, çalışıyor gibi oluyor ve şimdilik idare ediyor.
E tabi AI dalgası herkesi vurdu diyebiliriz; bankalar da geliyor, sigorta şirketleri de geliyor, e-ticaret oyuncuları da (bu konuda ikircikliyim). Herkes bir şekilde “AI platformu” kurmaya çalışıyor ya da en azından öyle hissettiriyor kendini. Fine-tuning işleri var, embedding pipeline’ları var, RAG mimarileri var… Ve ekiplerin çoğu aynı yere çarpıyor: GPU var ama verimli kullanamıyoruz.
Bir GPU’nun tamamını küçücük bir inference pod’una vermek kağıt üstünde biraz saçma dürüyor ama eski model bunu düzgün paylaştıramıyordu zaten. NVIDIA Multi-Instance GPU (MIG) veya time-slicing seçenekleri vardı tabiî ki; yalnız Kubernetes entegrasyonu biraz topaldı diyelim. DRA bu sancıyı hafifletmeye aday görünüyor.
Enterprise mı Startup mı?
İlginç olan şu ki, Açık konuşayım: eğer 3-5 kişilik bir startup iseniz. Elinizde tek A100 kart varsa bugün kalkıp DRA’ya koşmanız şart değil. Peki, klasik device plugin işinizi görür. Ama…
- Birden fazla GPU node’unuz varsa
- Topolojiye duyarlı iş yükleriniz varsa (multi-node training gibi)
- Ekipler arasında GPU paylaşımı sorunu yaşıyorsanız
- MIG partitioning yapıyorsanız
…o zaman DRA’ya bakmaya başlayın derim. Enterprise ölçekte,özellikle telekom ve büyük finans oyuncuları için bu mesele artık “olur mu olmaz mı” değil,“ne zaman geçeriz” meselesi.
AKS Tarafında Durum Ne?Azure Kubernetes Service tarafında DRA desteği yavaş yavaş oturuyor. Kubernetes 1.32 ile beta,1.34 ile de GA yolculuğu tamamlandı. AKS’in bu özellikleri devreye alması genelde upstream’den birkaç minör sürüm geriden gelir; yanı 2026 boyunca AKS üzerinde DRA’yı üretim seviyesinde kullanmak bence gerçekçi bir hedef.
Ama dikkat: NVIDIA’nın kendi DRA driver’ı henüz tam pişmiş sayılmaz. GA damgası Kubernetes API’sinde olsa da arka plandaki driver ekosistemi hâlâ olgunlaşıyor. O yüzden ben genelde şunu söylüyorum: pre-prod ortamda deneyin,izleyin,ama üretim GPU cluster’ınızı sabaha karşı tek hamlede migrate etmeye kalkmayın.
Peki neden?
Küçük Bir Karşılaştırma Tablosu
Sıkça Sorulan Sorular
DRA için mutlaka GPU’ya mı ihtiyacım var?
Hayır, öyle bir zorunluluk yok. DRA aslında sadece GPU için tasarlanmış bir şey değil. FPGA, SmartNIC, DPU, TPU, hatta özel donanım hızlandırıcıları — yanı aklınıza gelebilecek neredeyse her şeyle çalışıyor. Ama tecrübeme göre şu an en çok GPU tarafında kullanılıyor, çünkü AI iş yükleri her yeri kaplamış durumda.
Mevcut device plugin kurulumumu bir gecede DRA’ya geçirmem mi gerekiyor?
Tartışmasız hayır. İki model gayet güzel bir arada yaşayabiliyor. Bence en mantıklısı şu: yeni iş yüklerinizde DRA’yı deneyin, eskiler zaten çalışmaya devam ediyor. Zorla migrasyon yerine kademeli geçiş çok daha akıllıca bir yol (yanlış duymadınız)
AKS’te DRA’yı şu an üretimde kullanabilir mıyım?
Teknik olarak deneyebilirsiniz, açıkçası (evet, doğru duydunuz). Ama üretim için ben biraz daha beklemenizi öneririm. NVIDIA driver’ları henüz tam olgunlaşmıyor ve AKS entegrasyonu da tam oturmadı. Önce pre-prod’da iyice test edin; üretim planlaması için 2026 sonlarına bakmak daha güvenli.
Hmm, bunu nasıl anlatsamdı…
DRA scheduler performansımı olumsuz etkiler mi?
Structured parameters yaklaşımıyla scheduler artık ekstra dış çağrı yapmıyor — tüm veri zaten API server’da dürüyor. Yanı performans etkisi minimal. Ama hani çok karmaşık kısıtlar yazarsanız, mesela ağır CEL expression’lar falan, o zaman tabiî ki hesaplama yükü artıyor (evet, doğru duydunuz). Kısıtlarınızı sade tutarsanız sorun çıkmıyor.
DRA cluster autoscaler ile uyumlu mu?
Evet, artık uyumlu. Başlarda değildi aslında — ilk tasarım autoscaler’ı epey zorluyordu. Yeni structured parameters yaklaşımı bu problemi büyük ölçüde çözdü ve bence GA’nın önünü açan en kritik değişikliklerden biriydi.
Kaynaklar ve İleri Okuma
Kubernetes Blog: Spotlight on WG Device Management
Kubernetes Resmî Dokümantasyonu: Dynamic Resource Allocation
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.
4 comments