La virtualizzazione OpenShift (progetto upstream – Kubernetes: KubeVirt, vedi e ), in precedenza conosciuta come Virtualizzazione nativa per container, è stata introdotta come funzionalità della piattaforma OpenShift, progettata per il deploy e la gestione di macchine virtuali (VM) come entità fondamentali di Kubernetes. Questo tipo di compito risulta tecnicamente complesso, a causa delle differenze fondamentali tra le tecnologie. Per raggiungere l'obiettivo prefissato, sono state utilizzate le tecnologie familiari basate su Red Hat Enterprise Linux e KVM, che sono con noi da molti anni e hanno dimostrato la loro efficacia.
In questo articolo esamineremo gli aspetti tecnici della virtualizzazione OpenShift che rendono possibile la coesistenza di VM e container all'interno di una stessa piattaforma che li gestisce come un'entità unica.
Compiti computazionali
I container sfruttano meccanismi del kernel Linux, come namespaces e cgroups, per isolare i processi e gestire le risorse. Solitamente, con processi si intendono applicazioni Python, Java o file eseguibili, ma in realtà possono essere qualsiasi processo, come il bash, Emacs o vim.
Ma cos'è una macchina virtuale? Dal punto di vista dell'hypervisor, è anch'essa un processo. Ma non un processo di applicazione, bensì un processo KVM, responsabile dell'esecuzione di una specifica VM.
L'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 helper e processi qemu-kvm. Inoltre, abbiamo accesso agli strumenti KVM per la gestione delle macchine virtuali, come qemu-img, qemu-nbd e virsh.
Poiché la macchina virtuale è un pod, eredita automaticamente tutta la funzionalità di un pod in Kubernetes. Ai pod di VM, proprio come ai normali pod, si applicano schemi e criteri del pianificatore come taints, tolerations, affinity e anti-affinity. Inoltre, si ottengono vantaggi come alta disponibilità, ecc. Tuttavia, c'è una differenza importante: i normali pod non migrano da un host a un altro nel senso a cui siamo abituati. Se un nodo si spegne, il pod su di esso viene interrotto e riprogrammato su un altro nodo nel cluster. Nel caso di una macchina virtuale, ci aspettiamo di vedere la migrazione in tempo reale.
Per risolvere questo problema è stata creata una custom resource definition (CDR) che descrive il meccanismo di migrazione live, responsabile per l'inizializzazione, il monitoraggio e la gestione delle migrazioni live 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 a cui è stata assegnata la Live Migration come strategia di eviction, vengono automaticamente create delle attività di migrazione. In questo modo, è possibile controllare il comportamento delle macchine virtuali durante il loro spostamento tra i nodi del cluster. Puoi configurare sia la Live Migration che gestire le VM come tutte le altre pod.
Rete
Qualsiasi sistema Kubernetes fornisce connettività tra i nodi e i pod utilizzando reti SDN software-defined. Anche OpenShift non fa eccezione, e a partire dalla terza versione utilizza per default OpenShiftSDN. Inoltre, in OpenShift 4 è stata introdotta una nuova funzionalità chiamata Multus, che permette di rendere disponibili più reti e di connettere i pod a esse simultaneamente.
Con Multus, l'amministratore può specificare reti CNI aggiuntive che verranno poi distribuite e configurate nel cluster da un operatore speciale noto come Cluster Network Operator. I pod possono quindi collegarsi a una o più di queste reti, solitamente alla rete standard OpenShiftSDN e a un'interfaccia aggiuntiva. Possono essere utilizzati anche dispositivi SR-IOV, standard Linux Bridge, dispositivi MACVLAN e IPVLAN, se necessario 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
In relazione a OpenShift virtualization, questo significa che le VM possono essere collegate direttamente a una rete esterna, bypassando SDN. Questo è importante per le macchine virtuali migrate su OpenShift da Red Hat Virtualization o VMware vSphere, poiché, con accesso al secondo livello OSI, non ci sarà variazione delle impostazioni di rete. Ciò significa anche che le VM possono avere un indirizzo di rete le cui comunicazioni bypassano SDN. In questo modo, possiamo utilizzare efficacemente adattatori di rete specializzati o connetterci direttamente a un'archiviazione di rete...
Per ulteriori informazioni su come creare e collegare le macchine virtuali di OpenShift virtualization alla rete, puoi . Inoltre, , distribuito all'interno di OpenShift virtualization, offre un altro modo ben noto per creare e gestire configurazioni di rete su nodi fisici utilizzati dai hypervisors.
Archiviazione
La connessione e la gestione dei dischi delle macchine virtuali in OpenShift virtualization avviene utilizzando concetti Kubernetes come StorageClasses, PersistentVolumeClaims (PVC) e PersistentVolume (PV), così come protocolli di archiviazione standard per l'ambiente Kubernetes. In questo modo, gli amministratori Kubernetes e i team responsabili delle applicazioni hanno a disposizione un meccanismo di gestione unificato e familiare sia per i container sia per le macchine virtuali. Per molti amministratori di ambienti di virtualizzazione, questo concetto potrebbe sembrare familiare, poiché utilizza lo stesso principio di separazione tra file di configurazione delle VM e dischi, applicato in OpenStack e in molte altre piattaforme cloud.
Tuttavia, non è possibile creare ogni volta un nuovo disco per la VM, poiché durante la migrazione da un hypervisor a OpenShift dobbiamo mantenere i dati. Anche quando stiamo distribuendo una nuova VM, è sempre più veloce farlo da un template piuttosto che creare da zero. Pertanto, abbiamo bisogno della funzionalità di importazione dei dischi esistenti.
Per semplificare questo compito, OpenShift virtualization distribuisce il progetto Containerized Data Importer (CDI), che riduce l'importazione di immagini disco da più fonti alla creazione di una registrazione in 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
Questa registrazione attiva CDI, avviando la sequenza di azioni mostrata nell'immagine sottostante:
Dopo che CDI ha completato il suo lavoro, il PVC conterrà un disco della macchina virtuale pronto per l'uso e convertito nel formato standard di OpenShift…
Nel lavorare con OpenShift virtualization, è utile anche OpenShift Container Storage (OCS), una soluzione di Red Hat basata sul file system Ceph, che implementa funzionalità di storage persistente per i container. Oltre ai metodi di accesso PVC standard – RWO (blocco) e RWX (file) – OCS fornisce RWX per dispositivi raw block, molto utile per organizzare l'accesso condiviso ai blocchi per applicazioni con elevate esigenze di prestazioni. Inoltre, OCS supporta il nuovo standard di richiesta del gruppo oggetti Object Bucket Claim, che consente alle applicazioni di utilizzare direttamente lo storage di oggetti.
Macchine virtuali nei container
Se sei interessato a verificare come funziona, sappi che OpenShift virtualization è già disponibile nella versione Tech Preview come parte di OpenShift 3.11 e versioni successive. I possessori di una sottoscrizione valida a OpenShift possono utilizzare OpenShift virtualization completamente gratuitamente e senza ulteriori passaggi. Al momento della pubblicazione di questo post, le versioni attuali sono OpenShift 4.4 e OpenShift virtualization 2.3; se utilizzi versioni precedenti, vale la pena aggiornarsi per ottenere le ultime funzionalità. Una versione completamente supportata di OpenShift virtualization dovrebbe essere rilasciata nella seconda metà del 2020.
Per ulteriori informazioni, consulta per istruzioni su come installare, comprese , che forniscono dettagli sulla configurazione delle reti esterne.
Fonte: habr.com
