OpenShift virtualization: кантэйнеры, KVM і віртуальныя машыны

OpenShift virtualization (апстрым праект – Kubernetes: KubeVirt, гл. тут и тут), у дзявоцтве Container-native Virtualization, быў прадстаўлены, як функцыянал платформы OpenShift, які прызначаны для разгортвання і кіраванні віртуальнымі машынамі (ВМ), як базавымі сутнасцямі Kubernetes. Такая задача з'яўляецца тэхнічна складанай, з прычыны фундаментальных адрозненняў тэхналогій. Для таго, каб дамагчыся пастаўленай мэты, былі скарыстаны ўсім знаёмыя тэхналогіі на базе Red Hat Enterprise Linux і KVM, якія з намі не адзін год і даказалі сваю эфектыўнасць.

OpenShift virtualization: кантэйнеры, KVM і віртуальныя машыны

У гэтым артыкуле мы разгледзім тэхнічныя аспекты OpenShift virtualization, якія робяць магчымым суіснаванне ВМ і кантэйнераў у рамках адной платформы, якая кіруе імі, як адзіным цэлым.

Вылічальныя задачы

Кантэйнеры задзейнічаюць механізмы Linux-ядра, такія як namespaces і cgroups, для ізаляцыі працэсаў і кіраванні рэсурсамі. Звычайна пад працэсамі разумеюцца прыкладанні Python, Java ці выкананыя файлы, але насамрэч гэта могуць быць любыя працэсы, той жа bash, Emacs ці vim.

А што такое віртуальная машына? З пункту гледжання гіпервізара - гэта таксама працэс. Але толькі не працэс прыкладання, а KVM-працэс, які адказвае за выкананне канкрэтнай ВМ.

OpenShift virtualization: кантэйнеры, KVM і віртуальныя машыны

Кантэйнерная выява ўтрымоўвае ў сабе ўсе прылады, бібліятэкі і файлы, неабходныя для віртуальнай машыны KVM. Калі праінспектаваць pod працавальнай ВМ, то мы ўбачым тамака хелперы і працэсы qemu-kvm. Акрамя таго, у нас ёсць доступ да KVM-інструментаў для кіравання віртуальнымі машынамі, такім як qemu-img, qemu-nbd і virsh.

OpenShift virtualization: кантэйнеры, KVM і віртуальныя машыны

Паколькі віртуальная машына гэта pod, яна аўтаматам успадкоўвае ўсю функцыянальнасць pod'а ў Kubernetes. Да ВМ-pod'ам сапраўды гэтак жа, як і звычайным pod'ам, ужываюцца схемы і крытэры планавальніка накшталт taints, tolerations, affinity і anti-affinity. Таксама вы атрымліваеце перавагі ў выглядзе высокай даступнасці і г.д. Аднак ёсць адно важнае адрозненне: звычайныя pod'ыне мігруюць з хаста на хост у звыклым нам сэнсе. Калі вузел адключаецца, то pod на ім перарываецца і пераназначаецца на іншы вузел у кластары. А ў выпадку віртуальнай машыны мы чакаем убачыць жывую міграцыю.

Для ўхілення гэтага прабелу быў створаны custom resource definition (CDR), які апісвае механізм жывой міграцыі, які адказвае за ініцыялізацыю, маніторынг і кіраванне жывымі міграцыямі ВМ паміж працоўнымі вузламі.

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

Пры дэактывацыі вузла для тых яго віртуальных машын, у якіх у якасці eviction strategy зададзена Live Migration, аўтаматычна ствараюцца задачы міграцыі. Такім чынам можна кантраляваць паводзіны віртуальных машын, пры перасоўванні паміж нодамі кластара. Вы можаце як наладзіць Live Migration, так і кіраваць ВМ, як і ўсімі астатнімі подамі.

сетка

Любая Kubernetes-сістэма забяспечвае сувязь паміж вузламі і pod'амі з дапамогай праграмных SDN-сетак. OpenShift не выключэнне і пачынаючы з 3. Версіі па змаўчанні выкарыстоўвае для гэтага OpenShiftSDN. Акрамя таго, у OpenShift 4 з'явіўся яшчэ адна новая функцыя пад назовам Multus, якая дазваляе зрабіць даступным некалькі сетак і падлучаць да іх pod адначасова.

OpenShift virtualization: кантэйнеры, KVM і віртуальныя машыны

