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
