Özet: Vanilla Kubernetes açık kaynak konteyner orkestrasyon platformudur; Red Hat OpenShift ise Kubernetes üzerine eklenmiş kurumsal bir katmandır ve aynı temel API'yı kullanır. Seçim, ekibin platform mühendisliği kapasitesine, lisans bütçesine ve regülasyon gereksinimlerine göre yapılır; çoğu Türk şirketi için yönetilen (managed) Kubernetes-as-a-Service hem maliyet hem esneklik açısından en dengeli seçenektir.
Ana noktalar:
- OpenShift, Kubernetes API'sının üzerine eklenmiş bir kurumsal katmandır; tüm Kubernetes manifest'leri OpenShift üzerinde çalışır.
- Vanilla Kubernetes üretim için yeterli olsa da güvenlik, monitoring ve backup katmanlarını ekibin kurması gerekir.
- OpenShift'in oc CLI'sı kubectl ile %95 örtüştüğü için geliştirici öğrenme eğrisi minimumdur.
- OpenShift varsayılan SCC kısıtlamaları (örneğin root ile çalışmama) Helm chart uyumluluğunu etkileyebilir.
- Managed KaaS, hem operasyonel yükü hem de bare-metal vs sanal makine kararını sağlayıcıya devreder.
Konteyner orkestrasyonu artık modern uygulama mimarisinin omurgası; ancak bu omurga hangi platform üzerinde inşa edilmeli? Vanilla Kubernetes açık kaynak esneklik vaat ederken Red Hat OpenShift "kurumsal hazır Kubernetes" konumlandırmasıyla geliyor; üstelik aynı temel teknoloji üzerine inşa edilmiş olsalar da operasyonel, güvenlik ve maliyet boyutlarında önemli farklar var. Yanlış seçim, kurumun yıllık BT bütçesinde ciddi yan etkilere yol açabiliyor.
Bu rehber, platform ekipleri, DevOps mühendisleri, çözüm mimarları ve CTO'lar için yazıldı. Kubernetes ile OpenShift'in mimari, güvenlik, geliştirici deneyimi, lisans, TCO ve düzenleyici uyum açılarından farklarını somut karşılaştırmalarla aktarıyoruz. Marka tercihi değil, iş yüküne uygun karar verme aracı sunmayı hedefliyoruz.
Sonunda, "ekibim 5 geliştirici" ile "şirketim BDDK düzenlemesi altında" gibi farklı senaryolar için doğru kararı verebilecek netlik kazanacaksınız.
CNCF Annual Survey raporları, Kubernetes'in kurumsal konteyner orkestrasyonunda de facto standart haline geldiğini doğruluyor (kaynak).
Kubernetes ve OpenShift nedir?
İki platform da konteyner orkestrasyonu yapar; ama farklı seviyelerde paketlenir.
Vanilla Kubernetes ne sunar?
Vanilla Kubernetes, CNCF (Cloud Native Computing Foundation) tarafından yönetilen, Apache 2.0 lisansıyla açık kaynak olarak dağıtılan konteyner orkestrasyon platformudur. Pod scheduling, service discovery, declarative configuration ve auto-healing gibi temel orkestrasyon özelliklerini sunar.
Kurulum ve operasyon büyük ölçüde sizin sorumluluğunuzdadır: ağ eklentisi (CNI), depolama (CSI), ingress controller, monitoring stack, certificate manager gibi onlarca bileşeni kendiniz seçer, kurar ve günceller. Esneklik en üst seviyededir; operasyon yükü de.
Red Hat OpenShift nedir ve nasıl konumlanır?
Red Hat OpenShift, Kubernetes çekirdeği üzerine inşa edilmiş, Red Hat tarafından paketlenmiş ve desteklenen kurumsal bir dağıtımdır. Kurulum installer'ı, integrated registry, built-in CI/CD (Tekton/Pipelines), developer console, integrated logging ve monitoring stack gibi onlarca eklentiyi tek paket olarak getirir.
Konumlanmasının özü "Day 2 operations" — yani üretime aldıktan sonraki güvenlik, izleme, yamalama ve yaşam döngüsü yönetimini standartlaştırmaktır.
OKD ve OpenShift Container Platform farkı
OKD (eski adıyla OpenShift Origin), OpenShift'in topluluk sürümüdür; ücretsiz ve açık kaynaktır ancak Red Hat resmi desteği yoktur. OpenShift Container Platform (OCP) ise ticari sürümdür; abonelik gerektirir, Red Hat tarafından sertifikalı imajlar ve 7/24 destek sunar.
Üretim ortamı genelde OCP veya managed OpenShift seçer; OKD eğitim ve test senaryoları için uygundur.
Mimari farklılıklar
Aynı Kubernetes çekirdeği üzerine inşa edilmiş olsalar da bazı temel teknoloji tercihleri farklıdır.
Konteyner çalışma zamanı: containerd vs. CRI-O
Vanilla Kubernetes günümüzde varsayılan olarak containerd kullanır; daha hafif, daha hızlı ve geniş ekosistem desteği var. OpenShift ise CRI-O kullanır; Kubernetes için özel tasarlanmış, daha minimal bir runtime. Pratikte iki seçenek de performans açısından eşdeğer; geliştirici için fark görünmez.
Ağ katmanı: Calico, Cilium, OVN-Kubernetes
Vanilla Kubernetes ağ eklentisini siz seçersiniz: Calico (network policy), Cilium (eBPF tabanlı, gözlemlenebilirlik), Flannel (basit). OpenShift varsayılan olarak OVN-Kubernetes ile gelir; entegre, ama farklı CNI'ları desteklemez kadar esnek değildir.
Image registry: harici registry vs. entegre OpenShift Registry
Vanilla Kubernetes ortamında Harbor, Nexus, Artifactory veya cloud sağlayıcının registry'si kullanılır. OpenShift ise entegre bir registry ile gelir; bu, image push/pull işlemlerinin cluster içinde kalmasını sağlar ve external dependency'i azaltır.
Build sistemleri: kaniko, Buildah, Source-to-Image (S2I)
Vanilla Kubernetes'te image build genelde CI/CD pipeline'da (Jenkins, GitLab CI) kaniko veya buildah ile yapılır. OpenShift, Source-to-Image (S2I) özelliği ile kaynak kodundan doğrudan image üretebilir; geliştirici Dockerfile yazmadan deployment yapabilir.
S2I, özellikle iç dağıtım için standart "altın imaj" kullanan kurumlarda değer üretir; her dilin (Java, Node.js, Python, Go) onaylı bir base image'i tanımlanır, geliştirici yalnızca kaynak kodunu push eder. Vanilla Kubernetes tarafında bu konsepti elde etmek için Cloud Native Buildpacks veya benzeri abstraction katmanları gerekir.
Güvenlik karşılaştırması
Güvenlik, OpenShift'in en güçlü değer önerisidir.
Pod Security Admission vs. Security Context Constraints (SCC)
Vanilla Kubernetes 1.25+ Pod Security Admission (PSA) ile gelir; bu, pod'ların hangi privilege seviyesinde çalışabileceğini düzenler. OpenShift ise yıllardır Security Context Constraints (SCC) kullanır; varsayılan olarak root kullanıcıyla çalışan pod'ları reddeder.
Pratikte bu fark, çoğu açık kaynak Helm chart'ın OpenShift üzerinde ek konfigürasyon gerektirmesi anlamına gelir. Bu hem güvenlik avantajı hem de operasyonel sürtünme yaratır.
RBAC ve OAuth entegrasyonu
Her iki platform da RBAC sunar. OpenShift, ek olarak entegre bir OAuth sunucusu ve LDAP, Active Directory, GitHub, Google gibi identity provider'larla doğrudan entegrasyon sağlar. Vanilla Kubernetes'te bu entegrasyonu Dex, Keycloak veya cloud provider IAM ile siz kurarsınız.
Varsayılan güvenli ayarlar
OpenShift'in "secure by default" felsefesi, sıfırdan kurulan cluster'ın production-ready güvenlik standartlarına sahip olmasını sağlar. Vanilla Kubernetes'te bu standartlara ulaşmak ekibinizin bilinçli kararlar almasını gerektirir.
Sertifikalı container imajları
Red Hat, Red Hat Universal Base Image (UBI) ve sertifikalı operator'lar ile tedarik zinciri güvenliği sağlar. Vanilla Kubernetes ekosisteminde bu güvenliği Docker Hub veya farklı registry'lerden gelen imajların provenance kontrolü ile siz yönetirsiniz.
Modern tedarik zinciri güvenliği için her iki tarafta da SBOM (Software Bill of Materials), Sigstore/cosign ile imza doğrulama ve image signing politikaları tavsiye edilir. OpenShift bu kontrolleri operator'larla hazır getirirken vanilla Kubernetes'te bu yığını siz kurarsınız: harbor + trivy + cosign + kyverno tipik bir kombinasyondur.
Geliştirici deneyimi (DX)
Hızlı geliştirme döngüsü, modern platformların kritik metriklerinden.
kubectl vs. oc CLI
kubectl Kubernetes'in resmi CLI'sıdır; oc ise OpenShift'in kubectl üzerine eklediği komutlarla (oc new-app, oc rollout, oc port-forward gibi) zenginleştirilmiş sürümüdür. oc tüm kubectl komutlarını destekler.
Web konsolu ve Developer Catalog
Vanilla Kubernetes'in resmi web dashboard'u temeldir; pek çok ekip bunun yerine Lens, Rancher veya Headlamp gibi üçüncü taraf araçlar kullanır. OpenShift Web Console ise zengin bir geliştirici deneyimi sunar: Developer Catalog, topology view, application templates ve quickstart'lar dahildir.
GitOps: ArgoCD vs. OpenShift GitOps
ArgoCD vanilla Kubernetes ekosisteminde GitOps için standart. OpenShift GitOps ise aynı ArgoCD'nin Red Hat destekli, OpenShift'e entegre versiyonudur. Aynı araç, farklı paketleme.
CI/CD: Tekton, Jenkins, OpenShift Pipelines
OpenShift Pipelines, Tekton'un Red Hat destekli versiyonu olarak gelir. Vanilla Kubernetes'te Argo Workflows, Tekton veya Jenkins ile aynı sonucu alırsınız. Yine paketleme farkı belirleyici.
Lisanslama ve maliyet (TCO)
En kritik karar boyutu.
Vanilla Kubernetes maliyet kalemleri
Vanilla Kubernetes ücretsizdir, ancak TCO'su sıfır değil: platform mühendislerinin maaşı, monitoring/logging araçlarının lisansları, güvenlik tarama araçları, eğitim ve sertifikasyon maliyetleri eklenir. Tipik bir self-managed Kubernetes cluster'ının "gizli maliyeti" 2-3 senior platform engineer FTE'ye karşılık gelir.
Red Hat OpenShift abonelik modelleri
OpenShift, çekirdek (core) başına veya sanal makine başına lisanslanır. Yıllık abonelik modeli, kurumsal destek ve sertifikalı imaj kullanımını içerir. Birim maliyet yüksektir, ancak güvenlik ve destek kalemlerini de kapsadığı için TCO karşılaştırması nüanslıdır.
Managed KaaS alternatifi
Üçüncü bir seçenek: managed Kubernetes as a Service. Sağlayıcı (Cloud4U Türkiye gibi) cluster'ı kurar, günceller, yedekler ve izler. Maliyet öngörülebilir, operasyon yükü ortadan kalkar.
5/15/50 geliştirici için TCO örneği
| Ekip büyüklüğü | Vanilla K8s (örnek) | OpenShift (örnek) | Managed KaaS (örnek) |
|---|---|---|---|
| 5 geliştirici | Yüksek operasyon yükü, düşük lisans | Çok pahalı | En uygun |
| 15 geliştirici | Operasyon yükü ekleniyor | Orta-üst | Hâlâ uygun |
| 50+ geliştirici | Operasyon ölçeklenebilir | Lisans daha hesaplı oluyor | Orta-üst |
Hangi senaryoda hangi platform?
Karar matrisini somutlaştıralım.
KOBİ ve hızlı MVP: managed KaaS
5-20 geliştiricili bir startup için en hızlı yol, sağlayıcının yönettiği KaaS. Cluster operasyonu için kimseyi işe almaz, ürün geliştirmeye odaklanırsınız. Cloud4U Türkiye KaaS, TRY ile faturalama ve Türkçe destek avantajı sunar.
Düzenlemeye tabi sektörler: OpenShift
Bankacılık (BDDK), sağlık veya kamu sektörü gibi düzenlemeye tabi alanlarda OpenShift'in standartlaşmış güvenlik ve sertifikasyon avantajları, denetim sürecini hızlandırır. Lisans maliyeti, denetim hazırlığında biriken eforu azaltarak kendini amorti edebilir.
Hybrid ve multi-cloud stratejileri
OpenShift, hem on-premise hem de farklı bulut sağlayıcılarda aynı operasyonel deneyimi sunma vaadi sunar. Hybrid stratejisi olan büyük kurumlar için bu konsistans değer üretir.
Karar ağacı
- Mevzuat ağırlığı var (BDDK, KVKK denetim) → OpenShift veya managed KaaS (Türkiye DC)
- Hızlı time-to-market önceliği → managed KaaS
- Platform ekibimiz var ve sıfırdan kontrol istiyoruz → vanilla Kubernetes
- 100+ geliştirici, multi-cloud → OpenShift
Bu karar matrisinde göz ardı edilmemesi gereken faktör, ekibin mevcut yetkinliğidir. Red Hat ekosistemine aşina bir ekip OpenShift'te haftalar içinde production'a çıkarken vanilla Kubernetes'te öğrenme eğrisi aylar sürebilir. Tersine, CNCF açık kaynak ekosistemiyle yıllardır çalışan bir DevOps ekibine OpenShift dayatmak operasyonel sürtünme yaratır.
KVKK, BDDK ve veri yerelleştirme
Düzenleyici uyum, Türkiye'deki seçimin merkezinde.
Türkiye'de OpenShift ve KaaS
İstanbul veri merkezinde çalışan bir OpenShift veya KaaS, KVKK kapsamındaki kişisel verileri Türkiye sınırlarında tutar; yurt dışına aktarım yükümlülüğü ortadan kalkar. Bu, denetim hazırlığını ve müşteri güvencesini basitleştirir.
Bankacılık (BDDK) için onaylı altyapı
BDDK Bilgi Sistemleri Yönetmeliği, kritik bankacılık iş yüklerinin Türkiye'deki onaylı veri merkezlerinde işlenmesini şart koşar. OpenShift'in standartlaşmış güvenlik kontrol setleri, BDDK denetiminde gösterilecek dokümantasyonun büyük bölümünü hazır sunar.
Veri merkezi konumunun önemi
Konteyner üzerinde çalışan uygulama veriyi nereye yazıyor? Persistent volume hangi storage backend'de? Backup nereye gidiyor? Bu soruların yanıtları, KVKK denetiminin omurgasıdır; sağlayıcı seçiminde önceliklendirin.
OpenShift'ten Kubernetes'e (ve tersi) geçiş
Sıklıkla göz ardı edilen, ama gerektiğinde kritik bir senaryo.
Route → Ingress dönüşümü
OpenShift Route nesneleri, vanilla Kubernetes Ingress'in eşdeğeridir. Migration sırasında her Route, eşdeğer bir Ingress + IngressClass tanımına dönüştürülmelidir. TLS ve path-based routing kuralları taşınırken konfigürasyon farklılıklarına dikkat edin.
BuildConfig ve ImageStream taşıma
OpenShift'in BuildConfig ve ImageStream nesneleri vanilla Kubernetes'te karşılığı olmayan kavramlardır. Migration sırasında bu nesneler Tekton veya GitLab CI pipeline'larıyla yeniden yazılmalı, image'lar harici registry'ye taşınmalıdır.
Helm chart'lara migration
OpenShift'te S2I ile deploy edilen uygulamalar, vanilla Kubernetes'e taşınırken Helm chart'larına dönüştürülür. Bu süreç, deployment standardizasyonu için aslında bir fırsattır; uygulamaların farklı platformlara taşınabilirliği artar.
Migration sırasında özellikle DeploymentConfig'in Deployment'a dönüştürülmesi, rolling update stratejilerinin yeniden yapılandırılması ve OpenShift'e özgü annotation'ların temizlenmesi adımları planlanmalıdır. Tipik bir 50 servisli uygulamanın migration projesi 2-4 hafta sürer; pilot servisten başlayıp aşamalı ilerlemek riski azaltır.
Kubernetes resmi dokümantasyonu, küme yönetimi, güvenlik politikası ve workload deployment için referans kaynaktır (kaynak).
Sıkça sorulan sorular (SSS)
OpenShift Kubernetes'in yerini alır mı?
Hayır, OpenShift Kubernetes'in yerini almaz; Kubernetes üzerine inşa edilmiş bir kurumsal katmandır ve çekirdeği Kubernetes API'dır. Tüm Kubernetes manifest'leri OpenShift üzerinde de çalışır; OpenShift yalnızca developer console, S2I ve entegre güvenlik gibi ek araçlar ekler.
Vanilla Kubernetes üretim ortamı için yeterli mi?
Evet, vanilla Kubernetes üretim için yeterlidir; ancak güvenlik, monitoring, backup ve networking katmanlarını ekibinizin kurması ve sürdürmesi gerekir. 2-3 senior platform engineer'lı bir ekip bunu başarabilir; aksi takdirde managed KaaS daha pratik bir seçimdir.
OpenShift lisans maliyeti gerçekten yüksek mi?
Birim lisans olarak evet yüksektir; ancak destek, güvenlik ve araçlar dahil bütünsel TCO'da kendi yönetilen vanilla K8s ile karşılaştırıldığında genelde dengelidir. Bazı senaryolarda OpenShift TCO'su daha da düşük çıkabilir; bu, platform mühendisi maaş yüküne bağlıdır.
KaaS seçersem OpenShift mi Kubernetes mi olmalı?
Çoğu Türk şirketi için Kubernetes tabanlı KaaS, maliyet ve esneklik açısından en uygun seçimdir. OpenShift KaaS, yalnızca S2I, BuildConfig gibi OpenShift'e özel özelliklere ihtiyaç duyan ekipler için anlamlı olur.
Geliştiricilerim OpenShift öğrenmek zorunda mı?
Hayır, oc CLI kubectl ile %95 örtüştüğü için ek bir öğrenme zorunluluğu yoktur. Developer Console gibi araçlar öğrenme eğrisini düşürür ve YAML yazma ihtiyacını azaltır.
Helm chart'larım OpenShift'te çalışır mı?
Çoğu Helm chart OpenShift'in varsayılan SCC kısıtlamalarıyla çakışabilir; ancak küçük değer dosyası düzeltmeleriyle uyumlu hale getirilebilir. runAsUser, fsGroup gibi alanları SCC politikalarına uygun ayarlamak genellikle yeterlidir.
Bare-metal mı, sanal makinede mi kurmalıyım?
Üretim performansı için bare-metal idealdir; operasyonel basitlik için sanal makinede kurmak yaygın bir pratiktir. Managed KaaS bu kararı sizin yerinize sağlayıcı verir ve operasyonel yükü tamamen ortadan kaldırır.
Cloud4U Türkiye Kubernetes as a Service ile üretime hızlı çıkın
OpenShift'in kurumsal seviyede tüm avantajlarını isterken karmaşıklığını yönetmek istemiyorsanız ya da vanilla Kubernetes'in esnekliğini sağlayıcı yönetiminde almak istiyorsanız, managed Kubernetes as a Service en pratik seçenektir. Cloud4U Türkiye KaaS, İstanbul veri merkezinde yönetilen Kubernetes cluster'ları sunar.
- OpenShift karmaşıklığı olmadan kurumsal hazır Kubernetes; managed control plane
- KVKK uyumlu altyapı, İstanbul veri merkezi ve BDDK denetimine uygun dokümantasyon
- TRY ile aylık öngörülebilir fiyatlandırma, 7/24 Türkçe destek ve ücretsiz POC
Platform ekibinizi cluster kurmaktan kurtarıp ürün geliştirmeye odaklamak için Cloud4U Türkiye Kubernetes as a Service sayfasını ziyaret edin ve mimari önerisi için bizimle iletişime geçin.
