Bakın şimdi, Kubernetes tarafında yıllardır aynı döngüyü görüyorum: iş önce dağınık başlıyor, sonra bir noktada “tamam, bunu artık ortak bir dille konuşalım” ihtiyacı geliyor. Microsoft’un KubeCon + CloudNativeCon Europe 2026’da anlattığı güncellemeler de bana tam bunu hissettirdi. AI iş yükleri büyüdükçe mesele sadece modeli ayağa kaldırmak olmuyor; modeli güvenli, tekrar edilebilir ve ölçeklenebilir biçimde çalıştırmak gerekiyor. Kısa cevap bu. Ama işin içinde epey detay var.
Ben bu geçişi ilk kez 2010’ların ortasında sanallaştırma projelerinde çok net görmüştüm. O zaman da herkesin elinde farklı script’ler, farklı deployment alışkanlıkları vardı. Sonra bir baktık ki operasyon ekibi gece yarısı aynı hatayı üç ayrı yöntemle çözmeye çalışıyor… yorucu iş. Kubernetes’in başarı hikâyesi biraz burada başladı zaten: “nasıl çalıştırırız?” sorusundan çok “nasıl bozmadan değiştiririz?” sorusunu standardize etti. Evet, tam da bu.
Evet, doğru duydunuz.
Kubernetes neden hâlâ oyunun merkezinde?
Açık konuşayım, Kubernetes’i yalnızca “container orkestrasyonu” diye küçültmek haksızlık olur. Ben önü daha çok ortak mutfak gibi görüyorum: Herkes kendi yemeğini pişirebilir ama ocaklar aynıysa, gaz basıncı aynıysa ve temizlik düzeni belliyse işler rayında gider. Microsoft’un mesajı da bunun etrafında dönüyor; yeni yetenekler ekleniyor ama asıl amaç platformu daha tutarlı hâle getirmek. Basit gibi duruyor. Değil aslında.
Geçen yıl Amsterdam’da bir finans müşterisinde benzer bir tartışma yaşamıştık. Veri bilimi ekibi GPU istiyor, platform ekibi işe standart node havuzundan çıkmak istemiyordu. Tam orada scheduling meselesinin ne kadar hayatı olduğunu gördük. Kağıt üstünde süper görünen mimarı, pratikte kaynak paylaşımı yüzünden çatırdıyor. İşin aslı şu ki, yapay zekâ yükleri klasik web uygulamalarından daha nazlı; gecikmeye de topolojiye de duyarlı. Siz ne dersiniz?
DRA neden önemli?
Dynamic Resource Allocation yani DRA, bence bu dönemin sessiz kahramanlarından biri. Çünkü GPU ya da özel donanımı sadece “var” saymak yetmiyor; o kaynağın nasıl ayrıldığını da standartlaştırmak gerekiyor. Microsoft’un upstream tarafta bu işi sahiplenmesi güzel haber. Fena değil demek az kalır; baya iş görüyor.
Bir proje toplantısında — 2024 Kasım’da İstanbul’daki bir üretim firmasındaydı — ekip bana şunu sormuştu: “Neden node etiketi yetmiyor?” Cevap aslında basit ama can sıkıcıydı: Çünkü etiket var diye gerçek fiziksel uyum sihirli şekilde oluşmuyor. GPU ile NIC yan yana mı? Topoloji doğru mu? Job doğru yerde mi koşuyor? Bunlar kilit ayrıntılar. Küçük görünürler ama faturayı sonra çıkarırlar. Hmm, tam burası önemli.
Küçük startup ile enterprise arasında fark ne?
Hani, Küçük bir startup için mesele genelde hızlı deneme yapmak oluyor. Birkaç GPU node’u alınır, model deploy edilir ve yol alınır (ben de ilk duyduğumda şaşırmıştım). Ama enterprise seviyede oyun değişiyor; multi-cluster yönetimi, compliance, veri yerleşimi. Maliyet kontrolü devreye giriyor (kendi tecrübem). Siz ne dersiniz? Yani aynı teknoloji var ama sorulan soru değişiyor.
Çok konuştum, örnekle göstereyim.
- Startup: Hızlı kurulum, az sayıda cluster, minimum operasyon yükü
- Enterprise: Standardizasyon, güvenlik sınırları, denetlenebilirlik (bence en önemlisi)
- Ortak ihtiyaç: Tahmin edilebilir ölçekleme ve sağlam gözlemleme
AI’da standart arayışı neden şimdi hızlandı?
Neyse… burada can alıcı nokta şu: AI tarafı hâlâ biraz kaotik. Bir sistem çalışıyor mu çalışmıyor mu anlaşılırdı eskiden; şimdi işe cevap kalitesi iyi mi kötü mü diye bakıyoruz. Bu apayrı bir disiplin getiriyor. Bu yüzden açık kaynakta ortak API’ler ve davranış kalıpları oluşturmak şart hâle geliyor. Kolay mı? Pek değil.
Ben DP-203’e hazırlanırken veri akışlarının ne kadar çabuk karmaşaya döndüğünü birebir hissetmiştim. Aynı mantık AI altyapısında da geçerli oluyor: veri nereden geliyor, hangi sürüm kullanılıyor, hangi inference katmanı devrede (kendi tecrübem). Bunlar net değilse her ekip kendi gerçeğini yazıyor. Sonra kimse kimsenin çıktısına güvenemiyor. Bak şimdi mesele oraya geliyor işte.
AI altyapısının olgunlaşması için daha fazla araçtan önce daha fazla ortak davranış lazım. Kubernetes bunu container dünyasında yaptı; şimdi benzer şey AI operasyonda yeniden kuruluyor.
Microsoft’un öne çıkardığı parçalar neler söylüyor?
Size bir şey söyleyeyim, KubeCon Europe 2026’da anlatılan başlıklar aslında tek tek teknik detay gibi görünse de birlikte okununca başka bir resim çıkıyor ortaya: GPU planlama iyileşsin, ağ topolojisi dikkate alınsın, inference yönetimi ortaklaşsın (şaşırtıcı ama gerçek). Hepsi aynı hedefe gidiyor — karmaşayı azaltmak. Yani olay sadece özellik listesi değil.
| Bileşen | Ne işe yarıyor? | Neden önemli? |
|---|---|---|
| DRA | Donanım kaynaklarını dinamik ayırıyor | GPU gibi pahalı kaynaklarda israfı azaltıyor |
| DRA Network / DRANet | Ağ kaynaklarını topolojiye göre bağlıyor | AI eğitiminde performansı ciddi etkiliyor |
| AI Runway | Inference için ortak Kubernetes API sunuyor | Ekiplerin servis modelini standardize ediyor |
Ağ katmanı niye ayrı dert?
E tabii insanlar bazen sadece GPU’ya bakıyor ama ağ tarafını unutuyorlar… sonra performans bekledikleri gibi çıkmayınca şaşırıyorlar! Ben Logosoft tarafında yürüttüğümüz yüksek trafikli bir telco projesinde buna çok benzer bir tablo görmüştüm; NIC yerleşimi doğru yapılmayınca throughput düşüyor ve suçlu hep sonradan aranıyor.
Aynı olay AI eğitimlerinde de yaşanabiliyor çünkü GPU güçlü olsa bile data path kötü işe sonuç vasat kalabiliyor. Burada DRANet’in upstream uyumluluğu değerli duruyor; özellikle Azure RDMA NIC desteğiyle birlikte düşününce performans hassas işlerde eli güçlendiriyor. Kısacası ağ kısmını atlamayın.
Tedarikçi bağımlılığı azalır mı?
Bence kısmen evet, ama tamamen sihir beklememek lazım. Open source yaklaşımının güzelliği şu: tek ürünün pazarlama cümlesine mahkûm kalmazsınız; davranış modeli toplulukla şekillenir. Buna rağmen platform ekibinin yine ciddi tasarım yapması gerekiyor — yoksa açık standart var diye mimarı otomatik düzelmez. Azıcık dikkat şart yani.
Sahada bunun karşılığı ne olacak?
Küçük işletmeler için en büyük kazanım basitlik olabilir. Platform ekibi birkaç temel politika belirler, inference servisini ortak API ile koyar ve yoluna bakar. Enterprise tarafta işe daha karmaşık avantajlar gelir; cluster lifecycle yönetimi, observability standartları, güvenlik sınırları ve maliyet raporlama işleri birbirine bağlanabilir. Güzel tarafı bu.
Bazı projelerde beklediğim kadar parlak olmayan kısım şu oldu doğrusu: her yeni framework ya da API hemen mucize yaratmıyor. Mesela organizasyon içinde süreçler oturmamışsa teknoloji tek başına kurtarmıyor. Az önce X dedim ama aslında Y daha doğru olabilir; çünkü problem çoğu zaman koddan önce yönetişimde yatıyor. Şey… bunu sahada defalarca gördüm.
# Basit düşünce modeli
if workload == "training":
reserve_gpu()
validate_topology()
elif workload == "inference":
expose_common_api()
enforce_policy()
else:
keep_it_standard()Nerede heyecanlanıyorum, nerede temkinliyim?
Açıkçası heyecanlandığım yer açık kaynak topluluğunun artık AI’yı da cloud-native disiplinine çekmeye başlaması. Bu kötü şeyleri otomatik olarak yok etmeyecek tabii ama en azından tekrarlanabilirlik sağlıyor. Ben AZ-305 hazırlığında mimarı kararların ne kadar belgeye bağlı olduğunu defalarca gördüm; aynısı burada da geçerli olacak gibi duruyor. Yani çizgi netleşiyor.
Tedirgin olduğum nokta işe şurası: standart API’ler güzel, ama benim sahada gördüğüm her ekip farklı olgunluk seviyesinde. Bir müşteri PoC’de uçarken başka müşteri regülasyon nedeniyle daha ilk adımda takılıyor. Yani herkes aynı hızda koşmuyor; bazısı yürüyerek ilerlemek zorunda. Bu da normal aslında.
Sizin için kısa okuma notu
Bak şimdi, eğer bu konuyu kendi ortamınıza uyarlıyorsanız önce şu üç soruyu sorun: hangi iş yükü gerçekten GPU istiyor, hangi cluster’lar ayrı yönetilmeli ve inference servisiniz kaç farklı ekip tarafından tüketilecek? Bu üç soru netleşmeden araç seçimine dalmak kolay hata yaptırıyor — ki bu çoğu kişinin gözünden kaçıyor. Lafı gevelemeden söyleyeyim, önce ihtiyaç netleşsin. azd Mart 2026: AI Ajanları ve Copilot’la Yeni Dönem yazımızda da bu konuya değinmiştik. GitHub’ın EU Veri Yerleşimi Neden Bir Anda Büyüdü? yazımızda da bu konuya değinmiştik. Copilot’la Kendini Otomatikleştirmek: Ajanlarla Yeni Çalışma Şekli yazımızda da bu konuya değinmiştik. Azure ile Spring Testlerinde Docker Kullanınca Ne Değişiyor? yazımızda da bu konuya değinmiştik.
Sıkça Sorulan Sorular
DRA tam olarak ne işe yarar?
DRA yani Dynamic Resource Allocation, özel donanımları Kubernetes içinde daha esnek şekilde paylaştırmaya yardım ediyor. GPU gibi pahalı kaynaklarda özellikle faydalı.
AI Runway neden önemli görülüyor?
Inference iş yükleri için ortak bir Kubernetes API sunuyor ve platform ekiplerinin dağıtımları daha tutarlı bir şekilde yönetmesine yardımcı oluyor. Bu da farklı ekiplerin aynı standartla çalışmasını kolaylaştırıyor.
Azure RDMA NIC desteği neyi değiştirir?
Ağ ile GPU arasındaki fiziksel uyumu iyileştirerek eğitim performansını yukarı çekebilir. Büyük modellerde küçük topoloji farkları bile hissedilir.
Küçük şirketler bu yeniliklerden faydalanabilir mi?
Evet, ama hepsini aynı anda almak zorunda değiller. En çok da ortak API yaklaşımı küçük ekiplerin operasyon yükünü azaltabilir.
Enterprise ortamda en kritik konu ne?
Genelde güvenlik, gözlemlenebilirlik ve yönetişim öne çıkıyor. Teknik yenilikten çok bunun nasıl standarda bağlandığı belirleyici oluyor.
Kaynaklar ve İleri Okuma
Orijinal Microsoft Blog Yazısı
Azure Kubernetes Service Resmî Dokümantasyonu
Kubernetes Resmî Dokümantasyonu
DRA Example Driver GitHub Deposu
İçeriği paylaş:
İlgili Yazılar
📬 Bu yazıyı faydalı buldunuz mu?
Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!
Yorum gönder