OpenShift virtualization: mga container, KVM at virtual machine

OpenShift virtualization (upstream na proyekto - Kubernetes: KubeVirt, tingnan. dito и dito), nee Container-native Virtualization, ay ipinakilala bilang isang functionality ng OpenShift platform, na idinisenyo para sa pag-deploy at pamamahala ng mga virtual machine (VM) bilang mga pangunahing Kubernetes entity. Ang ganitong uri ng gawain ay teknikal na mapaghamong dahil sa mga pangunahing pagkakaiba sa teknolohiya. Upang makamit ang layuning ito, gumamit kami ng mga pamilyar na teknolohiya batay sa Red Hat Enterprise Linux at KVM, na kasama namin sa loob ng maraming taon at napatunayan ang pagiging epektibo ng mga ito.

Sa artikulong ito, titingnan natin ang mga teknikal na aspeto ng OpenShift virtualization na ginagawang posible para sa mga VM at container na magkakasamang mabuhay sa loob ng isang platform na namamahala sa kanila bilang isang entity.

Mga gawaing computational

Gumagamit ang mga container ng mga mekanismo ng kernel ng Linux gaya ng mga namespace at cgroup para ihiwalay ang mga proseso at pamahalaan ang mga mapagkukunan. Karaniwang nauunawaan ang mga proseso bilang Python, Java application o executable file, ngunit sa katunayan maaari silang maging anumang proseso, gaya ng bash, Emacs o vim.

Ano ang isang virtual machine? Mula sa punto ng view ng hypervisor, ito ay isa ring proseso. Ngunit hindi ang proseso ng aplikasyon, ngunit ang proseso ng KVM na responsable para sa pagpapatupad ng isang partikular na VM.

Ang imahe ng lalagyan ay naglalaman ng lahat ng mga tool, aklatan at mga file na kailangan para sa KVM virtual machine. Kung susuriin natin ang pod ng isang tumatakbong VM, makikita natin doon ang mga katulong at proseso ng qemu-kvm. Bukod pa rito, mayroon kaming access sa mga tool ng KVM para sa pamamahala ng mga virtual machine tulad ng qemu-img, qemu-nbd at virsh.

Dahil ang isang virtual machine ay isang pod, awtomatiko nitong minana ang lahat ng functionality ng isang pod sa Kubernetes. Ang mga VM pod, tulad ng mga regular na pod, ay napapailalim sa mga scheme ng scheduler at pamantayan gaya ng mga bahid, pagpapaubaya, affinity at anti-affinity. Makukuha mo rin ang mga benepisyo ng mataas na kakayahang magamit, atbp. Gayunpaman, mayroong isang mahalagang pagkakaiba: ang mga regular na pod ay hindi lumilipat mula sa host patungo sa host sa karaniwang kahulugan. Kung offline ang isang node, wawakasan ang pod dito at itatalaga sa isa pang node sa cluster. At sa kaso ng isang virtual machine, inaasahan naming makita ang live na paglipat.

Upang matugunan ang agwat na ito, isang custom na resource definition (CDR) ang ginawa upang ilarawan ang mekanismo ng live na paglipat na responsable para sa pagsisimula, pagsubaybay, at pamamahala ng mga live na paglilipat ng mga VM sa pagitan ng mga node ng manggagawa.

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

Kapag na-deactivate ang isang node, awtomatikong nagagawa ang mga gawain sa paglilipat para sa mga virtual machine na iyon na may nakatakdang Live Migration bilang kanilang diskarte sa pagpapaalis. Sa ganitong paraan makokontrol mo ang pag-uugali ng mga virtual machine kapag lumilipat sa pagitan ng mga cluster node. Maaari mong parehong i-configure ang Live Migration at pamahalaan ang VM, tulad ng lahat ng iba pang pod.

Сеть

Ang anumang sistema ng Kubernetes ay nagbibigay ng komunikasyon sa pagitan ng mga node at pod gamit ang software ng mga network ng SDN. Ang OpenShift ay walang pagbubukod at, simula sa bersyon 3, ay gumagamit ng OpenShiftSDN bilang default para dito. Bilang karagdagan, ang OpenShift 4 ay may isa pang bagong tampok na tinatawag na Multus, na nagbibigay-daan sa iyong gawing available ang maraming network at ikonekta ang mga pod sa kanila nang sabay-sabay.

Gamit ang Multus, maaaring tukuyin ng administrator ang mga karagdagang CNI network, na pagkatapos ay ide-deploy at iko-configure sa cluster ng isang espesyal na Cluster Network Operator. Ang mga pod ay pagkatapos ay konektado sa isa o higit pa sa mga network na ito, kadalasan ang karaniwang OpenShiftSDN at isang karagdagang interface. Ang mga SR-IOV device, karaniwang Linux Bridge, MACVLAN at IPVLAN device ay maaaring gamitin lahat kung kailangan ito ng iyong VM. Ipinapakita ng figure sa ibaba kung paano itakda ang Multus CNI para sa bridge network sa eth1 interface:

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

