Virtualización OpenShift: contenedores, KVM y máquinas virtuales

Virtualización OpenShift (proyecto ascendente - Kubernetes: KubeVirt, ver. aquí и aquí), de soltera Virtualización nativa de contenedores, se introdujo como una funcionalidad de la plataforma OpenShift, que está diseñada para implementar y administrar máquinas virtuales (VM) como entidades básicas de Kubernetes. Este tipo de tarea es técnicamente desafiante debido a diferencias fundamentales en la tecnología. Para lograr este objetivo, utilizamos tecnologías familiares basadas en Red Hat Enterprise Linux y KVM, que llevan muchos años con nosotros y han demostrado su eficacia.

Virtualización OpenShift: contenedores, KVM y máquinas virtuales

En este artículo, veremos los aspectos técnicos de la virtualización OpenShift que hacen posible que las máquinas virtuales y los contenedores coexistan dentro de una única plataforma que los gestiona como una sola entidad.

Tareas computacionales

Los contenedores utilizan mecanismos del kernel de Linux, como espacios de nombres y cgroups, para aislar procesos y administrar recursos. Por lo general, los procesos se entienden como Python, aplicaciones Java o archivos ejecutables, pero en realidad pueden ser cualquier proceso, como bash, Emacs o vim.

¿Qué es una máquina virtual? Desde el punto de vista del hipervisor, esto también es un proceso. Pero no el proceso de solicitud, sino el proceso KVM responsable de ejecutar una VM específica.

Virtualización OpenShift: contenedores, KVM y máquinas virtuales

La imagen del contenedor contiene todas las herramientas, bibliotecas y archivos necesarios para la máquina virtual KVM. Si inspeccionamos el pod de una VM en ejecución, veremos ayudantes y procesos qemu-kvm. Además, tenemos acceso a herramientas KVM para la gestión de máquinas virtuales como qemu-img, qemu-nbd y virsh.

Virtualización OpenShift: contenedores, KVM y máquinas virtuales

Dado que una máquina virtual es un pod, hereda automáticamente todas las funciones de un pod en Kubernetes. Los pods de VM, al igual que los pods normales, están sujetos a esquemas y criterios de programación, como contaminación, tolerancias, afinidad y antiafinidad. También obtienes los beneficios de alta disponibilidad, etc. Sin embargo, hay una diferencia importante: los pods normales no migran de un host a otro en el sentido habitual. Si un nodo se desconecta, el pod que contiene se finaliza y se reasigna a otro nodo del clúster. Y en el caso de una máquina virtual, esperamos ver una migración en vivo.

Para abordar esta brecha, se creó una definición de recursos personalizada (CDR) para describir el mecanismo de migración en vivo que es responsable de inicializar, monitorear y administrar las migraciones en vivo de máquinas virtuales entre nodos trabajadores.

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
  name: migration-job
spec:
  vmiName: fedora

Cuando se desactiva un nodo, las tareas de migración se crean automáticamente para aquellas máquinas virtuales que tienen Live Migration configurada como estrategia de desalojo. De esta manera puede controlar el comportamiento de las máquinas virtuales cuando se mueve entre nodos del clúster. Puede configurar Live Migration y administrar la VM, como todos los demás pods.

Red

Cualquier sistema Kubernetes proporciona comunicación entre nodos y pods mediante redes SDN de software. OpenShift no es una excepción y, a partir de la versión 3, utiliza OpenShiftSDN de forma predeterminada para esto. Además, OpenShift 4 tiene otra característica nueva llamada Multus, que le permite tener disponibles múltiples redes y conectar pods a ellas simultáneamente.

Virtualización OpenShift: contenedores, KVM y máquinas virtuales

