Kubernetes ile OpenShift Arasındaki Fark: Motor mu, Hazır Platform mu?

Ortak zemin: ikisi de Kubernetes konuşur

Kubernetes, konteynerleştirilmiş iş yüklerini ve servisleri yönetmek için geliştirilmiş, taşınabilir ve genişletilebilir açık kaynak bir platformdur. Pod, Deployment, Service, ConfigMap, Secret ve kalıcı birim (PersistentVolume) gibi nesnelerle uygulamanın istenen durumunu tanımlarsınız; kontrol düzlemi bu durumu sürekli gerçeğe yaklaştırır.

OpenShift (Red Hat OpenShift Container Platform) bu motorun yerine geçen ayrı bir teknoloji değildir; Kubernetes üzerine kurulmuş, kurumsal kullanım için paketlenmiş bir dağıtımdır. Kubernetes nesnelerinin tamamı OpenShift'te de çalışır, kubectl komutları geçerlidir. Bu yüzden soru aslında şudur: Kubernetes'i çevresindeki bileşenleri kendiniz seçerek mi kuracaksınız, yoksa bu seçimleri sizin yerinize önceden yapmış bir platformu mu kullanacaksınız?

Temel fark: çekirdek motor ve görüş sahibi platform

Kubernetes'in resmî dokümantasyonu kendini geleneksel, her şeyi içeren bir PaaS (Platform as a Service) olarak tanımlamaz. Kaynak koddan imaj üretmez, uygulamanızı derlemez; CI/CD akışını, izleme yığınını, imaj kayıt deposunu ve kimlik doğrulama yöntemini kuruma bırakır. Bu esneklik, aynı zamanda ekibe çok sayıda karar ve bakım yükü getirir.

OpenShift ise bu boşlukları önceden doldurur. Red Hat dokümantasyonuna göre platform; web konsolu, kimlik doğrulama, entegre imaj kayıt deposu, izleme, düğüm yapılandırması ve yükseltme, ağ ve Operatör yönetimini kutudan çıktığı gibi sunar. Düğümler, küme API'si üzerinden güncellenen değişmez bir işletim sistemiyle (Red Hat Enterprise Linux CoreOS) çalışır. Kısacası Kubernetes bir motordur, OpenShift ise o motorun etrafına kaporta, gösterge paneli ve bakım planı eklenmiş bir araçtır.

Ölçüt ölçüt karşılaştırma

• Kurulum: Kubernetes / kubeadm gibi araçlarla ya da bir bulut sağlayıcının yönetilen hizmetiyle kurulur, eklentiler tek tek seçilir. OpenShift / yükleyici, kümeyi işletim sistemi ve platform bileşenleriyle birlikte kurar; bazı ortamlarda kurulum tamamen otomatiktir.
• Dışarıya açma: Kubernetes / Ingress ya da Gateway API ile, seçtiğiniz bir denetleyici üzerinden. OpenShift / Route nesnesi ve hazır yönlendirici; Ingress de desteklenir.
• Güvenlik varsayılanları: Kubernetes / Pod güvenlik standartları ve RBAC kurumun yapılandırmasına bağlıdır. OpenShift / güvenlik bağlamı kısıtlamaları (Security Context Constraints) varsayılan olarak sıkıdır; konteynerlerin kök kullanıcıyla çalışmasına kolayca izin verilmez.
• Geliştirici deneyimi: Kubernetes / kubectl ve ayrıca kurulan araçlar. OpenShift / web konsolunda geliştirici görünümü, oc komut satırı aracı, kaynak koddan imaj üreten build süreçleri.
• Uzantılar: Kubernetes / Helm, Operatörler ve topluluk projeleri elle seçilir. OpenShift / Operator Lifecycle Manager ve OperatorHub ile katalogdan kurulum.
• Yükseltme: Kubernetes / bileşen uyumluluğunu ekip yönetir. OpenShift / küme sürümü ve işletim sistemi birlikte, platform Operatörleri üzerinden yükseltilir.
• Destek ve lisans: Kubernetes / açık kaynak, ticari destek ayrıca alınır. OpenShift / Red Hat aboneliğiyle kurumsal destek; topluluk sürümü OKD ise aboneliksiz kullanılabilir.

Hangi durumda Kubernetes daha uygun?

Kubernetes'i doğrudan kullanmak, platform ekibinin güçlü olduğu ve bileşen seçiminde tam kontrol istenen yerlerde mantıklıdır. Bulutta yönetilen bir Kubernetes hizmeti kullanıyorsanız kontrol düzleminin bakımı zaten sağlayıcıdadır; üstüne yalnız ihtiyaç duyduğunuz araçları eklersiniz.

• Ekibinizde ağ, depolama, gözlemlenebilirlik ve güvenlik bileşenlerini seçip sürdürebilecek deneyim varsa.
• Belirli bir bulut sağlayıcının yerel servisleriyle sıkı entegrasyon önemliyse.
• Uç ortamlar ya da küçük kümeler gibi hafif bir kurulum gerekiyorsa.
• Abonelik yerine iç yetkinliğe yatırım yapılması tercih ediliyorsa.

