Kubernetes v1.36’da DRA: Donanım Paylaşımında Yeni Dönem
Kubernetes tarafında bazı sürümler vardır, ilk bakışta küçük görünür ama sonra cluster’ın yönünü değiştirir (yanlış duymadınız). DRA için v1.36 da bence tam öyle bir nokta. Ben bu güncellemeyi, “GPU verdik, — ki bu tartışılır — tamamdır” seviyesinden çıkıp donanımı daha akıllı, daha esnek. Biraz da daha insan gibi yönetmeye giden bir adım olarak görüyorum. Hani ne farkı var diyorsunuz, değil mi? İşin aslı şu; platform ekibiyseniz artık sadece cihaz atamıyorsunuz, cihazın davranışını da epeyce şekillendiriyorsunuz.
İşin garibi, Ben yıllardır Azure ve Kubernetes tarafında kurumsal müşterilerle çalışırken şunu net gördüm: en pahalı kaynak çoğu zaman CPU değil, yanlış tahsis edilen özel donanım oluyor. 2024’te İstanbul’daki bir finans kurumunda GPU havuzu planlarken bunu birebir yaşadık; bazı işler H100 istiyordu ama herkesin H100’e abanması gerekmiyordu. Orada fallback mantığı devreye girseydi işimiz bayağı kolay olurdu. Şimdi v1.36 ile gelen yenilikler tam da o boşluğu dolduruyor gibi dürüyor.
Bir dakika — bununla bitmedi.
DRA neden önemli hâle geldi?
Bak şimdi, Klasik Kubernetes kaynak modeli çoğu senaryoda yetiyordu. Ama AI eğitimi, medya işleme, düşük gecikmeli ağ işleri ve parçalanabilir GPU ihtiyacı girince tablo değişti. Bir anda “CPU request/limit ver geç” kafası yetmemeye başladı. Mesela büyük kurumsal ortamlarda aynı cluster içinde hem genel amaçlı uygulama hem de özel hızlandırıcı isteyen işler olunca dengeyi tutturmak zorlaşıyor.
2023 sonunda Ankara’da bir üretim müşterisinde benzer bir karışıklık yaşadık. Takımda herkes ayrı ayrı özel node pool açmıştı; maliyet şişmişti, kapasite işe yarım yamalak kullanılıyordu. Eğer o yapıda bugünkü gibi prioritized list ve cihaz bazlı politika seçenekleri olsaydı, ciddi bir sadeleşme yapılabilirdi. Açık konuşayım: bu tip iyileştirmeler kağıt üstünde küçük dürüyor ama operasyon tarafında farkı bayağı büyük.
Bir de şu var: DRA sadece AI ekiplerinin oyuncağı değil. Ağ kartları, storage hızlandırıcıları ve başka özel donanımlar da bu modelin içine girince platform yöneticisinin eline tek bir çatı altında daha temiz bir kontrol seti geçiyor. Ben bunu seviyorum çünkü dağıtık karmaşayı azaltıyor. Ama tabiî her güzel şeyin bir eksiği var; öğrenme eğrisi hâlâ biraz dik.
Küçük ekip mi, kurumsal yapı mı?
Küçük bir startup iseniz her yeni DRA özelliğini hemen açmak zorunda değilsiniz. Hatta bazen hiç açmamak daha iyi olabilir; önce kullanım kalıbınızı oturtun, sonra cihaz seçimini ince ayara alın. Çünkü erken aşamada sorun genelde teknoloji eksikliğinden değil, süreç eksikliğinden çıkıyor.
Peki neden? Azure Cosmos DB ile Kurumsal Yapay Zekâ: Ölçek Meselesi yazımızda bu konuya da değinmiştik. Azure SQL’de AI_GENERATE_EMBEDDINGS GA: T-SQL ile Vektör Devri yazımızda bu konuya da değinmiştik.
Kurumsal tarafta işe durum başka (şaşırtıcı ama gerçek). 10-20 ekip aynı Kubernetes altyapısını kullanıyorsa — itiraz edebilirsiniz tabi — cihaz taint’i, toleration’ı, fallback listesi ve partitioning gibi özellikler doğrudan maliyet kalemi oluyor. Logosoft’ta geçen yıl Eylül ayında yaptığımız bir değerlendirmede bunu çok net gördük: aynı fiziksel GPU havuzundan iki farklı iş kolu beslenebildiğinde kapasite kullanımı bariz şekilde yükseliyor. Daha fazla bilgi için AI iş yüklerini ölçeklendirme yazımıza bakabilirsiniz.
v1.36 ile gelen başlıklar ne söylüyor?
Kendi deneyimimden konuşuyorum, Prioritized list artık stable olmuş durumda ve bence en pratik yeniliklerden biri bu. Tek tek model adı ezberlemek yerine sıralı tercih verebiliyorsunuz: önce H100 olsun, yoksa A100 olsun gibi… Bu yaklaşım özellikle heterojen kümelerde hayat kurtarıyor (buna dikkat edin)
Extended resource support beta seviyesine gelmiş olması da önemli. Eski sistemlerden DRA’ya geçerken kimseyi bir gecede kırıp dökmüyorsunuz. Ben bunu göç projelerinde severim; çünkü müşteri tarafında “hemen hepsini yeniden yazalım” demek çoğu zaman gerçekçi olmuyor. GitHub Copilot Build Performance: Proje Bazlı Analiz Geldi yazımızda bu konuya da değinmiştik.
Partitionable devices tarafı işe ayrı bir kapı açıyor. MIG benzeri bölünebilir donanımları düşünün; tek devasa kart yerine küçük dilimler halinde kapasite sunabiliyorsunuz. 2022’de Almanya’daki bir Ar-Ge grubuyla konuşurken bu ihtiyacın ne kadar büyüdüğünü görmüştüm — herkes tüm kartı istemiyor aslında, çoğu iş yarısını bile doldurmuyor. Daha fazla bilgi için Microsoft 365 Copilot Agent Evaluations: Ajan Kalitesi Ölçümü yazımıza bakabilirsiniz.
| Özellik | Sürüm Durumu | Pratik Etki | Bence Notu | |
|---|---|---|---|---|
| Prioritized list | Stable | Daha iyi fallback seçimi | Baya iş görür | |
| Extended resource support | Beta | Kademeli geçiş kolaylığı | Migrasyon için değerli | |
| Partitionable devices | Beta | Daha verimli paylaşım | Pahalı donanımda şart gibi | |
| Device taints/tolerations | Beta | Sorunlu ya da ayrılmış cihaz kontrolü | Kritik operasyon aracı | ? |
| Device binding conditions | Beta |
Sahada en çok işime yarayan taraflar
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
4 comments