La virtualizzazione di OpenShift (progetto upstream – Kubernetes: KubeVirt, vedi e ), in precedenza nota come Virtualizzazione nativa ai container, è stata introdotta come funzionalità della piattaforma OpenShift, progettata per il deployment e la gestione di macchine virtuali (VM) come entità fondamentali di Kubernetes. Questo tipo di compito è tecnicamente complesso a causa delle differenze fondamentali delle tecnologie. Per raggiungere questo obiettivo, sono state utilizzate tecnologie ben note basate su Red Hat Enterprise Linux e KVM, che ci accompagnano da anni e hanno dimostrato la loro efficacia.
In questo articolo esamineremo gli aspetti tecnici della virtualizzazione di OpenShift che rendono possibile la coesistenza di VM e container all'interno di una piattaforma che li gestisce come un'unica entità.
Compiti di calcolo
I container utilizzano meccanismi del kernel Linux, come namespaces e cgroups, per isolare i processi e gestire le risorse. Di solito, con processi si intendono applicazioni Python, Java o file eseguibili, ma in realtà possono essere qualsiasi processo, incluso bash, Emacs o vim.
Che cos'è una macchina virtuale? Dal punto di vista dell'iper-vista, è anch'essa un processo. Ma non un processo applicativo, bensì un processo KVM, responsabile dell'esecuzione di una specifica VM.
Un'immagine del container contiene tutti gli strumenti, le librerie e i file necessari per la macchina virtuale KVM. Se ispezioniamo il pod di una VM in esecuzione, vedremo al suo interno helper e processi qemu-kvm. Inoltre, abbiamo accesso agli strumenti KVM per gestire le macchine virtuali, come qemu-img, qemu-nbd e virsh.
Poiché la macchina virtuale è un pod, eredita automaticamente tutta la funzionalità del pod in Kubernetes. I VM-pod, proprio come i normali pod, sono soggetti a schemi e criteri del scheduler come taints, tolerations, affinity e anti-affinity. Inoltre, si ottengono vantaggi come l'alta disponibilità, e così via. Tuttavia, c'è una differenza importante: i normali pod non migrano da un host all'altro nel senso tradizionale del termine. Se un nodo si spegne, il pod su di esso viene interrotto e riassegnato a un altro nodo nel cluster. Nel caso di una macchina virtuale, ci aspettiamo di vedere una migrazione live.
Per risolvere questo problema è stata creata una custom resource definition (CDR) che descrive il meccanismo di migrazione attiva, responsabile dell'inizializzazione, del monitoraggio e della gestione delle migrazioni attive delle VM tra i nodi di lavoro.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Durante la disattivazione di un nodo, per le macchine virtuali che utilizzano la strategia di evacuazione Live Migration, vengono automaticamente create attività di migrazione. In questo modo è possibile controllare il comportamento delle macchine virtuali durante lo spostamento tra i nodi del cluster. È possibile sia configurare la Live Migration che gestire le VM come tutte le altre pod.
Rete
Qualsiasi sistema Kubernetes assicura la comunicazione tra i nodi e i pod tramite reti SDN software. Anche OpenShift non fa eccezione e, a partire dalla versione 3, utilizza di default OpenShiftSDN. Inoltre, in OpenShift 4 è stata introdotta una nuova funzionalità chiamata Multus, che consente di rendere disponibili più reti e collegare simultaneamente i pod ad esse.
Con Multus, l'amministratore può definire reti CNI aggiuntive, che verranno poi distribuite e configurate nel cluster da un operator speciale denominato Cluster Network Operator. Successivamente, i pod vengono connessi a una o più di queste reti, di solito alla rete standard OpenShiftSDN e a un'interfaccia aggiuntiva. Dispositivi SR-IOV, Bridge Linux standard, dispositivi MACVLAN e IPVLAN possono anche essere utilizzati, se necessari per la tua VM. Nella figura sottostante, è mostrato come configurare Multus CNI per una rete bridge sull'interfaccia 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
Per quanto riguarda la virtualizzazione di OpenShift, questo significa che la VM può essere collegata direttamente a una rete esterna, bypassando l'SDN. Questo è importante per le macchine virtuali migrate su OpenShift da Red Hat Virtualization o VMware vSphere, poiché con l'accesso al secondo livello OSI non ci saranno modifiche nelle impostazioni di rete. Questo significa anche che la VM può avere un indirizzo di rete che sfugge all'SDN. In questo modo, possiamo sfruttare efficacemente adattatori di rete specializzati o collegarci direttamente a uno storage SAN…
Puoi scoprire di più su come creare e collegare macchine virtuali della virtualizzazione OpenShift alla rete . Inoltre, , distribuito con la virtualizzazione OpenShift, offre un ulteriore modo familiare per creare e gestire configurazioni di rete su nodi fisici utilizzati dai hypervisor.
Archiviazione
La connessione e la gestione dei dischi delle macchine virtuali nell'ambito della virtualizzazione OpenShift avviene utilizzando concetti di Kubernetes come StorageClasses, PersistentVolumeClaims (PVC) e PersistentVolume (PV), oltre ai protocolli di archiviazione standard dell'ambiente Kubernetes. In questo modo, gli amministratori di Kubernetes e i team responsabili delle applicazioni hanno un meccanismo di gestione unificato e familiare sia per i container che per le macchine virtuali. Per molti amministratori di ambienti di virtualizzazione, questo concetto potrebbe sembrare familiare, poiché utilizza lo stesso principio di separazione dei file di configurazione delle VM dai dischi, che si applica in OpenStack e in molte altre piattaforme cloud.
Tuttavia, non si può semplicemente creare un nuovo disco per la VM ogni volta, poiché durante la migrazione da un hypervisor a OpenShift dobbiamo mantenere i dati. Anche quando distribuiamo una nuova VM, è sempre più veloce farlo da un modello piuttosto che crearla da zero. Pertanto, abbiamo bisogno della funzionalità di importazione dei dischi esistenti.
Per semplificare questa attività, OpenShift virtualization implementa il progetto Containerized Data Importer (CDI), che riduce l'importazione delle immagini disco da diverse fonti alla creazione di una voce nel 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
È proprio questa voce che attiva il CDI, avviando la sequenza di operazioni mostrata nell'immagine sottostante:
Dopo che il CDI avrà completato il suo lavoro, il PVC conterrà un disco virtuale pronto per l'uso e convertito nel formato standard di OpenShift...
Nel lavoro con la virtualizzazione OpenShift, anche OpenShift Container Storage (OCS) può tornare utile, una soluzione Red Hat basata sul file system Ceph che implementa funzionalità di storage persistente per i container. Oltre ai metodi di accesso standard PVC – RWO (blocco) e RWX (file) – OCS fornisce RWX per dispositivi raw block, molto utile nell'organizzare l'accesso blocco condiviso per applicazioni ad alte prestazioni. Inoltre, OCS supporta il nuovo standard di richiesta per il gruppo di oggetti Object Bucket Claim, consentendo alle applicazioni di utilizzare direttamente lo storage di oggetti.
Macchine virtuali nei container
Se siete curiosi di sapere come funziona, sappiate che la virtualizzazione OpenShift è già disponibile nella versione Tech Preview a partire da OpenShift 3.11 e successive. I titolari di un abbonamento attivo a OpenShift possono usufruire della virtualizzazione di OpenShift gratuitamente e senza ulteriori complicazioni. Al momento della pubblicazione di questo post, le versioni attuali sono OpenShift 4.4 e OpenShift virtualization 2.3; se utilizzate versioni precedenti, vi consigliamo di aggiornare per ottenere le ultime funzionalità. La versione completamente supportata della virtualizzazione di OpenShift dovrebbe essere rilasciata nella seconda metà del 2020.
Per ulteriori informazioni, contattate per istruzioni sull'installazione, comprese , che forniscono dettagli sulla configurazione delle reti esterne.
Fonte: habr.com
