En este documento, se proporciona una guía paso a paso para implementar una carga de trabajo basada en máquina virtual (VM) en GKE en Bare Metal con el entorno de ejecución de VM en Google Distributed Cloud. La carga de trabajo que se usa en esta guía es la aplicación de punto de venta de muestra. Esta aplicación representa una terminal de punto de venta típica que se ejecuta en el hardware local de una tienda minorista.
En este documento, migrarás esta aplicación de una VM a un clúster de GKE en Bare Metal y accederás al frontend web de la aplicación. Para migrar una VM existente al clúster, primero se debe crear una imagen de disco de esa VM. Luego, la imagen debe estar alojada en un repositorio al que el clúster pueda acceder. Por último, puedes usar la URL de esa imagen para crear la VM. El entorno de ejecución de VM en Google Distributed Cloud 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 este documento, se usa una imagen ya preparada de una instancia de VM de Compute Engine en la que la carga de trabajo se ejecuta como un servicio systemd. Puedes seguir estos mismos pasos para implementar tu propia aplicación.
Objetivos
Antes de comenzar
Para completar este documento, necesitas los siguientes recursos:
- Acceso a un clúster de GKE on Bare Metal versión 1.12.0 o superior que se creó mediante la guía Ejecuta GKE en Bare Metal en VM de Compute Engine 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 mediante un navegador. Si no necesitas ese comportamiento, puedes seguir este documento con cualquier GKE en Bare Metal.
- Una estación de trabajo que cumpla con los siguientes requisitos:
Habilita el entorno de ejecución de VM en Google Distributed Cloud y, luego, instala el complemento virtctl
La definición de recurso personalizado (CRD) del entorno de ejecución de VM en Google Distributed Cloud forma parte de todos los clústeres de GKE en Bare Metal desde la versión 1.10. Cuando se instala, ya se crea una instancia del recurso personalizado VMRuntime
. Sin embargo, está inhabilitado de forma predeterminada.
Habilita el entorno de ejecución de VM en Google Distributed Cloud:
sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
- KUBECONFIG_PATH: Ruta de acceso al archivo de configuración de Kubernetes del clúster de usuario de GKE Enterprise
Valida que
VMRuntime
esté habilitado:kubectl wait --for=jsonpath='{.status.ready}'=true vmruntime vmruntime
Es posible que
VMRuntime
tarde unos minutos en estar listo. Si no está listo, verifica algunas veces con retrasos breves. En el siguiente resultado de ejemplo, se muestra queVMRuntime
está listo:vmruntime.vm.cluster.gke.io/vmruntime condition met
Instala el complemento virtctl para
kubectl
:sudo -E bmctl install virtctl
En el siguiente resultado de ejemplo, se muestra que se completó el proceso de instalación del complemento
virtctl
: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
Verifica la instalación del complemento
virtctl
:kubectl virt
En el siguiente resultado de ejemplo, se muestra que el complemento
virtctl
está disponible para usar conkubectl
: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 GKE en Bare Metal, el entorno de ejecución de VM en Google Distributed Cloud espera una imagen de VM. Esta imagen sirve como el disco de arranque de la VM implementada.
En este instructivo, migrarás una carga de trabajo basada en VM de Compute Engine a un clúster de GKE en Bare Metal. Se creó esta VM de Compute Engine y se configuró la aplicación de punto de venta (PoS) de muestra para que se ejecute como un servicio systemd. Se creó una imagen de disco de esta VM junto con la carga de trabajo de la aplicación de PoS en Google Cloud. Luego, esta imagen se exportó a un bucket de Cloud Storage como una imagen qcow2
.
En los siguientes pasos, usarás esta imagen de qcow2
ya preparada.
El código fuente de este documento está disponible en el repositorio anthos-samples de GitHub. Usas recursos de este repositorio para completar los pasos siguientes.
Implementa un
StatefulSet
de MySQL. La aplicación de punto de venta espera conectarse a una base de datos MySQL para almacenar información de pago y de inventario. El repositorio del punto de venta tiene un manifiesto de muestra que implementa unStatefulSet
de MySQL, configura unConfigMap
asociado y unService
de Kubernetes. ElConfigMap
define las credenciales para la instancia de MySQL, que son las mismas credenciales que se pasaron a la aplicación de punto de venta.kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/point-of-sale/main/k8-manifests/common/mysql-db.yaml
Implementa la carga de trabajo de VM con la imagen
qcow2
ya preparada: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 deVirtualMachine
yVirtualMachineDisk
. En lugar de usar el complementovirtctl
, podrías haber implementado la carga de trabajo de la VM mediante las 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 del siguiente ejemplo que explica 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"
Verifica el estado de creación de la VM.
El recurso
VirtualMachine
se identifica con el recursovm.cluster.gke.io/v1.VirtualMachine
en el entorno de ejecución de VM en Google Distributed Cloud. La forma abreviada esgvm
.Cuando creas una VM, se generan los siguientes dos recursos:
- Un VirtualMachineDisk es el disco persistente en el que se importa el contenido de la imagen de VM.
- Una VirtualMachine es la instancia de VM en sí. El DataVolume se activa en la VirtualMachine antes de que la VM se inicie.
Verifica el estado de 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 imágenes:
NAME PHASE PROGRESS RESTARTS AGE pos-vm-boot-dv ImportScheduled N/A 8s
Verifica el estado de
VirtualMachine
.VirtualMachine
se encuentra en el estadoProvisioning
hasta que se importa por completoDataVolume
:kubectl get gvm
En el siguiente resultado de ejemplo, se muestra el
VirtualMachine
que se aprovisiona:NAME STATUS AGE IP pos-vm Provisioning 1m
Espera a que la imagen de VM se importe por completo a
DataVolume
. Sigue viendo 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 importa:
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 completa la importación y se crea el
DataVolume
, el siguiente resultado de ejemplo muestra elPHASE
deSucceeded
:kubectl get datavolume
NAME PHASE PROGRESS RESTARTS AGE pos-vm-boot-dv Succeeded 100.0% 14m18s
Confirma que el
VirtualMachine
se haya creado de forma correcta:kubectl get gvm
Si la creación se realizó correctamente,
STATUS
mostraráRUNNING
, como se muestra 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 muestra de punto de venta. La aplicación está configurada para iniciarse de forma automática en el inicio como un servicio systemd. Puedes ver los archivos de configuración de los servicios systemd en el directorio pos-systemd-services.
Conéctate a la consola de VM. Ejecuta el siguiente comando y presiona Intro⏎ cuando veas el mensaje
Successfully connected to pos-vm…
:kubectl virt console pos-vm
Este comando produce el siguiente resultado de ejemplo en el que se 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 el entorno de ejecución de VM en Google Distributed Cloud VirtualMachine.
- Nombre de usuario de acceso:
abmuser
- Contraseña:
abmworks
- Nombre de usuario de acceso:
Verifica el estado de los servicios de aplicaciones 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 MySQL mediante un servicio de Kubernetes mysql-db que se creó en el paso anterior. Este comportamiento significa que la VM se conecta de forma automática a la misma red que
Pods
yServices
, lo que permite una comunicación fluida entre las cargas de trabajo de VM y otras aplicaciones alojadas en contenedores. No tienes que hacer nada adicional para que elServices
de Kubernetes sea accesible desde las VM implementadas mediante el entorno de ejecución de VM de Anthos.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
Sal de la VM. Para salir de la conexión de la consola, presiona
Ctrl + ]
con la secuencia de escape^]
.
Accede a la carga de trabajo basada en VM
Si tu clúster se configuró según la guía Ejecuta GKE en Bare Metal en VM de Compute Engine con un balanceador de cargas manual, ya tiene un recurso Ingress
llamado pos-ingress
. Este recurso enruta el tráfico desde la dirección IP pública del balanceador de cargas de Ingress al servicio del servidor de la API de la aplicación de muestra del punto de venta.
Si tu clúster no tiene este recurso
Ingress
, aplica el siguiente manifiesto para crearlo:kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-gcp-terraform/resources/manifests/pos-ingress.yaml
Crea un
Service
de Kubernetes que enrute el tráfico a la VM. El recursoIngress
enruta el tráfico a esteService
:kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-vmruntime/pos-service.yaml
El siguiente resultado de ejemplo confirma la creación de un servicio:
service/api-server-svc created
Obtén la dirección IP pública del balanceador de cargas
Ingress
. El balanceador de cargasIngress
enruta el tráfico según las reglas de recursosIngress
. Ya tienes una reglapos-ingress
para reenviar solicitudes al servidor de la APIService
. EsteService
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
Accede a la aplicación mediante la dirección IP del balanceador de cargas del Ingress en un navegador. En las siguientes capturas de pantalla de ejemplo, se muestra el kiosco de punto de venta simple con dos artículos. Si quieres pedir varios de ellos, puedes hacer clic en los artículos más de una vez y hacer un pedido con el botón Pay. Esta experiencia muestra que implementaste de forma correcta una carga de trabajo tradicional basada en VM en un clúster de Anthos mediante el entorno de ejecución de VM en Google Distributed Cloud.
Limpia
Puedes borrar todos los recursos creados en este instructivo o borrar solo la VM y conservar los recursos reutilizables. En Borra una VM en GKE en Bare Metal, se explican en detalle las opciones disponibles.
Borrar todo
Borra el entorno de ejecución de VM en Google Distributed Cloud
VirtualMachine
junto con todos los recursos:kubectl virt delete vm pos-vm --all
El siguiente resultado de ejemplo 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 VM
Si borras solo la VM, se conserva el
VirtualMachineDisk
que se crea. Esto permite volver a usar esta imagen de VM y ahorra el tiempo dedicado a importar la imagen cuando se crea una VM nueva.kubectl virt delete vm pos-vm
El siguiente resultado de ejemplo 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. La imagen de esta VM es de acceso público a través del bucket pos-vm-images de Cloud Storage. Para obtener más información sobre cómo se configuró la VM y se creó su imagen, consulta las instrucciones en el repositorio de punto de venta.
- Cuando creas una VM en un clúster de Anthos mediante 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 deVirtualMachine
yVirtualMachineDisk
. En lugar de usar el complementovirtctl
, puedes implementar una VM mediante las definiciones de KRM como se ven en el archivo YAML creado.