Merhabalar,
OpenShift Virtualization Mimari Önerileri Serimize devam ediyoruz.
İlk yazıda, https://asiyeyigit.com/openshift-virtualization-platform-mimari-onerileri-serisi-1/ sanallaştırma dünyasında yaşanan dönüşümün aslında yalnızca teknolojik bir değişim olmadığını, bunun çok daha derin bir güven ve operasyonel alışkanlık meselesi olduğunu ele aldık. Yıllardır olgunlaşmış, stabilitesi kanıtlanmış ve ekiplerin reflekslerinin oturduğu geleneksel sanallaştırma platformlarından çıkışın yarattığı soru işaretlerini açıkça belirttik. Kurumların temel ihtiyacının sadece “VM çalıştırabilen” yeni bir platform olmadığını, aynı zamanda operasyonel güveni koruyan, ekiplerin alışkanlıklarını tamamen yıkmadan onları ileri taşıyan ve geleceğin mimarilerine kapı açan bir yaklaşım olduğunu vurguladık. Bu noktada OpenShift Virtualization’ın, sanal makineler ile konteyner dünyasını aynı platformda birleştirerek hem bugünü koruyan hem de geleceğe hazırlayan dengeli bir çözüm sunduğunu detaylandırdık.
Bu çerçevede, OpenShift Virtualization’ın aslında yeni ve deneysel bir yapı olmadığını gördük. KVM, QEMU ve libvirt gibi yıllardır kurumsal ortamlarda kendini kanıtlamış teknolojilerin üzerine inşa edildiğini konuştuk. Platformun sunduklarıyla operasyonel süreçleri sadeleştiren, merkezi yönetim sağlayan ve ölçeklenebilirliği doğal olarak destekleyen bir mimari sunduğunu gösterdik. Node rolleri, yüksek erişilebilirlik, failure domain yapıları, control plane tasarımı ve kaynak planlaması gibi kritik mimari kararların, platformun başarısında belirleyici olduğunu özellikle vurguladık. Özetle ilk yazı, “OpenShift Virtualization Platform nasıl kurulur” sorusundan ziyade, “nasıl doğru tasarlanır ve sürdürülebilir hale getirilir” sorusuna güçlü bir temel oluşturdu.
İkinci yazıda ise, https://asiyeyigit.com/openshift-virtualization-platform-mimari-onerileri-serisi-2/ bu mimari bakışı daha derinleştirerek, OpenShift Virtualization’ın bare metal ortamlardaki bağımlılıklarını ve altyapı gereksinimlerini detaylı şekilde ele aldık. Bulut ortamlarında çoğu zaman görünmeyen DNS, DHCP, NTP ve load balancer gibi servislerin, aslında platformun sağlıklı çalışması için ne kadar kritik olduğunu belirttik. Bu bileşenlerin yalnızca “olması yeterli” yapılar olmadığını, doğru tasarlanmadıklarında tüm platformun erişilemez hale gelebileceğini vurguladık. Bunun yanında donanım standardizasyonu, kapasite planlaması, NIC bonding, trafik ayrıştırma ve NMState ile merkezi ağ yönetimi gibi konuların, performans ve dayanıklılık açısından ne kadar belirleyici olduğunu detaylandırdık.
Depolama tarafında ise geleneksel “tek datastore” yaklaşımından farklı olarak, her sanal makine diskinin bir PVC olarak yönetildiği Kubernetes-native modelin getirdiği esnekliği ve kontrol seviyesini ele aldık. CSI mimarisinin yalnızca bir entegrasyon katmanı değil, aynı zamanda storage operasyonlarını standartlaştıran ve üretici bağımsızlığı sağlayan kritik bir yapı olduğunu gösterdik. Snapshot, clone, QoS, multipath ve RWX gibi yeteneklerin, doğru storage ve CSI kombinasyonu ile nasıl güçlü avantajlara dönüştüğünü; ancak bu yeteneklerin her ortamda aynı şekilde gelmediğini ve mutlaka doğrulanması gerektiğini vurguladık. Sonuç olarak ikinci yazıda, OpenShift Virtualization’ın yalnızca bir platform değil, altyapıdan operasyona kadar tüm katmanları dönüştüren bütüncül bir mimari yaklaşım olduğunu net bir şekilde belirttik.
Bu yazıda platformun en kritik katmanlarından biri olan ağ mimarisine daha derinlemesine bakacağız. Çünkü sanallaştırma dünyasında ağ, yalnızca veri taşıyan bir yapı değildir; aynı zamanda performansın, güvenliğin ve operasyonel sürdürülebilirliğin belirleyicisidir.
Ağ mimarisini doğru anlayabilmek için, konuyu yalnızca “bağlantı” olarak değil, aynı zamanda OSI katmanları (Open Systems Interconnection Model) perspektifinden değerlendirmek gerekir. Çünkü OpenShift Virtualization’da kullandığımız her bileşen aslında belirli bir katmanda çalışır ve yapılan her mimari tercih, bu katmanların bir veya birkaçını doğrudan etkiler.
Örneğin; fiziksel ağ kartları (NIC) Layer 1 (Physical Layer – Fiziksel Katman) ve Layer 2 (Data Link Layer – Veri Bağlantı Katmanı) seviyesinde çalışırken, VLAN etiketleme Layer 2 (Data Link Layer) seviyesinde gerçekleşir. IP tabanlı iletişim, yani pod-to-pod veya node-to-node trafik ise Layer 3 (Network Layer – Ağ Katmanı) seviyesinde yürütülür. Service, Route ve LoadBalancer gibi bileşenler ise çoğunlukla Layer 4 (Transport Layer – Taşıma Katmanı) ve Layer 7 (Application Layer – Uygulama Katmanı) seviyelerinde devreye girer. Bu katmanları doğru anlamak, neden bazı tasarımların önerildiğini, bazılarının ise riskli olduğunu net şekilde açıklar.
Sanal makineler doğası gereği izole yapılar değildir. Sürekli olarak diğer sistemlerle, uygulamalarla ve kullanıcılarla iletişim halindedirler. Bu nedenle bir sanallaştırma platformunun sunduğu ağ esnekliği, platformun gerçek değerini belirler. OpenShift Virtualization bu noktada oldukça güçlü bir model sunar. Sanal makineler, cluster’ın yazılım tanımlı ağı (SDN – OVN-Kubernetes) üzerinden haberleşebilir, service mesh ile gelişmiş trafik yönetimi senaryolarına dahil olabilir, Linux bridge veya Open vSwitch (OVS) üzerinden doğrudan dış ağlara bağlanabilir ya da SR-IOV (Single Root I/O Virtualization) ve DPDK (Data Plane Development Kit) ile donanıma yakın performans elde edebilir. Bu seçeneklerin hiçbirinin zorunlu olmaması, mimaride ciddi bir esneklik sağlar. Ancak bu esneklik, doğru tasarım yapılmadığında ciddi riskler de doğurur. OpenShift kurulduğunda, node’lar genellikle bir veya birden fazla fiziksel NIC’in bond edilmesiyle oluşturulan bir yapı üzerinden çalışır. Bu bond yapısı (örneğin bond0), hem Layer 1 (Physical Layer) seviyesinde fiziksel bağlantıyı hem de Layer 2 (Data Link Layer) seviyesinde link aggregation (örneğin LACP) mekanizmasını içerir. Bu yapı üzerine kurulan OVS, cluster’ın SDN trafiğini taşır ve Layer 2 (Data Link Layer) seviyesinde switching yaparken, OVN-Kubernetes ile birlikte Layer 3 (Network Layer) seviyesinde routing ve overlay network fonksiyonlarını da yerine getirir. Bu noktada kritik soru şudur: Sanal makine trafiği bu SDN altyapısı ile paylaşılmalı mı?
Teknik olarak mümkündür, ancak önerilmez. Çünkü SDN; node-to-node iletişim (Layer 3 – Network Layer), pod-to-pod trafik (Layer 3 – Network Layer), control plane erişimi ve servis yönlendirmeleri gibi kritik bileşenleri taşır. Bu altyapının üzerine VM trafiği bind edildiğinde, Layer 2 seviyesinde (Data Link Layer) oluşabilecek bir konfigürasyon hatası bile tüm cluster’ın iletişimini etkileyebilir. Bu yüzden en sağlıklı yaklaşım, VM trafiği için mümkün olduğunca ayrı fiziksel NIC’ler veya en azından ayrı bond yapıları kullanmaktır.
İlk diyagramda, her VLAN için host seviyesinde ayrı interface oluşturulduğunu görürüz. Örneğin bond0.123, bond0.456 gibi VLAN interface’leri tanımlanır ve her biri üzerine ayrı bir bridge (br123, br456) kurulur. Bu yapı tamamen Layer 2 (Data Link Layer) seviyesinde çalışır. VLAN interface’leri, fiziksel trunk bağlantının alt segmentlerini temsil ederken, bridge’ler de birer switch gibi davranır. Ancak bu modelin en büyük problemi, her VLAN için ayrı interface ve ayrı bridge gerektirmesidir. Bu durum, NMState konfigürasyonlarını karmaşık hale getirir, operasyonel yükü artırır ve özellikle büyük ortamlarda insan hatasına açık bir yapı oluşturur.
İkinci diyagram ise modern ve önerilen yaklaşımı gösterir. Bu modelde tek bir OVS kullanılır ve VLAN tagging işlemi doğrudan bu sanal switch içinde gerçekleştirilir. Yani VM’ler aynı bridge’e bağlanır ancak her VM’in trafiği OVS tarafından uygun VLAN etiketi ile işaretlenir. Bu işlem yine Layer 2 (Data Link Layer) seviyesinde gerçekleşir, ancak kritik fark şudur: VLAN yönetimi artık host interface’lerinde değil, merkezi olarak sanal switch üzerinde yapılır. Bu sayede her VLAN için ayrı interface tanımlamaya gerek kalmaz ve konfigürasyon ciddi şekilde sadeleşir.
Bu iki yaklaşım arasındaki farkı en net şekilde şöyle ifade edebiliriz: İlk modelde VLAN yönetimi host seviyesinde (interface bazlı), ikinci modelde ise switch seviyesinde (OVS içinde) yapılır. Modern ve ölçeklenebilir mimarilerde tercih edilen yaklaşım açık şekilde ikinci modeldir.
Dış ağ bağlantılarında kullanılan Linux bridge ve Open vSwitch (OVS) de yine Layer 2 (Data Link Layer) seviyesinde çalışan bileşenlerdir. Linux bridge daha basit ve düşük overhead sunarken, OVS daha gelişmiş özellikler sağlar. Özellikle network policy gibi mekanizmalar sayesinde trafik kontrolü yapılabilir. Bu nedenle kurumsal ortamlarda OVS genellikle daha doğru bir tercih olur.
Ağ güvenliği tarafında ise network policy mekanizmaları devreye girer. SDN’e bağlı VM’ler için kullanılan NetworkPolicy, Layer 3 (Network Layer) ve Layer 4 (Transport Layer) seviyesinde trafik kontrolü sağlar. VLAN gibi harici ağlara bağlı VM’ler için kullanılan MultiNetworkPolicy ise benzer şekilde trafiği kontrol eder. Bu yaklaşım, mikro-segmentation olarak bilinen, workload bazlı ağ izolasyonunu mümkün kılar.
Multus’un önemini de vurgulamalıyız. Multus, çok katmanlı ağ yapısını mümkün kılan önemli bir bileşendir. Multus sayesinde bir VM aynı anda birden fazla ağa bağlanabilir. Bu, klasik sanallaştırma dünyasındaki çoklu NIC kullanımına benzer ve özellikle kompleks mimarilerde büyük avantaj sağlar.
Bu noktada, OpenShift Virtualization ağ mimarisinde en sık karıştırılan ama mimari olarak oldukça kritik bir ayrımı netleştirmek gerekir: Open vSwitch (OVS) ne sağlar, Multus neyi mümkün kılar? Çünkü bu iki bileşen çoğu zaman aynı problem alanını çözüyor gibi algılansa da, aslında tamamen farklı katmanlarda ve farklı sorumluluklarla çalışırlar.
Öncelikle en net haliyle ifade etmek gerekirse; Multus olmadan bir sanal makinenin birden fazla farklı ağa bağlanması mümkün değildir. OVS tek başına bu yeteneği sağlamaz. Bunun temel nedeni, OVS’in bir ağ altyapısı bileşeni olması, Multus’un ise bu altyapıyı Kubernetes ve dolayısıyla sanal makinelerle ilişkilendiren bir orkestrasyon katmanı olmasıdır. Başka bir deyişle, OVS Layer 2 (Data Link Layer – Veri Bağlantı Katmanı) seviyesinde çalışan bir sanal switch’tir; VLAN tagging, switching ve trafik yönlendirme gibi işlemleri gerçekleştirir. Ancak bir sanal makineye birden fazla ağ arayüzü (NIC) kazandırmak OVS’in sorumluluğunda değildir.
Multus ise OSI modelinin doğrudan bir katmanına karşılık gelmeyen, Kubernetes’in ağ modelini genişleten bir bileşendir. Varsayılan olarak Kubernetes (ve dolayısıyla OpenShift), her iş yüküne yalnızca tek bir ağ bağlantısı (default network – genellikle SDN/OVN-Kubernetes) sağlar. Multus bu sınırlamayı ortadan kaldırır ve bir sanal makinenin birden fazla ağa bağlanabilmesini mümkün kılar. Bu sayede bir VM aynı anda hem cluster içi SDN ağına hem de harici VLAN ağlarına ya da özel amaçlı farklı network segmentlerine bağlanabilir.
Bu ayrımı daha somut bir örnekle düşünmek faydalı olacaktır. Multus kullanılmayan bir senaryoda bir sanal makine yalnızca tek bir ağa bağlanır; bu genellikle cluster’ın varsayılan SDN ağıdır ve VM’in tüm trafiği bu ağ üzerinden akar. Ancak Multus devreye girdiğinde aynı sanal makineye birden fazla sanal NIC tanımlanabilir. Örneğin bir VM’in ilk arayüzü (eth0) yönetim trafiği için SDN’e bağlıyken, ikinci arayüzü (eth1) OVS üzerinden VLAN 123’e, üçüncü arayüzü (eth2) ise farklı bir VLAN veya yüksek performanslı bir SR-IOV ağına bağlanabilir. Bu yapı, klasik sanallaştırma dünyasındaki çoklu NIC kullanımının Kubernetes-native karşılığıdır.
Bu noktada OVS ve Multus’un birlikte nasıl çalıştığını doğru konumlandırmak önemlidir. NMState, host seviyesinde fiziksel NIC’leri, bond yapılarını ve OVS bridge’lerini konfigüre eder; yani Layer 1 (Physical Layer – Fiziksel Katman) ve Layer 2 (Data Link Layer – Veri Bağlantı Katmanı) seviyesinde altyapıyı hazırlar. OVS, bu altyapı üzerinde Layer 2 seviyesinde switching ve VLAN tagging işlemlerini gerçekleştirir. Multus ise bu hazır ağ yapılarını Kubernetes nesneleri üzerinden sanal makinelere “attach” eder. Yani Multus, OVS’in sunduğu ağı doğrudan VM’e bağlayan köprü görevi görür.
Özetle, OVS ve benzeri teknolojiler ağın nasıl çalışacağını belirlerken, Multus bu ağın kime ve nasıl sunulacağını belirler. Bu nedenle OVS olmadan dış ağ bağlantısı kurmak zor olabilir, ancak Multus olmadan çoklu ağ mimarisi kurmak mümkün değildir. Modern OpenShift Virtualization tasarımlarında bu iki bileşen birlikte düşünülmeli; OVS, esnek ve güçlü bir Layer 2 switching altyapısı sağlarken, Multus bu altyapıyı çoklu ağ senaryoları için kullanılabilir hale getiren kritik bir orkestrasyon katmanı olarak konumlandırılmalıdır.
Bu ayrımı doğru anlamak, özellikle birden fazla network segmentine ihtiyaç duyan kurumsal iş yüklerinde (örneğin yönetim, uygulama ve yedekleme ağlarının ayrılması gibi) mimari kararların sağlıklı alınabilmesi açısından belirleyici olacaktır.
Son olarak, OpenShift Virtualization ağ mimarisinde geleceği temsil eden bir yaklaşım olarak User-Defined Networks (UDN) kavramına da değinmek gerekir. OpenShift 4.18 ile birlikte gelen bu özellik, hem kullanıcıların hem de yöneticilerin ihtiyaç duydukları ağ segmentlerini talep üzerine oluşturabilmelerini mümkün kılar. UDN sayesinde yalnızca cluster içi izole ağlar değil, aynı zamanda dış dünyaya açık (public) veya tamamen izole (private) network yapıları da dinamik olarak tanımlanabilir. Bu yaklaşım, özellikle self-service modelini destekleyen ve farklı ekiplerin kendi network ihtiyaçlarını bağımsız şekilde yönetmek istediği ortamlarda önemli bir esneklik sunar.
Ancak mevcut durumda UDN’in sanal makinelerle entegrasyonu henüz tam olgunlaşmış değildir. Bu nedenle pratikte, özellikle üretim ortamlarında sanal makinelerin dış ağlara bağlanması için hâlâ Open vSwitch (OVS) tabanlı mimariler önerilmektedir. OVS, Layer 2 (Data Link Layer – Veri Bağlantı Katmanı) seviyesinde sağladığı stabilite, VLAN desteği ve network policy ile entegrasyon yetenekleri sayesinde bugün için en güvenilir ve yaygın kullanılan yöntemdir. UDN ise bu modelin yerini alabilecek potansiyele sahip olsa da, mevcut durumda daha çok gelişim aşamasında olan bir teknoloji olarak konumlanmaktadır.
Bununla birlikte, UDN’in getirdiği yaklaşım oldukça değerlidir. Ağ segmentlerinin merkezi ekipler tarafından statik olarak tanımlandığı klasik modelden, kullanıcıların ihtiyaç duydukları network’leri dinamik olarak oluşturabildiği daha esnek ve self-service bir modele geçişin sinyallerini vermektedir. Bu, OpenShift’in sürekli evrilen bir mimari yaklaşım sunduğunu göstermektedir. UDN’in sanal makinelerle entegrasyonu olgunlaştıkça, gelecekte ağ mimarilerinin çok daha sade, esnek ve kullanıcı odaklı hale gelmesi beklenmektedir.
Özetle, OpenShift Virtualization ağ mimarisinde başarı; yalnızca bağlantı kurmakla değil, bu bağlantıyı doğru OSI katmanında, doğru bileşenle ve doğru soyutlama seviyesinde tasarlamakla ilgilidir. Özellikle VLAN yönetiminde host tabanlı yaklaşım yerine OVS tabanlı merkezi tagging modeline geçmek, hem operasyonel sadelik hem de ölçeklenebilirlik açısından kritik bir fark yaratır. Bu fark, küçük ortamlarda hissedilmese bile, büyük ve kurumsal ortamlarda mimarinin sürdürülebilirliğini belirleyen en önemli tasarım kararlarından biri haline gelir.
Sarav Asiye Yiğit * 17 Mart 2026
Kaynakça:
https://access.redhat.com/sites/default/files/attachments/openshift_virtualization_architecture_guide_v1.0.0.pdf