OpenShift-virtualisatie (upstream-project - Kubernetes: KubeVirt, zie. и ), oftewel Container-native Virtualization, werd geïntroduceerd als een functionaliteit van het OpenShift-platform, dat is ontworpen voor het implementeren en beheren van virtuele machines (VM's) als standaard Kubernetes-entiteiten. Dit soort taken zijn technisch uitdagend vanwege fundamentele verschillen in technologie. Om dit doel te bereiken hebben we gebruik gemaakt van bekende technologieën gebaseerd op Red Hat Enterprise Linux en KVM, die al vele jaren bij ons zijn en hun effectiviteit hebben bewezen.
In dit artikel zullen we kijken naar de technische aspecten van OpenShift-virtualisatie die het mogelijk maken dat VM’s en containers naast elkaar bestaan binnen één platform dat ze als één entiteit beheert.
Computationele taken
Containers gebruiken Linux-kernelmechanismen zoals naamruimten en cgroups om processen te isoleren en bronnen te beheren. Meestal worden processen opgevat als Python, Java-applicaties of uitvoerbare bestanden, maar in feite kunnen dit alle processen zijn, zoals bash, Emacs of vim.
Wat is een virtuele machine? Vanuit het oogpunt van de hypervisor is dit ook een proces. Maar niet het aanvraagproces, maar het KVM-proces dat verantwoordelijk is voor het uitvoeren van een specifieke VM.
De containerimage bevat alle tools, bibliotheken en bestanden die nodig zijn voor de virtuele KVM-machine. Als we de pod van een actieve VM inspecteren, zullen we daar helpers en qemu-kvm-processen zien. Daarnaast hebben we toegang tot KVM-tools voor het beheren van virtuele machines zoals qemu-img, qemu-nbd en virsh.
Omdat een virtuele machine een pod is, neemt deze automatisch alle functionaliteit van een pod in Kubernetes over. VM-pods zijn, net als gewone pods, onderworpen aan planningsschema's en criteria zoals taints, toleranties, affiniteit en anti-affiniteit. U profiteert ook van de voordelen van hoge beschikbaarheid, enz. Er is echter één belangrijk verschil: gewone peulen migreren niet in de gebruikelijke zin van gastheer naar gastheer. Als een knooppunt offline gaat, wordt de pod daarop beëindigd en opnieuw toegewezen aan een ander knooppunt in het cluster. En in het geval van een virtuele machine verwachten we live migratie.
Om deze kloof te dichten, is er een aangepaste resourcedefinitie (CDR) gemaakt om het live-migratiemechanisme te beschrijven dat verantwoordelijk is voor het initialiseren, monitoren en beheren van live-migraties van VM's tussen werkknooppunten.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Wanneer een knooppunt wordt gedeactiveerd, worden er automatisch migratietaken gemaakt voor de virtuele machines waarvoor Live Migration is ingesteld als uitzettingsstrategie. Op deze manier kunt u het gedrag van virtuele machines controleren bij het verplaatsen tussen clusterknooppunten. U kunt zowel Live Migration configureren als de VM beheren, net als alle andere pods.
Сеть
Elk Kubernetes-systeem biedt communicatie tussen knooppunten en pods met behulp van software-SDN-netwerken. OpenShift is hierop geen uitzondering en gebruikt hiervoor vanaf versie 3 standaard OpenShiftSDN. Daarnaast heeft OpenShift 4 nog een nieuwe functie genaamd Multus, waarmee je meerdere netwerken beschikbaar kunt maken en er tegelijkertijd pods op kunt aansluiten.
Met Multus kan de beheerder aanvullende CNI-netwerken definiëren, die vervolgens door een speciale Cluster Network Operator op het cluster worden geïmplementeerd en geconfigureerd. De pods worden vervolgens verbonden met een of meer van deze netwerken, meestal de standaard OpenShiftSDN en een extra interface. SR-IOV-apparaten, standaard Linux Bridge-, MACVLAN- en IPVLAN-apparaten kunnen allemaal worden gebruikt als uw VM dit nodig heeft. De onderstaande afbeelding laat zien hoe u Multus CNI instelt voor het bridge-netwerk op de eth1-interface:
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
In relatie tot OpenShift-virtualisatie betekent dit dat een VM rechtstreeks op een extern netwerk kan worden aangesloten, zonder SDN te omzeilen. Dit is belangrijk voor virtuele machines die vanuit Red Hat Virtualization of VMware vSphere naar OpenShift zijn gemigreerd, omdat er geen verandering in de netwerkinstellingen zal optreden als u toegang heeft tot de tweede OSI-laag. Dit betekent ook dat de VM mogelijk een netwerkadres heeft dat SDN omzeilt. We kunnen dus effectief gespecialiseerde netwerkadapters gebruiken, of rechtstreeks verbinding maken met het opslagsysteem via het netwerk...
U kunt meer leren over het maken en verbinden van virtuele OpenShift-virtualisatiemachines met het netwerk . Bovendien , ingezet als onderdeel van OpenShift-virtualisatie, biedt een andere vertrouwde manier om netwerkconfiguraties te creëren en te beheren op fysieke knooppunten die onder hypervisors worden gebruikt.
opslagruimte
Het verbinden en beheren van virtuele machineschijven binnen OpenShift-virtualisatie wordt uitgevoerd met behulp van Kubernetes-concepten zoals StorageClasses, PersistentVolumeClaims (PVC) en PersistentVolume (PV), evenals opslagprotocollen die standaard zijn voor de Kubernetes-omgeving. Dit geeft Kubernetes-beheerders en applicatieteams een gemeenschappelijke, vertrouwde manier om zowel containers als virtuele machines te beheren. En voor veel beheerders van virtualisatieomgevingen klinkt dit concept misschien bekend omdat het hetzelfde principe van het scheiden van VM-configuratiebestanden en -schijven gebruikt dat wordt gebruikt in OpenStack en veel andere cloudplatforms.
We kunnen echter niet zomaar elke keer een nieuwe schijf voor de VM maken, omdat we bij de migratie van de hypervisor naar OpenShift de gegevens moeten opslaan. Ja, zelfs als we een nieuwe VM implementeren, is het altijd sneller om dit vanuit een sjabloon te doen dan om deze helemaal opnieuw te maken. We hebben dus functionaliteit nodig voor het importeren van bestaande schijven.
Om deze taak te vereenvoudigen, maakt OpenShift-virtualisatie gebruik van het Containerized Data Importer (CDI)-project, dat het importeren van schijfkopieën van schijven uit meerdere bronnen reduceert tot het maken van een PVC-invoer.
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
Het is deze invoer die CDI activeert en de reeks acties activeert die in de onderstaande afbeelding worden weergegeven:
Nadat de CDI is voltooid, bevat de PVC de virtuele machineschijf, klaar voor gebruik en geconverteerd naar het standaard OpenShift-formaat...
Bij het werken met OpenShift-virtualisatie is OpenShift Container Storage (OCS), een Red Hat-oplossing gebaseerd op het Ceph-bestandssysteem dat persistente opslagfunctionaliteit voor containers implementeert, ook nuttig. Naast de standaard PVC-toegangsmethoden - RWO (blok) en RWX (bestand) - biedt OCS RWX voor onbewerkte blokapparaten, wat erg handig is voor het delen van bloktoegang voor toepassingen met hoge prestatie-eisen. Daarnaast ondersteunt OCS de nieuwe Object Bucket Claim-standaard, waarmee applicaties direct gebruik kunnen maken van objectgegevensopslag.
Virtuele machines in containers
Als u wilt weten hoe het werkt, weet dan dat OpenShift-virtualisatie al beschikbaar is in de Tech Preview-versie als onderdeel van OpenShift 3.11 en hoger. Eigenaars van een bestaand OpenShift-abonnement kunnen volledig gratis en zonder extra stappen gebruik maken van OpenShift-virtualisatie. Op het moment van publicatie van dit bericht zijn OpenShift 4.4 en OpenShift virtualisatie 2.3 actueel; als u eerdere versies gebruikt, moet u upgraden om de nieuwste functies te krijgen. Een volledig ondersteunde versie van OpenShift-virtualisatie zou in de tweede helft van 2020 moeten verschijnen.
Voor meer informatie kunt u contact opnemen met voor installatie-instructies, inclusief , dat informatie biedt over het opzetten van externe netwerken.
Bron: www.habr.com