Виртуализация на OpenShift: контейнери, KVM и виртуални машини

Виртуализация на OpenShift (проект нагоре - Kubernetes: KubeVirt, вижте. тук и тук), родена от контейнерна виртуализация, беше въведена като функционалност на платформата OpenShift, която е предназначена за внедряване и управление на виртуални машини (VM) като основни обекти на Kubernetes. Този вид задача е технически предизвикателна поради фундаменталните различия в технологиите. За постигането на тази цел използвахме познати технологии, базирани на Red Hat Enterprise Linux и KVM, които са с нас от много години и са доказали своята ефективност.

В тази статия ще разгледаме техническите аспекти на виртуализацията на OpenShift, които правят възможно съвместното съществуване на виртуални машини и контейнери в рамките на една платформа, която ги управлява като един обект.

Изчислителни задачи

Контейнерите използват механизми на ядрото на Linux като пространства от имена и cgroups, за да изолират процеси и да управляват ресурси. Обикновено процесите се разбират като 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 мрежи, които след това ще бъдат разгърнати и конфигурирани в клъстера от специален клъстерен мрежов оператор. След това модулите се свързват към една или повече от тези мрежи, обикновено стандартния OpenShiftSDN и допълнителен интерфейс. SR-IOV устройства, стандартен Linux Bridge, MACVLAN и IPVLAN устройства могат да се използват, ако вашата виртуална машина се нуждае от това. Фигурата по-долу показва как да зададете Multis 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. Това е важно за виртуални машини, мигрирани към OpenShift от Red Hat Virtualization или VMware vSphere, тъй като ако имате достъп до втория OSI слой, няма да има промяна в мрежовите настройки. Това също означава, че VM може да има мрежов адрес, който заобикаля SDN. Така можем ефективно да използваме специализирани мрежови адаптери или да се свързваме директно към системата за съхранение през мрежата...

Можете да научите повече за това как да създавате и свързвате виртуални машини за виртуализация OpenShift към мрежата тук... Освен това, оператор nmstate, внедрен като част от виртуализацията на 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 г.

За повече информация моля свържете се Документация на OpenShift за инструкции за монтаж, включително Секция за множество настройки, който предоставя информация за настройка на външни мрежи.

Източник: www.habr.com