З дапамогай Multus адміністратар можа задаць дадатковыя сеткі CNI, якія потым будуць разгортваюцца і наладжваюцца на кластары спецыяльным аператарам Cluster Network Operator. Пасля чаго pod'ы падлучаюцца да адной ці некалькіх з гэтых сетак, звычайна да стандартнага OpenShiftSDN і дадатковаму інтэрфейсу. Прылады SR-IOV, стандартныя Linux Bridge, прылады MACVLAN і IPVLAN - усё гэта таксама можна выкарыстоўваць, калі гэта трэба вашай ВМ. На малюнку ніжэй паказана, як задаць Multus CNI для bridge сеткі на інтэрфейсе 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 virtualization гэта азначае, што ВМ можна падлучыць да вонкавай сеткі напроста, абыходзячы SDN. Гэта важна для віртуальных машын, перанесеных на OpenShift з Red Hat Virtualization ці VMware vSphere, бо пры наяўнасці доступу на другі ўзровень OSI не будзе змены сеткавых налад. Гэта таксама азначае, што ВМ можа мець сеткавы адрас, звароты да якога абмінуць SDN. Такім чынам, мы можам эфектыўна выкарыстоўваць спецыялізаваныя сеткавыя адаптары, ці падлучацца па сетцы да СХД напрамую…

Падрабязней даведацца аб тым, як ствараць і падключаць віртуальныя машыны OpenShift virtualization да сеткі можна тут. Акрамя таго, nmstate operator, які разгортваецца ў складзе OpenShift virtualization, прапануе яшчэ адзін добра знаёмы вам спосаб стварэння і кіраванні сеткавымі канфігурацыямі на фізічных вузлах, якія выкарыстоўваюцца пад гіпервізорамі.

захоўванне

Падлучэнне і кіраванне дыскамі віртуальных машын у рамках OpenShift virtualization выконваецца з выкарыстаннем такіх Kubernetes-канцэпцый як StorageClasses, PersistentVolumeClaims (PVC) і PersistentVolume (PV), а таксама стандартных для асяроддзя Kubernetes пратаколаў захоўвання. Такім чынам, адміністратары Kubernetes і якія адказваюць за прыкладанні каманды атрымліваюць адзіны і звыклы механізм кіравання як для кантэйнераў, так і для віртуальных машын. А для шматлікіх адміністратараў асяроддзяў віртуалізацыі гэтая канцэпцыя можа здацца знаёмай, паколькі ў ёй выкарыстоўваюцца той жа прынцып падзелу файлаў канфігурацыі ВМ і кружэлак, які ўжываецца ў OpenStack і на шматлікіх іншых хмарных платформах.

Аднак нельга проста кожны раз ствараць новую кружэлку для ВМ, бо пры міграцыі з гіпервізара ў OpenShift, нам неабходна захаваць дадзеныя. Ды нават калі мы разгортваем новую ВМ, гэта заўсёды хутчэй зрабіць з шаблона, чым стварыць з нуля. Такім чынам нам неабходны функцыянал імпарту наяўных дыскаў.

Для спрашчэння гэтай задачы OpenShift virtualization разгортвае праект 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, запускаючы паслядоўнасць дзеянняў, паказаных на малюнку ніжэй:

OpenShift virtualization: кантэйнеры, KVM і віртуальныя машыны

Пасля таго, як CDI адпрацуе, PVC будзе змяшчаць дыск віртуальнай машыны гатовы да выкарыстання і прыведзены ў стандартны для OpenShift фармат…
Пры працы з OpenShift virtualization таксама спатрэбіцца OpenShift Container Storage (OCS), рашэнне Red Hat на аснове файлавай сістэмы Ceph, якое рэалізуе функцыянал сталага сховішча для кантэйнераў. У дадатак да стандартных PVC-метадаў доступу – RWO (блочны) і RWX (файлавы) – OCS падае RWX для прылад raw block, што вельмі карысна пры арганізацыі сумеснага блокавага доступу для прыкладанняў з высокімі патрабаваннямі да прадукцыйнасці. Акрамя таго, OCS падтрымлівае новы стандарт запыту групы аб'ектаў Object Bucket Claim, які дазваляе прыкладанням напрамую выкарыстоўваць аб'ектнае сховішча дадзеных.

Віртуальныя машыны ў кантэйнерах

Калі вам цікава праверыць, як гэта працуе, то ведайце, што OpenShift virtualization ужо даступна ў варыянце Tech Preview у складзе OpenShift 3.11 і вышэй. Уладальнікі дзеючай падпіскі на OpenShift могуць скарыстацца OpenShift virtualization цалкам бясплатна і без якіх-небудзь дадатковых рухаў цела. На момант выхаду гэтай пасады актуальнымі з'яўляюцца OpenShift 4.4 і OpenShift virtualization 2.3, калі вы выкарыстоўваеце папярэднія версіі, то для атрымання апошніх функцый варта абнавіцца. Цалкам падтрымліваемая версія OpenShift virtualization павінна выйсці ў другой палове 2020 гады.

Для атрымання дадатковай інфармацыі звернецеся да дакументацыі па OpenShift за інструкцыямі па ўстаноўцы, у тым ліку раздзел па наладзе Multus, дзе прыводзяцца звесткі аб наладзе вонкавых сетак.

Крыніца: habr.com

Дадаць каментар