OpenShift virtualizācija (apstra projektu – Kubernetes: KubeVirt, skat. un ), savulaik pazīstama kā Container-native Virtualization, tika ieviesta kā OpenShift platformas funkcionalitāte, kas paredzēta virtuālo mašīnu (VM) izvietošanai un pārvaldīšanai kā pamata Kubernetes entitātēm. Šāds uzdevums ir tehniski sarežģīts, ņemot vērā tehnoloģiju fundamentālās atšķirības. Lai sasniegtu izvirzītos mērķus, tika izmantotas visiem zināmās tehnoloģijas, kas balstītas uz Red Hat Enterprise Linux un KVM, kuras ir ar mums ne vienu gadu un pierādījušas savu efektivitāti.
Šajā rakstā mēs apskatīsim OpenShift virtualizācijas tehniskos aspektus, kas padara iespējamu VM un konteineru līdzāspastāvēšanu vienā platformā, kas pārvalda tos kā vienotu veselumu.
Kalkulācijas uzdevumi
Konteineri izmanto Linux kodola mehānismus, piemēram, namespaces un cgroups, lai izolētu procesus un pārvaldītu resursus. Parasti ar procesiem saprot lietojumprogrammas Python, Java vai izpildāmos failus, taču patiesībā tie var būt jebkuri procesi, piemēram, bash, Emacs vai vim.
Kas ir virtuālā mašīna? No hipervizora viedokļa – tas ir arī process. Bet tikai ne lietojumprogrammas process, bet KVM process, kas atbild par konkrētas VM izpildi.
Konteineru attēls satur visus rīkus, bibliotēkas un failus, kas nepieciešami KVM virtuālajai mašīnai. Ja mēs pārbaudām darbojošos VM podu, mēs redzēsim tur palīgprogrammas un qemu-kvm procesus. Turklāt mums ir pieejamas KVM rīku izmantošanai virtuālo mašīnu pārvaldībā, piemēram, qemu-img, qemu-nbd un virsh.
Tā kā virtuālā mašīna ir pod, tā automātiski manto visu pod funkcionalitāti Kubernetes. Uz VM podiem attiecas tādi paši plānošanas shēmas un kritēriji kā parastajiem podiem, piemēram, taints, tolerances, afinitāte un anti-afinitāte. Jūs arī iegūstat priekšrocības augstās pieejamības veidā u.tml. Tomēr ir viena svarīga atšķirība: parastie podi nemigrē no viena hosta uz citu tā, kā mēs to ierasti saprotam. Ja mezgls izslēdzas, tad pod uz tā tiek pārtraukts un pārbūvēts citā mezglā klastra ietvaros. Savukārt virtuālajā mašīnā mēs sagaidām redzēt dzīvu migrāciju.
Lai novērstu šo trūkumu, tika izveidota custom resource definition (CDR), kas apraksta dzīvas migrācijas mehānismu, kas atbild par dzīvo migrāciju inicēšanu, uzraudzību un pārvaldību starp darba mezgliem.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Deaktivējot mezglu, automātiski tiek izveidotas migrācijas uzdevumi tiem virtuālajiem serveriem, kuriem kā eviction strategy ir norādīta Live Migration. Tādējādi var kontrolēt virtuālo serveru uzvedību, pārvietojoties starp klastera mezgliem. Jūs varat gan iestatīt Live Migration, gan pārvaldīt VM, tāpat kā visus pārējos podus.
Tīkls
Jebkura Kubernetes sistēma nodrošina saziņu starp mezgliem un podiem, izmantojot programmatūras SDN tīklus. OpenShift nav izņēmums, un sākot ar 3. versiju, pēc noklusējuma izmanto OpenShiftSDN. Turklāt OpenShift 4 ir parādījusies jauna funkcija ar nosaukumu Multus, kas ļauj piekļūt vairākām tīklā un vienlaikus pieslēgt podus.
Ar Multus administratoram ir iespēja norādīt papildu CNI tīklus, kas pēc tam tiks izvērsti un konfigurēti klasterī ar īpašu Cluster Network Operator operētāju. Pēc tam podi tiek pieslēgti vienam vai vairākiem šiem tīkliem, parasti standartam OpenShiftSDN un papildu saskarnei. SR-IOV ierīces, standarta Linux Bridge, MACVLAN un IPVLAN ierīces – viss to var izmantot, ja tas ir nepieciešams jūsu VM. Attēlā zemāk ir parādīts, kā iestatīt Multus CNI bridge tīklam uz saskarnes 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
Attiecībā uz OpenShift virtualizāciju tas nozīmē, ka VM var pieslēgties ārējam tīklam tieši, apejot SDN. Tas ir svarīgi virtuālajiem serveriem, kas pārvietoti uz OpenShift no Red Hat Virtualization vai VMware vSphere, jo piekļuve otrajā OSI līmenī nenozīmē, ka tiks mainīti tīkla iestatījumi. Tas arī nozīmē, ka VM var būt tīkla adrese, kurai piekļūst, apejot SDN. Šādā veidā mēs varam efektīvi izmantot specializētus tīkla adapterus vai tieši pieslēgties SAN…
Sīkāk par to, kā izveidot un pieslēgt virtuālos serverus OpenShift virtualizācijā tīklam, var uzzināt . Turklāt , kas tiek izvērsts OpenShift virtualizācijas sastāvā, piedāvā vēl vienu labi pazīstamu veidu, kā izveidot un pārvaldīt tīkla konfigurācijas uz fiziskajiem mezgliem, kuri tiek izmantoti kā hipervizori.
Žurnālu glabāšana JSON formātā.
Virtualizācijas ietvaros OpenShift vidē diskus un to pārvaldību virtuālajām iekārtām veic, izmantojot Kubernetes koncepcijas, piemēram, StorageClasses, PersistentVolumeClaims (PVC) un PersistentVolume (PV), kā arī standarta glabāšanas protokolus, kas raksturīgi Kubernetes videi. Tādējādi Kubernetes administratori un lietojumprogrammu komandas saņem vienotu un pazīstamu pārvaldības mehānismu gan konteineriem, gan virtuālajām mašīnām. Daudziem virtualizācijas vidē strādājošajiem administratīvajiem darbiniekiem šī koncepcija var būt pazīstama, jo tajā izmantots tāds pats princips, kāds tiek izmantots OpenStack un daudzās citās mākoņplatformās, kas nodrošina atsevišķas virtuālās mašīnas konfigurācijas failus un diskus.
Tomēr nav ieteicams katru reizi izveidot jaunu diskus virtuālajām mašīnām, jo migrācijas laikā no hipervizora uz OpenShift ir jānodrošina datu saglabāšana. Pat tad, kad mēs izvēršam jaunu virtuālo mašīnu, to vienmēr ir ātrāk izdarīt no parauga, nevis izveidot no nulles. Tādēļ mums ir nepieciešama esošo diskus importēšanas funkcionalitāte.
Lai atvieglotu šo uzdevumu, OpenShift virtualizācija izvērš Containerized Data Importer (CDI) projektu, kas apvieno diskattēlu importēšanu no dažādiem avotiem, izveidojot ierakstu 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
Tieši šis ieraksts aktivizē CDI, uzsākot darbību secību, kas attēlota zemāk.
Pēc tam, kad CDI ir darbināts, PVC saturēs virtuālās mašīnas disku, kas ir gatavs lietošanai un pielāgots OpenShift standartam...
Strādājot ar OpenShift virtualizāciju, noderīgs būs arī OpenShift Container Storage (OCS), Red Hat risinājums, kas balstīts uz Ceph failu sistēmas, nodrošinot pastāvīgā krātuve konteineriem. Papildus standarta PVC piekļuves metodēm – RWO (blokā) un RWX (failā) – OCS piedāvā RWX izejvielu blokiem, kas ir ļoti noderīgi, organizējot kopīgu bloka piekļuvi lietojumprogrammu, kurām ir augstas snieguma prasības. Turklāt OCS atbalsta jaunu objektu grupas pieteikumu normu Object Bucket Claim, kas ļauj lietojumprogrammām tieši izmantot datu objektu glabātuvi.
Virtuālās mašīnas konteineros
Ja, ja interesē pārbaudīt, kā tas darbojas, tad ziniet, ka OpenShift virtualizācija jau ir pieejama Tech Preview variantā OpenShift 3.11 un jaunākās versijās. OpenShift aktīvo abonentu īpašnieki var izmantot OpenShift virtualizāciju pilnīgi bez maksas un bez jebkādām papildu darbībām. Šī ieraksta izlaišanas brīdī aktuālās versijas ir OpenShift 4.4 un OpenShift virtualization 2.3; ja izmantojat iepriekšējās versijas, tad, lai iegūtu jaunākās funkcijas, ir vērts jaunināt. Pilnībā atbalstītā OpenShift virtualizācijas versija ir paredzēta izlaišanai 2020. gada otrajā pusē.
Lai iegūtu papildu informāciju, sazinieties ar par instalācijas instrukcijām, tostarp , kurā sniegta informācija par ārējo tīklu konfigurēšanu.
Avots: habr.com
