OpenShift virtualization (projekti apstrim - Kubernetes: KubeVirt, sh. dhe ), dikur Container-native Virtualization, u prezantua si funsionalitet i platformës OpenShift, që është e destinuar për implementimin dhe menaxhimin e makinave virtuale (VM), si entitete bazë të Kubernetes. Ky lloj detyre është teknikisht i komplikuar, për shkak të dallimeve themelore të teknologjive. Për të arritur objektivin e propozuar, u përdorën teknologjitë e njohura bazuar në Red Hat Enterprise Linux dhe KVM, të cilat janë me ne për shumë vite dhe kanë provuar efikasitetin e tyre.
Në këtë artikull do të shqyrtojmë aspektet teknike të OpenShift virtualization, të cilat e bëjnë të mundur bashkëjetesën e VM-ve dhe kontejnerëve në kuadër të një platforme që i menaxhon ata si një tërësi.
Detyrat llogaritëse
Kontejnerët angazhojnë mekanizmat e kernelit të Linux, të tillë si namespaces dhe cgroups, për izolimin e proceseve dhe menaxhimin e burimeve. Zakonisht, proceset kuptohen si aplikacione Python, Java ose skedarë ekzekutivë, por në të vërtetë mund të jenë çdo proces, si bash, Emacs ose vim.
Por çfarĂ« Ă«shtĂ« njĂ« makinĂ« virtuale? Nga kĂ«ndvĂ«shtrimi i hipervizorit â Ă«shtĂ« gjithashtu njĂ« proces. Por jo njĂ« proces aplikacioni, pĂ«rkundrazi, 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 skedarët e nevojshëm për makinën virtuale KVM. Nëse inspektojmë pod-in e VM-së në funksionim, do të shohim aty ndihmës dhe procese qemu-kvm. Për më tepër, kemi akses në mjetet KVM për menaxhimin e makinave virtuale, si qemu-img, qemu-nbd dhe virsh.
Duke qenë se makina virtuale është një pod, ajo automatikisht trashëgon të gjithë funksionalitetin e pod-it në Kubernetes. Për VM-pod-et aplikohen po ashtu skemat dhe kriteret e planifikuesit si taints, tolerations, affinity dhe anti-affinity. Gjithashtu, përfitoni përparësi si disponueshmërinë e lartë etj. Sidoqoftë, ka një ndryshim të rëndësishëm: pod-et e zakonshme nuk migrojnë nga host në host në kuptimin e zakonshëm. Nëse një nyje ndërpritet, atëherë pod-i mbi të ndërpritet dhe riemërohet në një nyje tjetër në klaster. Ndërsa në rastin e makinës virtuale presim të shohim migrimin e gjallë.
Për të adresuar këtë boshllëk, u krijua një custom resource definition (CDR), që përshkruan mekanizmin e migrimit të gjallë, i cili është përgjegjës për fillimin, monitorimin dhe menaxhimin e migrimeve të gjalla të VM-ve midis nyjeve punuese.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Kur deaktivimi i një node, për ato makina virtuale të saj, për të cilat strategjia e eviction është caktuar si Migrimi i Gjallë, krijohen automatikisht detyra migrimi. Kështu mund të kontrolloni sjelljen e makinave virtuale, gjatë lëvizjes mes node-ve të klasterit. Ju mund të konfiguroni Migrimin e Gjallë si dhe të menaxhoni VM, ashtu si dhe të gjitha pods e tjera.
Rrjeti
Cilido sistem Kubernetes siguron lidhje mes node-ve dhe podâave pĂ«rmes rrjeteve softuerike SDN. OpenShift nuk bĂ«n pĂ«rjashtim dhe qĂ« nga versioni i tretĂ« pĂ«rdor pĂ«r kĂ«tĂ« OpenShiftSDN si versionin e parazgjedhur. PĂ«r mĂ« tepĂ«r, nĂ« OpenShift 4 ka njĂ« funksion tĂ« ri tĂ« quajtur Multus, i cili lejon tĂ« disponohen disa rrjete dhe lidhjen e podâave me to njĂ«herĂ«sh.
Me Multus, administratorĂ«t mund tĂ« caktosh rrjete shtesĂ« CNI, tĂ« cilat mĂ« pas do tĂ« krijohen dhe konfigurohen nĂ« klaster nga operatori i veçantĂ« tĂ« Rrjetit tĂ« Klasterit. Pas kĂ«saj, podâave lidhen me njĂ« ose mĂ« shumĂ« nga kĂ«to rrjete, zakonisht me OpenShiftSDN standard dhe njĂ« ndĂ«rfaqe shtesĂ«. Pajisjet SR-IOV, bridge standarde Linux, pajisjet MACVLAN dhe IPVLAN â tĂ« gjitha kĂ«to gjithashtu mund tĂ« pĂ«rdoren, nĂ«se Ă«shtĂ« e nevojshme pĂ«r VM tuaj. NĂ« ilustrimin mĂ« poshtĂ« tregohet se si tĂ« caktohet 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
NĂ« lidhje me virtualizimin e OpenShift, kjo do tĂ« thotĂ« se VM mund tĂ« lidhet drejtpĂ«rdrejt me rrjetin e jashtĂ«m, duke e anashkaluar SDN. Kjo Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r makinat virtuale qĂ« janĂ« transferuar nĂ« OpenShift nga Red Hat Virtualization ose VMware vSphere, sepse me qasje nĂ« nivelin e dytĂ« OSI nuk do tĂ« ketĂ« ndryshime tĂ« konfigurations rrjetore. Kjo gjithashtu do tĂ« thotĂ« se VM mund tĂ« ketĂ« njĂ« adresĂ« rrjeti, pĂ«r tĂ« cilĂ«n kĂ«rkesat anashkalojnĂ« SDN. KĂ«shtu, mund tĂ« pĂ«rdorim me efikasitet adaptr tĂ« specializuar rrjetorĂ«, ose tĂ« lidhemi pĂ«rmes rrjetit direkt me SHTâŠ
Për më shumë informacion rreth mënyrës se si të krijoni dhe lidheni makinat virtuale të OpenShift virtualization me rrjetin, mund të . Për më tepër, , i cili implementohet si pjesë e OpenShift virtualization, ofron një tjetër mënyrë të njohur për krijimin dhe menaxhimin e konfigurimeve të rrjetit në node-t fizikë, që përdoren nën hipervizorët.
Ruajtja
Këto lidhje 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 protokolle standarde për ambientin Kubernetes të ruajtjes. Kështu, administratorët e Kubernetes dhe ekipet përgjegjëse për aplikacionet marrin një mekanizëm të njohur dhe të zakonshëm menaxhimi si për kontejnerët, ashtu edhe për makinat virtuale. Dhe për shumë administratorë të ambientalit të virtualizimit, kjo koncept mund të duket e njohur, pasi përdor të njëjtin parim të ndarjes së skedarëve të konfiguracionit VM dhe disqeve, që aplikohet në OpenStack dhe në shumë platforma të tjera cloud.
Megjithatë, nuk mund të krijohet një diskut i ri për VM çdo herë, sepse gjatë migrimit nga hipervizori në OpenShift, ne duhet të ruajmë të dhënat. Madje edhe kur vendosim një VM të re, është gjithmonë më e shpejtë ta bëjmë nga një model, sesa ta krijojmë nga e para. Kështu, na nevojitet funksionaliteti për importimin e disqeve ekzistuese.
Për të simplifikuar këtë detyrë, virtualizimi OpenShift nis projektin Containerized Data Importer (CDI), i cili e redukton importimin e imazheve të disqeve nga disa burime në krijimin e një regjistrimi 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
Pikërisht ky regjistrim aktivizon CDI, duke nisur sekuencën e veprimeve, siç tregohet në figurën më poshtë:
Pasi CDI tĂ« pĂ«rfundojĂ«, PVC do tĂ« pĂ«rmbajĂ« disqin e makinĂ«s virtuale gati pĂ«r t'u pĂ«rdorur dhe tĂ« sjellĂ« nĂ« formatin standard pĂ«r OpenShiftâŠ
Kur punoni me virtualizimin OpenShift, do t'ju nevojitet gjithashtu OpenShift Container Storage (OCS), një zgjidhje nga Red Hat e bazuar në sistemin e skedarëve Ceph, e cila realizon funksionalitetin e ruajtjes së përhershme për kontejnerët. Në përveç metodave standarde të qasjes PVC - RWO (bloku) dhe RWX (skedari) - OCS ofron RWX për pajisje raw block, që është shumë e dobishme për organizimin e qasjes së përbashkët të bllokut 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 Object Bucket Claim për grupe objektesh, i cili i lejon aplikacionet të përdorin drejtpërdrejt ruajtjen objekt.
Makinat virtuale në kontejnerë
Nëse jeni të interesuar të shihni se si funksionon, duhet të dini se virtualizimi OpenShift është tashmë në dispozicion në variantin Tech Preview si pjesë e OpenShift 3.11 dhe më sipër. Pronarët e një abonimi të vlefshëm për OpenShift mund ta përdorin virtualizimin OpenShift krejtësisht falas dhe pa asnjë lëvizje të mëtejshme. Në momentin e publikimit të këtij postimi, versionet aktuale janë OpenShift 4.4 dhe OpenShift virtualization 2.3; nëse po përdorni versione të mëparshme, vlen të përditësoheni për të marrë funksionet më të reja. Versioni i plotë i mbështetur i virtualizimit OpenShift pritet të publikohet në gjysmën e dytë të vitit 2020.
Për informacion të mëtejshëm, kontaktoni për udhëzime për instalimin, përfshirë , ku jepen informacionet për konfigurimin e rrjeteve të jashtme.
Burimi: habr.com
