Virtualizare OpenShift (proiect upstream - Kubernetes: KubeVirt, vezi. и ), denumit Container-native Virtualization, a fost introdusă ca o funcționalitate a platformei OpenShift, care este concepută pentru implementarea și gestionarea mașinilor virtuale (VM) ca entități Kubernetes de bază. Acest tip de sarcină este o provocare tehnic din cauza diferențelor fundamentale de tehnologie. Pentru a atinge acest obiectiv, am folosit tehnologii familiare bazate pe Red Hat Enterprise Linux și KVM, care ne sunt alături de mulți ani și și-au dovedit eficiența.
În acest articol, vom analiza aspectele tehnice ale virtualizării OpenShift care fac posibil ca VM-urile și containerele să coexiste într-o singură platformă care le gestionează ca o singură entitate.
Sarcini de calcul
Containerele folosesc mecanisme de nucleu Linux, cum ar fi spațiile de nume și cgroups, pentru a izola procesele și a gestiona resursele. De obicei, procesele sunt înțelese ca Python, aplicații Java sau fișiere executabile, dar de fapt pot fi orice procese, cum ar fi bash, Emacs sau vim.
Ce este o mașină virtuală? Din punctul de vedere al hypervisorului, acesta este tot un proces. Dar nu procesul de aplicare, ci procesul KVM responsabil pentru executarea unui anumit VM.
Imaginea containerului conține toate instrumentele, bibliotecile și fișierele necesare pentru mașina virtuală KVM. Dacă inspectăm podul unui VM care rulează, vom vedea acolo ajutoare și procese qemu-kvm. În plus, avem acces la instrumente KVM pentru gestionarea mașinilor virtuale, cum ar fi qemu-img, qemu-nbd și virsh.
Deoarece o mașină virtuală este un pod, moștenește automat toate funcționalitățile unui pod în Kubernetes. Podurile VM, la fel ca și podurile obișnuite, sunt supuse unor scheme și criterii de planificare, cum ar fi vicii, toleranțe, afinitate și anti-afinitate. De asemenea, beneficiați de disponibilitatea ridicată etc. Cu toate acestea, există o diferență importantă: păstăile obișnuite nu migrează de la gazdă la gazdă în sensul obișnuit. Dacă un nod este offline, podul de pe acesta este terminat și reatribuit unui alt nod din cluster. Și în cazul unei mașini virtuale, ne așteptăm să vedem o migrare live.
Pentru a aborda acest decalaj, a fost creată o definiție personalizată a resurselor (CDR) pentru a descrie mecanismul de migrare live care este responsabil pentru inițializarea, monitorizarea și gestionarea migrărilor live ale VM-urilor între nodurile de lucru.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Când un nod este dezactivat, sarcinile de migrare sunt create automat pentru acele mașini virtuale care au setat Live Migration ca strategie de evacuare. În acest fel, puteți controla comportamentul mașinilor virtuale atunci când vă deplasați între nodurile de cluster. Puteți atât să configurați Live Migration, cât și să gestionați VM, ca toate celelalte poduri.
rețea
Orice sistem Kubernetes asigură comunicarea între noduri și pod-uri folosind rețele software SDN. OpenShift nu face excepție și, începând cu versiunea 3, utilizează în mod implicit OpenShiftSDN pentru aceasta. În plus, OpenShift 4 are o altă funcție nouă numită Multus, care vă permite să faceți mai multe rețele disponibile și să conectați poduri la acestea simultan.
Folosind Multus, administratorul poate defini rețele CNI suplimentare, care vor fi apoi implementate și configurate pe cluster de către un Cluster Network Operator special. Podurile sunt apoi conectate la una sau mai multe dintre aceste rețele, de obicei OpenShiftSDN standard și o interfață suplimentară. Dispozitivele SR-IOV, Linux Bridge standard, dispozitivele MACVLAN și IPVLAN pot fi toate folosite dacă VM-ul dvs. are nevoie. Figura de mai jos arată cum să setați Multus CNI pentru rețeaua 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 legătură cu virtualizarea OpenShift, aceasta înseamnă că o VM poate fi conectată direct la o rețea externă, ocolind SDN-ul. Acest lucru este important pentru mașinile virtuale migrate la OpenShift de la Red Hat Virtualization sau VMware vSphere, deoarece dacă aveți acces la al doilea nivel OSI, nu va exista nicio modificare a setărilor de rețea. Aceasta înseamnă, de asemenea, că VM-ul poate avea o adresă de rețea care ocolește SDN. Astfel, putem folosi eficient adaptoare de rețea specializate sau ne putem conecta direct la sistemul de stocare prin rețea...
Puteți afla mai multe despre cum să creați și să conectați mașinile virtuale de virtualizare OpenShift la rețea . În plus, , implementat ca parte a virtualizării OpenShift, oferă o altă modalitate familiară de a crea și de a gestiona configurații de rețea pe nodurile fizice care sunt utilizate sub hipervizoare.
Depozitare
Conectarea și gestionarea discurilor de mașini virtuale în cadrul virtualizării OpenShift se realizează folosind concepte Kubernetes precum StorageClasses, PersistentVolumeClaims (PVC) și PersistentVolume (PV), precum și protocoale standard de stocare pentru mediul Kubernetes. Acest lucru oferă administratorilor și echipelor de aplicații Kubernetes o modalitate comună și familiară de a gestiona atât containerele, cât și mașinile virtuale. Și pentru mulți administratori de medii de virtualizare, acest concept poate suna familiar deoarece folosește același principiu de separare a fișierelor de configurare VM și a discurilor care este folosit în OpenStack și în multe alte platforme cloud.
Cu toate acestea, nu putem crea pur și simplu un nou disc pentru VM de fiecare dată, deoarece la migrarea de la hypervisor la OpenShift, trebuie să salvăm datele. Da, chiar și atunci când implementăm o nouă VM, este întotdeauna mai rapid să o facem dintr-un șablon decât să o creăm de la zero. Astfel, avem nevoie de funcționalitate pentru importarea discurilor existente.
Pentru a simplifica această sarcină, virtualizarea OpenShift implementează proiectul Containerized Data Importer (CDI), care reduce importul de imagini de disc ale discurilor din mai multe surse la crearea unei intrări 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ă intrare este cea care activează CDI, declanșând secvența de acțiuni prezentată în figura de mai jos:
După finalizarea CDI, PVC-ul va conține discul mașinii virtuale gata de utilizare și convertit în formatul standard OpenShift...
Când lucrați cu virtualizarea OpenShift, este utilă și OpenShift Container Storage (OCS), o soluție Red Hat bazată pe sistemul de fișiere Ceph care implementează funcționalitatea de stocare persistentă pentru containere. Pe lângă metodele standard de acces PVC - RWO (bloc) și RWX (fișier) - OCS oferă RWX pentru dispozitivele de bloc brut, care este foarte util pentru partajarea accesului la bloc pentru aplicații cu cerințe de înaltă performanță. În plus, OCS acceptă noul standard Object Bucket Claim, care permite aplicațiilor să utilizeze direct stocarea datelor obiect.
Mașini virtuale în containere
Dacă sunteți interesat să verificați cum funcționează, atunci știți că virtualizarea OpenShift este deja disponibilă în versiunea Tech Preview, ca parte a OpenShift 3.11 și o versiune ulterioară. Proprietarii unui abonament OpenShift existent pot folosi virtualizarea OpenShift complet gratuit și fără pași suplimentari. La momentul publicării acestei postări, OpenShift 4.4 și OpenShift virtualization 2.3 sunt actuale; dacă utilizați versiuni anterioare, atunci ar trebui să faceți upgrade pentru a obține cele mai recente funcții. O versiune complet acceptată a virtualizării OpenShift ar trebui să fie lansată în a doua jumătate a anului 2020.
Pentru mai multe informații, vă rugăm să consultați pentru instrucțiuni de instalare, inclusiv , care oferă informații despre configurarea rețelelor externe.
Sursa: www.habr.com