OpenShift-virtualisering: containere, KVM og virtuelle maskiner

OpenShift-virtualisering (oppstrømsprosjekt - Kubernetes: KubeVirt, se. her и her), nee Container-native Virtualization, ble introdusert som en funksjonalitet i OpenShift-plattformen, som er designet for å distribuere og administrere virtuelle maskiner (VM-er) som grunnleggende Kubernetes-enheter. Denne typen oppgave er teknisk utfordrende på grunn av grunnleggende forskjeller i teknologi. For å nå dette målet brukte vi kjente teknologier basert på Red Hat Enterprise Linux og KVM, som har vært med oss ​​i mange år og har bevist sin effektivitet.

I denne artikkelen vil vi se på de tekniske aspektene ved OpenShift-virtualisering som gjør det mulig for VM-er og containere å sameksistere innenfor en enkelt plattform som administrerer dem som en enkelt enhet.

Beregningsoppgaver

Containere bruker Linux-kjernemekanismer som navnerom og cgroups for å isolere prosesser og administrere ressurser. Vanligvis forstås prosesser som Python, Java-applikasjoner eller kjørbare filer, men faktisk kan de være alle prosesser, for eksempel bash, Emacs eller vim.

Hva er en virtuell maskin? Fra hypervisors synspunkt er dette også en prosess. Men ikke søknadsprosessen, men KVM-prosessen som er ansvarlig for å utføre en spesifikk VM.

Beholderbildet inneholder alle verktøyene, bibliotekene og filene som trengs for den virtuelle KVM-maskinen. Hvis vi inspiserer poden til en kjørende VM, vil vi se hjelpere og qemu-kvm-prosesser der. I tillegg har vi tilgang til KVM-verktøy for å administrere virtuelle maskiner som qemu-img, qemu-nbd og virsh.

Siden en virtuell maskin er en pod, arver den automatisk all funksjonaliteten til en pod i Kubernetes. VM-poder, akkurat som vanlige pods, er underlagt planleggingsskjemaer og kriterier som smuss, tolerasjoner, affinitet og anti-affinitet. Du får også fordelene med høy tilgjengelighet osv. Det er imidlertid én viktig forskjell: vanlige pods migrerer ikke fra vert til vert i vanlig forstand. Hvis en node går offline, avsluttes poden på den og tilordnes på nytt til en annen node i klyngen. Og når det gjelder en virtuell maskin, forventer vi å se live migrering.

For å løse dette gapet ble det opprettet en egendefinert ressursdefinisjon (CDR) for å beskrive den direkte migreringsmekanismen som er ansvarlig for å initialisere, overvåke og administrere live-migreringer av VM-er mellom arbeidernoder.

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

Når en node er deaktivert, opprettes migreringsoppgaver automatisk for de virtuelle maskinene som har satt Live Migration som utkastingsstrategi. På denne måten kan du kontrollere atferden til virtuelle maskiner når du beveger deg mellom klyngenoder. Du kan både konfigurere Live Migration og administrere VM-en, som alle andre poder.

nettverk

Ethvert Kubernetes-system gir kommunikasjon mellom noder og poder ved hjelp av programvare SDN-nettverk. OpenShift er intet unntak, og fra og med versjon 3 bruker OpenShiftSDN som standard for dette. I tillegg har OpenShift 4 en annen ny funksjon kalt Multus, som lar deg gjøre flere nettverk tilgjengelige og koble poder til dem samtidig.

