OpenShift վիրտուալացում՝ կոնտեյներներ, KVM և վիրտուալ մեքենաներ

OpenShift վիրտուալացում (վերընթաց նախագիծ - Kubernetes: KubeVirt, տես. այստեղ и այստեղ), nee Container-native Virtualization, ներկայացվել է որպես OpenShift պլատֆորմի ֆունկցիոնալություն, որը նախատեսված է վիրտուալ մեքենաների (VM) տեղակայման և կառավարման համար՝ որպես հիմնական Kubernetes սուբյեկտներ: Այս տեսակի առաջադրանքը տեխնիկապես դժվար է տեխնոլոգիայի հիմնարար տարբերությունների պատճառով: Այս նպատակին հասնելու համար մենք օգտագործեցինք Red Hat Enterprise Linux-ի և KVM-ի վրա հիմնված ծանոթ տեխնոլոգիաները, որոնք երկար տարիներ մեզ հետ են և ապացուցել են իրենց արդյունավետությունը։

Այս հոդվածում մենք կդիտարկենք OpenShift վիրտուալացման տեխնիկական ասպեկտները, որոնք հնարավորություն են տալիս VM-ներին և բեռնարկղերին գոյակցել մեկ հարթակում, որը կառավարում է դրանք որպես մեկ ամբողջություն:

Հաշվողական առաջադրանքներ

Կոնտեյներներն օգտագործում են Linux միջուկի մեխանիզմներ, ինչպիսիք են անվանատարածքները և cgroups-ը՝ գործընթացները մեկուսացնելու և ռեսուրսները կառավարելու համար: Սովորաբար գործընթացները հասկացվում են որպես Python, Java հավելվածներ կամ գործարկվող ֆայլեր, բայց իրականում դրանք կարող են լինել ցանկացած գործընթաց, օրինակ՝ bash, Emacs կամ vim:

Ի՞նչ է վիրտուալ մեքենան: Հիպերվիզորի տեսանկյունից սա նույնպես գործընթաց է։ Բայց ոչ թե դիմումի գործընթացը, այլ KVM գործընթացը, որը պատասխանատու է կոնկրետ VM-ի կատարման համար:

Կոնտեյների պատկերը պարունակում է KVM վիրտուալ մեքենայի համար անհրաժեշտ բոլոր գործիքները, գրադարանները և ֆայլերը: Եթե ​​մենք ստուգենք աշխատող VM-ի պատիճը, այնտեղ կտեսնենք օգնականներ և qemu-kvm գործընթացներ: Բացի այդ, մեզ հասանելի են KVM գործիքները վիրտուալ մեքենաների կառավարման համար, ինչպիսիք են qemu-img, qemu-nbd և virsh:

Քանի որ վիրտուալ մեքենան պատիճ է, այն ինքնաբերաբար ժառանգում է «Կուբերնետեսում» պատի ամբողջ ֆունկցիոնալությունը: VM pods, ճիշտ այնպես, ինչպես սովորական pods, ենթակա են ժամանակացույցի սխեմաների և չափանիշների, ինչպիսիք են աղտոտումը, հանդուրժողականությունը, հարաբերակցությունը և հակահարաբերությունները: Դուք նաև ստանում եք բարձր հասանելիության առավելությունները և այլն: Այնուամենայնիվ, կա մեկ կարևոր տարբերություն. սովորական պատիճները սովորական իմաստով չեն տեղափոխվում հյուրընկալողից հյուրընկալող: Եթե ​​հանգույցը դուրս է գալիս ցանցից, ապա դրա վրա գտնվող պատնեշը կդադարեցվի և վերահանձնարարվի կլաստերի մեկ այլ հանգույցի: Իսկ վիրտուալ մեքենայի դեպքում մենք ակնկալում ենք տեսնել կենդանի միգրացիա:

Այս բացը վերացնելու համար ստեղծվել է հատուկ ռեսուրսների սահմանում (CDR)՝ նկարագրելու կենդանի միգրացիայի մեխանիզմը, որը պատասխանատու է աշխատող հանգույցների միջև VM-ների կենդանի միգրացիայի սկզբնավորման, մոնիտորինգի և կառավարման համար:

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
  name: migration-job
