OpenShift virtualization (апстрім проект – Kubernetes: KubeVirt, див. и ), у дівочості Container-native Virtualization, був представлений як функціонал платформи OpenShift, який призначений для розгортання та управління віртуальними машинами (ВМ), як базовими сутностями Kubernetes. Такі завдання є технічно складною, внаслідок фундаментальних відмінностей технологій. Для того, щоб досягти поставленої мети, були використані всім знайомі технології на базі Red Hat Enterprise Linux та KVM, які з нами не один рік довели свою ефективність.
У цій статті ми розглянемо технічні аспекти OpenShift virtualization, які уможливлюють співіснування ВМ та контейнерів в рамках однієї платформи, яка керує ними як єдиним цілим.
Обчислювальні завдання
Контейнери використовують механізми Linux-ядра, такі як namespaces і cgroups, для ізоляції процесів і управління ресурсами. Зазвичай під процесами розуміються програми Python, Java або файли, що виконуються, але насправді це можуть бути будь-які процеси, той же bash, Emacs або vim.
А що таке віртуальна машина? З погляду гіпервізора – це також процес. Але тільки процес докладання, а KVM-процес, відповідальний виконання конкретної ВМ.
Контейнерний образ містить у собі всі інструменти, бібліотеки та файли, необхідні для віртуальної машини KVM. Якщо проінспектувати працюючу ВМ, то ми побачимо там хелпери і процеси 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
При деактивації вузла для тих його віртуальних машин, у яких як eviction strategy задано Live Migration, автоматично створюються завдання міграції. Таким чином, можна контролювати поведінку віртуальних машин, при переміщенні між нодами кластера. Ви можете як налаштувати Live Migration, так і керувати ВМ, як і всіма іншими подами.
Мережа
Будь-яка Kubernetes-система забезпечує зв'язок між вузлами та pod'ами за допомогою програмних SDN-мереж. OpenShift не є винятком і починаючи з 3-ї версії за замовчуванням використовує для цього OpenShiftSDN. Крім того, в OpenShift 4 з'явився ще одна нова функція під назвою Multus, яка дозволяє зробити доступним кілька мереж і підключати до них одночасно.
За допомогою 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, пропонує ще один добре знайомий вам спосіб створення та керування мережними конфігураціями на фізичних вузлах, що використовуються під гіпервізорами.
Зберігання
Підключення та керування дисками віртуальних машин у рамках OpenShift virtualization виконується з використанням таких Kubernetes-концепцій як StorageClasses, PersistentVolumeClaims (PVC) та PersistentVolume (PV), а також стандартних для середовища Kubernetes протоколів зберігання. Таким чином, адміністратори Kubernetes і відповідальні за програми команди отримують єдиний і звичний механізм управління як для контейнерів, так і для віртуальних машин. А для багатьох адміністраторів серед віртуалізації ця концепція може здатися знайомою, оскільки в ній використовуються той же принцип поділу файлів конфігурації ВМ та дисків, який застосовується в OpenStack та на багатьох інших платформах хмар.
Однак не можна просто щоразу створювати новий диск для ВМ, оскільки при міграції з гіпервізора до OpenShift нам необхідно зберегти дані. Та навіть коли ми розгортаємо нову ВМ, це завжди швидше зробити із шаблону, ніж створити з нуля. Таким чином, нам необхідний функціонал імпорту наявних дисків.
Для спрощення цього завдання OpenShift virtualization розгортає проект 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 virtualization також стане в нагоді OpenShift Container Storage (OCS), рішення Red Hat на основі файлової системи Ceph, що реалізує функціонал постійного сховища для контейнерів. Крім стандартних PVC-методів доступу – RWO (блоковий) та RWX (файловий) – OCS надає RWX для пристроїв raw block, що дуже корисно при організації спільного блокового доступу для додатків з високими вимогами до продуктивності. Крім того, OCS підтримує новий стандарт запиту групи об'єктів Object Bucket Claim, що дозволяє програмам безпосередньо використовувати об'єктне сховище даних.
Віртуальні машини у контейнерах
Якщо вам цікаво перевірити, як це працює, знайте, що OpenShift virtualization вже доступна у варіанті Tech Preview у складі OpenShift 3.11 і вище. Власники підписки на OpenShift можуть скористатися OpenShift virtualization абсолютно безкоштовно і без будь-яких додаткових рухів тіла. На момент виходу цієї поста актуальними є OpenShift 4.4 та OpenShift virtualization 2.3, якщо ви використовуєте попередні версії, то для отримання останніх функцій варто оновитись. Версія OpenShift virtualization, що повністю підтримується, повинна вийти в другій половині 2020 року.
Для отримання додаткової інформації зверніться до за інструкціями з встановлення, включаючи , де наведено відомості про налаштування зовнішніх мереж.
Джерело: habr.com