Virtualizimi OpenShift (projekti upstream - Kubernetes: KubeVirt, sh. dhe ), i njohur më parë si Virtualizimi Container-native, u prezantua si një funksionalitet i platformës OpenShift, që është i destinuar për zhvendosjen dhe menaxhimin e makinave virtuale (VM), si entitete bazike të Kubernetes. Kjo lloj detyre është teknikisht e komplikuar, për shkak të dallimeve themelore në teknologji. Për të arritur qëllimin e vendosur, u përdorën teknologji të njohura nga Red Hat Enterprise Linux dhe KVM, të cilat e kanë dëshmuar efektivitetin e tyre për shumë vite.
Në këtë artikull do të shqyrtojmë aspektet teknike të virtualizimit OpenShift, që e bëjnë të mundur bashkëjetesën e VM-ve dhe kontejnerëve brenda një platforme, e cila i menaxhon ata si një tërësi.
Detyrat llogaritëse
Kontejnerët angazhojnë mekanizmat e bërthamës Linux, si namespaces dhe cgroups, për të isoluar proceset dhe menaxhuar burimet. Zakonisht, proceset përfshijnë aplikacione Python, Java ose skedarë ekzekutivë, por në fakt, ato mund të jenë çfarëdo procesesh, si bash, Emacs ose vim.
ĂfarĂ« Ă«shtĂ« njĂ« makinĂ« virtuale? Nga pikĂ«pamja e hipervizorit, ajo Ă«shtĂ« gjithashtu njĂ« proces. Por jo njĂ« proces aplikacioni, por njĂ« proces KVM qĂ« Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r ekzekutimin e njĂ« VM specifike.
Imazhi i kontejnerit përmban të gjitha mjetet, bibliotekat dhe skedaret e nevojshme për makinën virtuale KVM. Nëse inspektojmë pod-in e VM-së në punë, do të shohim ndihmësit dhe proceset qemu-kvm. Për më tepër, kemi qasje në mjetet KVM për menaxhimin e makinave virtuale, si qemu-img, qemu-nbd dhe virsh.
Meqenëse makina virtuale është një pod, ajo automatikisht trashëgon të gjitha funksionalitetet e pod-it në Kubernetes. Si për VM-pod-et ashtu edhe për pod-et normale, zbatohen skemat dhe kritere të planifikuesit si taints, tolerations, afiniteti dhe anti-afiniteti. Po ashtu, përfitoni avantazhe të tilla si disponueshmëria e lartë etj. Megjithatë, ka një dallim të rëndësishëm: pod-et normale nuk migrojnë nga hosti në host në kuptimin e zakonshëm. Nëse nyja ndalon, pod-i mbi të ndërpritet dhe ri-emërohet në një nyje tjetër në klaster. Ndërsa për makinën virtuale, ne presim të shohim migron aktive.
Për të zgjidhur këtë problem u krijua një definition burimesh të personalizuara (CDR), e cila përshkruan mekanizmin e migrimit në kohë reale, që është përgjegjës për inicializimin, monitorimin dhe menaxhimin e migrimeve të VM-ve midis nyjeve të punës.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Kur një nyje deaktivizohet, automatikisht krijohen detyra migrimi për ato VM, për të cilat strategjia e largimit është caktuar si Migrimi në Kohë Reale. Kështu, mund të kontrolloni sjelljen e VM-ve gjatë lëvizjes midis nyjeve të klasterit. Ju mund të konfiguroni Migrimin në Kohë Reale, si dhe të menaxhoni VM-të, ashtu si të gjitha pod-et e tjera.
RRjeti
Ădo sistem Kubernetes siguron lidhje midis nyjeve dhe pod-ve pĂ«rmes rrjeteve SDN software. OpenShift nuk Ă«shtĂ« pĂ«rjashtim dhe qĂ« nga versioni 3, pĂ«r kĂ«tĂ« pĂ«rdor nĂ« parazgjedhje OpenShiftSDN. PĂ«r mĂ« tepĂ«r, nĂ« OpenShift 4 Ă«shtĂ« prezantuar njĂ« funksion i ri i quajtur Multus, i cili lejon qasjen nĂ« disa rrjete dhe lidhjen e tyre me pod-et njĂ«kohĂ«sisht.
Me ndihmĂ«n e Multus, admini mund tĂ« vendosĂ« rrjeta tĂ« tjera CNI, tĂ« cilat mĂ« pas do tĂ« implementohen dhe konfigurohen nĂ« klaster nga njĂ« operator i veçantĂ«, Cluster Network Operator. Pas kĂ«saj, pod'Ă«t lidhen me njĂ«rĂ«n ose mĂ« shumĂ« nga kĂ«to rrjeta, zakonisht me OpenShiftSDN standard dhe njĂ« ndĂ«rfaqe shtesĂ«. Pajisjet SR-IOV, Linux Bridge standarde, pajisjet MACVLAN dhe IPVLAN â tĂ« gjitha kĂ«to gjithashtu mund tĂ« pĂ«rdoren, nĂ«se Ă«shtĂ« e nevojshme pĂ«r VM-nĂ« tuaj. NĂ« figurĂ«n mĂ« poshtĂ« tregohet se si tĂ« vendosni Multus CNI pĂ«r rrjetin bridge nĂ« ndĂ«rfaqen eth1:
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
PĂ«r OpenShift virtualization, kjo do tĂ« thotĂ« se VM-tĂ« mund tĂ« lidhen drejtpĂ«rdrejt me rrjetin e jashtĂ«m, duke anashkaluar SDN. Kjo Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r VM-tĂ« e migrueshme nĂ« OpenShift nga Red Hat Virtualization ose VMware vSphere, pasi me qasje nĂ« nivelin e dytĂ« OSI nuk do tĂ« ketĂ« ndryshime nĂ« konfigurimet e rrjetit. Kjo gjithashtu nĂ«nkupton se VM-tĂ« mund tĂ« kenĂ« njĂ« adresĂ« rrjeti, tĂ« cilat tejkalojnĂ« SDN. NĂ« kĂ«tĂ« mĂ«nyrĂ«, ne mund tĂ« pĂ«rdorim nĂ« mĂ«nyrĂ« efektive adaptatorĂ«t e specializuar tĂ« rrjetit, ose tĂ« lidhemi drejtpĂ«rdrejt me SCKâŠ
Për më shumë informacione mbi mënyrën e krijimit dhe lidhjes së VM-ve të OpenShift virtualization me rrjetin mund të lexoni . Për më tepër, , i implementuar si pjesë e OpenShift virtualization, ofron një mënyrë tjetër që ju është njohur mirë për të krijuar dhe menaxhuar konfigurimet e rrjetit në nodet fizike që përdoren nga hipervizorët.
Ruajtja
Lidhja dhe menaxhimi i disqeve të makinave virtuale në kuadër të virtualizimit OpenShift realizohet duke përdorur koncepte të tilla Kubernetes si StorageClasses, PersistentVolumeClaims (PVC) dhe PersistentVolume (PV), si dhe protokollet e ruajtjes standarde për mjedisin Kubernetes. Kështu, administratorët e Kubernetes dhe ekipet që janë përgjegjëse për aplikacionet marrin një mekanizëm të njëjtë dhe të njohur menaxhimi për konteinerët dhe makinat virtuale. Për shumë administratorë të mjediseve të virtualizimit, kjo koncept do t'u duket familjare, pasi përdor të njëjtin princip të ndarjes së skedarëve të konfigurimit të VM dhe disqeve, që zbatohet në OpenStack dhe në shumë platforma të tjera cloud.
Megjithatë, nuk mund ta krijojmë thjesht një disk të ri për VM për çdo herë, pasi gjatë migrimit nga hipervizori në OpenShift, na nevojitet të ruajmë të dhënat. Madje, edhe kur përfundojmë një VM të re, është gjithmonë më e shpejtë ta bëjmë nga një model sesa ta krijojmë nga fillimi. Prandaj, na nevojitet funksionaliteti i importit të disqeve ekzistuese.
Për të lehtësuar këtë proces, OpenShift virtualization vendos projektin Containerized Data Importer (CDI), i cili redukton importimin e imazheve të disqeve nga disa burime në krijimin e një regjistri në PVC.
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
Kjo regjistër është ajo që aktivizon CDI, duke nisur një sekuencë veprimesh, siç ilustrohet në figurën më poshtë:
Pasi CDI tĂ« pĂ«rfundojĂ«, PVC do tĂ« pĂ«rmbajĂ« njĂ« disk virtual tĂ« makinĂ«s i gatshĂ«m pĂ«r t'u pĂ«rdorur dhe i pĂ«rshtatur nĂ« formatin standard pĂ«r OpenShiftâŠ
Kur punoni me OpenShift virtualization, OpenShift Container Storage (OCS) do t'ju ndihmojë gjithashtu, një zgjidhje nga Red Hat e bazuar në sistemin e skedarëve Ceph, e cila ofron funksionalitetin e ruajtjes së përhershme për kontejnerët. Përveç metodave standarde të aksesit me PVC - RWO (bllok) dhe RWX (skedar) - OCS ofron RWX për pajisjet e bllokut të papërpunuar, e cila është shumë e dobishme për organizimin e qasjes së përbashkët në bllok për aplikacione me kërkesa të larta për performancë. Për më tepër, OCS mbështet standardin e ri të kërkesës për grupin e objekteve Object Bucket Claim, që lejon aplikacionet të përdorin drejtpërdrejt ruajtjen e objekteve të dhënash.
Makinat virtuale në kontejnerë
Nëse jeni të interesuar të provoni se si funksionon, merrni parasysh se OpenShift virtualization është tashmë e disponueshme në variantin Tech Preview si pjesë e OpenShift 3.11 dhe më lart. Pronarët e një abonimi aktiv në OpenShift mund ta përdorin OpenShift virtualization plotësisht falas dhe pa ndonjë procedurë shtesë. Në momentin e daljes së këtij postimi, versionet aktuale janë OpenShift 4.4 dhe OpenShift virtualization 2.3; nëse po përdorni versionet e mëparshme, ia vlen të përditësoni për të marrë funksionalitetet më të fundit. Një version i plotë i mbështetur i OpenShift virtualization pritet të dërgohet në gjysmën e dytë të vitit 2020.
Për informacion të mëtejshëm, kontaktoni për udhëzimet e instalimit që përfshijnë , ku jepen detaje mbi konfigurimin e rrjeteve të jashtme.
Burimi: habr.com
