Az OpenShift virtualizáció (upstream projekt – Kubernetes: KubeVirt, lásd alább) a Container-native Virtualization néven indult, és az OpenShift platform funkciójaként került bemutatásra, amely lehetővé teszi virtuális gépek (VM) telepítését és kezelését a Kubernetes alapvető entitásaként. E feladat technikailag bonyolult, a technológiák alapvető eltérései miatt. A kitűzött cél eléréséhez a Red Hat Enterprise Linux és KVM jól ismert technológiáit használtuk, amelyek már évek óta velünk vannak és bizonyították hatékonyságukat. és Ebben a cikkben az OpenShift virtualizáció technikai aspektusait vizsgáljuk, amelyek lehetővé teszik a VM-ek és konténerek összeegyeztetését egy olyan platform keretein belül, amely egységes egészként kezeli őket.
Számítási feladatok
A konténerek a Linux kernel mechanizmusait, például a namespaces és cgroups mechanizmusokat használják a folyamatok elszigetelésére és az erőforrások kezelésére. Általában a folyamatok alatt Python, Java vagy végrehajtható fájlok alkalmazásait értjük, de valójában bármilyen folyamat lehet, például bash, Emacs vagy vim.
De mit jelent a virtuális gép? A hypervisor szempontjából ez szintén egy folyamat. De ez nem egy alkalmazásfolyamat, hanem egy KVM-folyamat, amely egy adott VM végrehajtásáért felelős.
A konténer képe mindazt az eszközt, könyvtárat és fájlt tartalmaz, amely a KVM virtuális géphez szükséges. Ha megvizsgáljuk egy működő VM podját, akkor ott segédprogramokat és qemu-kvm folyamatokat fogunk látni. Továbbá hozzáférésünk van a virtuális gépek kezelésére szolgáló KVM-eszközökhöz, mint például a qemu-img, qemu-nbd és virsh.
Mivel a virtuális gép egy pod, automatikusan örökli a pod funkcionalitását a Kubernetes rendszerben. A VM-podokat, akárcsak a normál podokat, a tervező ügynök mintáira és kritériumaira alkalmazzák, mint például a taints, tolerations, affinity és anti-affinity. Emellett előnyöket kapunk, mint például a magas rendelkezésre állás stb. Van azonban egy fontos különbség: a normál podok nem vándorolnak az egyik gazdagépről a másikra a megszokott értelemben. Ha a node leáll, akkor az ott működő pod megszakad és átkerül egy másik node-ra a klaszterben. A virtuális gép esetén azonban élő migrációra számítunk.
E probléma megoldására egy custom resource definition (CDR) készült, amely leírja az élő migráció mechanizmusát, amely a virtuális gépek élő migrációjának inicializálásáért, figyeléséért és kezeléséért felel.
A probléma megoldására létrehoztak egy testreszabott erőforrásdefiníciót (CDR), amely leírja a valósidejű migráció mechanizmusát, és amely felelős a VM-ek élő migrálásának inicializálásáért, nyomon követéséért és kezeléséért a munkacsomópontok között.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
A csomópont leállításakor azoknál a virtuális gépeknél, amelyek esetében az evakuálási stratégia a Live Migration-ra van beállítva, automatikusan migrációs feladatok jönnek létre. Így ellenőrizheti a virtuális gépek viselkedését, amikor a klaszter csomópontjai között mozognak. Ön beállíthatja a Live Migration-t, és kezelheti a VMs-t, mint az összes többi podot.
Hálózat
Bármely Kubernetes rendszer biztosítja a kapcsolatot a csomópontok és a pod'ok között szoftveres SDN hálózatokon keresztül. Az OpenShift sem kivétel, és a 3. verziótól kezdve alapértelmezés szerint az OpenShiftSDN-t használja erre. Továbbá az OpenShift 4-ben megjelent egy új funkció, a Multus, amely lehetővé teszi, hogy több hálózatot érjünk el, és egyszerre csatlakoztassuk azokat a podokhoz.
A Multus használatával az adminisztrátor további CNI hálózatokat állíthat be, amelyeket egy külön Cluster Network Operator üzemeltető telepít és konfigurál a klaszteren. Ezt követően a pod'ok csatlakozhatnak ezekhez a hálózatokhoz, jellemzően a standard OpenShiftSDN-hez és egy plusz interfészhez. SR-IOV eszközök, standard Linux Bridge, MACVLAN és IPVLAN eszközök – mindezek is használhatók, ha annak szüksége van az Ön VMs-ére. Az alábbi ábra mutatja, hogyan állíthat egy Multus CNI-t a bridge há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 virtuális gépek esetében ez azt jelenti, hogy a VM közvetlenül csatlakoztatható egy külső hálózathoz, megkerülve az SDN-t. Ez fontos a Red Hat Virtualization-ból vagy VMware vSphere-ból OpenShift-re áthelyezett virtuális gépek számára, mivel a második OSI réteghez való hozzáférés esetén a hálózati beállítások nem változnak. Ez azt is jelenti, hogy a VM-nek lehet egy olyan hálózati címe, amely megkerüli az SDN-t. Így hatékonyan kihasználhatjuk a speciális hálózati adaptereket, vagy közvetlenül csatlakozhatunk a tárolórendszerehez...
További információkat találhat arról, hogyan lehet virtuális gépeket létrehozni és csatlakoztatni az OpenShift virtuális gépekhez a hálózaton. . Ezen kívül, , amely az OpenShift virtualization részeként van telepítve, egy jól ismert módszert kínál a hálózati konfigurációk létrehozására és kezelésére a fizikai csomópontokon, amelyeket hypervisorokként használnak.
Tárolás
A virtuális gépek lemezeinek csatlakoztatása és kezelése az OpenShift virtualizáció keretein belül olyan Kubernetes-koncepciók használatával történik, mint a StorageClasses, PersistentVolumeClaims (PVC) és PersistentVolume (PV), valamint a Kubernetes környezethez standardizált tárolási protokollok. Így a Kubernetes adminisztrátorai és az alkalmazásokért felelős csapatok egyetlen, megszokott kezelési mechanizmust kapnak mind a konténerek, mind a virtuális gépek számára. Sokan a virtualizációs környezetek adminisztrátorai közül ismerősnek találhatják ezt a fogalmat, mivel a fájlok konfigurációs és lemezválasztásának elválasztásának ugyanazt az elvét alkalmazza, amelyet az OpenStack és számos más felhőplatform is használ.
Azonban nem lehet minden alkalommal új lemezt létrehozni a virtuális gépek számára, mivel a hypervisorról az OpenShiftbe történő migrálás során meg kell őriznünk az adatokat. Még akkor is, amikor új virtuális gépet indítunk, sokkal gyorsabb sablonból indítani, mint a semmiből kezdeni. Ezért szükségünk van meglévő lemezek importálására vonatkozó funkcióra.
Ennek a feladatnak az egyszerűsítése érdekében az OpenShift virtualizáció elindítja a Containerized Data Importer (CDI) projektet, amely lehetővé teszi a lemezképek importálását több forrásból a PVC bejegyzés létrehozásához.
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, elindítva az alábbi ábrán látható lépéssorozatot:
Miután a CDI működésbe lépett, a PVC tartalmazni fog egy használatra kész virtuális gép lemezt, amely az OpenShift szabványos formátumára van konvertálva...
Az OpenShift virtualizációval való munka során az OpenShift Container Storage (OCS) is hasznos lehet, a Red Hat megoldása a Ceph fájl rendszerén alapul, amely állandó tárolási funkciót valósít meg a konténerek számára. Az OCS a standard PVC-hozzáférési módszerek – RWO (blokkszintű) és RWX (fájlszintű) – mellett biztosít RWX-ot nyers blokktesztárolókhoz, ami nagyon hasznos nagy teljesítményigényű alkalmazások közötti közös blokkhordozó hozzáférésének megszervezésében. Ezenkívül az OCS támogatja az Object Bucket Claim új objektum csoportkérési szabványt, amely lehetővé teszi, hogy az alkalmazások közvetlenül használhassák az objektumtárolót.
Virtuális gépek konténerekben
Ha érdekli, hogy működik, tudja, hogy az OpenShift virtualizáció már elérhető Tech Preview változatban az OpenShift 3.11 és újabb verzióiban. Az OpenShift aktív előfizetői ingyenesen és további lépések nélkül használhatják az OpenShift virtualizációt. E bejegyzés időpontjában az OpenShift 4.4 és az OpenShift virtualizáció 2.3 a legfrissebb verziók, ha korábbi verziókat használ, érdemes frissítenie az újabb funkciók érdekében. A teljes mértékben támogatott OpenShift virtualizációs verzió 2020 második felében várható.
További információkért forduljon a az telepítési utasításokért, beleértve , amely tartalmazza a külső hálózatok konfigurálására vonatkozó információkat.
Forrás: habr.com
