21 Edge Virtualization #

En esta sección se describe cómo se puede utilizar Edge Virtualization para ejecutar máquinas virtuales en los nodos periféricos. Edge Virtualization se hadiseñado para casos de uso de virtualización ligeros, en los que se espera que se utilice un flujo de trabajo común para el despliegue y la gestión tanto de aplicaciones virtualizadas como en contenedores.

SUSE Edge Virtualization admite dos métodos para ejecutar máquinas virtuales:

Despliegue manual de las máquinas virtuales mediante libvirt+qemu-kvm a nivel del host (sin intervención de Kubernetes)
Despliegue del operador KubeVirt para la gestión basada en Kubernetes de máquinas virtuales

Ambas opciones son válidas, pero solo la segunda se trata a continuación. Si desea utilizar los mecanismos de virtualización estándares listos para usar que proporciona SUSE Linux Micro, encontrará una guía completa en este documento. Aunque está escrita principalmente para SUSE Linux Enterprise Server, los conceptos son prácticamente idénticos.

Esta guía explica inicialmente cómo desplegar los componentes de virtualización adicionales en un sistema que ya ha sido predesplegado, pero incluye una sección que describe cómo integrar esta configuración en el despliegue inicial a través de Edge Image Builder. Si no desea repasar los conceptos básicos y configurarlo todo manualmente, pase directamente a esa sección.

21.1 Descripción general de KubeVirt #

KubeVirt permite gestionar máquinas virtuales con Kubernetes junto con el resto de sus cargas de trabajo en contenedores. Para ello, ejecuta la parte del espacio de usuario de la pila de virtualización de Linux en un contenedor. Esto minimiza los requisitos del sistema host, lo que facilita la configuración y la gestión.

Encontrará los detalles sobre la arquitectura de KubeVirt en la documentación original.

21.2 Requisitos previos #

Si está siguiendo esta guía, se da por hecho que ya dispone de lo siguiente:

Al menos un host físico con SUSE Linux Micro 6.1 instalado y con las extensiones de virtualización habilitadas en el BIOS (consulte este documento para obtener más detalles).
Un clúster Kubernetes de K3s/RKE2 ya desplegado en todos sus nodos y con una kubeconfig adecuada que permita el acceso de superusuario al clúster.
Acceso al usuario root: estas instrucciones dan por sentado que usted es el usuario root y que no está derivando sus privilegios mediante sudo.
Debe tener Helm disponible localmente con una conexión de red adecuada para poder enviar configuraciones a su clúster de Kubernetes y descargar las imágenes necesarias.

21.3 Instalación manual de Edge Virtualization #

Esta guía no explica el despliegue de Kubernetes, pero da por sentado que ha instalado la versión de K3s o RKE2 adecuada para SUSE Edge y que tiene su kubeconfig configurada adecuadamente para que los comandos estándar kubectl se puedan ejecutar como superusuario. También se presupone que su nodo forma un clúster de un solo nodo, aunque no se esperan diferencias significativas para los despliegues de varios nodos.

SUSE Edge Virtualization se despliega mediante tres charts de Helm distintos, en concreto:

KubeVirt: los componentes básicos de virtualización, es decir, las CRD de Kubernetes, los operadores y otros componentes necesarios para que Kubernetes pueda desplegar y gestionar máquinas virtuales.
Extensión de panel de control KubeVirt: una extensión opcional de la interfaz de usuario de Rancher que permite la gestión básica de máquinas virtuales; por ejemplo, iniciar/detener máquinas virtuales, así como acceder al panel de control.
Containerized Data Importer (CDI): un componente adicional que permite la integración del almacenamiento persistente para KubeVirt, proporcionando capacidades para que las máquinas virtuales puedan usar sistemas secundarios de almacenamiento existentes de Kubernetes para los datos, pero también permitiendo a los usuarios importar o clonar volúmenes de datos para máquinas virtuales.

Cada uno de estos charts de Helm tiene versiones distintas según la versión de SUSE Edge que esté utilizando actualmente. Para usarlos en entornos de producción o con asistencia, utilice los artefactos que se pueden encontrar en el registro de SUSE.

En primer lugar, asegúrese de que puede acceder correctamente a kubectl:

$ kubectl get nodes

Esto debería mostrar algo similar a lo siguiente:

NAME                   STATUS   ROLES                       AGE     VERSION
node1.edge.rdo.wales   Ready    control-plane,etcd,master   4h20m   v1.30.5+rke2r1
node2.edge.rdo.wales   Ready    control-plane,etcd,master   4h15m   v1.30.5+rke2r1
node3.edge.rdo.wales   Ready    control-plane,etcd,master   4h15m   v1.30.5+rke2r1

