OpenShift virtualization (proiect upstream - Kubernetes: KubeVirt, vezi. și ), cunoscut anterior sub numele de Container-native Virtualization, a fost introdus ca o caracteristică a platformei OpenShift, destinată pentru desfășurarea și gestionarea mașinilor virtuale (VM), ca entități de bază Kubernetes. Această sarcină este complexă din punct de vedere tehnic din cauza diferențelor fundamentale ale tehnologiilor. Pentru a atinge acest obiectiv, s-au folosit tehnologii deja cunoscute pe baza Red Hat Enterprise Linux și KVM, care sunt cu noi de mulți ani și și-au dovedit eficiența.
În acest articol, vom examina aspectele tehnice ale OpenShift virtualization, care permit coexistența VM-urilor și containerelor în cadrul aceleași platforme care le gestionează ca un întreg.
Sarcinile de calcul
Containerele folosesc mecanisme ale nucleului Linux, cum ar fi namespaces și cgroups, pentru a izola procesele și a gestiona resursele. De obicei, prin procese se înțeleg aplicații Python, Java sau fișiere executabile, dar în realitate pot fi orice procese, precum bash, Emacs sau vim.
Și ce este o mașină virtuală? Din perspectiva hypervisorului, este de asemenea un proces. Numai că nu este un proces de aplicație, ci un proces KVM, responsabil pentru executarea unei anumite VM.
Imaginea containerului conține toate instrumentele, bibliotecile și fișierele necesare pentru mașina virtuală KVM. Dacă inspectăm pod-ul unei VM în funcțiune, vom vedea acolo ajutoare și procese qemu-kvm. În plus, avem acces la instrumentele KVM pentru gestionarea mașinilor virtuale, cum ar fi qemu-img, qemu-nbd și virsh.
Deoarece mașina virtuală este un pod, ea moștenește automat toate funcționalitățile pod-ului din Kubernetes. La VM-pod-uri, la fel ca și la pod-urile obișnuite, se aplică schemele și criteriile scheduler-ului, cum ar fi taints, tolerations, affinity și anti-affinity. De asemenea, beneficiați de avantaje precum disponibilitatea ridicată etc. Totuși, există o diferență importantă: pod-urile obișnuite nu migrează de la un host la altul în sensul nostru obișnuit. Dacă un nod se oprește, pod-ul de pe acesta se întrerupe și este reapucat pe un alt nod din cluster. Iar în cazul unei mașini virtuale, ne așteptăm să vedem migrarea live.
Pentru a rezolva această problemă a fost creată o definiție de resursă personalizată (CDR) care descrie mecanismul migrației live, responsabil pentru inițializarea, monitorizarea și gestionarea migrațiilor live ale VM-urilor între nodurile de lucru.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Atunci când un nod este dezactivat, pentru mașinile virtuale ale căror strategii de evacuare sunt definite ca Live Migration, sarcini de migrare sunt create automat. Astfel, se poate controla comportamentul mașinilor virtuale atunci când acestea sunt mutate între nodurile cluster-ului. Puteți configura și administrarea Live Migration exact ca și celelalte pod-uri.
Rețea
Orice sistem Kubernetes asigură conectivitate între noduri și pod-uri prin intermediul rețelelor SDN software. OpenShift nu face excepție și, începând cu versiunea 3, utilizează în mod implicit OpenShiftSDN pentru acest scop. În plus, în OpenShift 4 a apărut o nouă funcționalitate numită Multus, care permite accesul la multiple rețele și conectarea simultană a pod-urilor la acestea.
Cu ajutorul Multus, administratorul poate defini rețele CNI suplimentare, care apoi vor fi desfășurate și configurate în cluster de către un operator special numit Cluster Network Operator. După aceasta, pod-urile se conectează la una sau mai multe dintre aceste rețele, de obicei la OpenShiftSDN standard și la o interfață suplimentară. Dispozitivele SR-IOV, podurile Linux standard, dispozitivele MACVLAN și IPVLAN pot fi utilizate, dacă este necesar pentru mașina dvs. virtuală. În imaginea de mai jos este arătat cum se definește CNI Multus pentru o rețea bridge pe interfața 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 contextul virtualizării OpenShift, aceasta înseamnă că mașinile virtuale pot fi conectate direct la o rețea externă, ocolind SDN-ul. Acest lucru este important pentru mașinile virtuale migrate pe OpenShift din Red Hat Virtualization sau VMware vSphere, deoarece în prezența accesului la nivelul 2 OSI, nu vor exista modificări ale setărilor de rețea. De asemenea, aceasta înseamnă că mașinile virtuale pot avea o adresă de rețea a cărei solicitări ocolesc SDN-ul. Astfel, putem folosi eficient adaptoare de rețea specializate sau ne putem conecta direct prin rețea la sistemele de stocare…
Pentru a afla mai multe despre cum să creați și să conectați mașinile virtuale OpenShift virtualization la rețea, puteți accesa . În plus, , desfășurat în cadrul OpenShift virtualization, oferă o altă modalitate bine cunoscută de a crea și gestiona configurațiile rețelei pe nodurile fizice utilizate de hypervizori.
Stocare
Conectarea și gestionarea discurilor mașinilor virtuale în cadrul virtualizării OpenShift se realizează folosind concepte Kubernetes precum StorageClasses, PersistentVolumeClaims (PVC) și PersistentVolume (PV), precum și protocoale de stocare standard pentru mediu Kubernetes. Astfel, administratorii Kubernetes și echipele responsabile de aplicații primesc un mecanism unic și obișnuit de gestionare atât pentru containere, cât și pentru mașini virtuale. De asemenea, pentru mulți administratori ai mediilor de virtualizare, acest concept poate părea familiar, deoarece folosește același principiu de împărțire a fișierelor de configurare ale VM-urilor și discurilor, aplicat în OpenStack și pe multe alte platforme cloud.
Cu toate acestea, nu putem crea pur și simplu un nou disc pentru VM de fiecare dată, deoarece în timpul migrației de la hipervizor la OpenShift, trebuie să păstrăm datele. Chiar și atunci când desfășurăm o nouă VM, este întotdeauna mai rapid să o facem dintr-un șablon decât să o creăm de la zero. Prin urmare, avem nevoie de funcționalitatea de importare a discurilor existente.
Pentru a simplifica această sarcină, virtualizarea OpenShift desfășoară proiectul Containerized Data Importer (CDI), care reduce importul imaginilor de disc din mai multe surse la crearea unei înregistrări în 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
Această înregistrare activează CDI, declanșând secvența de acțiuni prezentată în imaginea de mai jos:
După ce CDI finalizează procesul, PVC va conține un disc al mașinii virtuale gata de utilizare, adus în formatul standard pentru OpenShift…
Atunci când lucrați cu virtualizarea OpenShift, OpenShift Container Storage (OCS) va fi, de asemenea, util, o soluție Red Hat bazată pe sistemul de fișiere Ceph, care implementează funcționalitatea de stocare persistentă pentru containere. În plus față de metodele standard de acces PVC – RWO (bloc) și RWX (fișier) – OCS oferă RWX pentru dispozitive raw block, ceea ce este foarte util în organizarea accesului bloc comun pentru aplicații cu cerințe ridicate de performanță. În plus, OCS suportă noul standard de cerere a grupului de obiecte Object Bucket Claim, permițând aplicațiilor să utilizeze direct stocarea de obiecte.
Mașini virtuale în containere
Dacă sunteți curios să verificați cum funcționează, știți că virtualizarea OpenShift este deja disponibilă în variantă Tech Preview în cadrul OpenShift 3.11 și versiunile ulterioare. Proprietarii unei subscripții active la OpenShift pot beneficia de virtualizarea OpenShift complet gratuit și fără nicio acțiune suplimentară. La momentul publicării acestui post, versiunile relevante sunt OpenShift 4.4 și OpenShift virtualization 2.3; dacă utilizați versiuni anterioare, merită să faceți upgrade pentru a obține cele mai recente funcționalități. Versiunea complet suportată a virtualizării OpenShift ar trebui să fie lansată în a doua jumătate a anului 2020.
Pentru informații suplimentare, contactați pentru instrucțiuni de instalare, inclusiv , care oferă detalii despre configurarea rețelelor externe.
Sursa: habr.com
