Virtualizzazione OpenShift (progetto upstream - Kubernetes: KubeVirt, vedi. и ), nata Container-native Virtualization, è stata introdotta come funzionalità della piattaforma OpenShift, progettata per la distribuzione e la gestione di macchine virtuali (VM) come entità Kubernetes di base. Questo tipo di compito è tecnicamente impegnativo a causa delle differenze fondamentali nella tecnologia. Per raggiungere questo obiettivo abbiamo utilizzato tecnologie familiari basate su Red Hat Enterprise Linux e KVM, che ci accompagnano da molti anni e hanno dimostrato la loro efficacia.
In questo articolo vedremo gli aspetti tecnici della virtualizzazione OpenShift che rendono possibile la coesistenza di VM e container all'interno di un'unica piattaforma che li gestisce come un'unica entità.
Compiti computazionali
I contenitori utilizzano meccanismi del kernel Linux come spazi dei nomi e cgroup per isolare processi e gestire le risorse. Di solito per processi si intendono Python, applicazioni Java o file eseguibili, ma in realtà possono essere qualsiasi processo, come bash, Emacs o vim.
Cos'è una macchina virtuale? Dal punto di vista dell'hypervisor, anche questo è un processo. Ma non il processo applicativo, bensì il processo KVM responsabile dell'esecuzione di una specifica VM.
L'immagine del contenitore 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 gli helper e i processi qemu-kvm. Inoltre, abbiamo accesso a strumenti KVM per la gestione di macchine virtuali come qemu-img, qemu-nbd e virsh.
Poiché una macchina virtuale è un pod, eredita automaticamente tutte le funzionalità di un pod in Kubernetes. I pod VM, proprio come i pod normali, sono soggetti a schemi e criteri di pianificazione come incompatibilità, tolleranze, affinità e anti-affinità. Ottieni anche i vantaggi dell'alta disponibilità, ecc. Tuttavia, esiste una differenza importante: i pod regolari non migrano da un host all'altro nel senso usuale. Se un nodo va offline, il pod su di esso viene terminato e riassegnato a un altro nodo nel cluster. E nel caso di una macchina virtuale, ci aspettiamo di vedere la migrazione in tempo reale.
Per colmare questa lacuna, è stata creata una definizione di risorsa personalizzata (CDR) per descrivere il meccanismo di migrazione in tempo reale responsabile dell'inizializzazione, del monitoraggio e della gestione delle migrazioni in tempo reale delle VM tra i nodi di lavoro.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Quando un nodo viene disattivato, le attività di migrazione vengono create automaticamente per quelle macchine virtuali che hanno impostato Live Migration come strategia di eliminazione. In questo modo è possibile controllare il comportamento delle macchine virtuali durante lo spostamento tra i nodi del cluster. Puoi sia configurare Live Migration che gestire la VM, come tutti gli altri pod.
Rete
Qualsiasi sistema Kubernetes fornisce la comunicazione tra nodi e pod utilizzando reti SDN software. OpenShift non fa eccezione e, a partire dalla versione 3, utilizza OpenShiftSDN per impostazione predefinita. Inoltre, OpenShift 4 ha un'altra nuova funzionalità chiamata Multus, che consente di rendere disponibili più reti e connettere i pod ad esse contemporaneamente.
Utilizzando Multus, l'amministratore può definire ulteriori reti CNI, che verranno poi implementate e configurate sul cluster da un apposito Cluster Network Operator. I pod vengono quindi collegati a una o più di queste reti, solitamente la OpenShiftSDN standard e un'interfaccia aggiuntiva. Se la tua VM ne ha bisogno, puoi utilizzare dispositivi SR-IOV, Linux Bridge standard, MACVLAN e IPVLAN. La figura seguente mostra come impostare Multus CNI per la 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 alla virtualizzazione OpenShift, ciò significa che una VM può essere connessa direttamente a una rete esterna, bypassando SDN. Questo è importante per le macchine virtuali migrate a OpenShift da Red Hat Virtualization o VMware vSphere, poiché se hai accesso al secondo livello OSI, non ci saranno modifiche nelle impostazioni di rete. Ciò significa anche che la VM potrebbe avere un indirizzo di rete che ignora l'SDN. Pertanto, possiamo utilizzare in modo efficace adattatori di rete specializzati o collegarci direttamente al sistema di archiviazione tramite la rete...
Puoi saperne di più su come creare e connettere le macchine virtuali di virtualizzazione OpenShift alla rete . Inoltre, , distribuito come parte della virtualizzazione OpenShift, offre un altro modo familiare per creare e gestire configurazioni di rete su nodi fisici utilizzati sotto gli hypervisor.
Conservazione
La connessione e la gestione dei dischi delle macchine virtuali all'interno della virtualizzazione OpenShift vengono eseguite utilizzando concetti Kubernetes come StorageClasses, PersistentVolumeClaims (PVC) e PersistentVolume (PV), nonché protocolli di storage standard per l'ambiente Kubernetes. Ciò offre agli amministratori Kubernetes e ai team applicativi un modo comune e familiare per gestire sia i contenitori che le macchine virtuali. E per molti amministratori di ambienti di virtualizzazione, questo concetto può sembrare familiare perché utilizza lo stesso principio di separazione dei file e dei dischi di configurazione delle VM utilizzato in OpenStack e molte altre piattaforme cloud.
Tuttavia, non possiamo semplicemente creare ogni volta un nuovo disco per la VM, poiché durante la migrazione dall'hypervisor a OpenShift, dobbiamo salvare i dati. Sì, anche quando distribuiamo una nuova VM, è sempre più veloce farlo da un modello piuttosto che crearlo da zero. Pertanto, abbiamo bisogno della funzionalità per importare i dischi esistenti.
Per semplificare questa attività, la virtualizzazione OpenShift distribuisce il progetto Containerized Data Importer (CDI), che riduce l'importazione di immagini disco di dischi da più origini alla creazione di una voce 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, innescando la sequenza di azioni mostrate nella figura seguente:
Una volta completato il CDI, il PVC conterrà il disco della macchina virtuale pronto per l'uso e convertito nel formato OpenShift standard...
Quando si lavora con la virtualizzazione OpenShift, è utile anche OpenShift Container Storage (OCS), una soluzione Red Hat basata sul file system Ceph che implementa funzionalità di archiviazione persistente per i contenitori. Oltre ai metodi di accesso PVC standard - RWO (blocco) e RWX (file) - OCS fornisce RWX per dispositivi a blocchi grezzi, che è molto utile per condividere l'accesso ai blocchi per applicazioni con requisiti di prestazioni elevate. Inoltre, OCS supporta il nuovo standard Object Bucket Claim, che consente alle applicazioni di utilizzare direttamente l'archiviazione dei dati degli oggetti.
Macchine virtuali in contenitori
Se sei interessato a verificare come funziona, sappi che la virtualizzazione di OpenShift è già disponibile nella versione Tech Preview come parte di OpenShift 3.11 e versioni successive. I proprietari di un abbonamento OpenShift esistente possono utilizzare la virtualizzazione OpenShift in modo completamente gratuito e senza passaggi aggiuntivi. Al momento di questo post, OpenShift 4.4 e OpenShift virtualization 2.3 sono aggiornati; se stai utilizzando versioni precedenti, dovresti eseguire l'aggiornamento per ottenere le funzionalità più recenti. Una versione completamente supportata della virtualizzazione OpenShift dovrebbe essere rilasciata nella seconda metà del 2020.
Per ulteriori informazioni, fare riferimento a per le istruzioni di installazione, incluso , che fornisce informazioni sulla configurazione di reti esterne.
Fonte: habr.com