Ahora, puede instalar los charts de Helm de KubeVirt y Containerized Data Importer (CDI):

$ helm install kubevirt oci://registry.suse.com/edge/charts/kubevirt --namespace kubevirt-system --create-namespace
$ helm install cdi oci://registry.suse.com/edge/charts/cdi --namespace cdi-system --create-namespace

En unos minutos, debería tener todos los componentes de KubeVirt y CDI desplegados. Puede comprobar que todos los recursos se han desplegado en los espacios de nombres kubevirt-system y cdi-system.

Verifique los recursos de KubeVirt:

$ kubectl get all -n kubevirt-system

Esto debería mostrar algo similar a lo siguiente:

NAME                                   READY   STATUS    RESTARTS      AGE
pod/virt-operator-5fbcf48d58-p7xpm     1/1     Running   0             2m24s
pod/virt-operator-5fbcf48d58-wnf6s     1/1     Running   0             2m24s
pod/virt-handler-t594x                 1/1     Running   0             93s
pod/virt-controller-5f84c69884-cwjvd   1/1     Running   1 (64s ago)   93s
pod/virt-controller-5f84c69884-xxw6q   1/1     Running   1 (64s ago)   93s
pod/virt-api-7dfc54cf95-v8kcl          1/1     Running   1 (59s ago)   118s

NAME                                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/kubevirt-prometheus-metrics   ClusterIP   None            <none>        443/TCP   2m1s
service/virt-api                      ClusterIP   10.43.56.140    <none>        443/TCP   2m1s
service/kubevirt-operator-webhook     ClusterIP   10.43.201.121   <none>        443/TCP   2m1s
service/virt-exportproxy              ClusterIP   10.43.83.23     <none>        443/TCP   2m1s

NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
daemonset.apps/virt-handler   1         1         1       1            1           kubernetes.io/os=linux   93s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/virt-operator     2/2     2            2           2m24s
deployment.apps/virt-controller   2/2     2            2           93s
deployment.apps/virt-api          1/1     1            1           118s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/virt-operator-5fbcf48d58     2         2         2       2m24s
replicaset.apps/virt-controller-5f84c69884   2         2         2       93s
replicaset.apps/virt-api-7dfc54cf95          1         1         1       118s

NAME                            AGE     PHASE
kubevirt.kubevirt.io/kubevirt   2m24s   Deployed

Verifique los recursos de CDI:

$ kubectl get all -n cdi-system

Esto debería mostrar algo similar a lo siguiente:

NAME                                   READY   STATUS    RESTARTS   AGE
pod/cdi-operator-55c74f4b86-692xb      1/1     Running   0          2m24s
pod/cdi-apiserver-db465b888-62lvr      1/1     Running   0          2m21s
pod/cdi-deployment-56c7d74995-mgkfn    1/1     Running   0          2m21s
pod/cdi-uploadproxy-7d7b94b968-6kxc2   1/1     Running   0          2m22s

NAME                             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/cdi-uploadproxy          ClusterIP   10.43.117.7    <none>        443/TCP    2m22s
service/cdi-api                  ClusterIP   10.43.20.101   <none>        443/TCP    2m22s
service/cdi-prometheus-metrics   ClusterIP   10.43.39.153   <none>        8080/TCP   2m21s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cdi-operator      1/1     1            1           2m24s
deployment.apps/cdi-apiserver     1/1     1            1           2m22s
deployment.apps/cdi-deployment    1/1     1            1           2m21s
deployment.apps/cdi-uploadproxy   1/1     1            1           2m22s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/cdi-operator-55c74f4b86      1         1         1       2m24s
replicaset.apps/cdi-apiserver-db465b888      1         1         1       2m21s
replicaset.apps/cdi-deployment-56c7d74995    1         1         1       2m21s
replicaset.apps/cdi-uploadproxy-7d7b94b968   1         1         1       2m22s

Para verificar que las definiciones de recursos personalizados (CRD) de VirtualMachine están desplegadas, puede usar:

$ kubectl explain virtualmachine

Esto debería dar como resultado la definición del objeto VirtualMachine, que debería tener este aspecto:

GROUP:      kubevirt.io
KIND:       VirtualMachine
VERSION:    v1

