OpenShift virtualizacija (upstream projekat – Kubernetes: KubeVirt, vidi) in ), u nekadašnjem obliku Container-native Virtualization, predstavljena je kao funkcionalnost OpenShift platforme koja je namenjena za raspoređivanje i upravljanje virtuelnim mašinama (VM), kao osnovnim entitetima Kubernetes-a. Ova vrsta zadatka je tehnološki složena zbog fundamentalnih razlika u tehnologijama. Da bi se postigla željena svrha, korišćene su već poznate tehnologije zasnovane na Red Hat Enterprise Linux-u i KVM-u, koje su s nama već dugi niz godina i dokazale su svoju efikasnost.
U ovom članku ćemo razmotriti tehničke aspekte OpenShift virtualizacije, koji omogućavaju suživot VM-a i kontejnera unutar jedne platforme koja njima upravlja kao celinom.
Računarske zadatke
Kontejneri koriste mehanizme Linux jezgra, poput namespaces i cgroups, za izolaciju procesa i upravljanje resursima. Obično se pod procesima podrazumevaju aplikacije poput Python-a, Java-e ili izvršnih datoteka, ali zapravo to mogu biti bilo koji procesi, kao što su bash, Emacs ili vim.
A šta je virtuelna mašina? Sa stanovišta hipervizora – to je takođe proces. Ali ne proces aplikacije, već KVM-proces koji je odgovoran za izvršavanje konkretne VM.
Kontejnerska slika sadrži sve alate, biblioteke i datoteke potrebne za virtuelnu mašinu KVM. Ako ispitamo pod aktivne VM, videćemo tamo pomoćne programe i procese qemu-kvm. Pored toga, imamo pristup KVM alatima za upravljanje virtuelnim mašinama, kao što su qemu-img, qemu-nbd i virsh.
Pošto je virtuelna mašina pod, ona automatski nasleđuje sve funkcionalnosti poda u Kubernetes-u. Na VM-podove se, baš kao i na uobičajene podove, primenjuju sheme i kriterijumi planera kao što su taints, tolerations, affinity i anti-affinity. Takođe dobijate prednosti u vidu visoke dostupnosti itd. Međutim, postoji jedna važna razlika: obični podovi se ne migriraju sa hosta na host na način na koji smo navikli. Ako se čvor isključi, pod na njemu se prekida i ponovo dodeljuje drugom čvoru u klasteru. A u slučaju virtuelne mašine očekujemo da vidimo živu migraciju.
Da bi se otklonio ovaj problem, stvorena je custom resource definition (CRD) koja opisuje mehanizam žive migracije, koji je odgovoran za inicijalizaciju, monitoring i upravljanje živim migracijama VM-a između radnih čvorova.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
При деактивации узла для тех его виртуальных машин, у которых в качестве eviction strategy задано Live Migration, автоматически создаются задачи миграции. Таким образом можно контролировать поведение виртуальных машин, при перемещении между нодами кластера. Вы можете как настроить Live Migration, так и управлять ВМ, как и всеми остальными подами.
Omrežje
Каждая система Kubernetes обеспечивает связь между узлами и pod’ами с помощью программных SDN-сетей. OpenShift не исключение и начиная с 3-й версии по умолчанию использует для этого OpenShiftSDN. Кроме того, в OpenShift 4 появилась новая функция под названием Multus, которая позволяет сделать доступными несколько сетей и подключать к ним pod одновременно.
С помощью 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 к сети можно . Кроме того, , развертываемый в составе OpenShift virtualization, предлагает еще один хорошо знакомый вам способ создания и управления сетевыми конфигурациями на физических узлах, которые используются под гипервизорами.
Хранение
Povezovanje in upravljanje z diski virtualnih naprav v okviru OpenShift virtualizacije se izvaja s pomočjo konceptov Kubernetes, kot so StorageClasses, PersistentVolumeClaims (PVC) in PersistentVolume (PV), ter standardnih protokolov za shranjevanje, ki so značilni za okolje Kubernetes. Tako imajo skrbniki Kubernetes in ekipe, odgovorne za aplikacije, enoten in znan mehanizem upravljanja tako za kontejnere kot za virtualne naprave. Za mnoge skrbnike virtualizacijskih okolij se lahko ta koncept zdi znan, saj uporablja isti princip ločitve konfiguracijskih datotek VM in diskov, ki se uporablja v OpenStacku in na mnogih drugih oblačnih platformah.
Vendar pa ni možno preprosto ustvariti novega diska za VM vsakič, ko je to potrebno, saj moramo ob migraciji s hipervizorja v OpenShift ohraniti podatke. Tudi ko postavljamo novo VM, je vedno bolj učinkovito to narediti iz predloge kot pa jo ustvariti od začetka. Tako potrebujemo funkcionalnost uvoza obstoječih diskov.
Za poenostavitev te naloge OpenShift virtualizacija izvaja projekt Containerized Data Importer (CDI), ki zmanjša uvoz diskovnih slik iz več virov na ustvarjanje vnosa v 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
Ta vnos aktivira CDI, kar zažene zaporedje dejanj, prikazanih na spodnji sliki:
Ko CDI zaključi, bo PVC vseboval disk virtualne naprave, pripravljen za uporabo in pretvoren v standardni format za OpenShift...
Pri delu z OpenShift virtualizacijo bo prav tako koristno OpenShift Container Storage (OCS), rešitev Red Hat, ki temelji na datotečnem sistemu Ceph in omogoča funkcionalnost trajnega shranjevanja za kontejnere. Poleg standardnih PVC metod dostopa - RWO (blok) in RWX (datotečni) - OCS zagotavlja RWX za naprave surovega bloka, kar je zelo uporabno pri organizaciji skupnega dostopa do blokov za aplikacije z visokimi zahtevami glede zmogljivosti. Poleg tega OCS podpira nov standard za zahtevo skupine objektov Object Bucket Claim, ki aplikacijam omogoča neposredno uporabo objekta shranjevanja podatkov.
Virtualne naprave v kontejnerjih
Če vas zanima, kako to deluje, vedite, da je OpenShift virtualizacija že na voljo v različici Tech Preview kot del OpenShift 3.11 in višje. Lastniki aktivne naročnine na OpenShift lahko brezplačno in brez dodatnih naporov izkoristijo OpenShift virtualizacijo. Ob objavi te objave sta aktualna OpenShift 4.4 in OpenShift virtualizacija 2.3; če uporabljate prejšnje različice, je priporočljivo, da se nadgradite za dostop do najnovejših funkcij. Popolnoma podprta različica OpenShift virtualizacije naj bi izšla v drugi polovici leta 2020.
Za dodatne informacije se obrnite na za navodila za namestitev, vključno z , ki vsebuje informacije o nastavitvi zunanjih omrežij.
Izvor: habr.com
