OpenShift virtualisering: containere, KVM og virtuelle maskiner

OpenShift-virtualisering (oppstrømsprosjekt – Kubernetes: KubeVirt, se. her og her), tidligere kjent som Container-native Virtualization, ble presentert som en funksjon i OpenShift-plattformen, som er beregnet for distribusjon og administrasjon av virtuelle maskiner (VM), som grunnleggende enheter i Kubernetes. Denne typen oppgave er teknisk krevende, på grunn av de fundamentale forskjellene i teknologiene. For å oppnå dette målet, ble kjente teknologier basert på Red Hat Enterprise Linux og KVM brukt, som vi har hatt i mange år og som har vist seg effektive.

I denne artikkelen vil vi se på de tekniske aspektene ved OpenShift-virtualisering som muliggjør sameksistens av VM-er og containere innenfor en enkelt plattform som administrerer dem som en helhet.

Beregningsoppgaver

Containere bruker mekanismer fra Linux-kjernen, som namespaces og cgroups, for å isolere prosesser og administrere ressurser. Vanligvis refererer prosesser til applikasjoner som Python, Java eller kjørbare filer, men i realiteten kan det være hvilke som helst prosesser, den samme bash, Emacs eller vim.

Hva er en virtuell maskin? Fra hypervisorens perspektiv er det også en prosess. Men ikke en applikasjonsprosess, men en KVM-prosess som er ansvarlig for å kjøre en bestemt VM.

Container-bildet inneholder alle verktøyene, bibliotekene og filene som er nødvendige for en KVM-virtuell maskin. Hvis vi undersøker pod-en til en kjørende VM, vil vi se hjelpetjenester og prosesser som qemu-kvm. 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 underlegges de samme reglene og kriteriene for planleggeren som normale poder, for eksempel taints, tolerations, affinity og anti-affinity. Du får også fordeler som høy tilgjengelighet osv. Men det er ett viktig skille: normale poder migrerer ikke fra vert til vert i den forstand vi kjenner. Hvis en node slås av, blir pod-en på den avbrutt og tilordnet en annen node i klyngen. I tilfelle av en virtuell maskin forventer vi å se levende migrasjon.

For å løse dette problemet ble en tilpasset ressursdefinisjon (CDR) opprettet, som beskriver mekanismen for levende migrasjon, som er ansvarlig for initiering, overvåking og administrasjon av levende migrasjoner av VM-er mellom arbeidsnoder.

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

Når en node deaktiveres, opprettes det automatisk migrasjonsjobber for de virtuelle maskinene som har Live Migration som evakueringsstrategi. Dette gjør det mulig å kontrollere oppførselen til virtuelle maskiner når de flyttes mellom nodene i klyngen. Du kan både konfigurere Live Migration og administrere VM-er, akkurat som med alle andre pod-er.

Nettverk

Enhver Kubernetes-system sikrer kommunikasjon mellom noder og pod-er ved hjelp av programvarebaserte SDN-nettverk. OpenShift er ikke noe unntak og bruker fra og med versjon 3 OpenShiftSDN som standard for dette formålet. I tillegg har OpenShift 4 fått en ny funksjon kalt Multus, som gjør det mulig å tilgjengeliggjøre flere nettverk og koble pod-er til dem samtidig.

Ved hjelp av Multus kan administratoren spesifisere ekstra CNI-nettverk, som deretter distribueres og konfigureres i klyngen av den spesielle Cluster Network Operator. Deretter kan pod-er kobles til ett eller flere av disse nettverkene, vanligvis det standard OpenShiftSDN og et ekstra grensesnitt. SR-IOV-enheter, standard Linux Bridge, MACVLAN og IPVLAN-enheter kan også brukes hvis det er nødvendig for din VM. Nedenfor er et bilde som viser hvordan man angir Multus CNI for bridge-nettverket på grensesnittet 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 gjelder OpenShift-virtualisering, betyr dette at VM-en kan kobles direkte til et eksternt nettverk, omgå SDN. Dette er viktig for virtuelle maskiner som er overført til OpenShift fra Red Hat Virtualization eller VMware vSphere, ettersom endringer i nettverksinnstillinger ikke vil skje med tilgang på lag 2 OSI. Dette betyr også at VM-en kan ha en nettverksadresse som omgår SDN. Dermed kan vi effektivt bruke spesialiserte nettverksadaptere, eller koble til SAN direkte...

