OpenShift virtualiseerimine: konteinerid, KVM ja virtuaalmasinad

OpenShift virtuaalitute (ylävirta projekti – Kubernetes: KubeVirt, ks. siin ja siin), aiemmin tunnettu nimellä Container-native Virtualization, esiteltiin toiminto, joka on suunniteltu OpenShift-alustalle virtuaalikoneiden (VM) käyttöönottoon ja hallintaan perus Kubernetessa. Tämäntyyppinen tehtävä on teknisesti haastava johtuen teknologioiden perustavanlaatuisista eroista. Tavoitteeseen pääsemiseksi käytettiin kaikille tuttuja teknologioita Red Hat Enterprise Linuxin ja KVM:n pohjalta, jotka ovat olleet kanssamme jo vuosia ja todistaneet tehokkuutensa.

Tässä artikkelissa tarkastelemme OpenShift-virtuaalitesteihin liittyviä teknisiä näkökohtia, jotka mahdollistavat VM:ien ja konttien yhteiselon yhdellä alustalla, joka hallitsee niitä yhtenä kokonaisuutena.

Laskentatehtävät

Konteissa käytetään Linux-ytimen mekanismeja, kuten nimiavaruuksia ja cgroups, prosessien eristämiseen ja resurssien hallintaan. Yleensä prosessina ymmärretään Python-, Java- tai suoritettavat tiedostot, mutta todellisuudessa ne voivat olla mitä tahansa prosesseja, kuten bash, Emacs tai vim.

Entä mitä virtuaalikone on? Hypervisorin näkökulmasta – se on myös prosessi. Mutta ei sovellusprosessi, vaan KVM-prosessi, joka vastaa erityisen VM:n suorittamisesta.

Konteinerikuva sisältää kaikki työkalut, kirjastot ja tiedostot, jotka tarvitaan KVM-virtuaalikoneelle. Jos tarkastamme toimivan VM:n podia, näemme siellä apuohjelmia ja qemu-kvm-prosesseja. Meillä on myös pääsy KVM-työkaluihin virtuaalikoneiden hallintaan, kuten qemu-img, qemu-nbd ja virsh.

Koska virtuaalikone on pod, se automaattisesti perii koko podin toiminnallisuuden Kubernetessa. VM-podeihin sovelletaan samoja suunnittelu- ja kriteerikaavioita kuin tavallisiin podeihin, kuten taintit, toleraatiot, affiniteetti ja anti-affiniteetti. Saat myös etuja, kuten korkean saatavuuden jne. On kuitenkin yksi tärkeä ero: tavalliset podit eivät migroi isännältä toiselle meille tutulla tavalla. Jos solmu sammuu, pod siinä katkesi ja siirretään toiselle solmulle klusterissa. Mutta virtuaalikoneen osalta odotamme näkevämme elävän migraation.

Tämän aukon poistamiseksi luotiin mukautettu resurssimääritelmä (CDR), joka kuvaa elävän migraation mekanismia, joka vastaa VM:ien elävien migraatioiden aloituksesta, seurannasta ja hallinnasta työntekijäsolmujen välillä.

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

Klõpsamisel sõlme deaktiveerimise korral, nende virtuaalsete masinate jaoks, mille väljaviimise strateegia on määratud Live Migration, luuakse automaatselt migreerimisülesanded. See võimaldab teil kontrollida virtuaalsete masinate käitumist, kui neid liigutatakse klastris sõlmede vahel. Saate seadistada Live Migrationi ja hallata VM-e, nagu kõiki teisi pod'e.

Võrk

Iga Kubernetes-süsteem tagab sõlmede ja pod'ide vahelise ühenduse tarkvara SDN-võrkude kaudu. OpenShift ei ole erand ning alates 3. versioonist kasutatakse seda vaikimisi OpenShiftSDN-i. Lisaks on OpenShift 4-s lisandunud uus funktsioon nimega Multus, mis võimaldab mitut võrku korraga kergesti kätte saada ja pod'e neile ühendada.

Multus'e abil saab administraator määrata täiendavad CNI-võrgud, mis seejärel paigaldatakse ja seadistatakse klastris erilise Cluster Network Operator'i abil. Pärast seda ühendatakse pod'id ühte või mitmesse neist võrkudest, tavaliselt tavapärase OpenShiftSDN-i ja täiendava liidese kaudu. SR-IOV seadmed, tavalised Linux Bridge'id, MACVLAN ja IPVLAN seadmed – kõik neid saab samuti kasutada, kui see on teie VM-ile vajalik. Alloleval joonisel on näidatud, kuidas seadistada Multus CNI bridge-võrku liideses 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

