Instructivo: Implementa una VM existente en un clúster con el entorno de ejecución de VM en GDC

El entorno de ejecución de VM en GDC te permite implementar cargas de trabajo de máquina virtual (VM) directamente en una instalación del software de Distributed Cloud solo para equipos físicos. En este instructivo, migrarás una aplicación de punto de venta de ejemplo, que representa una terminal de punto de venta minorista, desde una VM de Compute Engine a un clúster de equipos físicos y accederás a su frontend web.

La implementación usa una imagen de disco preparada previamente en la que la carga de trabajo se ejecuta como un servicio de systemd. También puedes seguir estos pasos para preparar e implementar tus propias aplicaciones basadas en VM.

Objetivos

• Habilita el entorno de ejecución de VM en GDC y, luego, instala el complemento virtctl
• Implementa la VM basada en VMs
• Accede a la VM y verifica el estado de la aplicación
• Accede a la carga de trabajo basada en VM

Antes de comenzar

Para completar este documento, necesitas los siguientes recursos:

• Acceso a un clúster de equipos físicos de la versión 1.12.0 o posterior que se creó siguiendo la guía Instala con el balanceador de cargas manual. En este documento, se configuran los recursos de red para que puedas acceder a la carga de trabajo que se ejecuta dentro de la VM a través de un navegador. Si no necesitas ese comportamiento, puedes seguir este documento con cualquier instalación del software de Distributed Cloud solo para equipos físicos.
• Una estación de trabajo que cumpla con los siguientes requisitos:
  • Tiene acceso a tu clúster con la CLI de bmctl.
  • Tiene acceso a tu clúster con la CLI de kubectl.

Habilita el entorno de ejecución de VM en GDC y, luego, instala el complemento virtctl

La definición de recursos personalizados del entorno de ejecución de VM en GDC forma parte de todos los clústeres de equipos físicos desde la versión 1.10. Ya se creó una instancia del recurso personalizado VMRuntime durante la instalación. Sin embargo, está inhabilitada de forma predeterminada.

1. Habilita el entorno de ejecución de VM en GDC.

   sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
   

   • KUBECONFIG_PATH: Es la ruta de acceso del archivo kubeconfig del clúster de usuario.

2. Valida que la VMRuntime esté habilitada:

   kubectl wait --for=jsonpath='{.status.ready}'=true vmruntime vmruntime
   

   Es posible que esto tarde algunos minutos para VMRuntime. Si no está listo, verifica varias veces con retrasos breves. En el siguiente resultado de ejemplo, se muestra que el VMRuntime está listo:

   vmruntime.vm.cluster.gke.io/vmruntime condition met
   

3. Instala el complemento virtctl para kubectl:

   sudo -E bmctl install virtctl
   

   En el siguiente resultado de ejemplo, se muestra que el proceso de instalación del complemento virtctl se completó:

   Please check the logs at bmctl-workspace/log/install-virtctl-20220831-182135/install-virtctl.log
   [2022-08-31 18:21:35+0000] Install virtctl succeeded
   

4. Verifica la instalación del complemento virtctl:

   kubectl virt
   

   En el siguiente resultado de ejemplo, se muestra que el complemento virtctl está disponible para usarse con kubectl:

   Available Commands:
     addvolume         add a volume to a running VM
     completion        generate the autocompletion script for the specified shell
     config            Config subcommands.
     console           Connect to a console of a virtual machine instance.
     create            Create subcommands.
     delete            Delete  subcommands.
   ...
   

Implementa la carga de trabajo basada en VM

Cuando implementas una VM en una instalación de software de Distributed Cloud solo para equipos físicos, el entorno de ejecución de VM en GDC espera una imagen de VM. Esta imagen sirve como disco de arranque para la VM implementada.

Para migrar una VM existente al clúster, primero se debe crear una imagen de disco de esa VM. Luego, la imagen debe alojarse en un repositorio al que el clúster pueda acceder. Por último, la URL de esa imagen se puede usar para crear la VM. El entorno de ejecución de VM en GDC espera que las imágenes estén en formato qcow2. Si proporcionas un tipo de imagen diferente, se convierte automáticamente al formato qcow2. Para evitar la conversión repetitiva y habilitar la reutilización, puedes convertir una imagen de disco virtual y alojar la imagen qcow2.

En los siguientes pasos, usarás una imagen de qcow2 preparada con anterioridad en la que la carga de trabajo de muestra se creó como una imagen de disco de VM en Google Cloud y se exportó a un bucket de Cloud Storage.