spec:
  vmiName: fedora

Երբ հանգույցն ապաակտիվացված է, միգրացիոն առաջադրանքները ավտոմատ կերպով ստեղծվում են այն վիրտուալ մեքենաների համար, որոնք որպես վտարման ռազմավարություն սահմանված են Live Migration: Այս կերպ Դուք կարող եք վերահսկել վիրտուալ մեքենաների վարքը կլաստերային հանգույցների միջև շարժվելիս: Դուք կարող եք և՛ կարգավորել Live Migration-ը, և՛ կառավարել VM-ը, ինչպես բոլոր մյուս բլոկները:

Сеть

Ցանկացած Kubernetes համակարգ ապահովում է հաղորդակցություն հանգույցների և պատիճների միջև՝ օգտագործելով ծրագրային ապահովման SDN ցանցերը: OpenShift-ը բացառություն չէ և, սկսած 3-րդ տարբերակից, դրա համար լռելյայն օգտագործում է OpenShiftSDN: Բացի այդ, OpenShift 4-ն ունի ևս մեկ նոր ֆունկցիա, որը կոչվում է Multus, որը թույլ է տալիս մի քանի ցանցեր հասանելի դարձնել և միաժամանակ միացնել պոդեր:

Օգտագործելով Multus-ը, ադմինիստրատորը կարող է սահմանել լրացուցիչ CNI ցանցեր, որոնք այնուհետև կտեղակայվեն և կկարգավորվեն կլաստերի վրա հատուկ Կլաստերի ցանցի օպերատորի կողմից: Այնուհետև պատիճները միացված են այս ցանցերից մեկին կամ մի քանիսին, սովորաբար ստանդարտ OpenShiftSDN-ին և լրացուցիչ ինտերֆեյսին: SR-IOV սարքերը, ստանդարտ Linux Bridge, MACVLAN և IPVLAN սարքերը կարող են օգտագործվել, եթե ձեր VM-ին դա անհրաժեշտ է: Ստորև բերված նկարը ցույց է տալիս, թե ինչպես կարելի է տեղադրել Multus CNI կամուրջ ցանցի համար 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

OpenShift վիրտուալիզացիայի հետ կապված, սա նշանակում է, որ VM-ը կարող է ուղղակիորեն միանալ արտաքին ցանցին՝ շրջանցելով SDN-ը: Սա կարևոր է Red Hat Virtualization-ից կամ VMware vSphere-ից OpenShift տեղափոխված վիրտուալ մեքենաների համար, քանի որ եթե դուք մուտք ունեք դեպի երկրորդ OSI շերտ, ցանցի կարգավորումներում փոփոխություն չի լինի: Սա նաև նշանակում է, որ VM-ն կարող է ունենալ ցանցի հասցե, որը շրջանցում է SDN-ն: Այսպիսով, մենք կարող ենք արդյունավետ օգտագործել մասնագիտացված ցանցային ադապտերներ կամ ցանցի միջոցով ուղղակիորեն միանալ պահեստավորման համակարգին...

Դուք կարող եք ավելին իմանալ, թե ինչպես ստեղծել և միացնել OpenShift վիրտուալացման վիրտուալ մեքենաները ցանցին այստեղ: Բացի այդ, nmstate օպերատոր, որը տեղակայված է որպես OpenShift վիրտուալացման մաս, առաջարկում է ևս մեկ ծանոթ միջոց՝ ստեղծելու և կառավարելու ցանցի կոնֆիգուրացիաները ֆիզիկական հանգույցների վրա, որոնք օգտագործվում են հիպերվիզորների ներքո:

Պահեստավորում

