OpenShift virtualizáció: konténerek, KVM és virtuális gépek

OpenShift virtualizáció (upstream projekt - Kubernetes: KubeVirt, lásd. itt и itt), nee Container-native Virtualization, az OpenShift platform egyik funkciójaként került bevezetésre, amely virtuális gépek (VM-ek) alapvető Kubernetes-entitásként történő üzembe helyezésére és kezelésére szolgál. Ez a fajta feladat az alapvető technológiai különbségek miatt technikailag nagy kihívást jelent. A cél elérése érdekében az ismert Red Hat Enterprise Linux és KVM alapú technológiákat alkalmaztuk, amelyek már évek óta velünk vannak, és bizonyították hatékonyságukat.

OpenShift virtualizáció: konténerek, KVM és virtuális gépek

Ebben a cikkben megvizsgáljuk az OpenShift virtualizáció technikai szempontjait, amelyek lehetővé teszik a virtuális gépek és a konténerek egyetlen platformon belüli együttélését, amely egyetlen entitásként kezeli őket.

Számítási feladatok

A tárolók Linux kernelmechanizmusokat, például névtereket és cgroupokat használnak a folyamatok elkülönítésére és az erőforrások kezelésére. A folyamatok általában Python-, Java-alkalmazások vagy végrehajtható fájlok, de valójában bármilyen folyamat lehet, például bash, Emacs vagy vim.

Mi az a virtuális gép? A hipervizor szempontjából ez is egy folyamat. De nem az alkalmazási folyamat, hanem az adott virtuális gép végrehajtásáért felelős KVM-folyamat.

OpenShift virtualizáció: konténerek, KVM és virtuális gépek

A tárolókép tartalmazza a KVM virtuális géphez szükséges összes eszközt, könyvtárat és fájlt. Ha megvizsgáljuk egy futó virtuális gép podját, ott segítőket és qemu-kvm folyamatokat fogunk látni. Ezenkívül hozzáférésünk van a virtuális gépek, például a qemu-img, qemu-nbd és virsh kezeléséhez szükséges KVM-eszközökhöz.

OpenShift virtualizáció: konténerek, KVM és virtuális gépek

Mivel a virtuális gép egy pod, automatikusan örökli a Kubernetesben található pod összes funkcióját. A virtuális gépekre, csakúgy, mint a hagyományos podokra, az ütemezési sémák és kritériumok vonatkoznak, például a szennyeződések, a tűréshatárok, az affinitás és az antiaffinitás. Ön is élvezheti a magas rendelkezésre állás előnyeit stb. Van azonban egy fontos különbség: a normál hüvelyek nem vándorolnak gazdáról gazdára a szokásos értelemben. Ha egy csomópont offline állapotba kerül, a rajta lévő pod-ot leállítja, és újra hozzárendeli a fürt másik csomópontjához. Egy virtuális gép esetében pedig élő migrációra számítunk.

Ennek a hiányosságnak a kiküszöbölése érdekében egyéni erőforrás-definíciót (CDR) hoztak létre, amely leírja az élő áttelepítési mechanizmust, amely felelős a virtuális gépek dolgozói csomópontok közötti élő migrációjának inicializálásáért, figyeléséért és kezeléséért.

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
  name: migration-job
spec:
  vmiName: fedora

Ha egy csomópont deaktiválva van, a rendszer automatikusan létrehozza az áttelepítési feladatokat azokhoz a virtuális gépekhez, amelyeknél a Live Migration van beállítva kilakoltatási stratégiáként. Így szabályozhatja a virtuális gépek viselkedését a fürtcsomópontok közötti mozgás során. Az összes többi podhoz hasonlóan konfigurálhatja a Live Migration szolgáltatást és kezelheti a virtuális gépet.

Hálózat

Bármely Kubernetes rendszer kommunikációt biztosít a csomópontok és a podok között szoftveres SDN-hálózatok segítségével. Az OpenShift sem kivétel, és a 3-as verziótól kezdve alapértelmezés szerint az OpenShiftSDN-t használja ehhez. Ezenkívül az OpenShift 4 egy másik új funkcióval is rendelkezik, a Multus néven, amely lehetővé teszi több hálózat elérhetővé tételét és egyidejű csatlakoztatását azokhoz.

OpenShift virtualizáció: konténerek, KVM és virtuális gépek

A Multus használatával az adminisztrátor további CNI-hálózatokat határozhat meg, amelyeket ezután egy speciális fürthálózat-üzemeltető telepít és konfigurál a fürtön. A pod-ok ezután egy vagy több ilyen hálózathoz csatlakoznak, általában a szabványos OpenShiftSDN-hez és egy további interfészhez. Az SR-IOV eszközök, a szabványos Linux Bridge, a MACVLAN és az IPVLAN eszközök mind használhatók, ha a virtuális gépnek szüksége van rá. Az alábbi ábra bemutatja, hogyan kell beállítani a Multus CNI-t a hídhálózathoz az eth1 interfészen:

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  additionalNetworks:
  - name: multus1