Ved å bruke Multus kan administratoren definere ytterligere CNI-nettverk, som deretter vil bli distribuert og konfigurert på klyngen av en spesiell klyngenettverksoperatør. Podene kobles deretter til ett eller flere av disse nettverkene, vanligvis standard OpenShiftSDN og et ekstra grensesnitt. SR-IOV-enheter, standard Linux Bridge-, MACVLAN- og IPVLAN-enheter kan alle brukes hvis VM-en din trenger det. Figuren nedenfor viser hvordan du stiller inn Multus CNI for bronettverket på eth1-grensesnittet:

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 betyr dette at en VM kan kobles direkte til et eksternt nettverk, utenom SDN. Dette er viktig for virtuelle maskiner migrert til OpenShift fra Red Hat Virtualization eller VMware vSphere, siden hvis du har tilgang til det andre OSI-laget, vil det ikke være noen endring i nettverksinnstillingene. Dette betyr også at VM-en kan ha en nettverksadresse som omgår SDN. Dermed kan vi effektivt bruke spesialiserte nettverkskort, eller koble oss direkte til lagringssystemet over nettverket...

Du kan lære mer om hvordan du oppretter og kobler virtuelle OpenShift-virtualiseringsmaskiner til nettverket her. I tillegg, nmstate-operatør, distribuert som en del av OpenShift-virtualisering, tilbyr en annen kjent måte å opprette og administrere nettverkskonfigurasjoner på fysiske noder som brukes under hypervisorer.

lagring

Koble til og administrere virtuelle maskindisker innenfor OpenShift-virtualisering utføres ved hjelp av Kubernetes-konsepter som StorageClasses, PersistentVolumeClaims (PVC) og PersistentVolume (PV), samt lagringsprotokollstandard for Kubernetes-miljøet. Dette gir Kubernetes-administratorer og applikasjonsteam en vanlig, kjent måte å administrere både containere og virtuelle maskiner på. Og for mange administratorer av virtualiseringsmiljøer kan dette konseptet høres kjent ut fordi det bruker det samme prinsippet for å skille VM-konfigurasjonsfiler og disker som brukes i OpenStack og mange andre skyplattformer.

Vi kan imidlertid ikke bare lage en ny disk for VM hver gang, siden når vi migrerer fra hypervisoren til OpenShift, må vi lagre dataene. Ja, selv når vi distribuerer en ny VM, er det alltid raskere å gjøre det fra en mal enn å lage den fra bunnen av. Dermed trenger vi funksjonalitet for å importere eksisterende disker.

For å forenkle denne oppgaven, distribuerer OpenShift-virtualisering prosjektet Containerized Data Importer (CDI), som reduserer import av diskbilder av disker fra flere kilder til å lage en PVC-oppføring.

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 oppføringen som aktiverer CDI, og utløser handlingssekvensen vist i figuren nedenfor:

Etter at CDI er fullført, vil PVC inneholde den virtuelle maskindisken klar til bruk og konvertert til standard OpenShift-format...
Når du arbeider med OpenShift-virtualisering, er OpenShift Container Storage (OCS), en Red Hat-løsning basert på Ceph-filsystemet som implementerer vedvarende lagringsfunksjonalitet for containere, også nyttig. I tillegg til standard PVC-tilgangsmetodene - RWO (blokk) og RWX (fil) - tilbyr OCS RWX for råblokkenheter, noe som er veldig nyttig for å dele blokktilgang for applikasjoner med høye ytelseskrav. I tillegg støtter OCS den nye Object Bucket Claim-standarden, som lar applikasjoner bruke objektdatalagring direkte.

Virtuelle maskiner i containere

Hvis du er interessert i å sjekke hvordan det fungerer, så vet at OpenShift-virtualisering allerede er tilgjengelig i Tech Preview-versjonen som en del av OpenShift 3.11 og høyere. Eiere av et eksisterende OpenShift-abonnement kan bruke OpenShift-virtualisering helt gratis og uten ekstra trinn. På tidspunktet for dette innlegget er OpenShift 4.4 og OpenShift virtualisering 2.3 gjeldende; hvis du bruker tidligere versjoner, bør du oppgradere for å få de nyeste funksjonene. En fullt støttet versjon av OpenShift-virtualisering bør utgis i andre halvdel av 2020.

For mer informasjon vennligst kontakt OpenShift-dokumentasjon for monteringsanvisninger, inkludert Multioppsettseksjon, som gir informasjon om oppsett av eksterne nettverk.

Kilde: www.habr.com