OpenShift virtualisering (upstream projekt – Kubernetes: KubeVirt, se. og ), tidligere kendt som Container-native Virtualization, blev præsenteret som en funktionalitet i OpenShift-platformen, der er designet til at deployere og administrere virtuelle maskiner (VM'er) som grundlæggende enheder i Kubernetes. Denne type opgave er teknisk udfordrende på grund af de fundamentale forskelle mellem teknologierne. For at nå det ønskede mål blev velkendte teknologier baseret på Red Hat Enterprise Linux og KVM anvendt, som har været tilgængelige i flere år og har bevist deres effektivitet.
I denne artikel vil vi se på de tekniske aspekter ved OpenShift virtualisering, som muliggør sameksistens af VM'er og containere inden for én platform, der administrerer dem som en helhed.
Beregningsopgaver
Containere benytter mekanismer i Linux-kernen, såsom namespaces og cgroups, til at isolere processer og administrere ressourcer. Normalt refererer man til processer som Python, Java eller eksekverbare filer, men det kan faktisk være enhver proces, såsom bash, Emacs eller vim.
Hvad er en virtuel maskine? Set fra hypervisorens perspektiv – er det også en proces. Men det er ikke en applikationsproces, men en KVM-proces, der er ansvarlig for at køre en specifik VM.
Containerbilledet indeholder alle værktøjer, biblioteker og filer, der er nødvendige for den KVM-virtuel maskine. Hvis vi inspicerer pod'en for en kørende VM, vil vi se hjælpere og qemu-kvm processer der. Derudover har vi adgang til KVM-værktøjer til at administrere virtuelle maskiner, såsom qemu-img, qemu-nbd og virsh.
Da en virtuel maskine er en pod, arver den automatisk al funktionaliteten fra en pod i Kubernetes. Ligesom almindelige pods gælder der skemaer og kriterier for planlægning såsom taints, tolerationer, affinity og anti-affinity for VM-pods. Desuden får man fordele i form af høj tilgængelighed og så videre. Men der er én vigtig forskel: almindelige pods migrerer ikke fra host til host i den forstand, vi kender det. Hvis en node går ned, bliver pod'en på den underbrudt og genansat på en anden node i klyngen. Men i tilfældet med en virtuel maskine forventer vi at se live migrering.
For at tackle denne udfordring blev der oprettet en custom resource definition (CRD), der beskriver mekanismen for live migration, som er ansvarlig for initialization, overvågning og administration af live migreringer af VM'er mellem arbejdsnoder.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Når en node deaktiveres, oprettes der automatisk migrationsopgaver for de virtuelle maskiner, der har Live Migration som evictionsstrategi. Dette gør det muligt at kontrollere opførselen af virtuelle maskiner, når de flyttes mellem noden i klyngen. Du kan konfigurere Live Migration og administrere VM'er som med alle andre pods.
Netværk
Enhver Kubernetes-system sikrer kommunikation mellem noder og pods vha. software SDN-netværk. OpenShift er ingen undtagelse og bruger som standard OpenShiftSDN fra version 3. Desuden er der i OpenShift 4 en ny funktion kaldet Multus, der gør det muligt at tilgå flere netværk og forbinde pods til dem samtidig.
Med Multus kan administratorer definere yderligere CNI-netværk, som derefter implementeres og konfigureres i klyngen af en speciel Cluster Network Operator. Derefter kan pods oprette forbindelse til et eller flere af disse netværk, normalt til standard OpenShiftSDN og en ekstra grænseflade. SR-IOV-enheder, standard Linux Bridge, MACVLAN og IPVLAN-enheder kan også bruges, hvis det er nødvendigt for din VM. Nedenfor vises, hvordan man angiver Multus CNI til bridge-netværket på interface 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
I forhold til OpenShift-virtualisering betyder dette, at VM'en kan tilsluttes et eksternt netværk direkte, uden at gå gennem SDN. Dette er vigtigt for virtuelle maskiner, der er flyttet til OpenShift fra Red Hat Virtualization eller VMware vSphere, da der ikke vil være ændringer i netværksindstillingerne med adgang på Layer 2 OSI. Det betyder også, at VM'en kan have en netværksadresse, hvor anmodninger omgår SDN. På denne måde kan vi effektivt bruge specialiserede netværksadaptere eller oprette forbindelse til SAN direkte...
For mere information om, hvordan man opretter og forbinder OpenShift-virtualiserings-VBer til netværket, kan man . Derudover, , der implementeres som en del af OpenShift-virtualiseringen, tilbyder endnu en velkendt måde at oprette og administrere netværkskonfigurationer på fysiske noder, der bruges af hypervisorer.
Lagring
Tilslutning og administration af diske til virtuelle maskiner i OpenShift-virtualisering udføres ved hjælp af Kubernetes-koncepter som StorageClasses, PersistentVolumeClaims (PVC) og PersistentVolume (PV), samt standardlagringsprotokoller for Kubernetes-miljøet. På denne måde får Kubernetes-administratorer og app-teamene et ensartet og velkendt mekanisme til at administrere både containere og virtuelle maskiner. For mange administratorer af virtualiseringsmiljøer kan dette koncept virke genkendeligt, da det anvender den samme opdeling af konfigurationsfiler for VM'er og diske, som anvendes i OpenStack og mange andre cloud-platforme.
Men man kan ikke bare oprette en ny disk til VM'er hver gang, da vi skal bevare data under migrationen fra hypervisor til OpenShift. Selv når vi implementerer en ny VM, er det altid hurtigere at gøre det fra en skabelon end at oprette den fra bunden. Derfor har vi brug for funktionalitet til at importere eksisterende diske.
For at forenkle denne opgave implementerer OpenShift-virtualisering projektet Containerized Data Importer (CDI), som reducerer importen af diskbilleder fra flere kilder til at oprette en post i 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
Det er netop denne post, der aktiverer CDI og starter sekvensen af handlinger vist på billedet nedenfor:
Når CDI har bearbejdet, vil PVC indeholde en disk til den virtuelle maskine, klar til brug og konverteret til det standardformat, OpenShift anvender…
Når man arbejder med OpenShift-virtualisering, vil OpenShift Container Storage (OCS) også være nyttigt, en Red Hat-løsning baseret på filsystemet Ceph, som implementerer funktionaliteten for vedholdende lagring til containere. Ud over standard PVC-adgangsmetoderne – RWO (blok) og RWX (fil) – tilbyder OCS RWX til rå blokdevices, hvilket er meget nyttigt til at organisere delt blokadgang for applikationer med høje præstationskrav. Desuden understøtter OCS den nye standard for forespørgsler i objektgrupper kaldet Object Bucket Claim, som giver applikationer mulighed for direkte at bruge objektsystemet til datalagring.
Virtuelle maskiner i containere
Hvis du er interesseret i at se, hvordan det fungerer, så skal du vide, at OpenShift virtualisering allerede er tilgængelig i Tech Preview-versionen som en del af OpenShift 3.11 og højere. Ejere af et aktivt abonnement på OpenShift kan benytte OpenShift virtualisering helt gratis og uden yderligere besvær. På tidspunktet for udgivelsen af dette indlæg er OpenShift 4.4 og OpenShift virtualisering 2.3 de aktuelle versioner. Hvis du bruger tidligere versioner, er det en god idé at opgradere for at få de nyeste funktioner. Den fuldt understøttede version af OpenShift virtualisering forventes at blive lanceret i andet halvår af 2020.
For yderligere information, kontakt for installationsvejledninger, herunder , hvor oplysninger om opsætning af eksterne netværk findes.
Kilde: habr.com
