Tutorial: esegui il deployment di una VM esistente in un cluster utilizzando il runtime VM su GDC

VM Runtime on GDC ti consente di eseguire il deployment dei workload delle macchine virtuali (VM) direttamente in un'installazione del software Distributed Cloud solo per Bare Metal. In questo tutorial eseguirai la migrazione di un'applicazione per punti vendita di esempio, che rappresenta un terminale per punti vendita di vendita al dettaglio, da una VM Compute Engine a un cluster Bare Metal e accederai al relativo frontend web.

Il deployment utilizza un'immagine disco pre-preparata in cui il workload viene eseguito come servizio systemd. Puoi anche seguire questi passaggi per preparare ed eseguire il deployment delle tue applicazioni basate su VM.

Obiettivi

• Abilita VM Runtime on GDC e installa il plug-in virtctl
• Esegui il deployment del workload basato su VM
• Accedi alla VM e controlla lo stato dell'applicazione
• Accedi al workload basato su VM

Prima di iniziare

Per completare questo documento, hai bisogno delle seguenti risorse:

• Accesso a un cluster bare metal versione 1.12.0 o successiva creato seguendo la guida Installa con bilanciatore del carico manuale. Questo documento configura le risorse di networking in modo che tu possa accedere al workload in esecuzione all'interno della VM tramite un browser. Se non hai bisogno di questo comportamento, puoi seguire questo documento utilizzando qualsiasi installazione di Distributed Cloud solo software per bare metal.
• Una workstation che soddisfi i seguenti requisiti:
  • Ha accesso al tuo cluster utilizzando l'interfaccia a riga di comando bmctl.
  • Ha accesso al tuo cluster utilizzando l'interfaccia a riga di comando kubectl.

Abilita VM Runtime on GDC e installa il plug-in virtctl

La definizione di risorsa personalizzata VM Runtime on GDC fa parte di tutti i cluster bare metal dalla versione 1.10. Un'istanza della risorsa personalizzata VMRuntime viene già creata al momento dell'installazione. Tuttavia, è disattivato per impostazione predefinita.

1. Abilita VM Runtime on GDC:

   sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
   

   • KUBECONFIG_PATH: il percorso del file kubeconfig del cluster utente.

2. Verifica che VMRuntime sia abilitato:

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

   La preparazione di VMRuntime può richiedere alcuni minuti. Se non è pronto, controlla alcune volte con brevi ritardi. L'output di esempio seguente mostra che VMRuntime è pronto:

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

3. Installa il plug-in virtctl per kubectl:

   sudo -E bmctl install virtctl
   

   L'output di esempio seguente mostra che il processo di installazione del plug-in virtctl è stato completato:

   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 l'installazione del plug-in virtctl:

   kubectl virt
   

   L'output di esempio seguente mostra che il plug-in virtctl è disponibile per l'utilizzo 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.
   ...
   

Esegui il deployment del workload basato su VM

Quando esegui il deployment di una VM in un'installazione di Distributed Cloud (solo software) per Bare Metal, il runtime VM su GDC si aspetta un'immagine VM. Questa immagine funge da disco di avvio per la VM di cui è stato eseguito il deployment.

Per eseguire la migrazione di una VM esistente nel cluster, devi prima creare un'immagine disco della VM. L'immagine deve quindi essere ospitata in un repository a cui il cluster può accedere. Infine, l'URL dell'immagine può essere utilizzato per creare la VM. Il runtime VM su GDC prevede che le immagini siano in formato qcow2. Se fornisci un tipo di immagine diverso, viene convertito automaticamente nel formato qcow2. Per evitare conversioni ripetitive e consentire il riutilizzo, puoi convertire un'immagine disco virtuale e ospitare l'immagine qcow2.

Nei passaggi successivi, utilizzerai un'immagine qcow2 pre-preparata in cui il workload di esempio è stato creato come immagine disco VM in Google Cloud ed esportato in un bucket Cloud Storage.

Nota: anche se in questo documento utilizziamo una VM di Compute Engine, i passaggi per creare un'immagine disco di una VM variano a seconda dell'ambiente o della piattaforma in cui è in esecuzione la VM esistente. Se vuoi seguire i passaggi descritti in questo documento con la tua immagine personalizzata, puoi creare un'immagine disco delle tue VM esistenti.