DESCRIPTION:
    VirtualMachine handles the VirtualMachines that are not running or are in a
    stopped state The VirtualMachine contains the template to create the
    VirtualMachineInstance. It also mirrors the running state of the created
    VirtualMachineInstance in its status.
(snip)

21.4 Despliegue de máquinas virtuales #

Ahora que KubeVirt y CDI se han desplegado, vamos a definir una máquina virtual sencilla basada en openSUSE Tumbleweed. La configuración de esta máquina virtual es muy sencilla: usa una "conexión de red de pod" idéntica a la de cualquier otro pod. También emplea almacenamiento no persistente, lo que garantiza que el almacenamiento sea efímero, al igual que en cualquier contenedor que no tenga un PVC.

$ kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: tumbleweed
  namespace: default
spec:
  runStrategy: Always
  template:
    spec:
      domain:
        devices: {}
        machine:
          type: q35
        memory:
          guest: 2Gi
        resources: {}
      volumes:
      - containerDisk:
          image: registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScK
        name: cloudinitdisk
EOF

El resultado debe ser que se ha creado una VirtualMachine:

virtualmachine.kubevirt.io/tumbleweed created

Esta definición de VirtualMachine es mínima y especifica muy poco sobre la configuración. Solo indica que se trata de una máquina de tipo q35 con 2 GB de memoria que usa una imagen de disco basada en un containerDisk efímero (es decir, una imagen de disco que se almacena en una imagen de contenedor desde un repositorio de imágenes remoto), y especifica un disco cloudInit con cifrado base64, que solo utilizamos para la creación de usuarios y la obligación de usar contraseña en el momento del arranque (utilice base64 -d para descifrarlo).

Nota
Esta imagen de máquina virtual sirve solo para realizar pruebas. La imagen no cuenta con asistencia oficial y solo se ofrece como ejemplo para fines de documentación.

Esta máquina tarda unos minutos en arrancar, ya que necesita descargar la imagen de disco de openSUSE Tumbleweed, pero una vez que lo haya hecho, podrá ver más detalles sobre ella:

$ kubectl get vmi

Esto debería dar como resultado el nodo en el que se inició la máquina virtual y la dirección IP de la máquina virtual. Recuerde que, dado que utiliza conexión de red de pod, la dirección IP indicada será igual que la de cualquier otro pod y, por lo tanto, enrutable:

NAME         AGE     PHASE     IP           NODENAME               READY
tumbleweed   4m24s   Running   10.42.2.98   node3.edge.rdo.wales   True

Al ejecutar estos comandos en los propios nodos del clúster de Kubernetes, con una CNI que enruta el tráfico directamente a los pods (por ejemplo, Cilium), debería poder conectarse directamente por ssh a la máquina. Sustituya la siguiente dirección IP por la que se le haya asignado a su máquina virtual:

$ ssh suse@10.42.2.98
(password is "suse")

Cuando se encuentre en esta máquina virtual, puede practicar un poco, pero recuerde que tiene recursos limitados y solo cuenta con 1 GB de espacio en disco. Cuando termine, pulse Ctrl+D o exit para desconectarse de la sesión SSH.

El proceso de la máquina virtual sigue estando envuelto en un pod estándar de Kubernetes. La CRD VirtualMachine es una representación de la máquina virtual deseada, pero el proceso en el que se inicia realmente la máquina virtual es a través del pod virt-launcher, un pod estándar de Kubernetes, igual que cualquier otra aplicación. Por cada máquina virtual iniciada, se puede ver que hay un pod virt-launcher:

$ kubectl get pods

Esto debería mostrar el único pod virt-launcher para la máquina Tumbleweed que hemos definido:

NAME                             READY   STATUS    RESTARTS   AGE
virt-launcher-tumbleweed-8gcn4   3/3     Running   0          10m

Si echamos un vistazo a este pod virt-launcher, veremos que está ejecutando los procesos libvirt y qemu-kvm. Podemos entrar en el propio pod y echar un vistazo, pero tenga en cuenta que es necesario adaptar el siguiente comando al nombre de su pod:

$ kubectl exec -it virt-launcher-tumbleweed-8gcn4 -- bash

Una vez en el pod, pruebe a ejecutar comandos virsh y observe los procesos. Comprobará que se está ejecutando el binario qemu-system-x86_64, junto con ciertos procesos para supervisar la máquina virtual. También verá la ubicación de la imagen de disco y cómo está conectada la red (como un dispositivo tap):