Örneğin bir yazılım girişimi yönetilen bir Kubernetes hizmetiyle başlayıp Helm şablonları ve GitOps aracıyla dağıtım akışını kendisi kurabilir. Burada risk, zamanla birikmiş eklentilerin sürüm uyumunu takip edecek kimsenin kalmamasıdır.

Hangi durumda OpenShift daha uygun?

OpenShift, çok sayıda uygulama ekibinin aynı platformu paylaştığı, denetim ve uyum gerekliliklerinin ağır olduğu kurumlarda öne çıkar. Bankacılık, kamu ve telekom gibi sektörlerde veri merkezinde çalışan, tek bir tedarikçiden destek alınan ve güvenlik varsayılanları baştan sıkı bir platform tercih edilebilir.

• Platform ekibi küçük, uygulama ekibi sayısı fazlaysa.
• Kendi veri merkezinde (on-premise) ya da hibrit bulutta aynı deneyim isteniyorsa.
• Geliştiricilerin web konsolu ve hazır build akışlarıyla hızla uygulama yayınlaması bekleniyorsa.
• Kurumsal destek sözleşmesi bir satın alma şartıysa.

Örneğin bir bankanın altyapı ekibi, her uygulama ekibine kotası ve yetkileri tanımlı bir proje açar; ekipler kendi uygulamalarını konsoldan yayınlar, kök yetkisi isteyen bir imaj ise güvenlik kısıtları nedeniyle çalışmaz ve gözden geçirmeye düşer.

Aynı uygulamayı iki platformda yayınlamak: adım adım

Örneğin bir ekip, bir web servisini önce Kubernetes'te, sonra OpenShift'te yayınlıyor olsun. İki akış arasındaki fark, hangi adımın kime ait olduğunu net gösterir.

• Kubernetes: ekip imajı kendi CI aracında üretir ve seçtiği kayıt deposuna gönderir; Deployment ve Service manifestlerini yazar; dışarıya açmak için kümede kurulu Ingress denetleyicisine uygun bir Ingress tanımlar; TLS sertifikası için ayrı bir sertifika yöneticisi kurar; izleme için Prometheus benzeri bir yığını kendisi bağlar.
• OpenShift: ekip önce bir proje açar ve kotalarını görür; imajı entegre kayıt deposuna gönderebilir ya da kaynak koddan build ile ürettirir; aynı Deployment ve Service nesnelerini kullanır; dışarıya açmak için bir Route oluşturur; izleme verisini platformun hazır izleme bileşeninden okur.

İki akışta da uygulamanın kendisi aynıdır. Değişen, ekibin kurması ve bakımını yapması gereken çevre bileşenlerin sayısıdır. Seçim yaparken bu listeyi kendi ortamınız için yazmak, toplam işletim yükünü görmenin pratik bir yoludur.

Sık yapılan hatalar ve geçiş notları

OpenShift'e geçen ekiplerin ilk karşılaştığı sorun, kök kullanıcı varsayan konteyner imajlarıdır. İmajı rastgele bir kullanıcı kimliğiyle çalışacak, dosya izinlerini gruba verecek biçimde hazırlamak bu sorunu baştan önler. İkinci sık hata, Route ile Ingress'i aynı uygulamada karışık kullanıp hangi kuralın geçerli olduğunu takip edememektir.

Kubernetes tarafında ise en yaygın hata, kurulumdan sonra işletimi planlamamaktır: sertifika yenileme, etcd yedeği, sürüm yükseltme sırası ve eklenti uyumu yazılı bir işletim planına bağlanmazsa küme kısa sürede dokunulmaz hâle gelir. Hangi platformu seçerseniz seçin, manifestleri Kubernetes standart nesneleriyle yazmak ve platforma özgü nesneleri ayrı tutmak, ileride geçişi kolaylaştırır.

Mindset programlarında iki tarafı çalışmak

Kubernetes ile Orkestrasyon eğitimi; Kubernetes mimarisi ve temel kavramlar, iş yükü kaynakları, servis ve ağ yönetimi, konfigürasyon ve gizli yönetimi, depolama ve kalıcılık, ölçekleme ve kaynak yönetimi ile güvenilirlik ve sorun giderme modüllerinden oluşur. Bu içerik, hangi dağıtımı kullanırsanız kullanın geçerli olan çekirdeği verir.

OpenShift ile Kurumsal Kubernetes Platformu eğitimi ise OpenShift mimarisi ve küme bileşenleri, kimlik ve yetkilendirme, proje yönetimi ve kaynak kontrolü, güvenlik bağlamları ve politika, uygulama yayınlama ve build süreçleri, Operatörler, izleme ve kapasite yönetimi ile yükseltme, yedekleme ve işletim planı modüllerine odaklanır. Kubernetes temelini edindikten sonra OpenShift'e geçmek, platformun neyi farklı yaptığını görmeyi kolaylaştırır.