Kaugnay ng OpenShift virtualization, nangangahulugan ito na ang isang VM ay maaaring direktang konektado sa isang panlabas na network, na lumalampas sa SDN. Mahalaga ito para sa mga virtual machine na lumipat sa OpenShift mula sa Red Hat Virtualization o VMware vSphere, dahil kung mayroon kang access sa pangalawang layer ng OSI, walang pagbabago sa mga setting ng network. Nangangahulugan din ito na maaaring may network address ang VM na lumalampas sa SDN. Kaya, maaari naming epektibong gumamit ng mga espesyal na adapter ng network, o direktang kumonekta sa sistema ng imbakan sa network...

Maaari kang matuto nang higit pa tungkol sa kung paano lumikha at ikonekta ang OpenShift virtualization virtual machine sa network dito... Bukod sa, operator ng nmstate, na na-deploy bilang bahagi ng OpenShift virtualization, ay nag-aalok ng isa pang pamilyar na paraan upang lumikha at pamahalaan ang mga configuration ng network sa mga pisikal na node na ginagamit sa ilalim ng hypervisors.

Imbakan

Ang pagkonekta at pamamahala ng mga virtual machine disk sa loob ng OpenShift virtualization ay ginagawa gamit ang mga konsepto ng Kubernetes tulad ng StorageClasses, PersistentVolumeClaims (PVC) at PersistentVolume (PV), pati na rin ang mga storage protocol na pamantayan para sa kapaligiran ng Kubernetes. Nagbibigay ito sa mga administrator ng Kubernetes at mga application team ng isang pangkaraniwan, pamilyar na paraan upang pamahalaan ang parehong mga container at virtual machine. At para sa maraming mga administrator ng virtualization environment, maaaring pamilyar ang konseptong ito dahil gumagamit ito ng parehong prinsipyo ng paghihiwalay ng mga VM configuration file at disk na ginagamit sa OpenStack at marami pang ibang cloud platform.

Gayunpaman, hindi tayo basta-basta makakagawa ng bagong disk para sa VM, dahil kapag lumilipat mula sa hypervisor patungo sa OpenShift, kailangan nating i-save ang data. Oo, kahit na nag-deploy kami ng bagong VM, palaging mas mabilis itong gawin mula sa isang template kaysa gawin ito mula sa simula. Kaya, kailangan namin ng functionality para sa pag-import ng mga umiiral na disk.

Upang pasimplehin ang gawaing ito, ang OpenShift virtualization ay nagde-deploy ng proyektong Containerized Data Importer (CDI), na binabawasan ang pag-import ng mga imahe ng disk ng mga disk mula sa maraming mapagkukunan patungo sa paggawa ng PVC entry.

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

Ang entry na ito ang nag-activate ng CDI, na nagti-trigger sa pagkakasunud-sunod ng mga aksyon na ipinapakita sa figure sa ibaba:

Matapos makumpleto ang CDI, ang PVC ay maglalaman ng virtual machine disk na handa nang gamitin at mako-convert sa karaniwang format ng OpenShift...
Kapag nagtatrabaho sa OpenShift virtualization, ang OpenShift Container Storage (OCS), isang solusyon sa Red Hat batay sa Ceph file system na nagpapatupad ng tuluy-tuloy na storage functionality para sa mga container, ay kapaki-pakinabang din. Bilang karagdagan sa mga karaniwang pamamaraan ng pag-access sa PVC - RWO (block) at RWX (file) - Ang OCS ay nagbibigay ng RWX para sa mga raw block device, na lubhang kapaki-pakinabang para sa pagbabahagi ng block access para sa mga application na may mataas na mga kinakailangan sa pagganap. Bilang karagdagan, sinusuportahan ng OCS ang bagong pamantayan ng Object Bucket Claim, na nagpapahintulot sa mga application na direktang gumamit ng object data storage.

Mga virtual machine sa mga lalagyan

Kung interesado kang suriin kung paano ito gumagana, alamin na ang OpenShift virtualization ay magagamit na sa bersyon ng Tech Preview bilang bahagi ng OpenShift 3.11 at mas mataas. Ang mga may-ari ng isang umiiral nang OpenShift na subscription ay maaaring gumamit ng OpenShift virtualization na ganap na walang bayad at nang walang anumang karagdagang mga hakbang. Sa oras ng post na ito, ang OpenShift 4.4 at OpenShift virtualization 2.3 ay kasalukuyang; kung gumagamit ka ng mga nakaraang bersyon, dapat kang mag-upgrade upang makuha ang pinakabagong mga tampok. Ang isang ganap na suportadong bersyon ng OpenShift virtualization ay dapat ilabas sa ikalawang kalahati ng 2020.

Para sa karagdagang impormasyon, mangyaring sumangguni sa Dokumentasyon ng OpenShift para sa mga tagubilin sa pag-install, kabilang ang Seksyon ng Multus setup, na nagbibigay ng impormasyon tungkol sa pag-set up ng mga panlabas na network.

Pinagmulan: www.habr.com