OpenShift virtualisering: containrar, KVM och virtuella maskiner

OpenShift virtualisering (uppströmsprojekt – Kubernetes: KubeVirt, se. här och här), tidigare kallad Container-native Virtualization, presenterades som en funktionalitet inom OpenShift-plattformen, avsedd för att distribuera och hantera virtuella maskiner (VM) som grundläggande enheter i Kubernetes. Denna typ av uppgift är tekniskt komplex på grund av de fundamentala skillnaderna mellan teknologierna. För att uppnå det angivna målet har de välkända teknologierna baserade på Red Hat Enterprise Linux och KVM använts, vilka har varit med oss under många år och visat sin effektivitet.

I denna artikel kommer vi att undersöka de tekniska aspekterna av OpenShift virtualisering som möjliggör samexistens av VM och containrar inom en och samma plattform som hanterar dem som en enhet.

Beräkningsuppgifter

Containrar utnyttjar mekanismer i Linux-kärnan, såsom namespaces och cgroups, för processisolering och resursförvaltning. Vanligtvis förstås processer som applikationer som Python, Java eller körbara filer, men i själva verket kan det vara vilka processer som helst, samma bash, Emacs eller vim.

Vad är en virtuell maskin? Ur hypervisorns perspektiv är det också en process. Men inte en applikationsprocess, utan en KVM-process som ansvarar för att köra en specifik VM.

Containeravbildningen innehåller alla verktyg, bibliotek och filer som behövs för en KVM-virtuell maskin. Om vi inspekterar en pod av en aktiv VM kommer vi att se hjälpprogram och processer för qemu-kvm. Dessutom har vi tillgång till KVM-verktyg för att hantera virtuella maskiner, såsom qemu-img, qemu-nbd och virsh.

Eftersom en virtuell maskin är en pod, är den automatisktverkligadverkan av pod-funktionaliteten i Kubernetes. För VM-podder gäller på samma sätt som för vanliga podder scheman och kriterier för schemaläggning, såsom taints, tolerations, affinitet och anti-affinitet. Du får också fördelar som hög tillgänglighet osv. Det finns dock en viktig skillnad: vanliga poddar migrerar inte mellan värdar på det sätt som vi är vana vid. Om en nod stängs av, avbryts podden på den och omfördelas till en annan nod i klustret. Men när det gäller virtuella maskiner förväntar vi oss att se levande migration.

För att åtgärda denna brist skapades en anpassad resursdefinition (CDR) som beskriver mekanismen för levande migration, vilket ansvarar för initiering, övervakning och hantering av levande migrationer av VM mellan arbetsnoder.

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

Vid avaktivering av en nod för de virtuella maskiner vars evakueringsstrategi är Live Migration, skapas automatiskt migreringsuppgifter. På så sätt kan beteendet hos de virtuella maskinerna kontrolleras när de flyttas mellan noder i klustret. Du kan både konfigurera Live Migration och hantera VM, precis som med alla andra pods.

Nätverk

Alla Kubernetes-system tillhandahåller kommunikation mellan noder och poddar genom mjukvarubaserade SDN-nätverk. OpenShift är inget undantag och använder som standard OpenShiftSDN för detta från och med version 3. Dessutom har OpenShift 4 fått en ny funktion som heter Multus, som gör det möjligt att göra flera nätverk tillgängliga och koppla poddar till dem samtidigt.

Med Multus kan administratören ange ytterligare CNI-nätverk som sedan distribueras och konfigureras i klustret av den speciella Cluster Network Operator. Efter detta ansluts poddar till ett eller flera av dessa nätverk, vanligtvis till standard OpenShiftSDN och en extra gränssnitt. SR-IOV-enheter, standard Linux Bridge, MACVLAN- och IPVLAN-enheter – allt detta kan också användas om det behövs för din VM. Nedan visas hur man konfigurerar Multus CNI för bro-nätverket på gränssnittet 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

