OpenShift виртуализация (апстрим проект – Kubernetes: KubeVirt, см. и ), в девичеството Container-native Virtualization, беше представен като функционалност на платформата OpenShift, предназначена за разгръщане и управление на виртуални машини (ВМ) като основни единици на Kubernetes. Тази задача е технически сложна поради фундаменталните различия в технологиите. За постигане на поставената цел бяха използвани технологии, познати ни от дълго време на базата на Red Hat Enterprise Linux и KVM, които доказаха своята ефективност.
В тази статия ще разгледаме техническите аспекти на OpenShift виртуализация, които правят възможно съжителството на ВМ и контейнери в рамките на една платформа, която управлява тях като единно цяло.
Изчислителни задачи
Контейнерите използват механизми на Linux ядрото, като namespaces и cgroups, за изолация на процесите и управление на ресурсите. Обикновено под процеси се разбират приложения на Python, Java или изпълними файлове, но всъщност това могат да бъдат всякакви процеси, като bash, Emacs или vim.
А какво е виртуална машина? От гледна точка на хипервизора – това също е процес. Но не просто процес на приложение, а KVM процес, отговарящ за изпълнението на конкретна ВМ.
Контейнерният образ съдържа всички инструменти, библиотеки и файлове, необходими за виртуалната машина KVM. Ако инспектираме pod на работеща ВМ, ще видим помощи и процеси qemu-kvm. Освен това имаме достъп до KVM инструменти за управление на виртуалните машини, като qemu-img, qemu-nbd и virsh.
Тъй като виртуалната машина е 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
При деактивиране на възел за тези виртуални машини, при които стратегията за изхвърляне е зададена на Live Migration, автоматично се създават миграционни задачи. По този начин можете да контролирате поведението на виртуалните машини при преместване между възлите на клъстера. Можете както да конфигурирате Live Migration, така и да управлявате ВМ, както и всички останали подове.
Мрежа
Всяка Kubernetes система осигурява свързаност между възлите и подовете с помощта на софтуерни SDN мрежи. OpenShift не е изключение и от трета версия по подразбиране използва OpenShiftSDN. Освен това, в OpenShift 4 се появи нова функция, наречена Multus, която позволява наличието на множество мрежи и свързването на подове едновременно.
С помощта на Multus администраторът може да зададе допълнителни CNI мрежи, които след това ще бъдат разгръщани и конфигурирани в клъстера от специалния оператор Cluster Network Operator. След това подовете се свързват с една или повече от тези мрежи, обикновено с стандартния 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 виртуализацията, това означава, че ВМ може да бъде свързана директно към външната мрежа, като избегне SDN. Това е важно за виртуалните машини, преместени на OpenShift от Red Hat Virtualization или VMware vSphere, тъй като при наличие на достъп на второ ниво OSI няма промяна в мрежовите настройки. Това също означава, че ВМ може да има мрежов адрес, при обращенията към който се избягва SDN. По този начин можем ефективно да използваме специализирани мрежови адаптери или директно да се свързваме с СХД…
Можете да научите повече за това как да създавате и свързвате виртуални машини OpenShift виртуализация към мрежата . Освен това, , разгръщан в състава на OpenShift виртуализация, предлага още един добре познат начин за създаване и управление на мрежовите конфигурации на физическите възли, които се използват под хипервизорите.
Съхранение
Свързването и управлението на дисковете на виртуалните машини в рамките на OpenShift виртуализацията се извършва с помощта на концепции на Kubernetes, като StorageClasses, PersistentVolumeClaims (PVC) и PersistentVolume (PV), както и стандартни протоколи за съхранение, типични за средата на Kubernetes. По този начин администраторите на Kubernetes и екипите, отговорни за приложенията, получават единен и познат механизъм за управление както на контейнерите, така и на виртуалните машини. За много администратори на виртуализационни среди, тази концепция може да изглежда позната, тъй като използва същия принцип на разделяне на конфигурационни файлове за ВМ и дискове, който се прилага в 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 за устройства raw block, което е много полезно при организирането на общ достъп до блок за приложения с високи изисквания за производителност. Освен това, OCS поддържа новия стандарт за искане на групи обекти Object Bucket Claim, който позволява на приложенията да използват директно обектното хранилище на данни.
Виртуални машини в контейнери
Ако искате да проверите как работи това, знайте, че OpenShift виртуализацията вече е налична в вариант Tech Preview в OpenShift 3.11 и по-високи версии. Собствениците на активни абонаменти за OpenShift могат да се възползват от OpenShift виртуализацията напълно безплатно и без допълнителни усилия. Към момента на публикуването на този пост, актуални са OpenShift 4.4 и OpenShift виртуализация 2.3. Ако използвате по-стари версии, за да получите последните функции, е добре да извършите обновление. Пълната версия на OpenShift виртуализацията трябва да излезе през втората половина на 2020 година.
За допълнителна информация се свържете с за инструкции по инсталация, включително , където има информация за настройка на външни мрежи.
Източник: habr.com
