OpenShift-virtualisering (stroomop-projek - Kubernetes: KubeVirt, sien. и ), nee Container-inheemse Virtualization, is bekendgestel as 'n funksionaliteit van die OpenShift-platform, wat ontwerp is vir die implementering en bestuur van virtuele masjiene (VM's) as basiese Kubernetes-entiteite. Hierdie soort taak is tegnies uitdagend as gevolg van fundamentele verskille in tegnologie. Om hierdie doel te bereik, het ons bekende tegnologieë gebruik wat gebaseer is op Red Hat Enterprise Linux en KVM, wat al baie jare by ons is en hul doeltreffendheid bewys het.
In hierdie artikel sal ons kyk na die tegniese aspekte van OpenShift-virtualisering wat dit moontlik maak vir VM's en houers om saam te bestaan binne 'n enkele platform wat hulle as 'n enkele entiteit bestuur.
Rekenkundige take
Houers gebruik Linux-kernmeganismes soos naamruimtes en cgroups om prosesse te isoleer en hulpbronne te bestuur. Gewoonlik word prosesse verstaan as Python, Java-toepassings of uitvoerbare lêers, maar in werklikheid kan dit enige prosesse wees, soos bash, Emacs of vim.
Wat is 'n virtuele masjien? Uit die oogpunt van die hipervisor is dit ook 'n proses. Maar nie die aansoekproses nie, maar die KVM-proses wat verantwoordelik is vir die uitvoering van 'n spesifieke VM.
Die houerbeeld bevat al die gereedskap, biblioteke en lêers wat nodig is vir die KVM virtuele masjien. As ons die peul van 'n lopende VM inspekteer, sal ons helpers en qemu-kvm-prosesse daar sien. Boonop het ons toegang tot KVM-nutsgoed vir die bestuur van virtuele masjiene soos qemu-img, qemu-nbd en virsh.
Aangesien 'n virtuele masjien 'n peul is, erf dit outomaties al die funksionaliteit van 'n peul in Kubernetes. VM-peule, net soos gewone peule, is onderhewig aan skeduleerderskemas en kriteria soos vlekke, tolerasies, affiniteit en anti-affiniteit. Jy kry ook die voordele van hoë beskikbaarheid, ens. Daar is egter een belangrike verskil: gereelde peule migreer nie in die gewone sin van gasheer tot gasheer nie. As 'n nodus vanlyn gaan, word die pod daarop beëindig en hertoegewys aan 'n ander nodus in die cluster. En in die geval van 'n virtuele masjien, verwag ons om regstreekse migrasie te sien.
Om hierdie gaping aan te spreek, is 'n pasgemaakte hulpbrondefinisie (CDR) geskep om die lewendige migrasiemeganisme te beskryf wat verantwoordelik is vir die inisialisering, monitering en bestuur van lewendige migrasies van VM's tussen werkernodusse.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Wanneer 'n nodus gedeaktiveer is, word migrasietake outomaties geskep vir daardie virtuele masjiene wat Live Migration as hul uitsettingstrategie gestel het. Op hierdie manier kan jy die gedrag van virtuele masjiene beheer wanneer jy tussen cluster nodusse beweeg. Jy kan beide Live Migration instel en die VM bestuur, soos alle ander peule.
Netwerk
Enige Kubernetes-stelsel verskaf kommunikasie tussen nodusse en peule deur sagteware SDN-netwerke te gebruik. OpenShift is geen uitsondering nie en, vanaf weergawe 3, gebruik OpenShiftSDN by verstek hiervoor. Boonop het OpenShift 4 nog 'n nuwe kenmerk genaamd Multus, wat jou toelaat om verskeie netwerke beskikbaar te stel en peule gelyktydig daaraan te koppel.
Deur Multus te gebruik, kan die administrateur addisionele CNI-netwerke definieer, wat dan deur 'n spesiale groepnetwerkoperateur op die groep ontplooi en gekonfigureer sal word. Die peule word dan aan een of meer van hierdie netwerke gekoppel, gewoonlik die standaard OpenShiftSDN en 'n bykomende koppelvlak. SR-IOV toestelle, standaard Linux Bridge, MACVLAN en IPVLAN toestelle kan almal gebruik word as jou VM dit nodig het. Die figuur hieronder wys hoe om Multus CNI vir die brugnetwerk op die eth1-koppelvlak in te stel:
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
Met betrekking tot OpenShift-virtualisering beteken dit dat 'n VM direk aan 'n eksterne netwerk gekoppel kan word, wat SDN omseil. Dit is belangrik vir virtuele masjiene wat na OpenShift gemigreer is vanaf Red Hat Virtualization of VMware vSphere, want as jy toegang het tot die tweede OSI-laag, sal daar geen verandering in netwerkinstellings wees nie. Dit beteken ook dat die VM 'n netwerkadres kan hê wat SDN omseil. Ons kan dus effektief gespesialiseerde netwerkadapters gebruik, of direk oor die netwerk aan die bergingstelsel koppel...
Jy kan meer leer oor hoe om OpenShift-virtualisering virtuele masjiene te skep en aan die netwerk te koppel ... Buitendien, , ontplooi as deel van OpenShift-virtualisering, bied nog 'n bekende manier om netwerkkonfigurasies te skep en te bestuur op fisiese nodusse wat onder hipervisors gebruik word.
Storage
Die koppeling en bestuur van virtuele masjienskywe binne OpenShift-virtualisering word uitgevoer met behulp van Kubernetes-konsepte soos StorageClasses, PersistentVolumeClaims (PVC) en PersistentVolume (PV), sowel as stoorprotokolle-standaard vir die Kubernetes-omgewing. Dit gee Kubernetes-administrateurs en toepassingspanne 'n algemene, bekende manier om beide houers en virtuele masjiene te bestuur. En vir baie administrateurs van virtualisasie-omgewings kan hierdie konsep bekend klink omdat dit dieselfde beginsel gebruik om VM-konfigurasielêers en -skywe te skei wat in OpenStack en baie ander wolkplatforms gebruik word.
Ons kan egter nie net elke keer 'n nuwe skyf vir die VM skep nie, aangesien ons die data moet stoor wanneer ons van die hypervisor na OpenShift migreer. Ja, selfs wanneer ons 'n nuwe VM ontplooi, is dit altyd vinniger om dit vanaf 'n sjabloon te doen as om dit van nuuts af te skep. Ons benodig dus funksionaliteit vir die invoer van bestaande skywe.
Om hierdie taak te vereenvoudig, ontplooi OpenShift-virtualisering die Containerized Data Importer (CDI)-projek, wat die invoer van skyfbeelde van skywe vanaf verskeie bronne verminder tot die skep van 'n PVC-inskrywing.
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
Dit is hierdie inskrywing wat CDI aktiveer, wat die volgorde van aksies veroorsaak wat in die onderstaande figuur getoon word:
Nadat die CDI voltooi is, sal die PVC die virtuele masjienskyf bevat wat gereed is vir gebruik en omgeskakel word na die standaard OpenShift-formaat ...
Wanneer u met OpenShift-virtualisering werk, is OpenShift Container Storage (OCS), 'n Red Hat-oplossing gebaseer op die Ceph-lêerstelsel wat aanhoudende bergingsfunksies vir houers implementeer, ook nuttig. Benewens die standaard PVC-toegangsmetodes - RWO (blok) en RWX (lêer) - verskaf OCS RWX vir rou bloktoestelle, wat baie nuttig is om bloktoegang vir toepassings met hoë werkverrigtingvereistes te deel. Daarbenewens ondersteun OCS die nuwe Object Bucket Claim-standaard, wat toepassings toelaat om objekdataberging direk te gebruik.
Virtuele masjiene in houers
As jy belangstel om te kyk hoe dit werk, weet dan dat OpenShift-virtualisering reeds beskikbaar is in die Tech Preview-weergawe as deel van OpenShift 3.11 en hoër. Eienaars van 'n bestaande OpenShift-intekening kan OpenShift-virtualisering heeltemal gratis en sonder enige bykomende stappe gebruik. Ten tyde van hierdie plasing is OpenShift 4.4 en OpenShift-virtualisering 2.3 tans; as jy vorige weergawes gebruik, moet jy opgradeer om die nuutste kenmerke te kry. 'n Ten volle ondersteunde weergawe van OpenShift-virtualisering behoort in die tweede helfte van 2020 vrygestel te word.
Vir meer inligting, verwys asseblief na vir installasie-instruksies, insluitend , wat inligting verskaf oor die opstel van eksterne netwerke.
Bron: will.com