Con Multus, el administrador puede definir redes CNI adicionales, que luego serán implementadas y configuradas en el clúster por un operador de red de clúster especial. Luego, los pods se conectan a una o más de estas redes, generalmente el OpenShiftSDN estándar y una interfaz adicional. Se pueden utilizar dispositivos SR-IOV, Linux Bridge estándar, MACVLAN e IPVLAN si su VM lo necesita. La siguiente figura muestra cómo configurar Multus CNI para la red puente en la interfaz 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 con la virtualización OpenShift, esto significa que una VM se puede conectar directamente a una red externa, sin pasar por SDN. Esto es importante para las máquinas virtuales migradas a OpenShift desde Red Hat Virtualization o VMware vSphere, ya que si tiene acceso a la segunda capa OSI, no habrá cambios en la configuración de red. Esto también significa que la VM puede tener una dirección de red que omita SDN. Así, podemos utilizar efectivamente adaptadores de red especializados, o conectarnos directamente al sistema de almacenamiento a través de la red...

Puede obtener más información sobre cómo crear y conectar máquinas virtuales de virtualización OpenShift a la red. aquí. Además, operador nmstate, implementado como parte de la virtualización OpenShift, ofrece otra forma familiar de crear y administrar configuraciones de red en nodos físicos que se utilizan bajo hipervisores.

Almacenamiento

La conexión y administración de discos de máquinas virtuales dentro de la virtualización OpenShift se realiza utilizando conceptos de Kubernetes como StorageClasses, PersistentVolumeClaims (PVC) y PersistentVolume (PV), así como protocolos de almacenamiento estándar para el entorno de Kubernetes. Esto brinda a los administradores de Kubernetes y a los equipos de aplicaciones una forma común y familiar de administrar contenedores y máquinas virtuales. Y para muchos administradores de entornos de virtualización, este concepto puede resultar familiar porque utiliza el mismo principio de separación de archivos y discos de configuración de VM que se utiliza en OpenStack y muchas otras plataformas en la nube.

Sin embargo, no podemos simplemente crear un nuevo disco para la VM cada vez, ya que al migrar del hipervisor a OpenShift, necesitamos guardar los datos. Sí, incluso cuando implementamos una nueva VM, siempre es más rápido hacerlo desde una plantilla que crearla desde cero. Por lo tanto, necesitamos funcionalidad para importar discos existentes.

Para simplificar esta tarea, la virtualización OpenShift implementa el proyecto Containerized Data Importer (CDI), que reduce la importación de imágenes de discos de múltiples fuentes a la creación de una entrada 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

Es esta entrada la que activa el CDI, desencadenando la secuencia de acciones que se muestran en la siguiente figura:

Virtualización OpenShift: contenedores, KVM y máquinas virtuales

Una vez completado el CDI, el PVC contendrá el disco de la máquina virtual listo para usar y convertido al formato estándar OpenShift...
Cuando se trabaja con la virtualización OpenShift, también resulta útil OpenShift Container Storage (OCS), una solución de Red Hat basada en el sistema de archivos Ceph que implementa la funcionalidad de almacenamiento persistente para contenedores. Además de los métodos de acceso de PVC estándar, RWO (bloque) y RWX (archivo), OCS proporciona RWX para dispositivos de bloques sin formato, lo cual es muy útil para compartir acceso a bloques para aplicaciones con requisitos de alto rendimiento. Además, OCS admite el nuevo estándar Object Bucket Claim, que permite a las aplicaciones utilizar directamente el almacenamiento de datos de objetos.

Máquinas virtuales en contenedores

Si está interesado en comprobar cómo funciona, sepa que la virtualización de OpenShift ya está disponible en la versión Tech Preview como parte de OpenShift 3.11 y superior. Los propietarios de una suscripción a OpenShift existente pueden utilizar la virtualización de OpenShift de forma totalmente gratuita y sin ningún paso adicional. En el momento de escribir esta publicación, OpenShift 4.4 y OpenShift virtualization 2.3 están actualizados; si está utilizando versiones anteriores, debe actualizar para obtener las funciones más recientes. En la segunda mitad de 2020 debería lanzarse una versión totalmente compatible de la virtualización OpenShift.

Para obtener más información, consulte Documentación de OpenShift para obtener instrucciones de instalación, incluyendo Sección de configuración múltiple, que proporciona información sobre la configuración de redes externas.

Fuente: habr.com

Añadir un comentario