Nota: Aunque usamos una VM de Compute Engine en este documento, los pasos para crear una imagen de disco de una VM varían según el entorno o la plataforma en la que se ejecuta la VM existente. Puedes crear una imagen de disco de tus VMs existentes si quieres seguir los pasos de este documento con tu propia imagen personalizada.

El código fuente de este documento está disponible en el repositorio de GitHub anthos-samples. Usa los recursos de este repositorio para completar los pasos que se indican a continuación.

1. Implementa un StatefulSet de MySQL. La aplicación de punto de venta espera conectarse a una base de datos de MySQL para almacenar información de inventario y pagos. El repositorio de punto de venta tiene un manifiesto de muestra que implementa un StatefulSet de MySQL, configura un ConfigMap asociado y un Service de Kubernetes. El ConfigMap define las credenciales de la instancia de MySQL, que son las mismas credenciales que se pasan a la aplicación del punto de venta.

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/point-of-sale/main/k8-manifests/common/mysql-db.yaml
   

2. Implementa la carga de trabajo de la VM con la imagen qcow2 preparada previamente:

   kubectl virt create vm pos-vm \
       --boot-disk-size=80Gi \
       --memory=4Gi \
       --vcpu=2 \
       --image=https://storage.googleapis.com/pos-vm-images/pos-vm.qcow2
   

   Este comando crea un archivo YAML con el nombre de la VM (google-virtctl/pos-vm.yaml). Puedes inspeccionar el archivo para ver la definición de VirtualMachine y VirtualMachineDisk. En lugar de usar el complemento virtctl, podrías haber implementado la carga de trabajo de la VM con definiciones del modelo de recursos de Kubernetes (KRM), como se ve en el archivo YAML creado.

   Cuando el comando se ejecuta de forma correcta, produce un resultado como el siguiente ejemplo, en el que se explican los diferentes recursos que se crearon:

   Constructing manifest for vm "pos-vm":
   Manifest for vm "pos-vm" is saved to /home/tfadmin/google-virtctl/pos-vm.yaml
   Applying manifest for vm "pos-vm"
   Created gvm "pos-vm"
   

3. Verifica el estado de creación de la VM.

   El recurso VirtualMachine se identifica con el recurso vm.cluster.gke.io/v1.VirtualMachine en el entorno de ejecución de VM en GDC. La forma abreviada es gvm.

   Cuando creas una VM, se crean los siguientes dos recursos:

   • Un VirtualMachineDisk es el disco persistente en el que se importa el contenido de la imagen de la VM.
   • Un VirtualMachine es la instancia de VM en sí. El DataVolume se activa en la VirtualMachine antes de que se inicie la VM.

   Verifica el estado del VirtualMachineDisk. VirtualMachineDisk crea de forma interna un recurso DataVolume. La imagen de VM se importa al DataVolume que se activa en la VM:

   kubectl get datavolume
   

   En el siguiente resultado de ejemplo, se muestra el inicio de la importación de la imagen:

   NAME              PHASE             PROGRESS   RESTARTS   AGE
   pos-vm-boot-dv    ImportScheduled   N/A                   8s
   

4. Verifica el estado de VirtualMachine. El VirtualMachine está en el estado Provisioning hasta que el DataVolume se importe por completo:

   kubectl get gvm
   

   En el siguiente resultado de ejemplo, se muestra el aprovisionamiento de VirtualMachine:

   NAME      STATUS         AGE     IP
   pos-vm    Provisioning   1m
   

5. Espera a que la imagen de la VM se importe por completo en DataVolume. Sigue observando el progreso mientras se importa la imagen:

   kubectl get datavolume -w
   

   En el siguiente resultado de ejemplo, se muestra la imagen de disco que se está importando:

   NAME              PHASE              PROGRESS   RESTARTS   AGE
   pos-vm-boot-dv   ImportInProgress   0.00%                 14s
   ...
   ...
   pos-vm-boot-dv   ImportInProgress   0.00%                 31s
   pos-vm-boot-dv   ImportInProgress   1.02%                 33s
   pos-vm-boot-dv   ImportInProgress   1.02%                 35s
   ...
   

   Cuando se complete la importación y se cree el DataVolume, el siguiente resultado de ejemplo mostrará el PHASE de Succeeded :

   kubectl get datavolume
   

   NAME              PHASE             PROGRESS   RESTARTS   AGE
   pos-vm-boot-dv    Succeeded         100.0%                14m18s
   

   Nota: El tiempo de importación depende del tamaño de la imagen de VM que se use. La imagen de VM de Compute Engine en este documento es de alrededor de 5 GB y tarda hasta 15 minutos en importarse.

