OpenShift virtualiseerimine: konteinerid, KVM ja virtuaalsed masinad

OpenShift'i virtualiseerimine (ülemineku projekt - Kubernetes: KubeVirt, vt. siit ja siit), varem tuntud kui Container-native Virtualization, esitati OpenShift'i platvormi funktsionaalsusena, mis on mõeldud virtuaalmasinate (VM) juurutamiseks ja haldamiseks kui Kubernetes'e põhielementideks. Sellise ülesande täitmine on tehniliselt keeruline, põhjusel, et tehnoloogiate fundamentaalsed erinevused. Selle eesmärgi saavutamiseks kasutati kõikidele tuttavaid tehnoloogiaid, mis põhinevad Red Hat Enterprise Linuxil ja KVM-il, mis on meiega olnud aastaid ja tõestanud oma efektiivsust.

Selles artiklis vaatleme OpenShift'i virtualiseerimise tehnilisi aspekte, mis võimaldavad VM-de ja konteinerite samaaegset eksisteerimist ühes platvormis, mis haldab neid kui tervikut.

Arvutusülesanded

Konteinerid kasutavad Linuxi kerneli mehhanisme, nagu nimed ja cgroups, protsesside isoleerimiseks ja ressursside haldamiseks. Tavaliselt mõistetakse protsessina rakendusi nagu Python, Java või täidesaatvad failid, kuid tegelikult võivad need olla igasugused protsessid, näiteks bash, Emacs või vim.

Mis on virtuaalne masin? Hüperviisori vaatenurgast on see samuti protsess. Kuid see ei ole rakenduse protsess, vaid KVM-protsess, mis vastutab konkreetse virtuaalse masina töö eest.

Konteineripilt sisaldab kõiki tööriistu, raamatukogusid ja faile, mis on vajalikud KVM virtuaalse masina jaoks. Kui vaatame töötava virtuaalse masina pod'i, näeme seal abisaid ja qemu-kvm protsesse. Lisaks on meil juurdepääs KVM-tööriistadele virtuaalsete masinate haldamiseks, näiteks qemu-img, qemu-nbd ja virsh.

Kuna virtuaalne masin on pod, pärib see automaatselt kogu pod'i funktsionaalsuse Kuberneteses. Virtuaalsetele masinatele ka rakenduvad samad skeemid ja planeerimise kriteeriumid nagu tavapärastele pod'idele, näiteks taints, tolerations, affinity ja anti-affinity. Samuti saate eeliseid kõrgest saadavusest jne. Siiski on üks oluline erinevus: tavalised pod'id ei rändavad hostilt hostile meie harjumuslikus tähenduses. Kui sõlm lülitatakse välja, katkeb sellel olev pod ning see määratakse ümber teisele sõlmele klastris. Virtuaalse masina puhul ootame aga nägevat elavat rändamist.

Selle probleemi lahendamiseks loodi kohandatud ressursside määratlemine (CDR), mis kirjeldab elava migreerimise mehhanismi, mis vastutab VM-ide elava migreerimise algatamise, jälgimise ja haldamise eest töötlusnode vahel.

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
  name: migration-job
spec:
  vmiName: fedora

Node deaktiveerimise korral luuakse automaatselt migreerimisülesanded nende virtuaalmasinate jaoks, mille eviction strategy on seadistatud Live Migration-iks. Nii on võimalik kontrollida virtuaalmasinate käitumist klastrinodeside vahel liikumise ajal. Saate nii seadistada Live Migration-i kui ka hallata VM-e nagu kõiki teisi pod'e.

Võrk

Iga Kubernetes-süsteem tagab suhtluse node'ide ja pod'ide vahel tarkvaraliste SDN-võrkude kaudu. OpenShift ei ole erand ning alates 3. versioonist kasutab see selleks vaikimisi OpenShiftSDN-i. Lisaks on OpenShift 4-s lisandunud uus funktsioon nimega Multus, mis võimaldab juurdepääsu mitmele võrgule ja nende ühendamisele samaaegselt pod'idega.

Multusiga saab administraator määrata täiendavaid CNI võrke, mille seejärel spetsiaalne Cluster Network Operator juurutab ja konfigureerib klastris. Pärast seda ühendatakse pod’id ühte või mitmesse neist võrkudest, tavaliselt standardse OpenShiftSDN ja täiendava liidese kaudu. SR-IOV seadmeid, standardseid Linuxi sildasid, MACVLAN ja IPVLAN seadmeid – kõike seda saab kasutada, kui see on teie VM-i jaoks vajalik. Alloleval joonisel on kujutatud, kuidas seadistada Multus CNI bridge võrku liidese eth1 peal:

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

