Bir bankanın altyapı müdürüyle telefon görüşmesi: “AKS mi ARO mu, kararı bize verin.” 15 dakika sorduktan sonra cevap netleşti: ARO. Sebep: ekipte zaten OpenShift deneyimi vardı, regülatörle yapılan görüşmede “yönetilen Kubernetes” terimi geçmişti, ekip developer experience üzerinde ısrarcıydı. Aynı soruya bir e-ticaret startupı için cevap tam tersi: AKS, çünkü ekibin OpenShift deneyimi yok, esneklik kritik, maliyet hassas.
Bu yazıda Azure Red Hat OpenShift’i (ARO) sahada baktığımız haliyle anlatıyorum. Pazarlama broşüründen değil — gerçek kullanım, gerçek tradeoff, gerçek fiyat.
ARO nedir, AKS’ten farkı tam olarak ne?
İki cümleyle: ARO, OpenShift Container Platform’un Azure üzerinde Microsoft ve Red Hat tarafından ortak yönetilen halidir. Yani sadece bir Kubernetes değil, OpenShift — yani Kubernetes + RHCOS + Red Hat’in geliştirici/güvenlik araçları.
| Bileşen | AKS | ARO |
|---|---|---|
| Control plane | Microsoft yönetir | Microsoft + Red Hat ortak yönetir |
| İşletim sistemi (node) | Ubuntu / Mariner | Red Hat CoreOS (RHCOS) |
| Default container runtime | containerd | CRI-O |
| Web konsolu | Yok (kubectl + Portal) | OpenShift web console (zengin UI) |
| CI/CD built-in | Yok (3rd party kur) | Tekton + Pipelines built-in |
| Source-to-image (S2I) | Yok | Var, kod git → image otomatik |
| Service mesh | Open Service Mesh / Istio (kullanıcı kurar) | OpenShift Service Mesh built-in |
| Operator framework | Var ama daha az kullanılır | Çekirdek konsept, OperatorHub bütünleşik |
| RBAC + güvenlik | Standart K8s | SCC (Security Context Constraints) + ek politikalar |
| Destek | Microsoft | Microsoft + Red Hat (24×7 ortak) |
Saha kuralı: ARO “opinionated Kubernetes”. Red Hat’in opinion’ları (güvenlik default’ları, geliştirici akışları, OperatorHub) işinize yarıyorsa hızlanırsınız. Bu opinion’lara karşı çalışmak zorundaysanız hayatınızı zorlaştırır. Ekibinizin altyapı tercihi belirleyici.
Maliyet: Sahadan üç hesap
ARO’nun aylık baz maliyeti AKS’ten yüksek çünkü Red Hat lisansı dahil. Karşılaştırma için tipik bir Türk müşterisinin 3 master + 4 worker setup’ı:
| Kalem | AKS (4 worker, D4s_v3) | ARO (4 worker, D4s_v3) |
|---|---|---|
| Control plane | ~6.000 TL/ay | ~12.000 TL/ay (Red Hat dahil) |
| Worker nodeları (4 x D4s_v3) | ~22.000 TL/ay | ~22.000 TL/ay |
| Master nodeları (3 x D8s_v3) | 0 (managed) | ~17.000 TL/ay |
| Toplam aylık (yaklaşık) | ~28.000 TL | ~51.000 TL |
ARO’nun yaklaşık 1.8x maliyeti var. Bu farkı kapatan şey: hazır gelen bileşenlerin (Pipelines, Service Mesh, Image Registry, Logging) değeri ve Red Hat 24×7 desteği. Eğer bu bileşenleri AKS üzerinde kendiniz kurup yönetecekseniz operasyonel maliyet ARO’nun maliyet farkını aşar.
Hangi senaryoda ARO doğru tercih?
Senaryo 1: OpenShift on-prem deneyimi olan kurumlar
Banka, sigorta, telekom — pek çok kurum on-prem OpenShift kullanıyor. Buluta geçişte aynı developer experience, aynı RBAC modeli, aynı pipeline aracı kalmasını istiyorlar. ARO bunu birebir verir; ekip yeniden eğitime gerek duymaz.
Senaryo 2: Düzenleyici denetim sıkı olan sektörler
Red Hat’in Security Context Constraints (SCC) modeli default olarak “least privilege”. Container’ların root user çalıştırması, host network kullanması, privileged mode girmesi varsayılan kapalı. Bunu KVKK/BDDK denetiminde “out-of-the-box güvenli” olarak göstermek kolay.
Senaryo 3: Geliştirici deneyimi (DX) önceliği
OpenShift web konsolu kullanıcı dostu — geliştirici git push yapar, S2I image build edip deploy eder. “kubectl apply -f” hattı atlanır. 50+ kişilik dev takımları için bu hız ciddi avantaj.
Senaryo 4: Multi-cloud / hybrid stratejisi
Aynı OpenShift platformu Azure’da, AWS’de (ROSA), on-prem’de (OCP) çalışıyor. Workload portability gerçek; ekip aynı araçları her ortamda kullanır. Vendor lock-in azaltma stratejisi olarak değerlidir.
Hangi senaryoda AKS daha doğru?
- Maliyet hassas startup’lar: Aylık 23.000 TL fark ürün stage’inde önemli
- Sade Kubernetes seven ekipler: Vanilla K8s + Helm akışı isteyenler
- OpenShift opinion’larına yatkın olmayan mimari: Örn. host network ihtiyacı, privileged container, alternatif image registry
- Microsoft ekosistemine derin gömülü olanlar: AKS Azure servisleri ile entegrasyon ARO’dan biraz daha düşük sürtünmelidir (ARO’da Red Hat katmanı bazen ek konfigürasyon ister)
ARO kurulum: Sahadan dikkat edilmesi gerekenler
# Subscription registration (bir kez)
az provider register --namespace 'Microsoft.RedHatOpenShift'
az provider register --namespace 'Microsoft.Compute'
az provider register --namespace 'Microsoft.Storage'
az provider register --namespace 'Microsoft.Authorization'
# VNet ve subnet'ler (master + worker ayrı)
az network vnet create -g rg-aro-prod -n vnet-aro --address-prefixes 10.0.0.0/22
az network vnet subnet create -g rg-aro-prod --vnet-name vnet-aro
-n master-subnet --address-prefixes 10.0.0.0/23 --service-endpoints Microsoft.ContainerRegistry
az network vnet subnet create -g rg-aro-prod --vnet-name vnet-aro
-n worker-subnet --address-prefixes 10.0.2.0/23 --service-endpoints Microsoft.ContainerRegistry
# Disable subnet private endpoint policies
az network vnet subnet update -g rg-aro-prod --vnet-name vnet-aro
-n master-subnet --disable-private-link-service-network-policies true
# Cluster oluştur (40-60 dakika sürer)
az aro create
--resource-group rg-aro-prod
--name aro-banking-prod
--vnet vnet-aro
--master-subnet master-subnet
--worker-subnet worker-subnet
--pull-secret @pull-secret.txt
--location 'westeurope'
Pull-secret.txt Red Hat hesabınızdan indirilir. Bu olmadan cluster oluşmaz.
OpenShift’in geliştiriciler için sunduğu güzellikler
Source-to-Image (S2I)
Git repo URL’si verirsiniz, S2I dil/framework’ü tespit eder, image build edip deploy eder. Dockerfile yazmaya gerek yok.
oc new-app https://github.com/cloudspark/spring-app --name=order-service
# OpenShift: Java tespit etti, OpenJDK base image kullanıldı
# Build başladı, image registry'ye push edildi, deployment oluşturuldu
# Route otomatik açıldı, HTTPS cert otomatik
Tekton Pipelines (built-in CI/CD)
Tekton Operator OperatorHub’da. Kurar kurmaz Pipeline tanımlamaya başlarsınız. Jenkins veya GitLab CI’a alternatif olarak built-in.
OperatorHub
200+ Operator hazır. PostgreSQL, Kafka, MongoDB, Elastic, Prometheus — tek tıkla kurulup yönetilir. AKS tarafında bunları Helm chart ile manuel yapıyorsunuz.
Türkiye’den iki vaka
Vaka 1: Banka — başarılı ARO geçişi
22 mikroservis, on-prem OpenShift. Hedef Azure. ARO seçildi çünkü ekibin tüm araç zinciri (Tekton, Operators, web console) aynı kalacaktı. 3 ayda migration tamamlandı, on-prem environment dekomisyonlandı. Aylık maliyet on-prem’in %42’si, kalan parayla yıllık eğitim bütçesi finanse edildi.
Vaka 2: E-ticaret platformu — AKS’e dönüş
Önce ARO seçilmiş (“OpenShift on-prem’de var, devamı”). 8 ay sonra: ekip büyük kısmı startup’tan gelmiş, OpenShift opinion’larına alışamadı, custom image registry’ye geçmek istediler, SCC kuralları custom networking’i karmaşıklaştırdı. AKS’e geçiş 2 ayda yapıldı. ARO yanlış seçim değildi ama ekibin gerçek deneyimi ile uyuşmadı. Sahada “ekip uyumu” kararın yarısı.
ARO’yu doğru kullanmak için 5 öneri
- SCC default’larını koruyun: Custom SCC yazmak gerektiğinde sadece o spesifik servis için yazın, global gevşetme yapmayın
- OperatorHub’ı kullanın: PostgreSQL veya Kafka kurmak için Helm chart yazmayın, Operator var
- Developer self-service’i açın: Geliştirici namespace’i otomatik oluştursun, web konsoldan deploy etsin — bu OpenShift’in en güçlü yanı
- Cluster autoscaler ayarlayın: Worker sayısı dinamik olsun, gece kapalı saatlerde scale-in olsun
- Red Hat support’u kullanın: Aylık 30.000 TL+ fazla ödüyorsanız 24×7 support hattı kullanmamak savurganlık
Sık Sorulan Sorular
ARO’da kubectl çalışıyor mu yoksa sadece oc mu?
İkisi de çalışır. “oc” OpenShift CLI, kubectl’in superset’i — tüm kubectl komutları çalışır, üstüne OpenShift’e özel komutlar (oc new-app, oc rollout, oc logs build) eklenir.
ARO’da Helm kullanabilir miyim?
Evet, Helm 3 desteklenir. Ama OpenShift dünyası Helm yerine Operator tercih ediyor. Helm chart’ınız varsa kullanabilirsiniz; sıfırdan kuruyorsanız Operator yolunu düşünün.
ARO Microsoft veya Red Hat tarafından ne kadar destekleniyor?
%100 ortak destek. Microsoft + Red Hat 24×7 SLA ile arıza alır. Tek destek kanalı (Azure portal’dan ticket açarsınız), arka planda her iki tarafın mühendisleri çalışır.
ARO’dan AKS’e migration ne kadar zor?
Container image’lar standard, helm chart’lar büyük oranda taşınır. Ama OpenShift-specific kaynaklar (Routes, BuildConfigs, ImageStreams, SCCs) yeniden yazılmalı. Tipik 4-8 hafta sürer.
Türkiye’den ARO destek dili nedir?
Resmi olarak İngilizce. Microsoft Türkiye Premier müşterileri için Türkçe support kanalı var ama Red Hat tarafı İngilizce. Ekipte İngilizce konuşan en az 2 kişi olması lazım.
Sonuç
ARO, AKS’ten daha pahalı ama daha “opinionated” bir Kubernetes. Doğru senaryoda — kurumsal kullanım, OpenShift deneyimi, sıkı denetim — fark fazlasıyla geri ödenir. Yanlış senaryoda — startup, esnek mimari, maliyet hassasiyeti — AKS daha doğru. İki platform arasındaki seçim teknolojik değil, ekibinizin yetkinliği ve operasyonel modelinizle ilgilidir.
ARO/AKS karar matrisini sizin senaryonuzda çalıştırmak veya mevcut Kubernetes platformunuzu değerlendirmek için CloudSpark olarak 1 günlük assessment paketi sunuyoruz. İletişim sayfasından ulaşabilirsiniz.
