VMware Sonrası Dönemde Yeni Standart: OpenShift Virtualization (OCPV)

Bulut bilişim (cloud-native) ve konteyner teknolojileri modern uygulamaların standart altyapısı haline geldi. Ancak veri merkezlerimizin gerçek dünyasında durum biraz farklı: Devasa veritabanları, Windows lisans bağımlılıkları ve “dokunulmaması gereken” kritik legacy (geleneksel) sistemler hala sanal makinelerde (VM) yaşıyor.

Yakın zamana kadar bu iki dünyayı ayrı yönettik. Bir tarafta VMware vSphere gibi geleneksel hipervizör ekipleri, diğer tarafta ise OpenShift koşturan modern DevOps ekipleri vardı. Ancak Broadcom-VMware sürecinden sonra değişen agresif lisanslama politikaları, kurumsal şirketleri ciddi bir arayışa itti.

İşte bu kırılma noktasında OpenShift Virtualization (OCPV), basit bir “alternatif” olmaktan çıkıp, veri merkezinin yeni ana işletim sistemi haline geldi. Bu makalede, OCPV’nin ne olduğundan başlayarak, nasıl kullanılacağına ve üretim ortamında (production) nasıl ölçekleneceğine dair elimden geldiğince basitçe anlatacağım.

OpenShift Virtualization (OCPV) Nedir?

OpenShift Virtualization, Red Hat OpenShift üzerinde çalışan ve geleneksel sanal makineleri (VM), konteynerler (Containers) ile yan yana, aynı platformda yönetmenizi sağlayan yerel bir OpenShift özelliğidir.

Buradaki en kritik nokta şudur: OCPV, sanal makineleri dışarıdan “izlemez” veya harici bir katman olarak yönetmez. VM’leri doğrudan Kubernetes podlarının içinde çalıştırır. Geleneksel yapılarda, fiziksel sunucu üzerine bir hipervizör kurulur, bunun üzerinde sanal makineler çalışır ve konteyner dünyası için bu VM’lerin içine bir de Kubernetes kümesi kurulurdu (Nested Virtualization). Bu durum ciddi performans kaybı yaratırdı.

OCPV mimarisinde ise OpenShift doğrudan Bare Metal (Fiziksel) sunucular üzerine kurulur. Sanal makineniz artık Kubernetes için herhangi bir Pod nesnesinden farksızdır. Kubernetes’in sunduğu scheduling, RBAC ve network policy gibi tüm yetenekler, otomatik olarak sanal makineniz için de geçerli hale gelir.

Mimari: KubeVirt

OpenShift Virtualization’ın kalbinde, açık kaynak kodlu bir CNCF projesi olan KubeVirt yer alır. KubeVirt, Kubernetes API’sini Custom Resource Definitions (CRD) kullanarak genişletir ve kümeye VirtualMachine gibi yeni nesneler tanımalatır.

Geleneksel bir Linux sunucusunda sanallaştırma için ne kullanıyorsak (KVM ve QEMU), KubeVirt sayesinde bunu bir pod içinde kullanırız:

• virt-operator: Tüm sanallaştırma altyapısının yaşam döngüsünü (kurulum, güncelleme) yönetir.
• virt-api: VM oluşturma/durdurma gibi API taleplerini karşılar.
• virt-controller: Küme genelindeki VM’lerin durumunu izler ve hangi node üzerinde çalışacağına karar verir.
• virt-handler: Her bir worker node üzerinde çalışan bir DaemonSet'tir. Kubernetes dünyasındaki emirleri yerel KVM/QEMU süreçlerine tercüme eder.
• virt-launcher: Her VM için özel oluşturulan poddur. VM’in çalışacağı QEMU/KVM sürecini başlatır ve izole eder.

OpenShift Virtualization Nasıl Kullanılır?

OpenShift üzerinde hem web konsolunu kullanabilir hem de tamamen GitOps süreçlerine uygun şekilde declarative (bildirimsel) YAML dosyalarıyla çalışabilirsiniz.

Adım 1: Operatörün Kurulması

OpenShift Web Konsoluna giriş yapın. OperatorHub menüsünden OpenShift Virtualization operatörünü aratın ve Install butonuna basın. Kurulum tamamlandıktan sonra HyperConverged nesnesini oluşturarak sanallaştırma kümesini aktif hale getirin.

Adım 2: Bir Sanal Makine Dağıtmak (Örnek YAML)

Aşağıdaki manifesto, kurumsal üretime hazır, çift ağ kartlı ve kalıcı depolama alanına sahip bir Linux VM örneğidir:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: prod-linux-server
  namespace: my-apps
