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

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-a в 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 система осигурява свързаност между възлите и 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 виртуализацията, това означава, че ВМ може да бъде свързана директно към външната мрежа, заобикаляйки SDN. Това е важно за виртуалните машини, мигрирани на OpenShift от Red Hat Virtualization или VMware vSphere, тъй като при наличието на достъп на второ ниво OSI, мрежовите настройки няма да се променят. Това също означава, че ВМ може да има мрежов адрес, за който заявките за достъп ще заобикалят SDN. По този начин можем ефективно да използваме специализирани мрежови адаптери или да се свързваме директно към СХД.

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

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

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