6. Confirma que el VirtualMachine se haya creado correctamente:

   kubectl get gvm
   

   Si la creación se realizó de forma correcta, el STATUS muestra RUNNING, como se indica en el siguiente ejemplo, junto con la dirección IP de la VM:

   NAME      STATUS    AGE     IP
   pos-vm    Running   40m     192.168.3.250
   

Conéctate a la VM y verifica el estado de la aplicación

La imagen que se usa para la VM incluye la aplicación de ejemplo de punto de venta. La aplicación está configurada para iniciarse automáticamente en el arranque como un servicio de systemd. Puedes ver los archivos de configuración de los servicios de systemd en el directorio pos-systemd-services.

1. Conéctate a la consola de VM. Ejecuta el siguiente comando y presiona Intro⏎ después de ver el mensaje Successfully connected to pos-vm…:

   kubectl virt console pos-vm
   

   Este comando produce el siguiente resultado de ejemplo que te solicita que ingreses los login details:

   Successfully connected to pos-vm console. The escape sequence is ^]
   
   pos-from-public-image login:
   

   Usa la siguiente cuenta de usuario y contraseña. Esta cuenta se configuró dentro de la VM original desde la que se creó la imagen para la VirtualMachine del entorno de ejecución de VM en GDC.

   • Nombre de usuario de acceso: abmuser
   • Contraseña: abmworks

