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

Abilita il runtime delle VM su GDC e installa il plug-in virtctl

La definizione di risorsa personalizzata del runtime delle VM su GDC fa parte di tutti i cluster bare metal a partire dalla versione 1.10. Un'istanza della risorsa personalizzata VMRuntime viene creata automaticamente al momento dell'installazione. Tuttavia, è disattivato per impostazione predefinita.

1. Attiva il runtime delle 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 più volte con brevi ritardi. L'output dell'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
   

   Il seguente output di esempio mostra che la procedura di installazione del plug-in virtctl è stata completata:

   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 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, VM Runtime 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 workload basato su VM Compute Engine in un cluster. Questa VM di Compute Engine è stata creata e l'applicazione di esempio per il punto vendita (POS) è stata configurata per essere eseguita come servizio systemd. È stata creata un'immagine del disco di questa VM insieme al carico di lavoro dell'applicazione PoS in Google Cloud. Questa immagine è stata poi esportata in un bucket Cloud Storage come immagine qcow2. Utilizzerai questa immagine qcow2 pre-preparata nei passaggi successivi.

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

1. Esegui il deployment di un StatefulSet MySQL. L'applicazione point of sale prevede di connettersi a un database MySQL per archiviare l'inventario e i dati di pagamento. Il repository Point of Sale contiene un file 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 trasmesse all'applicazione del 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 preparata in precedenza:

   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 denominato come la VM (google-virtctl/pos-vm.yaml). Puoi esaminare il file per visualizzare la definizione di VirtualMachine e VirtualMachineDisk. Invece di utilizzare il plug-in virtctl, avresti potuto eseguire il deployment del carico di lavoro della VM utilizzando definizioni del modello di risorse Kubernetes (KRM), come mostrato nel file YAML creato.

   Quando il comando viene eseguito correttamente, produce un output come il 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 delle 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.
   • Una VirtualMachine è l'istanza VM stessa. 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 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 si trova 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 che l'immagine VM venga importata completamente in DataVolume. Continua a monitorare l'avanzamento dell'importazione dell'immagine:

   kubectl get datavolume -w
   

   Il seguente output di esempio mostra l'importazione dell'immagine del 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 dopo la 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
   

6. Verifica che VirtualMachine sia stato creato correttamente:

   kubectl get gvm
   

   Se la creazione è riuscita, 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 avviarsi automaticamente all'avvio come servizio systemd. Puoi visualizzare i file di configurazione dei servizi systemd nella directory pos-systemd-services.

1. Connettiti alla console VM. Esegui questo comando 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 il runtime delle VM su GDC VirtualMachine.

   • 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 sono tutti connessi 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 nulla di speciale per rendere raggiungibile il Services Kubernetes 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 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 in entrata al servizio del server API dell'applicazione di esempio per il punto 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 servizio Kubernetes Service che instrada il traffico alla VM. La risorsa Ingress indirizza il traffico a questo Service:

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

   Il seguente output di esempio 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. Recupera l'indirizzo IP esterno del bilanciatore del carico Ingress. Il bilanciatore del carico Ingress instrada il traffico in base alle regole delle risorse 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 chiosco del punto vendita con due articoli. Puoi fare clic sugli articoli, più di una volta se vuoi ordinarne più di uno, e inserire un ordine con il pulsante Paga. Questa esperienza mostra che hai eseguito correttamente il deployment di un carico di lavoro basato su VM in un cluster utilizzando VM Runtime su GDC.