Red Hat Summit 2026: Azure OpenShift ile AI Üretime Geçti
İtiraf edeyim, Geçen hafta Bostan’da Red Hat Summit 2026’yı uzaktan izlerken, açık konuşayım, bir an “yine aynı slaytlar mı?” diye düşündüm. Çoğu konferans böyle akıyor zaten; büyük sözler, küçük değişiklikler. Ama bu sefer biraz farklıydı. Microsoft, Platform Modernization Partner of the Year ödülünü aldı ve işin arkasındaki hikâye bence çoğu teknik haberden daha anlamlı.
📋 İçindekiler
-
Geçen ay e-ticaret tarafındaki bir müşteride tam burada sıkıntı yaşamıştık — Defender şüpheli pod davranışını yakaladı ama hangi namespace’te hangi service account’ın ne yaptığını ilk anda çıkaramadık. ACS devreye girince detay ortaya döküldü. Yarım saat sürecek investigation işi beş dakikaya indi desem yeridir. Şu yazıya da bakabilirsiniz:
- Model çalışıyor ama identity yönetimi yok; kim hangi modele erişebilir belli değil.
- GPU kaynakları paylaşılamıyor; her ekip kendi kümesini istiyor ve maliyet şişiyor.
- Governance dağılıyor; biri Hugging Face’ten model çekiyor, diğeri Foundry’den alıyor, üçüncüsü kendi fine-tune’ünü yapıyor.
- Production’da observability zayıf kalıyor; model saçmaladığında çoğu zaman sonradan fark ediyorsunuz. (bu kritik)
ARO + OpenShift AI + Azure AI Foundry üçlüsü tam buraya oynuyor aslında.
Bradesco örneğinin kıymeti de burada ortaya çıkıyor; 200 inisiyatifi tek policy çatısı altında tutabilmek öyle kağıt üstünde kolay görünen bir şey değil.
“Müşteriler artık feature istemiyor; en kritik iş yüklerini koşturacakları platformun güvenilirliğini istiyor.” — Aaron Isom, Technical Cloud Strategist
Bunu okuyunca kafamda bazı taşlar yerine oturdu açıkçası.
Son bir yıldır müşteri görüşmelerinde aynı soruyu defalarca duydum: “Aşkın bey, biz Azure OpenAI kullanıyoruz, Foundry’yi de kuracağız ama bunu enterprise seviyede nasıl yöneteceğiz?” Eskiden cevap biraz dolambaçlıydı; şimdi daha net görünüyor.
Eğer Kubernetes çevreindeyseniz ARO + OpenShift AI ciddi adaylardan biri oluyor.
Şimdi gelelim işin can alıcı noktasına.
Küçük Ekip Mi Kurumsal Yapı Mı?
Aslında, Açık konuşayım.
Eğer beş kişilik bir startup’sanız ve sadece POC yapıyorsanız ARO size pahalı gelebilir.
Azure Container Apps ya da direkt AKS sizi daha hızlı başlatır.
Ama bazı şartlarda tablo değişiyor:
- 50+ geliştiriciniz varsa;
- düzenlemeye tabi bir sektördeyseniz (finans, sağlık ya da kamu gibi); — ciddi fark yaratıyor
- birkaç bölgede iş yükünüz varsa;
- Zaten OpenShift bilen ekibiniz varsa (RHCSA veya RHCE sertifikalı insanlar).
Böyle olunca ARO’nun yönetilen yapısı gerçekten rahatlatıyor.
Maliyet tarafında da kaba hesap yapılabilir; Azure pricing calculator’a göre 3 master + 3 worker (D8s_v5) olan bir küme aylık yaklaşık 2500-3000 USD bandından başlıyor.
TL bazında bakınca evet kayda değer bir rakam.
Ama buna karşılık self-managed kümeyi üç SRE ile döndürmenin toplam maliyetini düşününce iş bazen tersine dönüyor.
Peki Nasıl Başlanır?
İnanın, Diyelim ki ikna oldunuz ve “tamam Aşkın bey biz de ARO deneyeceğiz” diyorsunuz.
O zaman gerçek hayattan kısa bir başlangıç planı şöyle olabilir:
# 1. Önce gerekli provider'ları register et az provider register --namespace Microsoft.RedHatOpenShift az provider register --namespace Microsoft.Compute az provider register --namespace Microsoft.Storage az provider register --namespace Microsoft.Authorization # 2. Pull secret'ı Red Hat'tan al (console.redhat.com) # 3. Network için VNet ve subnet'leri hazırla az network vnet create --resource-group aro-rg \ --name aro-vnet --address-prefixes 10.0.0.0/22 # 4. Kümeyi oluştur (bu adım 35-45 dakika sürer) az aro create --resource-group aro-rg \ --name my-aro-cluster \ --vnet aro-vnet \ --master-subnet master-subnet \ --worker-subnet worker-subnet \ --pull-secret @pull-secret.txtBurada en sık yapılan hata pull secret’ı yanlış formatta vermek oluyor.
JSON dosyası bekleniyor; base64 değil.
Ben ilk denediğimde yarım saat bununla uğraşmıştım doğrusu.
Hata mesajı da pek yol göstermiyor; sadece “invalid pull secret” deyip bırakıyor.
💡 Bilgi:”ARO kümeleri minimum 3 control plane + 3 worker node ile başlar.” Yanı POC için bile az buz kaynak harcıyorsunuz.
Eğer sadece deneme yapmak istiyorsanız Red Hat’in OpenShift Sandbox’ını veya CodeReady Containers’ı tercih edin.Neyse Ki OpenShift AI Tarafı Var!
💡 Bilgi:“OpenShift AI (eski adıyla RHODS), KubeFlow tabanlı bir ML platformu.” Jupyter notebook’lar,
model serving,
pipeline orchestration hepsi içinde.
Azure AI Foundry ile entegrasyon işe henüz tam oturmuş değil;
bazı yerleri elle bağlamak gerekiyor.
Mesela embedding modelini Foundry’de tutup inference’ı ARO’da yapmak istiyorsanız,
arada bir gateway katmanı kurmanız lazım.
Bu konuda Foundry Hosted Agents ile MAF’ı Prod’a Taşımak: Benim Notlarım
yazımda daha detaylı notlar paylaşmıştım,
ona da bakabilirsiniz.Neyi Beğenmedim?
Ama hep övgü yazmak istemiyorum çünkü dürüst olayım,
ARO’nun sorunları da var.
Bunları söylemezsem eksik kalır:Birincisi:
Cluster oluşturma süresi hâlâ uzun.
35-45 dakika,
bazen tam bir saate yaklaşıyor.
AKS tarafında bu iş genelde
5-10 dakika içinde bitiyor.
“Zaten production ortamını bir kere kurarsın” diyebilirsiniz;
doğru,
ama dev/test ortamlarını sürekli yıkıp kuran ekipler için sınır bozucu olabiliyor.İkinci olarak:
Maliyet şeffaflığı pek iç açıcı değil. Azure Cost Management,
ARO için ayrıntılı breakdown göstermiyor;
çoğu zaman tek satırda “ARO cluster” görüyorsunuz. Hangi namespace ne kadar tüketmiş,
hangi workload ne harcamış,
bunları ek araç olmadan görmek zor.İçincisi:
Türkiye’de henüz bölge yok.
Avrupa tarafında en yakın seçenekler North Europe (Dublin) veya West Europe (Amsterdam).
Latency hassas iş yükleriniz varsa bunu hesaba katmanız gerekiyor.
Bunu Azure’ın Avrupa Yatırımları: Egemen Bulut ve AI Genişlemesi
yazısında da konuşmuştum.Sıkça Sorulan Sorular
Azure Red Hat OpenShift ile AKS arasında ne fark var?
AKS, Microsoft’un yönettiği saf Kubernetes hizmeti. ARO işe Red Hat OpenShift’in Azure üzerinde joint-operated (yanı Microsoft + Red Hat birlikte destekliyor) versiyonu. Aslında ikisi arasındaki fark oldukça belirgin — ARO; built-in CI/CD, developer console, RBAC genişletmeleri, ek güvenlik özellikleri. Enterprise destek paketi sunuyor. Bence OpenShift ekosistemindeyseniz ARO çok daha mantıklı, vanilla Kubernetes yeterliyse AKS’e bakın.
ARO’da OpenAI veya Foundry modellerini nasıl kullanabilirim?
Modeller Azure tarafında çalışıyor, ARO’daki uygulamalarınız bunlara REST API üzerinden erişiyor. Managed identity ile authentication yapabilir, private endpoint ile trafiği VNet içinde tutabilirsiniz. Bir de şunu söyleyeyim — OpenShift AI tarafında kendi modellerinizi de serve edebiliyorsunuz. Yanı ikisini birlikte kullanan hibrit bir mimarı de gayet mümkün.
KVKK ve BDDK uyumluluğu için ARO uygun mu?
Bunu yaşayan biri olarak söyleyeyim, Açıkçası burada dikkatli olmak lazım. Veriniz Türkiye’de kalmak zorundaysa, henüz — itiraz edebilirsiniz tabi — Türkiye’de Azure bölgesi olmadığı için saf ARO tek başına yeterli olmayabilir. Ancak Azure Local + ARO hibrit yapısı veya West Europe gibi yakın bölgelerle BCRA/SCC çerçevesinde uyumluluk sağlanabiliyor. Her durumda hukuk ve compliance ekibinizle mutlaka konuşun — bence bu adımı atlamak büyük risk.
Mevcut on-prem OpenShift kümemi ARO’ya nasıl taşırım?
Red Hat’in OADP (OpenShift API for Data Protection) aracı veya MTC (Migration Toolkit for Containers) ile workload migration yapabilirsiniz. Tipik bir geçiş şöyle gidiyor: önce hedef kümeyi provision ediyorsunuz, sonra image registry mirror, ardından namespace bazlı batch migration (ciddiyim). Tecrübeme göre stateful uygulamalar için PV (persistent volume) stratejisini önceden netleştirmek çok önemli — bunu es geçmeyin.
ARO’yu tek başıma yönetebilir mıyım, yoksa ekip mi lazım?
Küçük bir POC için tek kişi yetebilir (yanlış duymadınız). Ama production için en az 2-3 kişilik bir platform ekibi öneririm. Hani OpenShift kavramları — mesela Operators, Routes, BuildConfigs — vanilla Kubernetes’ten oldukça farklı. Öğrenme eğrisi gerçekten var. Ekipte RHCSA veya en azından OpenShift Foundations sertifikası olan biri olsun, bence bu şart.
Kaynaklar ve İleri Okuma
İnanın, Microsoft Azure Blog — Red Hat Summit 2026 Duyurusu
Azure Red Hat OpenShift Resmî Dokümantasyonu
Red Hat OpenShift Resmî Sayfası
ARO Üzerinde AI Workload’ları — Microsoft Learn
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Ceren M.
Banco Bradesco gibi büyük bir bankanın ARO üzerinde AI’a geçişini görünce “acaba governance tarafını nasıl çözdüler” diye merak ettim, yazıda biraz daha detay olsaydı süper olurdu. Zaten production’a geçiş konusuna ilgi duyanlar için şu yazı da değerliydi: Microsoft Agent Framework v1.0: Lokal’den Prod’a Geçiş — https://www.askinkilic.com.tr/microsoft-agent-framework-v10-lokalden-proda-gecis/
Burak S.
Banco Bradesco örneği ilginç, büyük bir finansal kurumun ARO üzerinden AI’ı üretime taşıması kolay olmamış olmalı. Acaba bu geçiş sürecinde en çok hangi governance sorunlarıyla karşılaştılar, yazıda detay var mı?
Yorumlar kapalı.
2 comments