qemu@tumbleweed:/> ps ax
  PID TTY      STAT   TIME COMMAND
    1 ?        Ssl    0:00 /usr/bin/virt-launcher-monitor --qemu-timeout 269s --name tumbleweed --uid b9655c11-38f7-4fa8-8f5d-bfe987dab42c --namespace default --kubevirt-share-dir /var/run/kubevirt --ephemeral-disk-dir /var/run/kubevirt-ephemeral-disks --container-disk-dir /var/run/kube
   12 ?        Sl     0:01 /usr/bin/virt-launcher --qemu-timeout 269s --name tumbleweed --uid b9655c11-38f7-4fa8-8f5d-bfe987dab42c --namespace default --kubevirt-share-dir /var/run/kubevirt --ephemeral-disk-dir /var/run/kubevirt-ephemeral-disks --container-disk-dir /var/run/kubevirt/con
   24 ?        Sl     0:00 /usr/sbin/virtlogd -f /etc/libvirt/virtlogd.conf
   25 ?        Sl     0:01 /usr/sbin/virtqemud -f /var/run/libvirt/virtqemud.conf
   83 ?        Sl     0:31 /usr/bin/qemu-system-x86_64 -name guest=default_tumbleweed,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/run/kubevirt-private/libvirt/qemu/lib/domain-1-default_tumbleweed/master-key.aes"} -machine pc-q35-7.1,usb
  286 pts/0    Ss     0:00 bash
  320 pts/0    R+     0:00 ps ax

qemu@tumbleweed:/> virsh list --all
 Id   Name                 State
------------------------------------
 1    default_tumbleweed   running

qemu@tumbleweed:/> virsh domblklist 1
 Target   Source
---------------------------------------------------------------------------------------------
 sda      /var/run/kubevirt-ephemeral-disks/disk-data/tumbleweed-containerdisk-0/disk.qcow2
 sdb      /var/run/kubevirt-ephemeral-disks/cloud-init-data/default/tumbleweed/noCloud.iso

qemu@tumbleweed:/> virsh domiflist 1
 Interface   Type       Source   Model                     MAC
------------------------------------------------------------------------------
 tap0        ethernet   -        virtio-non-transitional   e6:e9:1a:05:c0:92

qemu@tumbleweed:/> exit
exit

Por último, eliminemos esta máquina virtual:

$ kubectl delete vm/tumbleweed
virtualmachine.kubevirt.io "tumbleweed" deleted

21.5 Uso de virtctl #

Además de la estándar de Kubernetes (kubectl), KubeVirt incluye una interfaz de línea de comandos adicional que permite interactuar con el clúster de una forma que obvia ciertas diferencias entre los entornos de virtualización y los usos para los que se diseñó Kubernetes. Por ejemplo, la herramienta virtctl permite gestionar el ciclo de vida de las máquinas virtuales (iniciar, detener, reiniciar, etc.), proporciona acceso a los paneles de control virtuales, permite cargar imágenes de máquinas virtuales e interactuar con construcciones de Kubernetes como servicios, sin utilizar directamente la API o las CRD.

Vamos a descargar la última versión estable de la herramienta virtctl:

$ export VERSION=v1.4.0
$ wget https://github.com/kubevirt/kubevirt/releases/download/$VERSION/virtctl-$VERSION-linux-amd64

Si utiliza una arquitectura diferente o una máquina que no sea Linux, encontrará otras versiones aquí. Debe hacer que este archivo sea ejecutable antes de continuar, y puede ser útil moverlo a una ubicación dentro de $PATH:

$ mv virtctl-$VERSION-linux-amd64 /usr/local/bin/virtctl
$ chmod a+x /usr/local/bin/virtctl

A continuación, puede utilizar la herramienta de línea de comandos virtctl para crear máquinas virtuales. Vamos a replicar nuestra máquina virtual anterior, teniendo en cuenta que estamos canalizando la salida directamente a kubectl apply:

$ virtctl create vm --name virtctl-example --memory=1Gi \
    --volume-containerdisk=src:registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest \
    --cloud-init-user-data "I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScK" | kubectl apply -f -

Esto debería mostrar la máquina virtual en ejecución (esta vez debería iniciarse mucho más rápido, ya que la imagen del contenedor estará almacenada en caché):

$ kubectl get vmi
NAME              AGE   PHASE     IP           NODENAME               READY
virtctl-example   52s   Running   10.42.2.29   node3.edge.rdo.wales   True

Ahora, podemos usar virtctl para conectarnos directamente a la máquina virtual:

$ virtctl ssh suse@virtctl-example
(password is "suse" - Ctrl-D to exit)

