OpenShift birtualizazioa (upstream proiektua - Kubernetes: KubeVirt, ikus. ΠΈ ), dee Container-native Virtualization, OpenShift plataformaren funtzionalitate gisa sartu zen, zeina makina birtualak (VM) Kubernetes oinarrizko entitate gisa hedatzeko eta kudeatzeko diseinatuta dagoen. Zeregin mota hau teknikoki zaila da teknologiaren oinarrizko desberdintasunengatik. Helburu hori lortzeko, Red Hat Enterprise Linux eta KVM-n oinarritutako teknologia ezagunak erabili ditugu, urte asko daramatzagu gurekin eta eraginkortasuna frogatu dutenak.
Artikulu honetan, OpenShift birtualizazioaren alderdi teknikoak aztertuko ditugu VMak eta edukiontziak entitate bakar gisa kudeatzen dituen plataforma bakar baten barruan elkarbizitzea ahalbidetzen dutenak.
Konputazio-zereginak
Edukiontziek Linux kernel-mekanismoak erabiltzen dituzte, hala nola izen-espazioak eta cgroup-ak, prozesuak isolatzeko eta baliabideak kudeatzeko. Normalean prozesuak Python, Java aplikazio edo fitxategi exekutagarri gisa ulertzen dira, baina egia esan edozein prozesu izan daitezke, hala nola bash, Emacs edo vim.
Zer da makina birtuala? Hipervisorearen ikuspuntutik, hau ere prozesu bat da. Baina ez aplikazio prozesua, VM zehatz bat exekutatzeko ardura duen KVM prozesua baizik.
Edukiontziaren irudiak KVM makina birtualerako beharrezkoak diren tresna, liburutegi eta fitxategi guztiak ditu. Exekutatzen ari den VM baten poda ikuskatzen badugu, laguntzaileak eta qemu-kvm prozesuak ikusiko ditugu. Gainera, Qemu-img, qemu-nbd eta virsh bezalako makina birtualak kudeatzeko KVM tresnetarako sarbidea dugu.
Makina birtual bat pod bat denez, automatikoki kubernetesen pod baten funtzionaltasun guztiak heredatzen ditu. VM lekak, ohiko lekak bezalaxe, programatzaileen eskemak eta irizpideak daude, hala nola kutsadura, tolerantzia, afinitatea eta afinitatearen aurkakoa. Erabilgarritasun handiko abantailak ere lortzen dituzu, etab. Hala ere, bada alde garrantzitsu bat: ohiko lekak ez dira ostalaritik ostalarira migratzen ohiko zentzuan. Nodo bat lineaz kanpo geratzen bada, bertan dagoen poda amaitu eta klusterreko beste nodo batera esleitzen da. Eta makina birtual baten kasuan, zuzeneko migrazioa ikustea espero dugu.
Hutsune horri aurre egiteko, pertsonalizatutako baliabideen definizioa (CDR) sortu zen langile-nodoen arteko VM-en zuzeneko migrazioak hasieratzeaz, kontrolatzeaz eta kudeatzeaz arduratzen den zuzeneko migrazio-mekanismoa deskribatzeko.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Nodo bat desaktibatzen denean, migrazio-zereginak automatikoki sortzen dira desalojo estrategia gisa Live Migration ezarrita duten makina birtualentzat. Horrela makina birtualen portaera kontrola dezakezu cluster-nodoen artean mugitzean. Zuzeneko Migrazioa konfigura dezakezu eta VM kudea dezakezu, gainerako pod guztiak bezala.
Sarea
Kubernetes edozein sistemak nodoen eta poden arteko komunikazioa eskaintzen du software SDN sareak erabiliz. OpenShift ez da salbuespena eta, 3. bertsiotik hasita, OpenShiftSDN erabiltzen du lehenespenez horretarako. Horrez gain, OpenShift 4-k Multus izeneko beste funtzio berri bat du, eta horri esker sare anitz erabilgarri jarri eta aldi berean podak konekta ditzakezu.
Multus erabiliz, administratzaileak CNI sare osagarriak defini ditzake, gero Cluster Network Operator berezi batek zabaldu eta konfiguratuko dituena. Lekak sare horietako batera edo gehiagotara konektatzen dira, normalean OpenShiftSDN estandarra eta interfaze gehigarri batera. SR-IOV gailuak, Linux Bridge estandarra, MACVLAN eta IPVLAN gailu guztiak erabil daitezke zure VM behar badu. Beheko irudiak eth1 interfazean zubi sarerako Multus CNI nola ezarri erakusten du:
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
OpenShift birtualizazioari dagokionez, horrek esan nahi du VM bat kanpoko sare batera zuzenean konektatu daitekeela, SDN saihestuz. Hau garrantzitsua da Red Hat Virtualization edo VMware vSphere-tik OpenShift-era migratutako makina birtualetarako, bigarren OSI geruzarako sarbidea baduzu, sareko ezarpenetan ez baita aldaketarik izango. Horrek esan nahi du VM-ak SDN saihesten duen sare-helbide bat izan dezakeela ere. Horrela, sare-egokitzaile espezializatuak eraginkortasunez erabil ditzakegu, edo sarearen bidez biltegiratze sistemara zuzenean konektatu...
OpenShift birtualizazio makina birtualak sarera nola sortu eta nola konektatu buruz gehiago ikas dezakezu ... Gainera, , OpenShift birtualizazioaren zati gisa zabalduta, hipervisoreetan erabiltzen diren nodo fisikoetan sare konfigurazioak sortzeko eta kudeatzeko beste modu ezagun bat eskaintzen du.
biltegiratze
OpenShift birtualizazioaren barruan makina birtualeko diskoak konektatzea eta kudeatzea Kubernetes-eko kontzeptuak erabiliz egiten da, hala nola StorageClasses, PersistentVolumeClaims (PVC) eta PersistentVolume (PV), baita Kubernetes ingurunerako biltegiratze-protokolo estandarrak ere. Horrek Kuberneteseko administratzaileei eta aplikazio-taldeei edukiontziak zein makina birtualak kudeatzeko modu arrunt eta ezaguna eskaintzen die. Eta birtualizazio-inguruneetako administratzaile askorentzat, kontzeptu hau ezaguna izan daiteke, OpenStack-en eta beste hodeiko plataforma askotan erabiltzen den VM konfigurazio fitxategiak eta diskoak bereizteko printzipio bera erabiltzen duelako.
Hala ere, ezin dugu VMrako disko berri bat sortu aldi bakoitzean, hipervisoretik OpenShift-era migratzean, datuak gorde behar baititugu. Bai, VM berri bat zabaltzen dugunean ere, beti da azkarragoa txantiloi batetik egitea hutsetik sortzea baino. Horrela, dauden diskoak inportatzeko funtzionaltasuna behar dugu.
Zeregin hori sinplifikatzeko, OpenShift birtualizazioak Containerized Data Importer (CDI) proiektua inplementatzen du, hainbat iturritatik diskoen diskoen irudiak inportatzea PVC sarrera bat sortzera murrizten duena.
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
Sarrera hau da CDI aktibatzen duena, beheko irudian agertzen den ekintzen sekuentzia abiaraziz:
CDI osatu ondoren, PVCak makina birtualaren diskoa edukiko du erabiltzeko prest eta OpenShift formatu estandarrera bihurtuta...
OpenShift birtualizazioarekin lan egitean, OpenShift Container Storage (OCS), edukiontzietarako biltegiratze iraunkorraren funtzionaltasuna ezartzen duen Ceph fitxategi-sisteman oinarritutako Red Hat soluzioa ere erabilgarria da. PVC sarbide-metodo estandarrez gain - RWO (blokea) eta RWX (fitxategia) - OCS-k RWX eskaintzen du raw block gailuetarako, eta hori oso erabilgarria da errendimendu handiko eskakizunak dituzten aplikazioetarako bloke sarbidea partekatzeko. Horrez gain, OCS-ek Object Bucket Claim estandar berria onartzen du, eta horri esker aplikazioek objektuen datuen biltegiratzea zuzenean erabil dezakete.
Makina birtualak edukiontzietan
Nola funtzionatzen duen egiaztatzea interesatzen bazaizu, jakin ezazu OpenShift birtualizazioa dagoeneko eskuragarri dagoela Tech Preview bertsioan OpenShift 3.11 eta berriagoa den moduan. Lehendik dagoen OpenShift harpidetza baten jabeek OpenShift birtualizazioa guztiz doan erabil dezakete eta urrats gehigarririk gabe. Argitalpen honen momentuan, OpenShift 4.4 eta OpenShift birtualizazioa 2.3 egungoak dira; aurreko bertsioak erabiltzen ari bazara, berritu egin beharko zenuke azken funtzioak lortzeko. OpenShift birtualizazioaren guztiz onartzen den bertsio bat 2020ko bigarren seihilekoan kaleratu beharko litzateke.
Informazio gehiagorako, mesedez, jo instalatzeko argibideetarako, barne , kanpoko sareak konfiguratzeari buruzko informazioa ematen duena.
Iturria: www.habr.com