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

Questo documento fornisce una guida passo passo per il deployment di un carico di lavoro basato su macchine virtuali (VM) in un'installazione di Google Distributed Cloud (solo software) su bare metal utilizzando il runtime VM su GDC. Il carico di lavoro utilizzato in questa guida è l'applicazione di esempio per il punto vendita. Questa applicazione rappresenta un tipico terminale per il punto vendita in esecuzione su hardware on-premise in un negozio al dettaglio.

In questo documento, esegui la migrazione di questa applicazione da una VM a un cluster e accedi al frontend web dell'applicazione. Per eseguire la migrazione di una VM esistente nel cluster, devi prima creare un'immagine disco della VM. Poi, l'immagine deve essere ospitata in un repository a cui il cluster può accedere. Infine, puoi utilizzare l'URL dell'immagine 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 del disco virtuale e ospitare l'immagine qcow2.

Questo documento utilizza un'immagine pre-preparata di un'istanza VM di Compute Engine in cui il carico di lavoro viene eseguito come un servizio systemd. Puoi seguire questi stessi passaggi per eseguire il deployment della tua applicazione.

Obiettivi

• Abilitare il runtime VM su GDC e installare il plug-in virtctl
• Eseguire il deployment del carico di lavoro basato su VM
• Accedere alla VM e controllare lo stato dell'applicazione
• Accedere al carico di lavoro 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 successive creato seguendo la guida Installazione con bilanciatore del carico manuale. Questo documento configura le risorse di rete in modo che tu possa accedere al carico di lavoro in esecuzione all'interno della VM tramite un browser. Se non hai bisogno di questo comportamento, puoi seguire questo documento utilizzando qualsiasi installazione di Google Distributed Cloud su bare metal.
• Una workstation che soddisfi i seguenti requisiti:
  • Ha accesso al cluster utilizzando l'interfaccia a riga di comando bmctl.
  • Ha accesso al cluster utilizzando l' interfaccia a riga di comando kubectl.

Abilitare il runtime VM su GDC e installare il plug-in virtctl

La definizione di risorsa personalizzata del runtime VM su GDC fa parte di tutti i cluster bare metal dalla versione 1.10. Al momento dell'installazione viene già creata un'istanza della risorsa personalizzata VMRuntime. Tuttavia, è disabilitata per impostazione predefinita.

1. Abilita il runtime VM su GDC:

   sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
   

   • KUBECONFIG_PATH: percorso del file kubeconfig del cluster utente.

2. Verifica che VMRuntime sia abilitato:

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

   Potrebbero essere necessari alcuni minuti prima che VMRuntime sia pronto. Se non è pronto, controlla alcune volte con brevi ritardi. L'esempio di output seguente mostra che VMRuntime è pronto:

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

3. Installa il virtctl per kubectl:

   sudo -E bmctl install virtctl
   

   L'esempio di output 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'esempio di output 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.
   ...
   

Eseguire il deployment del carico di lavoro basato su VM

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

In questo tutorial, esegui la migrazione di un carico di lavoro basato su VM di Compute Engine in un cluster. Questa VM di Compute Engine è stata creata e l'applicazione di esempio per il point of sale (PoS) è stata configurata per essere eseguita come servizio systemd. È stata creata un'immagine disco di questa VM insieme al carico di lavoro dell'applicazione per il punto vendita Google Cloud. Questa immagine è stata poi esportata in un bucket Cloud Storage come immagine qcow2. Nei passaggi seguenti utilizzerai questa immagine qcow2 pre-preparata.

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. Puoi creare un'immagine disco delle VM esistenti se vuoi seguire i passaggi descritti in questo documento con la tua immagine personalizzata.

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

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

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

2. Esegui il deployment del carico di lavoro della VM utilizzando l'immagine qcow2 pre-preparata:

   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 virtctl plug-in, avresti potuto eseguire il deployment del carico di lavoro 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 all'esempio seguente 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 vm.cluster.gke.io/v1.VirtualMachine risorsa nel runtime VM su GDC. La forma abbreviata è gvm.

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

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

   Controlla lo stato di VirtualMachineDisk. VirtualMachineDisk crea internamente una risorsa DataVolume. L'immagine VM viene importata in DataVolume, che viene montato nella VM:

   kubectl get datavolume
   

   L'esempio di output 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'esempio di output seguente mostra il provisioning di VirtualMachine:

   NAME      STATUS         AGE     IP
   pos-vm    Provisioning   1m
   

5. Attendi che l'immagine VM venga importata completamente in DataVolume. Continua a monitorare l'avanzamento durante l'importazione dell'immagine:

   kubectl get datavolume -w
   

   L'esempio di output 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 alla creazione di DataVolume, l'esempio di output seguente mostra la 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 richiede fino a 15 minuti per l'importazione.

6. Verifica che VirtualMachine sia stata creata 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
   

Connettersi alla VM e controllare lo stato dell'applicazione

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

1. Connettiti alla console 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 l'esempio di output seguente 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 il seguente account utente e la seguente password. Questo account è stato configurato all'interno della VM originale da cui è stata creata l'immagine per la VirtualMachine del runtime VM su GDC.

   • Nome utente di accesso: abmuser
   • Password: abmworks

2. Controlla lo stato dei servizi dell'applicazione per il punto vendita. 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 senza interruzioni tra i carichi di lavoro delle VM e altre applicazioni containerizzate. Non devi fare altro per rendere i Services Kubernetes raggiungibili dalle VM di cui è stato eseguito il deployment utilizzando il runtime VM su GDC.

   sudo systemctl status pos*
   

   L'esempio di output 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 + ].

Accedere al carico di lavoro basato su VM

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

1. Se il cluster non ha questa risorsa Ingress, creala applicando il seguente file 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'esempio di output 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 Service del server API. 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'esempio di output 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. L'esempio di screenshot seguente mostra il chiosco 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 carico di lavoro basato su VM in un cluster utilizzando il runtime VM su GDC.

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

Libera spazio

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

Elimina tutto

• Elimina la VirtualMachine del runtime VM su GDC insieme a tutte le risorse:

  kubectl virt delete vm pos-vm --all
  

  L'esempio di output 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 il VirtualMachineDisk creato. In questo modo puoi riutilizzare l'immagine VM e risparmiare tempo per l'importazione dell'immagine durante la creazione di una nuova VM.

  kubectl virt delete vm pos-vm
  

  L'esempio di output 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 di Compute Engine che esegue Ubuntu 20.04 LTS. L'immagine di questa VM è accessibile pubblicamente tramite il pos-vm-images bucket Cloud Storage. Per ulteriori informazioni 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.