Se pueden utilizar muchos otros comandos con virtctl. Por ejemplo, virtctl console permite acceder al panel de control serie si la red no funciona, y puede utilizar virtctl guestosinfo para obtener información completa sobre el sistema operativo, siempre que el invitado tenga instalado y en ejecución qemu-guest-agent.

Por último, hagamos una pausa y reiniciemos la máquina virtual:

$ virtctl pause vm virtctl-example
VMI virtctl-example was scheduled to pause

Verá que el objeto VirtualMachine aparece como Paused (En pausa) y el objeto VirtualMachineInstance aparece como Running (En ejecución), pero como READY=False:

$ kubectl get vm
NAME              AGE     STATUS   READY
virtctl-example   8m14s   Paused   False

$ kubectl get vmi
NAME              AGE     PHASE     IP           NODENAME               READY
virtctl-example   8m15s   Running   10.42.2.29   node3.edge.rdo.wales   False

También comprobará que ya no puede conectarse a la máquina virtual:

$ virtctl ssh suse@virtctl-example
can't access VMI virtctl-example: Operation cannot be fulfilled on virtualmachineinstance.kubevirt.io "virtctl-example": VMI is paused

Reiniciemos la máquina virtual y volvamos a intentarlo:

$ virtctl unpause vm virtctl-example
VMI virtctl-example was scheduled to unpause

Ahora deberíamos poder restablecer la conexión:

$ virtctl ssh suse@virtctl-example
suse@vmi/virtctl-example.default's password:
suse@virtctl-example:~> exit
logout

Por último, eliminemos la máquina virtual:

$ kubectl delete vm/virtctl-example
virtualmachine.kubevirt.io "virtctl-example" deleted

21.6 Conexión de redes sencilla con Ingress #

En esta sección, se explica cómo exponer máquinas virtuales como servicios estándar de Kubernetes y cómo hacerlas disponibles mediante el servicio Ingress de Kubernetes; por ejemplo, NGINX con RKE2 o Traefik con K3s. En este documento se entiende que estos componentes ya están configurados adecuadamente y que dispone de un puntero DNS adecuado (por ejemplo, un comodín) que dirija a los nodos de su servidor de Kubernetes o a su IP virtual de Ingress para que Ingress se resuelva adecuadamente.

Nota
En SUSE Edge 3.1 y versiones posteriores, si utiliza K3s en una configuración de nodos con varios servidores, es posible que haya tenido que configurar una IP virtual basada en MetalLB para Ingress. Esto no es necesario para RKE2.

En el entorno de ejemplo, se despliega otra máquina virtual Tumbleweed de openSUSE, se usa cloud-init para instalar NGINX como servidor Web sencillo en el momento del arranque y se configura un mensaje sencillo, que se envía para verificar que funciona según lo esperado cuando se realiza una llamada. Para ver cómo se hace, use el comando base64 -d en la sección cloud-init del siguiente ejemplo.

Vamos a crear esta máquina virtual:

$ kubectl apply -f - <<EOF
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: ingress-example
  namespace: default
spec:
  runStrategy: Always
  template:
    metadata:
      labels:
        app: nginx
    spec:
      domain:
        devices: {}
        machine:
          type: q35
        memory:
          guest: 2Gi
        resources: {}
      volumes:
      - containerDisk:
          image: registry.opensuse.org/home/roxenham/tumbleweed-container-disk/containerfile/cloud-image:latest
        name: tumbleweed-containerdisk-0
      - cloudInitNoCloud:
          userDataBase64: I2Nsb3VkLWNvbmZpZwpkaXNhYmxlX3Jvb3Q6IGZhbHNlCnNzaF9wd2F1dGg6IFRydWUKdXNlcnM6CiAgLSBkZWZhdWx0CiAgLSBuYW1lOiBzdXNlCiAgICBncm91cHM6IHN1ZG8KICAgIHNoZWxsOiAvYmluL2Jhc2gKICAgIHN1ZG86ICBBTEw9KEFMTCkgTk9QQVNTV0Q6QUxMCiAgICBsb2NrX3Bhc3N3ZDogRmFsc2UKICAgIHBsYWluX3RleHRfcGFzc3dkOiAnc3VzZScKcnVuY21kOgogIC0genlwcGVyIGluIC15IG5naW54CiAgLSBzeXN0ZW1jdGwgZW5hYmxlIC0tbm93IG5naW54CiAgLSBlY2hvICJJdCB3b3JrcyEiID4gL3Nydi93d3cvaHRkb2NzL2luZGV4Lmh0bQo=
        name: cloudinitdisk
