Merhabalar,
Yıllardır vazgeçilmezimiz VMware, son dönemdeki lisans maliyetleri, abonelik modeli, vendor lock-in ve satın alma sonrası belirsizlikler yüzünden, birçok kurum için soru işaretleri oluşturmaya başladı. Genel endişelerimiz: Bu kadar alıştığımız olgun bir yapıdan sonra bizi nasıl bir çözüm mutlu edebilir ki? Acaba bu olgunlukta ve güvenilirlikte sektörde hangi çözümler var? İş yüklerim çok kritik, bu derece önemli iş yüklerimi hangi çözüme emanet edebilirim ki gibi gibi… Diğer bir yandan da sanal ortamları yönetenler, GUI üzerinden ihtiyacı olan her şeyi yapmaya alışmış durumda. Bu kullanım kolaylığında ve hem de olgunluğunda nasıl bir yapı olabilir ki geceleri kabusa çeviren fikirler akılda dönüp durmasın.
lbette bu soruları sormak çok normal. Bu sorular bugün sektördeki neredeyse tüm altyapı ve platform ekiplerinin ortak kaygıları. Çünkü burada konuştuğumuz şey basit bir teknoloji değişimi değil ki! Yıllardır güvenilen, üzerinde yüzlerce kritik iş yükü çalışan, operasyonel reflekslerin oturduğu bir dünyanın sorgulanması. Dolayısıyla mesele “yeni ne var?”dan çok, “mevcut güveni kaybetmeden nasıl ilerleriz?” sorusunu net bir şekilde cevaplayabilmektir.
Aslında ihtiyaç, sadece VM çalıştırabilmekten ziyade, operasyonel güveni gerçekten hissedebilmektir. Sahadaki gerçek sorular, geçeceğim platform stabil çalışır mı? Bir sorun çıktığında hızlı müdahele edebilir miyim? Alıştığım yönetim kolaylığını kaybedecek miyim? Ekiplerim bu yapıyı gerçekten benimseyebilir mi? Yani konu teknolojinin müthişliğinden ziyade, Operasyonel olgunluk ve güven meselesi.
Diğer yönden, teknolojinin değişimi geleceğe de hazır yapıları benimseyebilmemizi zorunlu kılıyor. Aksi halde rakiplerimizden geri kalacağımız da çok açık. Mevcut sanal makineleri çalıştırmaya devam ederken, aynı zamanda geleceğin mimarisine hazırlanmayı mümkün kılan hibrit yaklaşımları hayatımızın içine alma gerekliliği de göz önüne almamız gereken bir gerçek.
Peki bu sorulara bugün sektörde en dengeli cevabı veren yaklaşım hangisi? Dengeden kastım, bir tarafta yıllardır güvenilen sanal makine dünyasını korurken, diğer tarafta kaçınılmaz olarak hayatımıza giren konteyner ve Kubernetes ekosistemini yok saymayan bir yaklaşım sunabilmek. Yani birini tercih ederken diğerinden vazgeçmeyi zorunlu kılmayan, aksine her iki dünyayı da aynı çatı altında bir araya getirebilen bir mimari. OpenShift Virtualization’ın farkı, mevcut VM’leri olduğu gibi çalıştırırken, aynı platform üzerinde konteyner tabanlı modern uygulamalara da alan açıyor. Yani bugünle yarın arasında bir köprü kurabiliyor. Yıllardır sanal ortamları GUI üzerinden yöneten ekipler için, “Acaba komut satırına mı mahkûm olacağız?” sorusu ciddi bir kaygı. Oysa OpenShift Virtualization, bu alışkanlığı yok saymak yerine, güçlü ve merkezi bir web arayüzü ile sanal makinelerin oluşturulmasından, izlenmesine ve yönetilmesine kadar tüm süreci görsel olarak sunuyor. Özetle, aranan sadece VMware’in “bir başka sanallaştırma ürünü” ile değiştirilmesi olmamalı. Aranan şey, bugünkü operasyonel güveni korurken, yarının mimarisine kapı açan, ekipleri yormayan ve yatırımın karşılığını kısa vadede veren bir platform olmalı.
Ben bu yazıda sanallaştırma ortamları için OpenShift Virtualization’ı seçen kurumların mimarilerini kurgularken nelere dikkat etmeleri gerektiğini detaylandıracağım.
OpenShift Virtualization, OpenShift platformunun bir parçası olarak sunulan ve sanal makineleri Kubernetes dünyasının doğal bir bileşeni haline getiren bir yapıdır. Temelinde, Linux ekosisteminin yıllardır güvenle kullanılan hipervizörü olan Kernel-based Virtual Machine (KVM) yer alır. Yani burada deneysel ya da yeni bir sanallaştırma teknolojisinden değil, kendini yıllardır kanıtlamış bir altyapıdan bahsediyoruz. KVM, performansı, ölçeklenebilirliği ve kararlılığı ile bilinen, kurumsal ortamlarda uzun süredir kullanılan bir hypervisor’dür. Hatta KVM, Red Hat Enterprise Linux çekirdeğinin ayrılmaz bir parçası olarak 15 yılı aşkın süredir üretim ortamlarında çalışıyor. Bugüne kadar Red Hat Virtualization, Red Hat OpenStack Platform ve doğrudan RHEL üzerinde çalışan sayısız kritik iş yükünün temelini oluşturdu. OpenShift Virtualization da tam olarak bu olgun ve güvenilir KVM altyapısını kullanır. Bunun yanında QEMU ve libvirt gibi sanallaştırma dünyasında kendini kanıtlamış bileşenlerle birlikte çalışarak, yöneticilerin beklediği yüksek performans ve stabiliteyi sağlar. Yani “yeni bir platforma geçiyorum ama altyapı ne kadar güvenilir?” sorusunun cevabı aslında oldukça nettir: Alt tarafta zaten yıllardır güvendiğiniz teknoloji çalışmaktadır. Bu sayede OpenShift, sadece bir Kubernetes platformu olmanın ötesine geçerek, pratikte kurumsal seviyede, güçlü, stabil ve ölçeklenebilir bir Type-1 hypervisor gibi davranır. Özellikle sanallaştırma yöneticileri için tasarlanmış modern yönetim araçları ve web arayüzü ile, alışılmış operasyonel beklentileri karşılayan, hatta birçok noktada onları ileriye taşıyan bir sanallaştırma platformu sunar.
Şekil 1: OpenShift Virtualization Mimarisi
Şekil 1, OpenShift Virtualization’ın sanal makineleri ve konteyner tabanlı iş yüklerini tek ve bütünleşik bir platform altında nasıl bir araya getirdiğini net bir şekilde gösteriyor. En üstte yer alan external network katmanı, sanal makinelerin ve uygulamaların kurumsal ağlar ve dış dünya ile güvenli biçimde haberleşmesini sağlarken, sol taraftaki control plane OpenShift kümesinin beyni olarak tüm VM ve konteyner yaşam döngüsünü merkezi şekilde yönetiyor. Orta bölümde yer alan compute node’lar üzerinde sanal makineler, Linux dünyasında kendini yıllardır kanıtlamış KVM hypervisor’ü üzerinde doğrudan ve yüksek performansla çalışıyor; ağ tarafında ise Open vSwitch, Linux bridge gibi farklı seçeneklerle esnek topolojiler destekleniyor. Sağ tarafta konumlanan infra workload’lar sayesinde monitoring, logging, metrics, ingress ve registry gibi kurumsal ihtiyaçlar platformun doğal bir parçası olarak sunuluyor ve sanal makineler de bu servislerden konteynerlerle aynı şekilde faydalanabiliyor. Alt katmanda CSI üzerinden sağlanan kalıcı depolama ile VM diskleri ve uygulama verileri tutarlı ve merkezi biçimde yönetilirken, software-defined network yaklaşımı tüm ağ trafiğinin yazılım tabanlı ve kontrollü bir şekilde yönetilmesini mümkün kılıyor. Sonuç olarak bu mimari, sanal makineleri ayrı bir dünya olarak konumlandırmak yerine, OpenShift’in güvenli, ölçeklenebilir ve operasyonel olarak olgun platform yapısının doğal bir bileşeni haline getiriyor.
Bu bölümde OpenShift Virtualization’ın bir sanallaştırma çözümü olarak doğru planlanması gerektiğinin üzerinde durduk. Kurumsal ölçekte güvenilir, ölçeklenebilir ve sürdürülebilir bir platform sağlamak için gereklilikleri doğru belirleyerek uygulamamız gerekiyor. Sanal makinelerin doğası gereği daha fazla kaynak, süreklilik ve öngörülebilirlik beklentisi olduğu düşünüldüğünde, node rolleri, ağ topolojisi, depolama mimarisi, yüksek erişilebilirlik ve operasyonel süreçlerin en baştan ele alınması kritik önem taşıyor. İlerleyen serilerimizde dikkat etmemiz gereken diğer konulara da değineceğim.
Şekil 2: OpenShift Virtualization Üzerinde Sanal Makineler
OpenShift Virtualization üzerinde çalışan sanal makineler, gelişmiş zamanlama ve yönetim yeteneklerinden doğal olarak faydalanır. Hangi sanal makinenin hangi sunucuda çalışacağı, kaynakların ne kadar dolu olduğu, yükün dengeli dağıtılması ve olası bir arıza durumunda sanal makinelerin otomatik olarak ayağa kaldırılması gibi konular platform tarafından merkezi olarak yönetilir. Bu sayede yönetim süreçleri sadeleşir, kaynaklar daha verimli kullanılır ve sanal makineler büyük ölçekli ortamlarda bile kararlı ve güvenilir şekilde çalışır. Ağ tarafında ise sanal makineler, OpenShift’in entegre yazılım tanımlı ağ (SDN) yapısına bağlanarak, ağ politikaları üzerinden güvenli ve kontrollü bir şekilde erişilebilir hale gelir. Bu yaklaşım, sanal makineler için hem giriş hem de çıkış trafiğinin kurumsal güvenlik gereksinimlerine uygun şekilde yönetilmesini sağlar. Bunun yanında, daha geleneksel ağ ihtiyaçları için Open vSwitch (OVS) üzerinden VLAN bağlantıları, SR-IOV gibi yüksek performanslı ağ seçenekleri ve gelişmekte olan OpenShift User-Defined Networking (UDN) desteği de sunulmaktadır. OpenShift Virtualization, farklı kurulum senaryolarını destekleyecek şekilde esnek bir yapı sunar. İster kurum içinde bare metal sunucular üzerinde kendi kendine yönetilen bir ortam kurulsun, ister bulut tarafında Amazon Web Services üzerinde self-managed OpenShift cluster’ları ya da Red Hat OpenShift Service on AWS (ROSA) kullanılsın, aynı sanallaştırma deneyimi korunur. Bu esneklik, kurumların mevcut altyapı stratejilerine ve operasyonel ihtiyaçlarına uygun bir sanallaştırma platformunu rahatlıkla benimseyebilmelerini sağlar. Şekil 2, OpenShift Virtualization’ın sanal makineleri hangi teknik katmanlar üzerinde çalıştırdığını ve bu katmanların birbiriyle nasıl ilişkilendiğini net bir şekilde gösteriyor. En altta fiziksel donanım yer alıyor. CPU, bellek, disk, ağ ve GPU gibi tüm kaynaklar burada bulunuyor. Bu donanımın üzerinde, sürücüler aracılığıyla donanımı yöneten Red Hat Enterprise Linux CoreOS çalışıyor. CoreOS, OpenShift node’ları için özel olarak tasarlanmış, hafif ve güvenli bir işletim sistemi olarak hem konteynerler hem de sanal makineler için sağlam bir temel oluşturuyor. Sanallaştırmanın kalbinde ise KVM yer alıyor. KVM, Linux çekirdeğinin bir parçası olarak donanımı doğrudan kullanabilen, Type-1 hypervisor mantığıyla çalışan olgun bir sanallaştırma teknolojisi sunuyor. KVM’nin üzerinde QEMU, sanal makinelerin çalışmasını sağlayan sanallaştırma katmanı olarak görev yaparken, libvirt ise bu sanal makinelerin yönetilmesini, başlatılmasını, durdurulmasını ve izlenmesini mümkün kılan kontrol katmanını oluşturuyor. En üstte ise sanal makineler yer alıyor ve bu VM’ler, fiziksel donanıma mümkün olan en yakın performansla çalışıyor. Aynı CoreOS katmanı üzerinde, sanal makinelerden bağımsız olarak “Other Applications” olarak gösterilen konteyner tabanlı uygulamalar da çalışabiliyor. Bu da OpenShift Virtualization’ın en önemli farkını ortaya koyuyor: Sanal makineler ve modern uygulamalar, aynı işletim sistemi ve aynı donanım üzerinde, birbirinden kopuk yapılar olmadan, yan yana ve uyum içinde çalışabiliyor.
Red Hat OpenShift, bünyesinde yer alan OpenShift Virtualization ile birlikte, hem konteyner tabanlı modern uygulamaları hem de geleneksel sanal makineleri tek ve ortak bir platform üzerinde çalıştırma imkânı sunar. OpenShift Virtualization’ın çalışabilmesi için bare metal OpenShift mimarisi kullanılır ve bu Mimari, ister kurum içinde kendi veri merkezinde, ister bulut tarafında farklı kurulum modelleriyle hayata geçirilebilir. OpenShift, Amazon Web Services, IBM Cloud ve Oracle Cloud Infrastructure gibi platformlar üzerinde, hem tamamen yönetilen hem de kurumun kendi yönettiği kurulum seçeneklerini destekler. Bu esneklik sayesinde kurumlar, veri merkezi ile bulut ortamları arasında aynı uygulama ve sanallaştırma platformunu standartlaştırabilirken, alt tarafta yine yıllardır güvenilen KVM tabanlı sanallaştırma teknolojisini kullanmaya devam eder.
Bu yazıda kurum içinde, kendi kendine yönetilen (self-managed), on-premises OpenShift Virtualization kurulumlarına odaklanacağım. Bu tür ortamlar, altyapı üzerinde tam kontrol sağladığı için regülasyon, veri yerelliği ya da yüksek performans gibi gereksinimleri olan kurumlar için ideal bir seçenektir. OpenShift Virtualization’ın on-premises kullanımı, mevcut ağ, depolama ve operasyonel süreçlerle sıkı entegrasyonu korurken, sanallaştırma altyapısının modernleştirilmesini mümkün kılar.
OpenShift Virtualization Neden Özel Bir Mimari Gerektirir?
OpenShift Virtualization, standart bir OpenShift kurulumundan daha fazla mimari planlama gerektirir. Bunun temel nedeni, sanal makinelerin konteynerlerden farklı olarak stateful olmasıdır. Yani durum bilgisini sürekli korurlar, daha fazla CPU, bellek ve disk kaynağı tüketirler ve platformdan yüksek performans ile süreklilik beklerler. Bu yüzden OpenShift Virtualization kullanılan bir cluster, hesaplama, ağ ve depolama katmanlarında dayanıklı, güvenilir ve performanslı olacak şekilde tasarlanmalıdır.
Operasyonel Araçlar ve Otomasyonun Önemi
Sadece sanal makineleri çalıştırmak yeterli değildir. Yöneticilerin, VM’leri kurabilecekleri, performans sorunlarını tespit edip çözebilecekleri, güvenliği sağlayabilecekleri, altyapıyı izleyebilecekleri ve mümkün olan her noktada otomasyon kullanabilecekleri araçlara ihtiyacı vardır. OpenShift’in Operator tabanlı yapısı, bu ihtiyaçları merkezi ve tutarlı bir şekilde karşılamayı mümkün kılar ve sanal makinelerin de platformun doğal bir parçası gibi yönetilmesini sağlar.
Node Rolleri Neden Bu Kadar Kritik?
OpenShift’te her node’un bir rolü vardır ve bu roller, üzerinde hangi iş yüklerinin çalışacağını belirler. Bare metal ortamlarda donanım doğrudan kullanıldığı için, bu rol planlaması ölçeklenebilirlik, performans ve dayanıklılık açısından çok önemlidir. Control Plane node’ları, cluster’ın beynidir ve API, scheduler ve etcd gibi hayati bileşenleri çalıştırır. Infrastructure node’ları, logging, monitoring, ingress gibi platform servislerini barındırır. Compute (worker) node’ları, sanal makinelerin ve uygulamaların çalıştığı asıl iş yükü katmanıdır.
Rolleri Ayırmak mı, Birleştirmek mi?
OpenShift, bir node’a birden fazla rol atamaya izin verir. Bu, donanımı daha verimli kullanmayı sağlar. Ancak kontrol plane ile başka iş yükleri aynı node’da çalıştığında kaynak çakışması riski oluşur. Bu risk, kritik bileşenlere yüksek öncelik verilerek ve iyi izleme sistemleri kullanılarak azaltılabilir. Genel olarak rollerin ayrılması daha güvenlidir. Fakat bare metal sunucular güçlü olduğu için bazen bu ayrım, kaynak israfına yol açabilir. Bu noktada dengeyi doğru kurmak gerekir.
Topoloji Farkındalığı ve Failure Domain Kavramı
OpenShift Virtualization’da yüksek erişilebilirlik sağlamak için fiziksel altyapıya uygun failure domain’ler tanımlanmalıdır. Bu, rack, oda, şasi veya lokasyon bazlı olabilir. Node’lara verilen etiketler sayesinde OpenShift, sanal makineleri aynı fiziksel risk altında olmayan node’lara dağıtabilir. Böylece tek bir rack, switch veya güç kaynağı arızası tüm sistemi etkilemez.
Control Plane Yüksek Erişilebilirliği Neden Hayati?
Control plane çalışmıyorsa, VM oluşturamaz, yönetemez ve cluster’ı kontrol edemezsiniz. Bu nedenle üretim ortamlarında en az üç control plane node’u önerilir. Bare metal ortamlarda donanım arızalarının onarımı uzun sürebileceği için, bazı senaryolarda 5 node’lu control plane daha güvenli olabilir. Bu yapı, bakım ve arıza durumlarında cluster’ın çalışmaya devam etmesini kolaylaştırır. Ancak daha fazla kaynak tüketir.
Hosted Control Plane (HCP) Ne Zaman Mantıklı?
Hosted Control Plane mimarisinde control plane, ayrı bir yönetim cluster’ında çalışır. Sanal makinelerin bulunduğu cluster ise sadece compute node’lardan oluşur. Bu yaklaşım özellikle çok sayıda cluster yöneten kurumlar için operasyonel kolaylık ve kaynak verimliliği sağlar. Ancak bu seride ağırlıklı olarak, control plane’in aynı cluster içinde olduğu klasik mimariyi ele alacağım. Çünkü bu yapı, izole ya da edge ortamlarda daha pratiktir.
Compute Kaynaklarını Mantıksal Olarak Ayırmak
OpenShift’te tüm node’lar tek bir cluster içinde yer alır. Ancak etiketler (labels) ve kısıtlamalar (taints) kullanılarak mantıksal gruplar oluşturulabilir. Örneğin: GPU’lu node’lar, belirli CPU mimarisine sahip sunucular, sadece belirli ekiplerin kullanacağı kaynaklar. Bu yapı sayesinde sanal makineler, ihtiyaçlarına uygun node’lara yönlendirilir ve kaynak yönetimi esnek hale gelir.
Cluster Capabilities (Modüler Kurulum)
OpenShift, bazı platform yeteneklerinin kurulum sırasında açılıp kapatılmasına izin verir. Ancak OpenShift Virtualization için baremetal, MachineAPI, console, CSI snapshot ve node tuning gibi yeteneklerin açık olması önerilir. Gereksiz bir kısıtlama, ileride beklenmeyen sorunlara yol açabilir.
Software-Defined Network (SDN) ve IP Planlaması
Her OpenShift cluster’ı bir SDN kullanmak zorundadır. Bu ağ, canlı VM taşıma, sağlık kontrolleri ve iç iletişim için kritik öneme sahiptir. Kurulum sırasında yapılan IP planlaması (CIDR ve host prefix), node sayısını ve node başına düşen Pod/VM sayısını doğrudan etkiler ve sonradan değiştirilemez. Bu yüzden baştan doğru planlama yapılmazsa cluster’ı yeniden kurmak gerekebilir.
İnternetsiz (Disconnected) ve Yarı Bağlantılı Ortamlar
Bazı kurumlar güvenlik nedeniyle internete kapalı çalışır. Bu durumda OpenShift içerikleri lokal bir registry üzerinden sağlanır. Yarı bağlantılı ortamlarda ise yalnızca gerekli imajlar lokal tutulur, geri kalan için sınırlı internet erişimi kullanılır. Bu yaklaşım hem güvenliği korur hem de operasyonel verimlilik sağlar.
Stretched Cluster: Güçlü ama Riskli
Stretched cluster, control plane node’larının birden fazla lokasyona dağıtıldığı bir mimaridir. Teorik olarak yüksek erişilebilirlik sağlar; ancak latency, network kararlılığı ve storage tutarlılığı konularında çok hassastır. İki lokasyonlu yapılarda quorum problemi nedeniyle bir site fiilen tek hata noktası haline gelir. Bu yüzden çoğu senaryoda, her lokasyonda ayrı cluster kurup storage replikasyonu yapmak daha sağlıklı bir yaklaşımdır.
OpenShift Virtualization Mimarisi, doğru planlandığında son derece güçlü, esnek ve kurumsal ihtiyaçlara uygun bir yapı sunar. Ancak bu gücün karşılığında, node rolleri, ağ, depolama, yüksek erişilebilirlik ve operasyonel süreçler mutlaka baştan düşünülmelidir. İyi bir mimari tasarım, platformun uzun yıllar güvenle işletilmesinin anahtarıdır.
Sarav Asiye Yiğit * 31 Ocak 2026
Kaynakça:
https://access.redhat.com/sites/default/files/attachments/openshift_virtualization_architecture_guide_v1.0.0.pdf