OpenShift virtualisatie: containers, KVM en virtuele machines

OpenShift-virtualisatie (de upstream-project – Kubernetes: KubeVirt, zie hier en hier), voorheen Container-native Virtualization, werd gepresenteerd als functionaliteit van het OpenShift-platform, dat is ontworpen voor het implementeren en beheren van virtuele machines (VM's) als basisentiteiten van Kubernetes. Deze taak is technisch complex vanwege de fundamentele verschillen in technologieën. Om het doel te bereiken, werden vertrouwde technologieën op basis van Red Hat Enterprise Linux en KVM gebruikt, die al jarenlang effectief zijn gebleken.

In dit artikel zullen we de technische aspecten van OpenShift-virtualisatie bekijken die de coexistentie van VM's en containers binnen één platform mogelijk maken, dat hen als één geheel beheert.

Computertaken

Containers gebruiken mechanismen van de Linux-kernel, zoals namespaces en cgroups, voor procesisolatie en bronbeheer. Gewoonlijk worden processen begrepen als applicaties zoals Python, Java of uitvoerbare bestanden, maar in werkelijkheid kunnen dit elk proces zijn, zoals bash, Emacs of vim.

En wat is een virtuele machine? Vanuit het perspectief van de hypervisor is dit ook een proces. Maar niet een toepassingsproces, maar een KVM-proces dat verantwoordelijk is voor de uitvoering van een specifieke VM.

Een containerafbeelding bevat alle tools, bibliotheken en bestanden die nodig zijn voor de KVM-virtuele machine. Als we een pod van een werkende VM inspecteren, zien we daar helpers en processen van qemu-kvm. Bovendien hebben we toegang tot KVM-tools voor het beheren van virtuele machines, zoals qemu-img, qemu-nbd en virsh.

Aangezien een virtuele machine een pod is, erft deze automatisch alle functionaliteit van een pod in Kubernetes. De VM-pods zijn net als gewone pods onderhevig aan schema’s en planningscriteria zoals taints, tolerances, affiniteit en anti-affiniteit. Ook profiteert u van voordelen zoals hoge beschikbaarheid, enzovoort. Echter, er is één belangrijke afwijking: gewone pods migreren niet van host naar host in de gebruikelijke zin. Als een knooppunt uitvalt, wordt de pod daarop onderbroken en opnieuw toegewezen aan een ander knooppunt in het cluster. In het geval van een virtuele machine verwachten we een live migratie te zien.

Om dit gat te dichten, is er een custom resource definition (CDR) ontwikkeld die het mechanisme voor live migratie beschrijft en verantwoordelijk is voor de initialisatie, monitoring en beheer van live migraties van VM's tussen werkknopen.

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

Bij het deactiveren van een node worden automatisch migratietaken aangemaakt voor die virtuele machines waarvan de evacuatiestrategie Live Migration is. Zo kunt u het gedrag van virtuele machines controleren bij het verplaatsen tussen nodes in het cluster. U kunt zowel Live Migration instellen als VM's beheren, net als alle andere pods.

Netwerk

Elke Kubernetes-systeem zorgt voor communicatie tussen nodes en pods via softwarematige SDN-netwerken. OpenShift vormt hierop geen uitzondering en gebruikt vanaf versie 3 standaard OpenShiftSDN hiervoor. Bovendien is er in OpenShift 4 een nieuwe functie toegevoegd, genaamd Multus, die het mogelijk maakt om meerdere netwerken beschikbaar te stellen en pods tegelijkertijd aan te sluiten.

Met Multus kan de beheerder extra CNI-netwerken definiëren die vervolgens door de speciale Cluster Network Operator in het cluster worden uitgerold en geconfigureerd. Daarna worden pods aangesloten op een of meerdere van deze netwerken, meestal op het standaard OpenShiftSDN en een extra interface. Apparaten zoals SR-IOV, standaard Linux Bridge, MACVLAN en IPVLAN kunnen ook worden gebruikt indien nodig door uw VM. Hieronder ziet u hoe u Multus CNI voor bridge-netwerken op de interface eth1 instelt:

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

Wat betreft OpenShift-virtualisatie betekent dit dat VM's rechtstreeks op het externe netwerk kunnen worden aangesloten, zonder dat SDN hierbij betrokken is. Dit is belangrijk voor virtuele machines die zijn overgezet naar OpenShift vanuit Red Hat Virtualization of VMware vSphere, omdat er bij toegang op de tweede laag van OSI geen wijziging van netwerkinstellingen zal plaatsvinden. Dit betekent ook dat VM's een netwerkadres kunnen hebben waarover toegang mogelijk is, zonder dat SDN erbij betrokken is. Zo kunnen we gespecialiseerde netwerkaansluitingen effectief gebruiken of rechtstreeks verbinding maken met opslagnetwerken...

U kunt meer lezen over het maken en aansluiten van virtuele machines voor OpenShift-virtualisatie op het netwerk. hier. Daarnaast nmstate operator, dat wordt uitgerold als onderdeel van OpenShift-virtualisatie, biedt nog een goed bekende manier om netwerkinstellingen op fysieke nodes die onder hypervisors functioneren te maken en te beheren.

Opslag

Het aansluiten en beheren van schijven van virtuele machines binnen OpenShift virtualization gebeurt met behulp van Kubernetes-concepten zoals StorageClasses, PersistentVolumeClaims (PVC) en PersistentVolume (PV), evenals de standaard opslagprotocollen die in de Kubernetes-omgeving worden gebruikt. Op deze manier krijgen Kubernetes-beheerders en de teams die verantwoordelijk zijn voor applicaties een uniforme en vertrouwde manier van beheer, zowel voor containers als voor virtuele machines. Voor veel beheerders van virtualisatieomgevingen kan dit concept bekend voorkomen, omdat het hetzelfde principe van scheiding van configuratiebestanden van VM's en schijven gebruikt dat ook in OpenStack en veel andere cloudplatforms wordt toegepast.

Echter, het is niet mogelijk om telkens een nieuwe schijf voor de VM te creëren, aangezien we bij migratie van de hypervisor naar OpenShift de gegevens moeten behouden. Zelfs als we een nieuwe VM opzetten, is het altijd sneller om dit vanuit een sjabloon te doen dan helemaal opnieuw te beginnen. Daarom hebben we functionaliteit nodig voor het importeren van bestaande schijven.

Om deze taak te vereenvoudigen, implementeert OpenShift virtualization het project Containerized Data Importer (CDI), dat de import van schijfimage-bestanden uit meerdere bronnen reduceert tot het creëren van een record in een 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

Dit record activeert CDI en start de reeks acties die hieronder in de afbeelding zijn weergegeven:

Nadat CDI is verwerkt, zal de PVC een schijf van de virtuele machine bevatten die klaar is voor gebruik en omgezet in het standaard OpenShift-formaat...
Bij het werken met OpenShift virtualization is ook OpenShift Container Storage (OCS) van nut, een oplossing van Red Hat gebaseerd op het Ceph-bestandssysteem, die permanente opslagfunctionaliteit voor containers implementeert. Naast de standaard toegangsmethoden van PVC - RWO (block) en RWX (filesystem) - biedt OCS RWX voor raw block-apparaten, wat zeer nuttig is voor het organiseren van gedeelde block-toegang voor applicaties met hoge prestatie-eisen. Daarnaast ondersteunt OCS de nieuwe standaard voor het aanvragen van objectgroepen, Object Bucket Claim, waardoor applicaties direct gebruik kunnen maken van object storage.

Virtuele machines in containers

Als u geïnteresseerd bent om te controleren hoe dit werkt, weet dan dat OpenShift-virtualisatie al beschikbaar is in de Tech Preview-uitvoering als onderdeel van OpenShift 3.11 en hoger. Eigenaren van een actieve OpenShift-abonnement kunnen volledig gratis gebruikmaken van OpenShift-virtualisatie zonder enige extra moeite. Op het moment van publicatie van dit bericht zijn OpenShift 4.4 en OpenShift-virtualisatie 2.3 de huidige versies; als u eerdere versies gebruikt, is het aan te raden te upgraden om de nieuwste functies te verkrijgen. De volledig ondersteunde versie van OpenShift-virtualisatie zou in de tweede helft van 2020 moeten uitkomen.

Voor meer informatie kunt u de documentatie over OpenShift raadplegen voor installatie-instructies, inclusief de sectie over Multus-configuratie, waar informatie over het configureren van externe netwerken wordt verstrekt.

Bron: habr.com