OpenShift virtualiseerimise kontekstis tähendab see, et VM-ide saab otse välise võrgu ühendada, mööda minnes SDN-ist. See on oluline virtuaalmasinate jaoks, mis on OpenShift'i viidud Red Hat Virtualization'ist või VMware vSphere'ist, kuna juurdepääsu olemasolu korral teisel OSI tasandil ei toimu võrguseadete muutusi. See tähendab ka, et VM-il võib olla võrgu aadress, millele pöördumised mööda SDN-i. Nii saame tõhusalt kasutada spetsialiseeritud võrkarteid või ühendada otse SAN-iga...

Lisateabe saamiseks selle kohta, kuidas luua ja ühendada OpenShift virtualiseerimise virtuaalseid masinaid võrku, vaadake siin. Lisaks nmstate operator, mis on paigaldatud OpenShift virtualiseerimise koosseisus, pakub veel üht hästi tuttavat viisi füüsiliste sõlmede võrgukonfiguratsioonide loomiseks ja haldamiseks, mida kasutatakse hyperviisorite all.

Salvestamine

Virtuaalmasinate ketaste ühendamine ja haldamine OpenShift virtualiseerimise raames toimub, kasutades selliseid Kubernetes'i kontseptsioone nagu StorageClasses, PersistentVolumeClaims (PVC) ja PersistentVolume (PV), samuti Kubernetes'i keskkonna standardseid salvestusprotokolle. Seega saavad Kubernetes'i administraatorid ja rakenduste eest vastutavad meeskonnad ühtse ja tuttava haldussüsteemi nii konteinerite kui ka virtuaalmasinate jaoks. Paljude virtualiseerimiskeskkondade administraatorite jaoks võib see kontseptsioon tunduda tuttav, kuna see kasutab sama põhimõtet VM-i konfiguratsioonifailide ja ketaste eraldamiseks nagu OpenStack ja paljudel teistel pilveplatvormidel.

Siiski ei ole võimalik iga kord uut ketast loomine VM-i jaoks, kuna OpenShift'ile migreerimisel peame andmeid säilitama. I even when we deploy a new VM, it is always faster to do so from a template than to create one from scratch. Thus, we need the functionality to import existing disks.

Selle ülesande lihtsustamiseks käivitab OpenShift virtualiseerimine Containerized Data Importer (CDI) projekti, mis vähendab ketaspiltide importimist erinevatest allikatest PVC-sse kirje loomisega.

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 this entry activates CDI, initiating the sequence of actions shown in the figure below:

Pärast CDI töötlemist sisaldab PVC virtuaalmasina ketast, mis on kasutamiseks valmis ja viidud OpenShift'i standardformaati...
OpenShift virtualiseerimisega töötamisel on samuti kasulik OpenShift Container Storage (OCS), Red Hati lahendus, mis põhineb Ceph failisüsteemil ja rakendab püsiva salvestuslahenduse konteineritele. Lisaks standardsetele PVC ligipääsu meetoditele – RWO (plokk) ja RWX (fail) – pakub OCS RWX toore plokiseadmete jaoks, mis on väga kasulik kõrge jõudlusnõudega rakenduste jaoks koos blokiga juurdepääsu korraldamiseks. Lisaks toetab OCS uut objektidegruppeerimise taotlemise standardit Object Bucket Claim, mis võimaldab rakendustel andmete objektide salvestust otse kasutada.

Virtuaalmasinad konteinerites

Kui teid huvitab, kuidas see töötab, siis teadke, et OpenShift virtualiseerimine on juba saadaval Tech Preview versioonina OpenShift 3.11 ja uuemates. OpenShift'i aktiivsete tellimuste omanikud saavad kasutada OpenShift virtualiseerimist täiesti tasuta ja ilma igasuguste lisategevusteta. Selle postituse kirjutamise hetkeks on aktuaalsed OpenShift 4.4 ja OpenShift virtualiseerimine 2.3; kui kasutate varasemaid versioone, siis tasub uuendada, et saada uusimaid funktsioone. Täielikult toetatav versioon OpenShift virtualiseerimisest peaks välja tulema 2020. aasta teises pooles.

Lisainformatsiooni saamiseks võtke ühendust OpenShift'i dokumentatsiooniga paigaldusjuhiste saamiseks, sealhulgas Multus'e seadistamise jaotisega, mis sisaldab teavet väliste võrkude seadistamise kohta.

Allikas: habr.com