Virtualizace OpenShift (projekta upstream – Kubernetes: KubeVirt, poznámka), dříve známá jako Container-native Virtualization, byla představena jako funkce platformy OpenShift, která je určena pro nasazení a správu virtuálních strojů (VM) jako základních entit Kubernetes. Tento úkol je technicky složitý kvůli fundamentálním rozdílům v technologiích. Abychom dosáhli stanoveného cíle, byly použity technologie známé díky Red Hat Enterprise Linux a KVM, které s námi jsou již několik let a prokázaly svou účinnost. a V tomto článku se podíváme na technické aspekty virtualizace OpenShift, které umožňují koexistenci VM a kontejnerů v rámci jedné platformy, která s nimi spravuje jako s jednotným celkem.
Výpočetní úkoly
Kontejnery využívají mechanismy jádra Linuxu, jako jsou namespaces a cgroups, pro izolaci procesů a správu zdrojů. Obvykle se pod procesy rozumí aplikace Python, Java nebo spustitelné soubory, ale ve skutečnosti to mohou být jakékoli procesy, například bash, Emacs nebo vim.
A co je to virtuální stroj? Z pohledu hypervisoru – to je také proces. Ale ne proces aplikace, nýbrž KVM-proces, který zodpovídá za provádění konkrétního VM.
Kontejnerový obraz obsahuje všechny nástroje, knihovny a soubory potřebné pro virtuální stroj KVM. Pokud prozkoumáme pod běžícího VM, uvidíme tam pomocníky a procesy qemu-kvm. Kromě toho máme přístup k nástrojům KVM pro správu virtuálních strojů, jako jsou qemu-img, qemu-nbd a virsh.
Protože virtuální stroj je pod, automaticky zdědí veškerou funkcionalitu podu v Kubernetes. K VM-podům se stejně jako k běžným podům aplikují schémata a kritéria plánovače jako tainty, tolerances, affinity a anti-affinity. Také získáváte výhody ve formě vysoké dostupnosti atd. Existuje však jedno důležité rozdílné: běžné pody se nemigrují z hostitele na hostitele v obvyklém smyslu. Pokud se uzel vypne, pod na něm se přeruší a převedou na jiný uzel v klastru. V případě virtuálního stroje však očekáváme vidět živou migraci.
Aby bylo možné tento nedostatek odstranit, byla vytvořena vlastní definice zdrojové definice (CDR), která popisuje mechanismus živé migrace, který zajišťuje inicializaci, sledování a správu živých migrací VM mezi pracovním uzly.
Pro odstranění tohoto problému byla vytvořena vlastní definice zdroje (CDR), která popisuje mechanismus živé migrace, jenž zodpovídá za inicializaci, monitorování a řízení živých migrací VM mezi pracovními uzly.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Při deaktivaci uzlu se automaticky vytvářejí migrační úlohy pro ty virtuální stroje, které mají nastavenou strategii evakuace Live Migration. Tímto způsobem lze řídit chování virtuálních strojů při přesunu mezi uzly clustera. Můžete jak nastavit Live Migration, tak spravovat VM, jakož i všechny ostatní pody.
Síť
Každý Kubernetes systém zajišťuje spojení mezi uzly a pody pomocí softwarových SDN sítí. OpenShift není výjimkou a od třetí verze používá pro tento účel standardně OpenShiftSDN. Kromě toho se v OpenShift 4 objevila nová funkce nazvaná Multus, která umožňuje zpřístupnit více sítí a připojit k nim pody současně.
Pomocí Multus může správce určit další CNI sítě, které jsou následně nasazeny a konfigurovány v clusteru speciálním operátorem Cluster Network Operator. Poté se pody připojí k jedné nebo více z těchto sítí, obvykle k standardnímu OpenShiftSDN a dalšímu rozhraní. Zařízení SR-IOV, standardní Linux Bridge, zařízení MACVLAN a IPVLAN – to vše lze také použít, pokud to vaše VM potřebuje. Na obrázku níže je uvedeno, jak nastavit Multus CNI pro bridge síť na rozhraní 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
V rámci virtualizace OpenShift to znamená, že VM lze připojit přímo k externí síti, obcházející SDN. To je důležité pro virtuální stroje, které byly přesunuty na OpenShift z Red Hat Virtualization nebo VMware vSphere, protože při přístupu na druhé úrovni OSI nedojde ke změně síťových nastavení. To také znamená, že VM může mít síťovou adresu, na kterou se přístupy obcházejí SDN. Tímto způsobem můžeme efektivně využívat specializované síťové adaptéry nebo se přímo připojit k úložným systémům...
Více informací o tom, jak vytvářet a připojovat virtuální stroje OpenShift virtualization k síti, naleznete . Kromě toho, , nasazovaný v rámci OpenShift virtualization, nabízí další dobře známý způsob, jak vytvářet a spravovat síťové konfigurace na fyzických uzlech, které jsou používány pod hypervizory.
Úložiště
Připojení a správa disků virtuálních strojů v rámci OpenShift virtualizace se provádí s využitím konceptů Kubernetes, jako jsou StorageClasses, PersistentVolumeClaims (PVC) a PersistentVolume (PV), jakož i standardních protokolů pro ukládání dat v prostředí Kubernetes. Tímto způsobem získávají administrátoři Kubernetes a týmy odpovědné za aplikace jednotný a známý mechanismus správy jak pro kontejnery, tak pro virtuální stroje. Pro mnohé administrátory virtualizačních prostředí může tento koncept vypadat povědomě, protože využívá stejný princip oddělení konfiguračních souborů VM a disků, který se aplikuje v OpenStacku a na mnoha dalších cloudových platformách.
Nelze však pokaždé vytvářet nový disk pro VM, protože při migraci z hypervisoru do OpenShift je nutné uchovat data. Dokonce i při nasazování nového VM je vždy rychlejší to udělat ze šablony, než začít od nuly. Proto potřebujeme funkčnost importu existujících disků.
Pro zjednodušení tohoto úkolu OpenShift virtualizace nasazuje projekt Containerized Data Importer (CDI), který zjednodušuje import diskových obrazů z několika zdrojů na vytvoření záznamu v 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
Tento záznam aktivuje CDI a spustí posloupnost akcí, jak je znázorněno na obrázku níže:
Jakmile CDI dokončí svou práci, PVC bude obsahovat disk virtuálního stroje připravený k použití a převedený do standardního formátu OpenShift...
Při práci s OpenShift virtualizací se také hodí OpenShift Container Storage (OCS), řešení Red Hatu založené na souborovém systému Ceph, které implementuje funkčnost trvalého úložiště pro kontejnery. Kromě standardních metod přístupu PVC – RWO (blokový) a RWX (soubrový) – OCS poskytuje RWX pro zařízení raw block, což je velmi užitečné při organizaci sdíleného blokového přístupu pro aplikace s vysokými požadavky na výkon. Navíc OCS podporuje nový standard žádosti o skupiny objektů Object Bucket Claim, který umožňuje aplikacím přímo využívat objektové úložiště.
Virtuální stroje v kontejnerech
Pokud máte zájem zjistit, jak to funguje, vězte, že OpenShift virtualization je již dostupná ve variantě Tech Preview v rámci OpenShift 3.11 a vyšších. Majitelé aktivního předplatného pro OpenShift mohou využívat OpenShift virtualization zcela zdarma a bez jakýchkoli dalších kroků. K datu vydání tohoto příspěvku jsou aktuální verze OpenShift 4.4 a OpenShift virtualization 2.3; pokud používáte předchozí verze, doporučuje se aktualizovat pro získání posledních funkcí. Plně podporovaná verze OpenShift virtualization by měla vyjít ve druhé polovině roku 2020.
Pro další informace se obraťte na pro pokyny k instalaci, včetně , která obsahuje informace o nastavení externích sítí.
Zdroj: habr.com
