OpenShift virtualizācija (augšupējais projekts - Kubernetes: KubeVirt, sk и ), nee Container-native Virtualization, tika ieviesta kā OpenShift platformas funkcionalitāte, kas paredzēta virtuālo mašīnu (VM) kā pamata Kubernetes entītiju izvietošanai un pārvaldībai. Šāda veida uzdevums ir tehniski sarežģīts tehnoloģiju būtisku atšķirību dēļ. Lai sasniegtu šo mērķi, mēs izmantojām pazīstamās tehnoloģijas, kuru pamatā ir Red Hat Enterprise Linux un KVM, kas ir bijuši ar mums jau daudzus gadus un ir pierādījuši savu efektivitāti.
Šajā rakstā mēs apskatīsim OpenShift virtualizācijas tehniskos aspektus, kas ļauj virtuālajām mašīnām un konteineriem līdzāspastāvēt vienā platformā, kas tos pārvalda kā vienu vienību.
Skaitļošanas uzdevumi
Konteineri izmanto Linux kodola mehānismus, piemēram, nosaukumvietas un cgroups, lai izolētu procesus un pārvaldītu resursus. Parasti procesi tiek saprasti kā Python, Java lietojumprogrammas vai izpildāmie faili, bet 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 arī ir process. Bet nevis pieteikšanās process, bet KVM process, kas ir atbildīgs par konkrētas VM izpildi.
Konteinera attēls satur visus KVM virtuālajai mašīnai nepieciešamos rīkus, bibliotēkas un failus. Ja mēs pārbaudīsim darbojas VM pod, mēs redzēsim tur palīgus un qemu-kvm procesus. Turklāt mums ir pieejami KVM rīki, lai pārvaldītu virtuālās mašīnas, piemēram, qemu-img, qemu-nbd un virsh.
Tā kā virtuālā mašīna ir pods, tā automātiski pārņem visas Kubernetes pod funkcionalitātes. VM podi, tāpat kā parastie podi, ir pakļauti plānotāja shēmām un kritērijiem, piemēram, bojājumiem, pielaidēm, afinitātei un antiafinitātei. Jūs saņemat arī priekšrocības, ko sniedz augsta pieejamība utt. Tomēr ir viena būtiska atšķirība: parastās pākstis nemigrē no saimnieka uz saimnieku parastajā nozīmē. Ja mezgls pāriet bezsaistē, tajā esošais pods tiek pārtraukts un tiek atkārtoti piešķirts citam klastera mezglam. Un virtuālās mašīnas gadījumā mēs sagaidām reāllaika migrāciju.
Lai novērstu šo trūkumu, tika izveidota pielāgota resursa definīcija (CDR), lai aprakstītu reāllaika migrācijas mehānismu, kas ir atbildīgs par VM tiešās migrācijas inicializāciju, uzraudzību un pārvaldību starp darbinieku mezgliem.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Kad mezgls ir deaktivizēts, migrācijas uzdevumi tiek automātiski izveidoti tām virtuālajām mašīnām, kurām kā izlikšanas stratēģija ir iestatīta Live Migration. Tādā veidā jūs varat kontrolēt virtuālo mašīnu uzvedību, pārvietojoties starp klastera mezgliem. Varat gan konfigurēt tiešo migrāciju, gan pārvaldīt virtuālo mašīnu, tāpat kā visus citus aplikumus.
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 no 3. versijas, šim nolūkam pēc noklusējuma tiek izmantots OpenShiftSDN. Turklāt OpenShift 4 ir vēl viena jauna funkcija, ko sauc par Multus, kas ļauj padarīt pieejamus vairākus tīklus un vienlaikus savienot ar tiem podi.
Izmantojot Multus, administrators var definēt papildu CNI tīklus, kurus pēc tam klasterī izvietos un konfigurēs īpašs klastera tīkla operators. Pēc tam podi tiek savienoti ar vienu vai vairākiem no šiem tīkliem, parasti standarta OpenShiftSDN un papildu saskarni. Ja jūsu virtuālajam datoram tas ir nepieciešams, var izmantot SR-IOV ierīces, standarta Linux Bridge, MACVLAN un IPVLAN ierīces. Tālāk esošajā attēlā parādīts, kā iestatīt Multus CNI tilta tīklam eth1 saskarnē:
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
Saistībā ar OpenShift virtualizāciju tas nozīmē, ka virtuālo mašīnu var tieši savienot ar ārēju tīklu, apejot SDN. Tas ir svarīgi virtuālajām mašīnām, kas migrētas uz OpenShift no Red Hat Virtualization vai VMware vSphere, jo, ja jums ir piekļuve otrajam OSI slānim, tīkla iestatījumi netiks mainīti. Tas arī nozīmē, ka VM var būt tīkla adrese, kas apiet SDN. Tādējādi mēs varam efektīvi izmantot specializētus tīkla adapterus vai izveidot savienojumu tieši ar uzglabāšanas sistēmu tīklā...
Varat uzzināt vairāk par to, kā izveidot un savienot ar tīklu OpenShift virtualizācijas virtuālās mašīnas ... Turklāt, , kas ir izvietota kā daļa no OpenShift virtualizācijas, piedāvā vēl vienu pazīstamu veidu, kā izveidot un pārvaldīt tīkla konfigurācijas fiziskajos mezglos, kas tiek izmantoti zem hipervizoriem.
Glabāšana
Virtuālās mašīnas disku pievienošana un pārvaldība OpenShift virtualizācijas ietvaros tiek veikta, izmantojot Kubernetes koncepcijas, piemēram, StorageClasses, PersistentVolumeClaims (PVC) un PersistentVolume (PV), kā arī Kubernetes vides standarta krātuves protokolus. Tas nodrošina Kubernetes administratoriem un lietojumprogrammu komandām kopīgu, pazīstamu veidu, kā pārvaldīt gan konteinerus, gan virtuālās mašīnas. Un daudziem virtualizācijas vidi administratoriem šī koncepcija var šķist pazīstama, jo tajā tiek izmantots tas pats VM konfigurācijas failu un disku atdalīšanas princips, kas tiek izmantots OpenStack un daudzās citās mākoņu platformās.
Tomēr mēs nevaram katru reizi vienkārši izveidot jaunu disku VM, jo, migrējot no hipervizora uz OpenShift, mums ir jāsaglabā dati. Jā, pat ja mēs izvietojam jaunu virtuālo mašīnu, vienmēr ir ātrāk to izdarīt, izmantojot veidni, nekā izveidot to no jauna. Tādējādi mums ir nepieciešama funkcionalitāte esošo disku importēšanai.
Lai vienkāršotu šo uzdevumu, OpenShift virtualizācija izvieto Containerized Data Importer (CDI) projektu, kas samazina disku diska attēlu importēšanu no vairākiem avotiem līdz PVC ieraksta izveidei.
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, izraisot darbību secību, kas parādīta attēlā zemāk:
Kad CDI būs pabeigts, PVC saturēs virtuālās mašīnas disku, kas ir gatavs lietošanai un pārveidots standarta OpenShift formātā...
Strādājot ar OpenShift virtualizāciju, noder arī OpenShift Container Storage (OCS), Red Hat risinājums, kura pamatā ir Ceph failu sistēma un kas ievieš konteineru pastāvīgas uzglabāšanas funkcionalitāti. Papildus standarta PVC piekļuves metodēm - RWO (bloks) un RWX (fails) - OCS nodrošina RWX neapstrādātu bloku ierīcēm, kas ir ļoti noderīga bloku piekļuves koplietošanai lietojumprogrammām ar augstām veiktspējas prasībām. Turklāt OCS atbalsta jauno Object Bucket Claim standartu, kas ļauj lietojumprogrammām tieši izmantot objektu datu krātuvi.
Virtuālās mašīnas konteineros
Ja vēlaties pārbaudīt, kā tas darbojas, ņemiet vērā, ka OpenShift virtualizācija jau ir pieejama Tech Preview versijā kā daļa no OpenShift 3.11 un jaunākas versijas. Esoša OpenShift abonementa īpašnieki var izmantot OpenShift virtualizāciju pilnīgi bez maksas un bez jebkādām papildu darbībām. Šīs ziņas publicēšanas laikā ir aktuālas OpenShift 4.4 un OpenShift virtualizācijas 2.3; ja izmantojat iepriekšējās versijas, jums ir jāveic jaunināšana, lai iegūtu jaunākās funkcijas. 2020. gada otrajā pusē vajadzētu izlaist pilnībā atbalstītu OpenShift virtualizācijas versiju.
Lai iegūtu vairāk informācijas, lūdzu, sazinieties ar uzstādīšanas instrukcijām, ieskaitot , kas sniedz informāciju par ārējo tīklu iestatīšanu.
Avots: www.habr.com