For mer informasjon om hvordan du oppretter og kobler virtuelle maskiner fra OpenShift-virtualisering til nettverket, kan du her. I tillegg, nmstate operator, som distribueres som en del av OpenShift-virtualisering, tilbyr en annen godt kjent metode for å opprette og administrere nettverkskonfigurasjoner på fysiske noder som brukes av hypervisorer.

Lagring

Tilkopling og håndtering av disker for virtuelle maskiner i OpenShift-virtualisering skjer ved bruk av Kubernetes-konsepter som StorageClasses, PersistentVolumeClaims (PVC) og PersistentVolume (PV), samt standard lagringsprotokoller for Kubernetes-miljøet. På denne måten får Kubernetes-administratorer og applikasjonsteam en enhetlig og kjent mekanisme for å administrere både containere og virtuelle maskiner. For mange administratorer av virtualiseringsmiljøer kan dette konseptet virke kjent, siden det bruker samme prinsipp for separasjon av konfigurasjonsfiler for VM-er og disker, som brukes i OpenStack og mange andre skyplattformer.

Imidlertid kan man ikke bare opprette en ny disk for VM-en hver gang, ettersom vi ved migrering fra hypervisor til OpenShift må bevare dataene. Selv når vi ruller ut en ny VM, er det alltid raskere å gjøre det fra en mal enn å starte fra bunnen av. Dermed trenger vi funksjonalitet for import av eksisterende disker.

For å forenkle denne oppgaven ruller OpenShift-virtualisering ut prosjektet Containerized Data Importer (CDI), som forenkler import av diskbilder fra flere kilder ned til å opprette 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

Akkurat denne posten aktiverer CDI, og starter sekvensen av handlinger som er vist i figuren nedenfor:

Når CDI har kjørt, vil PVC inneholde en virtuell maskindisk som er klar til bruk og formatert til standard OpenShift-format…
Når man jobber med OpenShift-virtualisering, vil OpenShift Container Storage (OCS) også være nyttig, en løsning fra Red Hat basert på Ceph-filsystemet som implementerer funksjonalitet for vedvarende lagring for containere. I tillegg til de standard PVC-adgangsmetodene – RWO (blokk) og RWX (fil) – gir OCS RWX for rå blokkenheter, noe som er svært nyttig for å organisere delt blokktilgang for applikasjoner med høye ytelseskrav. Videre støtter OCS den nye standardsøkningen for objektgruppe, Object Bucket Claim, som lar applikasjoner bruke objektlagringsløsninger direkte.

Virtuelle maskiner i containere

Hvis du er interessert i å sjekke hvordan dette fungerer, så vit at OpenShift virtualization allerede er tilgjengelig i Tech Preview som en del av OpenShift 3.11 og nyere. Eierne av en aktiv OpenShift-abonnementsplan kan bruke OpenShift virtualization helt gratis og uten noen ekstra tiltak. På tidspunktet for publiseringen av dette innlegget er OpenShift 4.4 og OpenShift virtualization 2.3 aktuelle versjoner; hvis du bruker tidligere versjoner, er det verdt å oppdatere for å få de nyeste funksjonene. Den fullstendig støttede versjonen av OpenShift virtualization forventes å bli lansert i andre halvdel av 2020.

For mer informasjon, kontakt dokumentasjonen for OpenShift for installasjonsinstruksjoner, inkludert delen om konfigurering av Multus, som gir informasjon om konfigurasjon av eksterne nettverk.

Kilde: habr.com