Virtualización OpenShift (proxecto ascendente - Kubernetes: KubeVirt, ver. и ), nee Container-native Virtualization, presentouse como unha funcionalidade da plataforma OpenShift, que está deseñada para implantar e xestionar máquinas virtuais (VM) como entidades básicas de Kubernetes. Este tipo de tarefas é un reto tecnicamente debido ás diferenzas fundamentais na tecnoloxía. Para conseguir este obxectivo, utilizamos tecnoloxías coñecidas baseadas en Red Hat Enterprise Linux e KVM, que levan moitos anos connosco e demostraron a súa eficacia.
Neste artigo, analizaremos os aspectos técnicos da virtualización OpenShift que permiten que máquinas virtuales e contedores coexistan nunha única plataforma que os xestiona como unha única entidade.
Tarefas computacionais
Os contedores usan mecanismos do núcleo de Linux como espazos de nomes e cgroups para illar procesos e xestionar recursos. Normalmente os procesos enténdense como Python, aplicacións Java ou ficheiros executables, pero en realidade poden ser calquera proceso, como bash, Emacs ou vim.
Que é unha máquina virtual? Desde o punto de vista do hipervisor, este tamén é un proceso. Pero non o proceso de aplicación, senón o proceso KVM responsable de executar unha VM específica.
A imaxe do contedor contén todas as ferramentas, bibliotecas e ficheiros necesarios para a máquina virtual KVM. Se inspeccionamos o pod dunha máquina virtual en execución, veremos alí axudantes e procesos qemu-kvm. Ademais, temos acceso a ferramentas KVM para xestionar máquinas virtuais como qemu-img, qemu-nbd e virsh.
Dado que unha máquina virtual é un pod, herda automaticamente toda a funcionalidade dun pod en Kubernetes. Os pods VM, do mesmo xeito que os pods habituais, están suxeitos a esquemas e criterios de planificador, como manchas, tolerancias, afinidade e antiafinidade. Tamén obtén os beneficios da alta dispoñibilidade, etc. Non obstante, hai unha diferenza importante: as vainas normais non migran de host a host no sentido habitual. Se un nodo queda fóra de liña, o pod que hai nel terminase e reasignarase a outro nodo do clúster. E no caso dunha máquina virtual, esperamos ver unha migración en directo.
Para abordar esta lagoa, creouse unha definición de recurso personalizada (CDR) para describir o mecanismo de migración en directo responsable de inicializar, supervisar e xestionar as migracións en directo das máquinas virtuales entre os nodos dos traballadores.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
Cando se desactiva un nodo, as tarefas de migración créanse automaticamente para aquelas máquinas virtuais que teñen definida a Migración en directo como estratexia de desafiuzamento. Deste xeito, pode controlar o comportamento das máquinas virtuais ao moverse entre os nodos do clúster. Podes configurar a migración en directo e xestionar a máquina virtual, como todos os outros pods.
Rede
Calquera sistema Kubernetes proporciona comunicación entre nodos e pods mediante redes SDN de software. OpenShift non é unha excepción e, a partir da versión 3, usa OpenShiftSDN por defecto para iso. Ademais, OpenShift 4 ten outra nova función chamada Multus, que permite facer dispoñibles varias redes e conectar pods a elas simultaneamente.
Usando Multus, o administrador pode definir redes CNI adicionais, que despois serán despregadas e configuradas no clúster por un operador de rede de clúster especial. A continuación, os pods conéctanse a unha ou máis destas redes, normalmente o OpenShiftSDN estándar e unha interface adicional. Pódense usar dispositivos SR-IOV, Linux Bridge estándar, MACVLAN e IPVLAN se a súa máquina virtual o precisa. A seguinte figura mostra como configurar Multus CNI para a rede ponte na interface 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
En relación á virtualización OpenShift, isto significa que unha máquina virtual pode conectarse directamente a unha rede externa, evitando SDN. Isto é importante para as máquinas virtuais migradas a OpenShift desde Red Hat Virtualization ou VMware vSphere, xa que se tes acceso á segunda capa OSI, non haberá ningún cambio na configuración da rede. Isto tamén significa que a máquina virtual pode ter un enderezo de rede que omita SDN. Así, podemos utilizar eficazmente adaptadores de rede especializados ou conectarnos directamente ao sistema de almacenamento a través da rede...
Podes obter máis información sobre como crear e conectar máquinas virtuais de virtualización OpenShift á rede ... Ademais, , despregado como parte da virtualización OpenShift, ofrece outra forma familiar de crear e xestionar configuracións de rede en nós físicos que se usan baixo hipervisores.
Almacenamento
A conexión e xestión de discos de máquinas virtuais dentro da virtualización OpenShift realízase utilizando conceptos de Kubernetes como StorageClasses, PersistentVolumeClaims (PVC) e PersistentVolume (PV), así como protocolos de almacenamento estándar para o contorno Kubernetes. Isto ofrécelle aos administradores e aos equipos de aplicacións de Kubernetes un xeito común e familiar de xestionar tanto os contedores como as máquinas virtuais. E para moitos administradores de contornas de virtualización, este concepto pode parecer familiar porque utiliza o mesmo principio de separación de ficheiros de configuración de VM e discos que se usa en OpenStack e moitas outras plataformas na nube.
Non obstante, non podemos simplemente crear un novo disco para a máquina virtual cada vez, xa que ao migrar desde o hipervisor a OpenShift, necesitamos gardar os datos. Si, mesmo cando despregamos unha nova máquina virtual, sempre é máis rápido facelo desde un modelo que crealo desde cero. Así, necesitamos funcionalidades para importar discos existentes.
Para simplificar esta tarefa, a virtualización OpenShift implanta o proxecto Containerized Data Importer (CDI), que reduce a importación de imaxes de discos de varias fontes para crear unha entrada de 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
É esta entrada a que activa CDI, desencadeando a secuencia de accións que se mostra na figura seguinte:
Despois de completar o CDI, o PVC conterá o disco da máquina virtual listo para o seu uso e convertido ao formato OpenShift estándar...
Cando se traballa coa virtualización OpenShift, tamén é útil OpenShift Container Storage (OCS), unha solución de Red Hat baseada no sistema de ficheiros Ceph que implementa a funcionalidade de almacenamento persistente para os contedores. Ademais dos métodos de acceso estándar de PVC - RWO (bloque) e RWX (ficheiro) - OCS proporciona RWX para dispositivos de bloques en bruto, o que é moi útil para compartir o acceso a bloques para aplicacións con requisitos de alto rendemento. Ademais, OCS admite o novo estándar Object Bucket Claim, que permite ás aplicacións utilizar directamente o almacenamento de datos de obxectos.
Máquinas virtuais en contedores
Se estás interesado en comprobar como funciona, sabe que a virtualización de OpenShift xa está dispoñible na versión Tech Preview como parte de OpenShift 3.11 ou superior. Os propietarios dunha subscrición a OpenShift existente poden usar a virtualización de OpenShift de forma totalmente gratuíta e sen ningún paso adicionais. No momento desta publicación, OpenShift 4.4 e OpenShift virtualization 2.3 están actuais; se estás a usar versións anteriores, deberías actualizar para obter as funcións máis recentes. Unha versión totalmente compatible da virtualización OpenShift debería lanzarse no segundo semestre de 2020.
Para máis información consulte para as instrucións de instalación, incluíndo , que proporciona información sobre a configuración de redes externas.
Fonte: www.habr.com