EOF

Cuando esta máquina virtual se haya iniciado correctamente, se podrá usar el comando virtctl para exponer la instancia VirtualMachineInstance con el puerto externo 8080 y el puerto de destino 80 (en el que NGINX escucha por defecto). Aquí, utilizamos el comando virtctl, ya que entiende la asignación entre el objeto de máquina virtual y el pod. Esto crea un nuevo servicio:

$ virtctl expose vmi ingress-example --port=8080 --target-port=80 --name=ingress-example
Service ingress-example successfully exposed for vmi ingress-example

A continuación, se crea automáticamente el servicio adecuado:

$ kubectl get svc/ingress-example
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)                         AGE
ingress-example   ClusterIP      10.43.217.19    <none>            8080/TCP                        9s

Ahora, si utiliza kubectl create ingress, puede crear un objeto Ingress que apunte a este servicio. Adapte la URL (conocida como "host" en el objeto ingress) aquí para que coincida con su configuración de DNS y asegúrese de que apunta al puerto 8080:

$ kubectl create ingress ingress-example --rule=ingress-example.suse.local/=ingress-example:8080

Con el servidor DNS configurado correctamente, debería poder ejecutar el comando curl en la URL de inmediato:

$ curl ingress-example.suse.local
It works!

Para limpiar, eliminaremos esta máquina virtual y sus recursos de servicio y de Ingress:

$ kubectl delete vm/ingress-example svc/ingress-example ingress/ingress-example
virtualmachine.kubevirt.io "ingress-example" deleted
service "ingress-example" deleted
ingress.networking.k8s.io "ingress-example" deleted

21.7 Uso de la extensión de interfaz de usuario de Rancher #

SUSE Edge Virtualization proporciona una extensión de interfaz de usuario para Rancher Manager, lo que permite la gestión básica de máquinas virtuales mediante la interfaz de usuario del panel de control de Rancher.

21.7.1 Instalación #

Consulte la sección sobre extensiones de panel de control de Rancher (Capítulo 6, Extensiones de panel de control de Rancher) para obtener instrucciones de instalación.

21.7.2 Uso de la extensión de panel de control KubeVirt de Rancher #

La extensión introduce una nueva sección KubeVirt en Cluster Explorer. Esta sección se añade a cualquier clúster gestionado que tenga instalado KubeVirt.

La extensión permite interactuar directamente con los recursos de la máquina virtual de KubeVirt para gestionar el ciclo de vida de las máquinas virtuales.

21.7.2.1 Creación de una máquina virtual #

En el panel de navegación izquierdo, diríjase a Cluster Explorer (Explorador de clústeres) haciendo clic en el clúster gestionado habilitado para KubeVirt.
Diríjase a la página KubeVirt > Virtual Machines (KubeVirt > Máquinas virtuales) y haga clic en Create from YAML (Crear desde YAML) en la parte superior derecha de la pantalla.
Rellene o pegue una definición de máquina virtual y pulse Create (Crear). Use la definición de máquina virtual de la sección Despliegue de máquinas virtuales como referencia.

21.7.2.2 Acciones de la máquina virtual #

Puede utilizar el menú de acciones al que se accede desde la lista desplegable ⋮ situada a la derecha de cada máquina virtual para iniciar, detener, pausar o hacer un reinicio suave. También puede usar las acciones de grupo de la parte superior de la lista seleccionando las máquinas virtuales en las que desea realizar la acción.

Estas acciones pueden afectar a la estrategia de ejecución de la máquina virtual. Consulte la tabla en la documentación de KubeVirt para obtener más detalles.

21.7.2.3 Acceso al panel de control de la máquina virtual #

La lista "Virtual Machines" (Máquinas virtuales) proporciona una lista desplegable Console (Panel de control) que permite conectarse a la máquina mediante VNC o un panel de control serie. Esta acción solo está disponible para máquinas en ejecución.

En algunos casos, para poder acceder al panel de control en una máquina virtual recién iniciada se debe esperar un poco.

21.8 Instalación con Edge Image Builder #

SUSE Edge usa Capítulo 11, Edge Image Builder para personalizar las imágenes del sistema operativo SUSE Linux Micro base. Siga las instrucciones de la Sección 27.9, “Instalación de KubeVirt y CDI” para realizar una instalación en un entorno aislado tanto de KubeVirt como de CDI sobre clústeres de Kubernetes aprovisionados por EIB.