Il codice sorgente di questo documento è disponibile nel repository GitHub anthos-samples. Utilizzerai le risorse di questo repository per completare i passaggi seguenti.

1. Esegui il deployment di un'istanza MySQL StatefulSet. L'applicazione per i punti vendita prevede la connessione a un database MySQL per archiviare le informazioni su inventario e pagamenti. Il repository del punto vendita ha un manifest di esempio che esegue il deployment di un StatefulSet MySQL, configura un ConfigMap associato e un Service Kubernetes. ConfigMap definisce le credenziali per l'istanza MySQL, che sono le stesse credenziali passate all'applicazione per i punti vendita.

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

2. Esegui il deployment del workload della VM utilizzando l'immagine qcow2 predefinita:

   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
   

   Questo comando crea un file YAML con il nome della VM (google-virtctl/pos-vm.yaml). Puoi esaminare il file per visualizzare la definizione di VirtualMachine e VirtualMachineDisk. Anziché utilizzare il plug-in virtctl, avresti potuto eseguire il deployment del workload della VM utilizzando le definizioni del modello di risorse Kubernetes (KRM), come mostrato nel file YAML creato.

   Quando il comando viene eseguito correttamente, produce un output simile al seguente esempio che spiega le diverse risorse create:

   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. Controlla lo stato di creazione della VM.

   La risorsa VirtualMachine è identificata dalla risorsa vm.cluster.gke.io/v1.VirtualMachine nel runtime VM su GDC. La forma abbreviata è gvm.

   Quando crei una VM, vengono create le seguenti due risorse:

   • Un VirtualMachineDisk è il disco permanente in cui vengono importati i contenuti dell'immagine VM.
   • Un oggetto VirtualMachine è l'istanza VM stessa. Il DataVolume viene montato nella VirtualMachine prima dell'avvio della VM.

   Controlla lo stato del VirtualMachineDisk. VirtualMachineDisk crea internamente una risorsa DataVolume. L'immagine VM viene importata nel DataVolume montato nella VM:

   kubectl get datavolume
   

   L'output di esempio seguente mostra l'inizio dell'importazione dell'immagine:

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

4. Controlla lo stato di VirtualMachine. VirtualMachine è nello stato Provisioning finché DataVolume non viene importato completamente:

   kubectl get gvm
   

   L'output di esempio seguente mostra il provisioning di VirtualMachine:

   NAME      STATUS         AGE     IP
   pos-vm    Provisioning   1m
   

5. Attendi il completamento dell'importazione dell'immagine VM in DataVolume. Continua a monitorare l'avanzamento durante l'importazione dell'immagine:

   kubectl get datavolume -w
   

   L'output di esempio seguente mostra l'importazione dell'immagine disco:

   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
   ...
   

   Al termine dell'importazione e della creazione di DataVolume, il seguente output di esempio mostra PHASE di Succeeded :

   kubectl get datavolume
   

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

   Nota: il tempo di importazione dipende dalle dimensioni dell'immagine VM utilizzata. L'immagine VM di Compute Engine in questo documento è di circa 5 GB e l'importazione richiede fino a 15 minuti.

6. Verifica che VirtualMachine sia stato creato correttamente:

   kubectl get gvm
   

   Se la creazione è andata a buon fine, STATUS mostra RUNNING, come mostrato nell'esempio seguente, insieme all'indirizzo IP della VM:

   NAME      STATUS    AGE     IP
   pos-vm    Running   40m     192.168.3.250
   

Connettiti alla VM e controlla lo stato dell'applicazione

L'immagine utilizzata per la VM include l'applicazione di esempio per il punto vendita. L'applicazione è configurata per l'avvio automatico come servizio systemd. Puoi visualizzare i file di configurazione dei servizi systemd nella directory pos-systemd-services.

1. Connettiti alla console della VM. Esegui il comando seguente e premi Invio⏎ dopo aver visualizzato il messaggio Successfully connected to pos-vm…:

   kubectl virt console pos-vm
   

   Questo comando produce il seguente output di esempio che ti chiede di inserire i dettagli di accesso:

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

   Utilizza l'account utente e la password seguenti. Questo account è stato configurato all'interno della VM originale da cui è stata creata l'immagine per la risorsa VirtualMachine di VM Runtime on GDC.

   • Nome utente di accesso: abmuser
   • Password: abmworks

