OpenShift-virtualigo (kontraŭflua projekto - Kubernetes: KubeVirt, vidu. и ), nee Container-denaska Virtualigo, estis lanĉita kiel funkcieco de la OpenShift-platformo, kiu estas dizajnita por deploji kaj administri virtualajn maŝinojn (VMs) kiel bazaj Kubernetes-unuoj. Tia tasko estas teknike malfacila pro fundamentaj diferencoj en teknologio. Por atingi ĉi tiun celon, ni uzis konatajn teknologiojn bazitajn sur Red Hat Enterprise Linux kaj KVM, kiuj estas ĉe ni dum multaj jaroj kaj pruvis sian efikecon.
En ĉi tiu artikolo, ni rigardos la teknikajn aspektojn de OpenShift-virtualigo, kiuj ebligas al VMs kaj ujoj kunekzisti ene de ununura platformo, kiu administras ilin kiel ununura ento.
Komputilaj taskoj
Ujoj uzas Linukso-kernmekanismojn kiel nomspacojn kaj cgrupojn por izoli procezojn kaj administri rimedojn. Kutime procezoj estas komprenataj kiel Python, Java-aplikoj aŭ ruleblaj dosieroj, sed fakte ili povas esti ajnaj procezoj, kiel bash, Emakso aŭ vim.
Kio estas virtuala maŝino? De la vidpunkto de la hiperviziero, ĉi tio ankaŭ estas procezo. Sed ne la aplika procezo, sed la KVM-procezo respondeca por ekzekuti specifan VM.
La ujo-bildo enhavas ĉiujn ilojn, bibliotekojn kaj dosierojn necesajn por la virtuala maŝino KVM. Se ni inspektas la pod de kuranta VM, ni vidos tie helpantojn kaj qemu-kvm-procezojn. Aldone, ni havas aliron al KVM-iloj por administri virtualajn maŝinojn kiel qemu-img, qemu-nbd kaj virsh.
Ĉar virtuala maŝino estas pod, ĝi aŭtomate heredas ĉiujn funkciojn de pod en Kubernetes. VM-podoj, same kiel regulaj balgoj, estas submetataj al planigaj kabaloj kaj kriterioj kiel makuloj, toleroj, afineco kaj kontraŭ-afineco. Vi ankaŭ ricevas la avantaĝojn de alta havebleco, ktp. Tamen, estas unu grava diferenco: regulaj balgoj ne migras de gastiganto al gastiganto en la kutima signifo. Se nodo malkonektas, la pod sur ĝi estas finita kaj reasignita al alia nodo en la areto. Kaj en la kazo de virtuala maŝino, ni atendas vidi vivan migradon.
Por trakti ĉi tiun breĉon, kutima rimeda difino (CDR) estis kreita por priskribi la vivan migradan mekanismon, kiu respondecas pri pravalorigo, monitorado kaj administrado de vivaj migradoj de VM-oj inter laboristaj nodoj.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Kiam nodo estas malaktivigita, migraj taskoj estas aŭtomate kreitaj por tiuj virtualaj maŝinoj, kiuj havas Live Migration agordita kiel sia eldomigo-strategio. Tiel vi povas kontroli la konduton de virtualaj maŝinoj kiam vi moviĝas inter grapolnodoj. Vi povas ambaŭ agordi Vivan Migradon kaj administri la VM, kiel ĉiuj aliaj podoj.
Reto
Ajna sistemo de Kubernetes disponigas komunikadon inter nodoj kaj podoj uzante programajn SDN-retojn. OpenShift ne estas escepto kaj, ekde la versio 3, uzas OpenShiftSDN defaŭlte por tio. Krome, OpenShift 4 havas alian novan funkcion nomitan Multus, kiu ebligas al vi disponigi plurajn retojn kaj konekti podojn al ili samtempe.
Uzante Multus, la administranto povas difini pliajn CNI-retojn, kiuj tiam estos deplojitaj kaj agorditaj sur la areto fare de speciala Cluster Network Operator. La balgoj tiam estas konektitaj al unu aŭ pli el ĉi tiuj retoj, kutime la norma OpenShiftSDN kaj aldona interfaco. SR-IOV-aparatoj, norma Linuksa Ponto, MACVLAN kaj IPVLAN-aparatoj ĉiuj povas esti uzataj se via VM bezonas ĝin. La suba figuro montras kiel agordi Multus CNI por la ponta reto sur la interfaco 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
Rilate al OpenShift-virtualigo, tio signifas, ke VM povas esti konektita al ekstera reto rekte, preterirante SDN. Ĉi tio estas grava por virtualaj maŝinoj migritaj al OpenShift de Red Hat Virtualization aŭ VMware vSphere, ĉar se vi havas aliron al la dua OSI-tavolo, ne estos ŝanĝo en retaj agordoj. Ĉi tio ankaŭ signifas, ke la VM povas havi retadreson, kiu preteriras SDN. Tiel, ni povas efike uzi specialigitajn retajn adaptilojn, aŭ konekti rekte al la stokadsistemo tra la reto...
Vi povas lerni pli pri kiel krei kaj konekti OpenShift virtualajn virtualajn maŝinojn al la reto ... Cetere, , deplojita kiel parto de OpenShift-virtualigo, ofertas alian konatan manieron krei kaj administri retajn agordojn sur fizikaj nodoj kiuj estas uzitaj sub hiperviziiloj.
Stokado
Konekti kaj administri virtualajn maŝinajn diskojn ene de OpenShift-virtualigo estas farita uzante Kubernetes-konceptojn kiel StorageClasses, PersistentVolumeClaims (PVC) kaj PersistentVolume (PV), same kiel stokadprotokolojn normo por la Kubernetes-medio. Ĉi tio donas al administrantoj kaj aplikaj teamoj de Kubernetes komunan kaj konatan manieron administri kaj ujojn kaj virtualajn maŝinojn. Kaj por multaj administrantoj de virtualigaj medioj, ĉi tiu koncepto povas soni konata ĉar ĝi uzas la saman principon de apartigado de VM-agordaj dosieroj kaj diskoj, kiu estas uzata en OpenStack kaj multaj aliaj nubaj platformoj.
Tamen ni ne povas simple krei novan diskon por la VM ĉiufoje, ĉar dum migrado de la hiperviziero al OpenShift, ni devas konservi la datumojn. Jes, eĉ kiam ni deplojas novan VM, ĉiam estas pli rapide fari ĝin de ŝablono ol krei ĝin de nulo. Tiel, ni bezonas funkciojn por importi ekzistantajn diskojn.
Por simpligi ĉi tiun taskon, OpenShift-virtualigo deplojas la projekton Containerized Data Importer (CDI), kiu reduktas importadon de diskobildoj de diskoj de multoblaj fontoj al kreado de PVC-eniro.
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
Estas ĉi tiu eniro kiu aktivigas CDI, ekigante la sekvencon de agoj montrita en la figuro malsupre:
Post kiam la CDI finiĝos, la PVC enhavos la virtualan maŝinan diskon pretan por uzo kaj konvertitan al la norma OpenShift-formato...
Kiam vi laboras kun OpenShift-virtualigo, OpenShift Container Storage (OCS), Red Hat-solvo bazita sur la Ceph-dosiersistemo, kiu efektivigas konstantan stokan funkcion por ujoj, ankaŭ estas utila. Aldone al la normaj PVC-alirmetodoj - RWO (bloko) kaj RWX (dosiero) - OCS provizas RWX por krudaj blokaj aparatoj, kio estas tre utila por kunhavigi blokan aliron por aplikoj kun altaj rendimentaj postuloj. Krome, OCS subtenas la novan Object Bucket Claim-normon, kiu permesas al aplikaĵoj rekte uzi objektajn datumojn.
Virtualaj maŝinoj en ujoj
Se vi interesiĝas kontroli kiel ĝi funkcias, tiam sciu, ke OpenShift-virtualigo jam haveblas en la Tech Preview-versio kiel parto de OpenShift 3.11 kaj pli. Posedantoj de ekzistanta OpenShift-abono povas uzi OpenShift-virtualigon tute senpage kaj sen aldonaj paŝoj. Je la publikigo de ĉi tiu afiŝo, OpenShift 4.4 kaj OpenShift-virtualigo 2.3 estas aktualaj; se vi uzas antaŭajn versiojn, tiam vi devus ĝisdatigi por akiri la plej novajn funkciojn. Plene subtenata versio de OpenShift-virtualigo devus esti publikigita en la dua duono de 2020.
Por pliaj informoj bonvolu kontakti por instalinstrukcioj, inkluzive , kiu provizas informojn pri starigo de eksteraj retoj.
fonto: www.habr.com