OpenShift-virtualisering (upstream-projekt - Kubernetes: KubeVirt, se. и ), nej Container-native Virtualization, blev introduceret som en funktionalitet af OpenShift-platformen, som er designet til at implementere og administrere virtuelle maskiner (VM'er) som grundlæggende Kubernetes-enheder. Denne form for opgave er teknisk udfordrende på grund af fundamentale forskelle i teknologi. For at nå dette mål brugte vi velkendte teknologier baseret på Red Hat Enterprise Linux og KVM, som har været med os i mange år og har bevist deres effektivitet.
I denne artikel vil vi se på de tekniske aspekter af OpenShift-virtualisering, der gør det muligt for VM'er og containere at sameksistere inden for en enkelt platform, der administrerer dem som en enkelt enhed.
Beregningsmæssige opgaver
Containere bruger Linux-kernemekanismer såsom navnerum og cgroups til at isolere processer og administrere ressourcer. Normalt forstås processer som Python, Java-applikationer eller eksekverbare filer, men faktisk kan de være alle processer, såsom bash, Emacs eller vim.
Hvad er en virtuel maskine? Set fra hypervisors synspunkt er dette også en proces. Men ikke ansøgningsprocessen, men KVM-processen, der er ansvarlig for at udføre en specifik VM.
Containerbilledet indeholder alle de værktøjer, biblioteker og filer, der er nødvendige for den virtuelle KVM-maskine. Hvis vi inspicerer poden på en kørende VM, vil vi se der hjælpere og qemu-kvm processer. Derudover har vi adgang til KVM-værktøjer til styring af virtuelle maskiner såsom qemu-img, qemu-nbd og virsh.
Da en virtuel maskine er en pod, arver den automatisk al funktionaliteten af en pod i Kubernetes. VM-pods, ligesom almindelige pods, er underlagt planlægningsskemaer og -kriterier som f.eks. taints, tolerationer, affinitet og anti-affinitet. Du får også fordelene ved høj tilgængelighed mv. Der er dog én vigtig forskel: almindelige bælg migrerer ikke fra vært til vært i sædvanlig forstand. Hvis en node går offline, afsluttes poden på den og omtildeles til en anden node i klyngen. Og i tilfælde af en virtuel maskine, forventer vi at se live migration.
For at løse dette hul blev der oprettet en brugerdefineret ressourcedefinition (CDR) for at beskrive den live-migreringsmekanisme, der er ansvarlig for initialisering, overvågning og styring af live-migreringer af VM'er mellem arbejdsknudepunkter.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Når en node er deaktiveret, oprettes migreringsopgaver automatisk for de virtuelle maskiner, der har Live Migration indstillet som deres udsættelsesstrategi. På denne måde kan du kontrollere adfærden af virtuelle maskiner, når du bevæger dig mellem klynge noder. Du kan både konfigurere Live Migration og administrere VM'en, ligesom alle andre pods.
netværk
Ethvert Kubernetes-system giver kommunikation mellem noder og pods ved hjælp af software SDN-netværk. OpenShift er ingen undtagelse, og fra version 3, bruger OpenShiftSDN som standard til dette. Derudover har OpenShift 4 en anden ny funktion kaldet Multus, som giver dig mulighed for at gøre flere netværk tilgængelige og forbinde pods til dem samtidigt.
Ved hjælp af Multus kan administratoren definere yderligere CNI-netværk, som derefter vil blive implementeret og konfigureret på klyngen af en speciel Cluster Network Operator. Pod'erne er derefter forbundet til et eller flere af disse netværk, normalt standard OpenShiftSDN og en ekstra grænseflade. SR-IOV enheder, standard Linux Bridge, MACVLAN og IPVLAN enheder kan alle bruges, hvis din VM har brug for det. Figuren nedenfor viser, hvordan du indstiller Multus CNI for bronetværket på eth1-grænsefladen:
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 det, at en VM kan tilsluttes et eksternt netværk direkte uden om SDN. Dette er vigtigt for virtuelle maskiner migreret til OpenShift fra Red Hat Virtualization eller VMware vSphere, da hvis du har adgang til det andet OSI-lag, vil der ikke være nogen ændring i netværksindstillingerne. Dette betyder også, at VM'en kan have en netværksadresse, der omgår SDN. Således kan vi effektivt bruge specialiserede netværksadaptere eller oprette forbindelse direkte til lagersystemet over netværket...
Du kan lære mere om, hvordan du opretter og forbinder virtuelle OpenShift-virtualiseringsmaskiner til netværket . Derudover , implementeret som en del af OpenShift-virtualisering, tilbyder en anden velkendt måde at oprette og administrere netværkskonfigurationer på fysiske noder, der bruges under hypervisorer.
Opbevaring
Tilslutning og styring af virtuelle maskindiske inden for OpenShift-virtualisering udføres ved hjælp af Kubernetes-koncepter såsom StorageClasses, PersistentVolumeClaims (PVC) og PersistentVolume (PV), samt lagerprotokoller standard for Kubernetes-miljøet. Dette giver Kubernetes-administratorer og applikationsteams en fælles, velkendt måde at administrere både containere og virtuelle maskiner på. Og for mange administratorer af virtualiseringsmiljøer lyder dette koncept måske bekendt, fordi det bruger det samme princip for adskillelse af VM-konfigurationsfiler og diske, som bruges i OpenStack og mange andre cloud-platforme.
Vi kan dog ikke bare oprette en ny disk til VM'en hver gang, da vi skal gemme dataene, når vi migrerer fra hypervisoren til OpenShift. Ja, selv når vi implementerer en ny VM, er det altid hurtigere at gøre det fra en skabelon end at oprette det 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 import af diskbilleder af diske fra flere kilder til at oprette en PVC-indgang.
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 denne post, der aktiverer CDI, der udløser rækkefølgen af handlinger vist i figuren nedenfor:
Efter CDI'en er afsluttet, vil PVC'en indeholde den virtuelle maskindisk klar til brug og konverteret til standard OpenShift-format...
Når du arbejder med OpenShift-virtualisering, er OpenShift Container Storage (OCS), en Red Hat-løsning baseret på Ceph-filsystemet, der implementerer persistent storage-funktionalitet til containere, også nyttig. Ud over standard PVC-adgangsmetoderne - RWO (blok) og RWX (fil) - leverer OCS RWX til råblokenheder, hvilket er meget nyttigt til at dele blokadgang til applikationer med høje ydeevnekrav. Derudover understøtter OCS den nye Object Bucket Claim-standard, som giver applikationer mulighed for direkte at bruge objektdatalagring.
Virtuelle maskiner i containere
Hvis du er interesseret i at tjekke, hvordan det fungerer, så ved, at OpenShift-virtualisering allerede er tilgængelig i Tech Preview-versionen som en del af OpenShift 3.11 og nyere. Ejere af et eksisterende OpenShift-abonnement kan bruge OpenShift-virtualisering helt gratis og uden yderligere trin. På tidspunktet for dette indlæg er OpenShift 4.4 og OpenShift virtualisering 2.3 aktuelle; hvis du bruger tidligere versioner, bør du opgradere for at få de nyeste funktioner. En fuldt understøttet version af OpenShift-virtualisering bør frigives i anden halvdel af 2020.
For mere information henvises til til monteringsvejledning, herunder , som giver information om opsætning af eksterne netværk.
Kilde: www.habr.com