När det gäller OpenShift-virtualisering innebär detta att VM kan anslutas direkt till det externa nätverket, utan att gå via SDN. Detta är viktigt för virtuella maskiner som flyttats till OpenShift från Red Hat Virtualization eller VMware vSphere, eftersom det inte kommer att ske några ändringar i nätverksinställningarna med andra nivåns åtkomst på OSI-modellen. Detta innebär också att VM kan ha en nätverksadress som gör att åtkomsten sker utan att gå via SDN. På så sätt kan vi effektivt använda specialiserade nätverksadaptrar eller ansluta direkt till lagringssystemet...

För att lära dig mer om hur man skapar och ansluter virtuella maskiner i OpenShift-virtualisering till nätverket kan du här. Dessutom, nmstate operator, som distribueras som en del av OpenShift-virtualisering, erbjuder ytterligare ett välkänt sätt att skapa och hantera nätverkskonfigurationer på fysiska noder som används av hypervisorer.

Lagring

Anslutning och hantering av diskar för virtuella maskiner inom OpenShift virtualization sker med hjälp av Kubernetes-koncept som StorageClasses, PersistentVolumeClaims (PVC) och PersistentVolume (PV), samt de standardlagringsprotokoll som används i Kubernetes-miljöer. På så sätt får Kubernetes-administratörer och applikationsteam en enhetlig och välkänd mekanism för att hantera både containrar och virtuella maskiner. Många av administratörerna inom virtualiseringsmiljö kan också känna igen denna koncept, eftersom den använder samma princip för att separera konfigurationsfiler för VM och diskar, som tillämpas i OpenStack och många andra molnplattformar.

Men man kan inte bara skapa en ny disk för VM varje gång, eftersom vi vid migrering från hypervisor till OpenShift behöver bevara data. Även när vi sätter upp en ny VM är det alltid snabbare att skapa den från en mall än att börja från grunden. Därför behöver vi funktionalitet för att importera befintliga diskar.

För att förenkla denna uppgift implementerar OpenShift virtualization projektet Containerized Data Importer (CDI), som förenar import av diskbilder från flera källor genom att skapa 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 är just denna post som aktiverar CDI och startar sekvensen av åtgärder som visas i bilden nedan:

När CDI har fullföljt sin uppgift kommer PVC att innehålla en disk för den virtuella maskinen, redo att användas och i standardformatet för OpenShift…
När man arbetar med OpenShift virtualization är även OpenShift Container Storage (OCS) användbart, en lösning från Red Hat baserad på Ceph-filssystemet som implementerar funktionalitet för permanent lagring för containrar. Utöver de standard PVC-åtkomstmetoderna – RWO (block) och RWX (fil) – erbjuder OCS RWX för rå block, vilket är mycket användbart för att organisera delad blockåtkomst för applikationer med höga prestandakrav. Dessutom stöder OCS den nya standarden för objektgruppförfrågan, Object Bucket Claim, vilket tillåter applikationer att direkt använda objektlagring.

Virtuella maskiner i containrar

Om du är nyfiken på att se hur det fungerar, så vet att OpenShift-virtualisering redan finns tillgänglig i Tech Preview-version inom OpenShift 3.11 och högre. Ägare av en aktiv prenumeration på OpenShift kan använda OpenShift-virtualisering helt gratis och utan några ytterligare rörelser. Vid tidpunkten för publiceringen av detta inlägg är OpenShift 4.4 och OpenShift-virtualisering 2.3 aktuella; om du använder tidigare versioner, bör du uppgradera för att få de senaste funktionerna. Den fullt stödjda versionen av OpenShift-virtualisering beräknas släppas under andra halvan av 2020.

För mer information, vänligen kontakta dokumentationen för OpenShift för installationsanvisningar, inklusive avsnittet om Multus-konfiguration, där information om att konfigurera externa nätverk ges.

Källa: habr.com