2. Controlla lo stato dei servizi dell'applicazione point of sale. L'applicazione per il punto vendita include tre servizi: API, Inventario e Pagamenti. Tutti questi servizi vengono eseguiti come servizi di sistema.

   I tre servizi si connettono tra loro tramite localhost. Tuttavia, l'applicazione si connette al database MySQL utilizzando un servizio Kubernetes mysql-db creato nel passaggio precedente. Questo comportamento significa che la VM è connessa automaticamente alla stessa rete di Pods e Services, consentendo una comunicazione fluida tra i workload delle VM e altre applicazioni containerizzate. Non devi fare nulla per rendere il Services Kubernetes raggiungibile dalle VM di cui è stato eseguito il deployment utilizzando il runtime VM su GDC.

   sudo systemctl status pos*
   

   L'output di esempio seguente mostra lo stato dei tre servizi e del servizio di sistema root, 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. Esci dalla VM. Per uscire dalla connessione alla console, utilizza la sequenza di escape ^] premendo Ctrl + ].

Accedi al workload basato su VM

Se il cluster è stato configurato seguendo la guida Installa con bilanciatore del carico manuale, ha una risorsa Ingress denominata pos-ingress già creata. Questa risorsa instrada il traffico dall'indirizzo IP esterno del bilanciatore del carico in entrata al servizio del server API dell'applicazione di esempio per i punti vendita.

1. Se il tuo cluster non dispone di questa risorsa Ingress, creala applicando il seguente manifest:

   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 Kubernetes che instrada il traffico alla VM. La risorsa Ingress instrada il traffico a questo Service:

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

   L'output di esempio seguente conferma la creazione di un servizio:

   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. Ottieni l'indirizzo IP esterno del bilanciatore del carico Ingress. Il bilanciatore del carico Ingress instrada il traffico in base alle regole della risorsa Ingress. Hai già una regola pos-ingress per inoltrare le richieste al server API Service. Questo Service inoltra le richieste alla VM:

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

   L'output di esempio seguente mostra l'indirizzo IP del bilanciatore del carico Ingress:

   172.29.249.159 # you might have a different IP address
   

4. Accedi all'applicazione utilizzando l'indirizzo IP del bilanciatore del carico Ingress in un browser. I seguenti screenshot di esempio mostrano il kiosk del punto vendita con due articoli. Puoi fare clic sugli articoli, più di una volta se vuoi ordinarne più di uno, ed effettuare un ordine con il pulsante Paga. Questa esperienza dimostra che hai eseguito correttamente il deployment di un workload basato su VM in un cluster utilizzando VM Runtime on GDC.

UI dell'applicazione per il punto vendita (fai clic sull'immagine per ingrandirla)

Esegui la pulizia

Puoi eliminare tutte le risorse create in questo tutorial o eliminare solo la VM e conservare le risorse riutilizzabili. Elimina una VM illustra in dettaglio le opzioni disponibili.

Elimina tutto

• Elimina VM Runtime on GDC VirtualMachine insieme a tutte le risorse:

  kubectl virt delete vm pos-vm --all
  

  L'output di esempio seguente conferma l'eliminazione:

  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".
  

Elimina solo la VM

• L'eliminazione della sola VM conserva la VirtualMachineDisk creata. In questo modo, l'immagine VM può essere riutilizzata e si risparmia tempo durante l'importazione dell'immagine quando si crea una nuova VM.

  kubectl virt delete vm pos-vm
  

  L'output di esempio seguente conferma l'eliminazione:

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

Passaggi successivi

• La VM originale utilizzata in questa guida è un'istanza Compute Engine che esegue Ubuntu 20.04 LTS. L'immagine di questa VM è accessibile pubblicamente tramite il bucket Cloud Storage pos-vm-images. Per saperne di più su come è stata configurata la VM e su come è stata creata la sua immagine, consulta le istruzioni nel repository del punto vendita.
• Quando crei una VM in un cluster utilizzando il comando kubectl virt create vm pos-vm, viene creato un file YAML con il nome della VM (google-virtctl/pos-vm.yaml). Puoi esaminare il file per visualizzare la definizione di VirtualMachine e VirtualMachineDisk. Anziché utilizzare il plug-in virtctl, puoi eseguire il deployment di una VM utilizzando le definizioni KRM, come mostrato nel file YAML creato.