spec:
  running: true # VM'in sürekli açık kalmasını sağlar
  template:
    metadata:
      labels:
        kubevirt.io/domain: prod-linux-server
    spec:
      domain:
        cpu:
          sockets: 2
          cores: 2 # Toplam 4 vCPU
        memory:
          guest: 8Gi
        devices:
          disks:
          - disk:
              bus: virtio
            name: root-disk
          interfaces:
          - masquerade: {} # Standart OpenShift pod ağı
            name: default
          - bridge: {} # Kurumsal VLAN ağı (Multus)
            name: vlan-network
      networks:
      - name: default
        pod: {}
      - multus:
          networkName: br100-vlan-config
        name: vlan-network
      volumes:
      - name: root-disk
        persistentVolumeClaim:
          claimName: rhel9-root-pvc

Bu YAML dosyasını oc apply -f vm.yaml komutuyla uyguladığınızda, OpenShift arka planda bir pod yaratacak ve sanal makineniz saniyeler içinde hazır olacaktır.

Tabii ki Openshift Console ekranından da VM lerinizi daha detaylı konfigüre edebilirsiniz. Örneğin VM ayağa kaldırırken Template veya instance type vs. gibi seçenekleri seçebilirsiniz. Network seçimi, storage entegrasyonu gibi ayarlamaları yaptıktan sonra Openshift Console ekranından VM’lerinizi hızlıca ayağa kaldırabilirsiniz.

Üretim Ortamı (Production) İçin Mimari İnce Ayarlar

VM’leri kurumsal ortamda ölçeklerken standart pod ayarları yetersiz kalır. İşte sistem mimarlarının bilmesi gereken en kritik başlıklar:

Depolama (Storage) ve StorageProfiles

Konteyner dünyasındaki geçici disklerin aksine, VM diskleri kalıcı olmak zorundadır. OCPV, CSI (Container Storage Interface) uyumlu depolama çözümlerini kullanır.

• Volume Mode: VM diskleri için her zaman Block modu tercih edilmelidir. Dosya sistemi (Filesystem) katmanını bypass ederek doğrudan ham diske yazar ve %20'ye varan I/O performansı sağlar.
• Access Mode: Canlı taşıma (Live Migration) yapılabilmesi için kullanılan storage’ın mutlaka ReadWriteMany (RWX) modunu desteklemesi gerekir (Örn: Red Hat OpenShift Data Foundation — ODF).

Ağ Yönetimi (Networking) ve Multus CNI

Standart Kubernetes ağlarında (pod network) podlar dinamik IP alır. Ancak bir kurumsal veritabanı VM’i, şirketin core switch’indeki spesifik bir VLAN’a (VLAN 100) ait sabit bir IP ile konuşmak ister. OCPV bu problemi Multus CNI ile aşar. Multus sayesinde VM, standart pod ağının yanında ikinci bir arayüzle doğrudan fiziksel network bloğuna bağlanabilir.

Dedicated Worker Node Stratejisi

Standart mikroservis podları ile yoğun I/O tüketen sanal makinelerin aynı sunucuda yarışması performans sorunlarına (noisy neighbor) yol açar. Bu yüzden VM’ler için Dedicated (Özel) Worker Node’lar ayrılmalı, bu işlem Kubernetes Taints ve Tolerations ile yapılmalıdır:

oc label node node1.cluster.local infra=virtualization
oc taint node node1.cluster.local kubevirt.io/drainer="":NoSchedule

Ekosistem Entegrasyonu

OCPV’yi ham KubeVirt projesinden ayıran en büyük fark, zengin kurumsal ekosistem entegrasyonudur:

1. GitOps (ArgoCD): VM’lerinizin CPU, RAM ve disk konfigürasyonlarını Git depolarında saklayabilir, tüm altyapıyı kodla yönetebilirsiniz (Infrastructure as Code).
2. Veri Koruma (OADP): Velero tabanlı OpenShift API for Data Protection ile VM’lerinizin anlık görüntülerini (Snapshot) alabilir, S3 uyumlu bir alana güvenle yedekleyebilirsiniz.
3. Migration Toolkit for Virtualization (MTV): Mevcut VMware ESXi veya oVirt ortamınızdaki sanal makineleri, web arayüzü üzerinden birkaç tıklamayla, canlı (Warm Migration) veya kapalı (Cold Migration) olarak kesintisiz bir şekilde OpenShift’e taşıyabilirsiniz.

Sonuç

OpenShift Virtualization, kurumlara “Sanal makinelerinizi çöpe atın” demiyor. Aksine, “Onları modern dünyanın merkezine getirin” diyor.

Aynı ağ politikalarını (Network Policies), aynı izleme araçlarını (Prometheus/Grafana) ve aynı deployment süreçlerini hem modern bir Go mikroservisi hem de 10 yıllık bir Windows IIS sunucusu için ortaklaşa kullanabilmek, operasyonel karmaşayı kökünden çözüyor. Yatırımlarınızı koruyarak geleceğe yürümek için OCPV, günümüzün en olgun bulut-yerel sanallaştırma platformudur.

Siz de veri merkezinizde VMware operasyonlarını OpenShift üzerine taşımayı planlıyor musunuz? Yaşadığınız deneyimleri veya merak ettikleriniz için her zaman iletişime geçebilirsiniz. İstişare etmekten büyük keyif duyarım :)