2. Verifica el estado de los servicios de la aplicación de punto de venta. La aplicación de punto de venta incluye tres servicios: API, inventario y pagos. Todos estos servicios se ejecutan como servicios del sistema.

   Los tres servicios se conectan entre sí a través de localhost. Sin embargo, la aplicación se conecta a la base de datos de MySQL con un Service de Kubernetes mysql-db que se creó en el paso anterior. Este comportamiento significa que la VM se conecta automáticamente a la misma red que Pods y Services, lo que permite una comunicación fluida entre las cargas de trabajo de la VM y otras aplicaciones alojadas en contenedores. No tienes que hacer nada más para que se pueda acceder al Services de Kubernetes desde las VMs implementadas con el entorno de ejecución de VM en GDC.

   sudo systemctl status pos*
   

   En el siguiente resultado de ejemplo, se muestra el estado de los tres servicios y el servicio del sistema raíz, pos.service:

   ● pos_payments.service - Payments service of the Point of Sale Application
       Loaded: loaded (/etc/systemd/system/pos_payments.service; enabled; vendor >
       Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
     Main PID: 750 (payments.sh)
         Tasks: 27 (limit: 4664)
       Memory: 295.1M
       CGroup: /system.slice/pos_payments.service
               ├─750 /bin/sh /pos/scripts/payments.sh
               └─760 java -jar /pos/jars/payments.jar --server.port=8083
   
   ● pos_inventory.service - Inventory service of the Point of Sale Application
       Loaded: loaded (/etc/systemd/system/pos_inventory.service; enabled; vendor>
       Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
     Main PID: 749 (inventory.sh)
         Tasks: 27 (limit: 4664)
       Memory: 272.6M
       CGroup: /system.slice/pos_inventory.service
               ├─749 /bin/sh /pos/scripts/inventory.sh
               └─759 java -jar /pos/jars/inventory.jar --server.port=8082
   
   ● pos.service - Point of Sale Application
       Loaded: loaded (/etc/systemd/system/pos.service; enabled; vendor preset: e>
       Active: active (exited) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago
     Main PID: 743 (code=exited, status=0/SUCCESS)
         Tasks: 0 (limit: 4664)
       Memory: 0B
       CGroup: /system.slice/pos.service
   
   Jun 21 18:55:30 pos-vm systemd[1]: Starting Point of Sale Application...
   Jun 21 18:55:30 pos-vm systemd[1]: Finished Point of Sale Application.
   
   ● pos_apiserver.service - API Server of the Point of Sale Application
       Loaded: loaded (/etc/systemd/system/pos_apiserver.service; enabled; vendor>
       Active: active (running) since Tue 2022-06-21 18:55:31 UTC; 1h 10min ago
     Main PID: 751 (api-server.sh)
         Tasks: 26 (limit: 4664)
       Memory: 203.1M
       CGroup: /system.slice/pos_apiserver.service
               ├─751 /bin/sh /pos/scripts/api-server.sh
               └─755 java -jar /pos/jars/api-server.jar --server.port=8081
   

3. Sal de la VM. Para salir de la conexión de la consola, usa la secuencia de escape ^] presionando Ctrl + ].

Accede a la carga de trabajo basada en VM

Si tu clúster se configuró siguiendo la guía Instala con un balanceador de cargas manual, ya tiene un recurso Ingress llamado pos-ingress creado. Este recurso enruta el tráfico de la dirección IP externa del balanceador de cargas de Ingress al servicio del servidor de la API de la aplicación de ejemplo de punto de venta.

1. Si tu clúster no tiene este recurso Ingress, créalo aplicando el siguiente manifiesto:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-gcp-terraform/resources/manifests/pos-ingress.yaml
   

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: pos-ingress
   spec:
     rules:
     - http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: api-server-svc
               port:
                 number: 8080

2. Crea un Service de Kubernetes que enrute el tráfico a la VM. El recurso Ingress enruta el tráfico a este Service:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-vmruntime/pos-service.yaml
   

   En el siguiente resultado de ejemplo, se confirma la creación de un Service:

   service/api-server-svc created
   

   apiVersion: v1
   kind: Service
   metadata:
     name: api-server-svc
   spec:
     selector:
       kubevirt/vm: pos-vm
     ports:
     - protocol: TCP
       port: 8080
       targetPort: 8081

3. Obtén la dirección IP externa del balanceador de cargas Ingress. El balanceador de cargas de Ingress enruta el tráfico según las reglas del recurso Ingress. Ya tienes una regla pos-ingress para reenviar solicitudes al servidor de la API Service. Este Service reenvía las solicitudes a la VM:

   INGRESS_IP=$(kubectl get ingress/pos-ingress -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   echo $INGRESS_IP
   

   En el siguiente resultado de ejemplo, se muestra la dirección IP del balanceador de cargas Ingress:

   172.29.249.159 # you might have a different IP address
   

4. Para acceder a la aplicación, usa la dirección IP del balanceador de cargas de Ingress en un navegador. En las siguientes capturas de pantalla de ejemplo, se muestra el kiosco de punto de venta con dos artículos. Puedes hacer clic en los artículos, más de una vez si quieres pedir varios, y realizar un pedido con el botón Pagar. Esta experiencia muestra que implementaste correctamente una carga de trabajo basada en VM en un clúster con el entorno de ejecución de VMs en GDC.

IU de la aplicación de punto de venta (haz clic en la imagen para ampliarla)

Realiza una limpieza

Puedes borrar todos los recursos que creaste en este instructivo o borrar solo la VM y conservar los recursos reutilizables. En Borra una VM, se explican las opciones disponibles en detalle.

Borrar todo

• Borra el entorno de ejecución de VM en GDC VirtualMachine junto con todos los recursos:

  kubectl virt delete vm pos-vm --all
  

  En el siguiente resultado de ejemplo, se confirma la eliminación:

  vm "pos-vm" used the following resources:
      gvm: pos-vm
      VirtualMachineDisk: pos-vm-boot-dv
  Start deleting the resources:
      Deleted gvm "pos-vm".
      Deleted VirtualMachineDisk "pos-vm-boot-dv".
  

Borrar solo la VM

• Si solo borras la VM, se conservará el VirtualMachineDisk que se cree. Esto permite reutilizar esta imagen de VM y ahorrar tiempo en la importación de la imagen cuando se crea una VM nueva.

  kubectl virt delete vm pos-vm
  

  En el siguiente resultado de ejemplo, se confirma la eliminación:

  vm "pos-vm" used the following resources:
      gvm: pos-vm
      VirtualMachineDisk: pos-vm-boot-dv
  Start deleting the resources:
      Deleted gvm "pos-vm".
  

¿Qué sigue?

• La VM original que se usa en esta guía es una instancia de Compute Engine que ejecuta Ubuntu 20.04 LTS. Se puede acceder de forma pública a la imagen de esta VM a través del bucket de Cloud Storage pos-vm-images. Para obtener más información sobre cómo se configuró la VM y cómo se creó su imagen, consulta las instrucciones en el repositorio de punto de venta.
• Cuando creas una VM en un clúster con el comando kubectl virt create vm pos-vm, se crea un archivo YAML con el nombre de la VM (google-virtctl/pos-vm.yaml). Puedes inspeccionar el archivo para ver la definición de VirtualMachine y VirtualMachineDisk. En lugar de usar el complemento virtctl, puedes implementar una VM con definiciones de KRM, como se ve en el archivo YAML creado.