Виртуализация на OpenShift (проект нагоре - Kubernetes: KubeVirt, вижте. и ), преди това Container-native Virtualization, беше въведена като функция на платформата OpenShift, предназначена за внедряване и управление на виртуални машини (VM) като основни обекти на Kubernetes. Този тип задача е технически сложна поради фундаментални разлики в технологиите. За постигането на тази цел бяха използвани познати технологии, базирани на Red Hat Enterprise. Linux и KVM, които са с нас от много години и са доказали своята ефективност.
В тази статия ще разгледаме техническите аспекти на виртуализацията на OpenShift, които правят възможно съвместното съществуване на виртуални машини и контейнери в рамките на една платформа, която ги управлява като един обект.
Изчислителни задачи
Механизми за използване на контейнери Linux- основни функции, като например пространства от имена и c-групи, за изолиране на процеси и управление на ресурси. Процесите обикновено се възприемат като приложения или изпълними файлове на Python или Java, но в действителност те могат да бъдат всеки процес, като bash, Emacs или vim.
Какво е виртуална машина? От гледна точка на хипервайзора това също е процес. Но не процесът на приложение, а KVM процесът, отговорен за изпълнението на конкретна VM.
Изображението на контейнера съдържа всички инструменти, библиотеки и файлове, необходими за KVM виртуалната машина. Ако инспектираме pod на работеща VM, ще видим там помощници и qemu-kvm процеси. Освен това имаме достъп до KVM инструменти за управление на виртуални машини като qemu-img, qemu-nbd и virsh.
Тъй като виртуалната машина е pod, тя автоматично наследява цялата функционалност на pod в Kubernetes. VM pods, точно като обикновените pods, са обект на схеми и критерии за планиране като петна, толерантности, афинитет и антиафинитет. Вие също така получавате предимствата на висока наличност и т.н. Има обаче една важна разлика: обикновените подове не мигрират от хост на хост в обичайния смисъл. Ако даден възел излезе офлайн, групата в него се прекратява и се пренасочва към друг възел в клъстера. А в случай на виртуална машина, очакваме да видим миграция на живо.
За да се преодолее тази празнина, беше създадена персонализирана дефиниция на ресурс (CDR), за да се опише механизмът за миграция на живо, който отговаря за инициализиране, наблюдение и управление на миграции на живо на виртуални машини между работни възли.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Когато даден възел е деактивиран, задачите за миграция се създават автоматично за онези виртуални машини, които имат мигриране на живо, зададено като стратегия за изгонване. По този начин можете да контролирате поведението на виртуалните машини при преместване между клъстерни възли. Можете както да конфигурирате Live Migration, така и да управлявате VM, както всички други подове.
Сеть
Всяка система на Kubernetes осигурява комуникация между възли и подове, използвайки софтуерни SDN мрежи. OpenShift не е изключение и, започвайки от версия 3, използва OpenShiftSDN по подразбиране за това. В допълнение, OpenShift 4 има друга нова функция, наречена Multus, която ви позволява да направите множество мрежи достъпни и да свържете подове към тях едновременно.
С помощта на Multus, администраторът може да дефинира допълнителни CNI мрежи, които след това се разполагат и конфигурират в клъстера с помощта на специален оператор на клъстерна мрежа. След това подовете (pods) се свързват към една или повече от тези мрежи, обикновено стандартната 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, това означава, че VM може да бъде свързан директно към външна мрежа, заобикаляйки SDN. Това е важно за виртуални машини, мигрирани към OpenShift от Red Hat Virtualization или VMware vSphere, тъй като ако имате достъп до втория OSI слой, няма да има промяна в мрежовите настройки. Това също означава, че VM може да има мрежов адрес, който заобикаля SDN. Така можем ефективно да използваме специализирани мрежови адаптери или да се свързваме директно към системата за съхранение през мрежата...
Можете да научите повече за това как да създавате и свързвате виртуални машини за виртуализация OpenShift към мрежата ... Освен това, , внедрен като част от виртуализацията на OpenShift, предлага друг познат начин за създаване и управление на мрежови конфигурации на физически възли, които се използват под хипервайзори.
Хранение
Свързването и управлението на дискове на виртуални машини в рамките на виртуализацията на OpenShift се извършва с помощта на концепции на Kubernetes като StorageClasses, PersistentVolumeClaims (PVC) и PersistentVolume (PV), както и протоколи за съхранение, стандартни за средата на Kubernetes. Това дава на администраторите и екипите на приложения на Kubernetes общ, познат начин за управление както на контейнери, така и на виртуални машини. И за много администратори на среди за виртуализация тази концепция може да звучи познато, защото използва същия принцип на разделяне на VM конфигурационни файлове и дискове, който се използва в OpenStack и много други облачни платформи.
Не можем обаче просто да създаваме нов диск за виртуалната машина всеки път, тъй като при мигриране от хипервайзора към OpenShift трябва да запазим данните. Да, дори когато внедрим нова виртуална машина, винаги е по-бързо да го направим от шаблон, отколкото да я създадем от нулата. Следователно имаме нужда от функционалност за импортиране на съществуващи дискове.
За да опрости тази задача, виртуализацията на 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 virtualization 2.3 са актуални; ако използвате предишни версии, тогава трябва да надстроите, за да получите най-новите функции. Напълно поддържана версия на виртуализацията OpenShift трябва да бъде пусната през втората половина на 2020 г.
За повече информация моля свържете се за инструкции за монтаж, включително , който предоставя информация за настройка на външни мрежи.
Източник: www.habr.com