Վիրտուալ մեքենաների սկավառակների միացումը և կառավարումը OpenShift վիրտուալացման շրջանակներում իրականացվում է Kubernetes-ի հայեցակարգերի միջոցով, ինչպիսիք են StorageClasses-ը, PersistentVolumeClaims (PVC) և PersistentVolume (PV), ինչպես նաև Kubernetes միջավայրի համար նախատեսված պահպանման արձանագրությունները: Սա Kubernetes-ի ադմինիստրատորներին և հավելվածների թիմերին տալիս է ինչպես կոնտեյներները, այնպես էլ վիրտուալ մեքենաները կառավարելու ընդհանուր, ծանոթ եղանակ: Եվ վիրտուալացման միջավայրերի շատ ադմինիստրատորների համար այս հայեցակարգը կարող է ծանոթ թվալ, քանի որ այն օգտագործում է VM-ի կազմաձևման ֆայլերն ու սկավառակները բաժանելու նույն սկզբունքը, որն օգտագործվում է OpenStack-ում և շատ այլ ամպային հարթակներում:

Այնուամենայնիվ, մենք չենք կարող ամեն անգամ պարզապես նոր սկավառակ ստեղծել VM-ի համար, քանի որ հիպերվիզորից OpenShift տեղափոխելիս մենք պետք է պահպանենք տվյալները: Այո, նույնիսկ երբ մենք տեղադրում ենք նոր VM, միշտ ավելի արագ է դա անել կաղապարից, քան այն ստեղծել զրոյից: Այսպիսով, մեզ անհրաժեշտ է ֆունկցիոնալություն առկա սկավառակների ներմուծման համար:

Այս առաջադրանքը պարզեցնելու համար OpenShift վիրտուալացումը տեղակայում է Containerized Data Importer (CDI) նախագիծը, որը նվազեցնում է սկավառակների սկավառակի պատկերների ներմուծումը բազմաթիվ աղբյուրներից մինչև 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

Հենց այս մուտքն է ակտիվացնում CDI-ն՝ գործարկելով ստորև նկարում ներկայացված գործողությունների հաջորդականությունը.

CDI-ն ավարտելուց հետո PVC-ը կպարունակի վիրտուալ մեքենայի սկավառակը, որը պատրաստ է օգտագործման և կվերափոխվի ստանդարտ OpenShift ձևաչափի...
OpenShift վիրտուալիզացիայի հետ աշխատելիս՝ OpenShift Container Storage (OCS)՝ Red Hat լուծումը, որը հիմնված է Ceph ֆայլային համակարգի վրա, որն իրականացնում է բեռնարկղերի մշտական ​​պահպանման գործառույթը, նույնպես օգտակար է: Ի լրումն ստանդարտ PVC մուտքի մեթոդների՝ RWO (բլոկ) և RWX (ֆայլ), OCS-ը տրամադրում է RWX չմշակված բլոկ սարքերի համար, ինչը շատ օգտակար է բլոկի հասանելիությունը կիսելու համար՝ բարձր կատարողականության պահանջներ ունեցող հավելվածների համար: Բացի այդ, OCS-ն աջակցում է Object Bucket Claim նոր ստանդարտին, որը թույլ է տալիս հավելվածներին ուղղակիորեն օգտագործել օբյեկտների տվյալների պահպանումը:

Վիրտուալ մեքենաներ տարաներում

Եթե ​​դուք հետաքրքրված եք ստուգել, ​​թե ինչպես է այն աշխատում, ապա իմացեք, որ OpenShift վիրտուալացումն արդեն հասանելի է Tech Preview տարբերակում՝ որպես OpenShift 3.11 և ավելի նոր տարբերակ: Գործող OpenShift բաժանորդագրության սեփականատերերը կարող են օգտագործել OpenShift վիրտուալացումն ամբողջովին անվճար և առանց որևէ լրացուցիչ քայլի: Այս գրառման հրապարակման պահին OpenShift 4.4-ը և OpenShift վիրտուալիզացիան 2.3-ն ընթացիկ են, եթե դուք օգտագործում եք նախորդ տարբերակները, ապա պետք է թարմացնեք վերջին հնարավորությունները ստանալու համար: OpenShift-ի վիրտուալացման լիովին աջակցվող տարբերակը պետք է թողարկվի 2020 թվականի երկրորդ կեսին:

Լրացուցիչ տեղեկությունների համար դիմեք OpenShift փաստաթղթեր տեղադրման հրահանգների համար, ներառյալ Multus setup բաժին, որը տեղեկատվություն է տրամադրում արտաքին ցանցերի ստեղծման մասին:

Source: www.habr.com