OpenShift virtualiseerimise kontekstis tähendab see, et virtuaalmasinaid saab otse liita välise võrgu kaudu, möödaminnes SDN-ist. See on oluline virtuaalmasinate jaoks, mis on viidud OpenShift'i Red Hat Virtualization'ist või VMware vSphere'ist, kuna teise OSI taseme juurdepääsu korral ei muutu võrguseaded. See tähendab ka, et virtuaalmasinal võib olla võrguaadress, millele pääsemine mööda SDN-i ei käi. Seega saame efektiivselt kasutada spetsialiseeritud võrguadaptereid või ühendada otse võrgu kaudu andmesalvestusse…

Rohkem teavet OpenShift virtualiseerimise virtuaalmasinate loomise ja võrguga ühendamise kohta leiate siit. Lisaks, nmstate operator, mis on juurutatud OpenShift virtualiseerimise koosseisus, pakub veel üht tuttavat viisi füüsiliste sõlmede võrgukonfiguratsioonide loomiseks ja haldamiseks, mida kasutatakse hypervisorite all.

Hoidmine

OpenShift'i virtualiseerimise raames toimuvad virtuaalmasinate kettade ühendamine ja haldamine Kubernetes'i kontseptsioonide, nagu StorageClasses, PersistentVolumeClaims (PVC) ja PersistentVolume (PV), ning Kubernetes'i keskkonnale tavapäraste salvestusprotokollide abil. Seega saavad Kubernetes'i administraatorid ja rakenduste meeskonnad ühtse ja tuttava haldussüsteemi nii konteinerite kui ka virtuaalmasinate jaoks. Paljude virtualiseerimisadministraatorite jaoks võib see kontseptsioon olla tuttav, kuna see kasutab sama põhimõtet, et eraldada VM-i konfigureerimise failid ja kettad, nagu näiteks OpenStack'is ja paljudes teistes pilveplatvormides.

Kuid ei ole võimalik iga kord luua uut ketast VM-ile, kuna OpenShift'i hüperviisori migreerimise korral peame andmeid säilitama. Isegi kui käivitame uue VM-i, on seda alati kiiremini teha mallist, kui nullist. Seega vajame olemasolevate ketaste importimise funktsionaalsust.

Selle ülesande lihtsustamiseks käivitab OpenShift virtualization projekti Containerized Data Importer (CDI), mis koondab ketta piltide importimise mitmest allikast PVC-sse salvestamise.

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

Just see entry activates CDI, triggering the sequence of actions shown in the image below:

Pärast CDI töö lõppemist sisaldab PVC virtuaalmasina ketast, mis on valmis kasutamiseks ja viidud OpenShift'i formaati...
OpenShift virtualiseerimise puhul on kasulik ka OpenShift Container Storage (OCS), Red Hati lahendus, mis põhineb Cephi failisüsteemil ning rakendab konteinerite püsihalduse funktsioone. OCS pakub lisaks standardsetele PVC-juurdepääsumeetoditele – RWO (plokihaldus) ja RWX (failihaldus) – RWX-i toorbloki seadmetele, mis on väga kasulik kõrge jõudluse nõudvate rakenduste ühiseks plokihaldamiseks. Lisaks toetab OCS uut objektihaarde rühma nõudmise standardit (Object Bucket Claim), mis võimaldab rakendustel otse objektiandmete salvestust kasutada.

Konteinerites asuvad virtuaalsed masinad

Kui teid huvitab, kuidas see töötab, siis teadke, et OpenShift virtualiseerimine on juba saadaval Tech Preview versioonis OpenShift 3.11 ja uuemates. Aktiivse OpenShift'i tellimuse omanikud saavad kasutada OpenShift virtualiseerimist täiesti tasuta ja ilma igasuguste lisategevusteta. Käesoleva postituse avaldamise hetkeks on aktuaalsed OpenShift 4.4 ja OpenShift virtualiseerimine 2.3, ning kui kasutate varasemaid versioone, siis on soovitatav uuendada, et saada uusimad funktsioonid. Täielikult toetatav versioon OpenShift virtualiseerimisest peaks välja tulema 2020. aasta teises pooles.

Lisainformatsiooni saamiseks võtke ühendust OpenShift'i dokumentatsiooniga paigaldamise juhiste osas, sealhulgas Multuse seadistamise jaotisega, kus on teave väliste võrkude seadistamise kohta.

Allikas: habr.com