rawCNIConfig: '{ "cniVersion": "0.3.1", "type": "bridge", "master": "eth1", "ipam":
   { "type": "static", "addresses": [ { "address": "191.168.1.1/24" } ] } }'
   type: Raw

Az OpenShift virtualizációval kapcsolatban ez azt jelenti, hogy a virtuális gép közvetlenül csatlakozhat egy külső hálózathoz, az SDN megkerülésével. Ez fontos a Red Hat Virtualization vagy a VMware vSphere alkalmazásból OpenShiftre áttelepített virtuális gépeknél, mivel ha hozzáfér a második OSI-réteghez, a hálózati beállítások nem változnak. Ez azt is jelenti, hogy a virtuális gépnek lehet olyan hálózati címe, amely megkerüli az SDN-t. Így hatékonyan használhatunk speciális hálózati adaptereket, vagy közvetlenül a hálózaton keresztül csatlakozhatunk a tárolórendszerhez...

További információ az OpenShift virtualizációs virtuális gépek létrehozásáról és a hálózathoz való csatlakoztatásáról itt. Ezen túlmenően, nmstate operátorAz OpenShift virtualizáció részeként üzembe helyezett másik ismerős módot kínál a hálózati konfigurációk létrehozására és kezelésére a hypervisorok alatt használt fizikai csomópontokon.

tárolás

A virtuálisgép-lemezek csatlakoztatása és kezelése az OpenShift virtualizáción belül a Kubernetes-koncepciók, például a StorageClasses, a PersistentVolumeClaims (PVC) és a PersistentVolume (PV), valamint a Kubernetes környezet szabványos tárolási protokolljai segítségével történik. Ezáltal a Kubernetes-rendszergazdák és az alkalmazáscsapatok közös, ismerős módot biztosítanak a tárolók és a virtuális gépek kezelésére. És sok virtualizációs környezet rendszergazdája számára ez a koncepció ismerősnek tűnhet, mert ugyanazt az elvet használja a virtuálisgép-konfigurációs fájlok és lemezek szétválasztására, mint az OpenStackben és sok más felhőplatformon.

Nem tudunk azonban egyszerűen minden alkalommal új lemezt létrehozni a virtuális gép számára, mivel a hypervisorról az OpenShiftre való áttéréskor mentenünk kell az adatokat. Igen, még akkor is, ha új virtuális gépet telepítünk, mindig gyorsabb sablonból csinálni, mint a semmiből létrehozni. Ezért szükségünk van a meglévő lemezek importálására szolgáló funkciókra.

A feladat egyszerűsítése érdekében az OpenShift virtualizáció a Containerized Data Importer (CDI) projektet telepíti, amely csökkenti a lemezek lemezképeinek importálását több forrásból egy PVC bejegyzés létrehozására.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: "fedora-disk0"
  labels:
    app: containerized-data-importer
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "http://10.0.0.1/images/Fedora-Cloud-Base-31-1.9.x86_64.qcow2"
spec:
  storageClassName: ocs-gold
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

Ez a bejegyzés aktiválja a CDI-t, és az alábbi ábrán látható műveletsort indítja el:

OpenShift virtualizáció: konténerek, KVM és virtuális gépek

A CDI befejezése után a PVC tartalmazza a virtuális gép lemezét használatra készen és a szabványos OpenShift formátumra konvertálva...
Az OpenShift virtualizációval való munka során az OpenShift Container Storage (OCS), a Ceph fájlrendszeren alapuló Red Hat megoldás is hasznos, amely tartós tárolási funkciókat valósít meg a konténerekhez. A szabványos PVC hozzáférési módszerek - RWO (blokk) és RWX (fájl) mellett - az OCS RWX-et biztosít a nyers blokk eszközök számára, ami nagyon hasznos a nagy teljesítményigényű alkalmazások blokk-hozzáférésének megosztásához. Ezenkívül az OCS támogatja az új Object Bucket Claim szabványt, amely lehetővé teszi az alkalmazások számára, hogy közvetlenül használják az objektumadatok tárolását.

Virtuális gépek konténerekben

Ha szeretné ellenőrizni, hogyan működik, akkor tudja, hogy az OpenShift virtualizáció már elérhető a Tech Preview verzióban az OpenShift 3.11 és újabb részeként. A meglévő OpenShift-előfizetés tulajdonosai teljesen ingyenesen és további lépések nélkül használhatják az OpenShift virtualizációt. A bejegyzés közzétételének időpontjában az OpenShift 4.4 és az OpenShift virtualizáció 2.3 aktuális; ha korábbi verziókat használ, akkor frissítenie kell a legújabb funkciók eléréséhez. Az OpenShift virtualizáció teljes mértékben támogatott verziója 2020 második felében jelenik meg.

További információkért kérjük, tekintse meg a OpenShift dokumentáció a telepítési utasításokért, beleértve Multus beállítási rész, amely információkat nyújt a külső hálózatok beállításáról.

Forrás: will.com

Hozzászólás