Questo documento fornisce una guida passo passo per il deployment di un carico di lavoro basato su macchine virtuali (VM) in Google Distributed Cloud utilizzando il runtime VM su GDC. Il carico di lavoro utilizzato di questa guida è riportato un esempio applicazione point of sale. Questa applicazione rappresenta un modello terminale point of sale eseguito su hardware on-premise in un negozio al dettaglio.
In questo documento eseguirai la migrazione di questa applicazione da una VM a un ambiente Google Distributed Cloud
e accedere al frontend web dell'applicazione. Per eseguire la migrazione di una VM esistente:
nel cluster, devi prima creare un'immagine disco di quella VM. Quindi, l'immagine
devono essere ospitati in un repository
a cui il cluster può accedere. Infine, l'URL di
che l'immagine possa essere utilizzata per creare la VM. Il runtime VM su GDC si aspetta che le immagini siano in formato qcow2
. Se fornisci un tipo di immagine diverso, questo viene
convertito automaticamente nel formato qcow2
. Per evitare conversioni ripetitive
e per consentire il riutilizzo, puoi convertire un'immagine disco virtuale
e ospitare l'immagine qcow2
.
Questo documento utilizza un'immagine preparata in precedenza di un'istanza VM di Compute Engine in cui il carico di lavoro viene eseguito come systemd completamente gestito di Google Cloud. Puoi seguire gli stessi passaggi per eseguire il deployment della tua applicazione.
Obiettivi
Prima di iniziare
Per compilare questo documento sono necessarie le seguenti risorse:
- Accedi a un cluster Google Distributed Cloud versione 1.12.0 o successiva creato seguendo la guida Eseguire Google Distributed Cloud su VM Compute Engine con bilanciatore del carico manuale. Questo documento configura le risorse di networking in modo che tu possa accedere 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 cloud distribuito di Google.
- Una workstation che soddisfi i seguenti requisiti:
Abilita il runtime VM su GDC e installa il plug-in virtctl
La definizione di risorsa personalizzata (CRD) del runtime VM su GDC fa parte di
tutti i cluster Google Distributed Cloud dalla versione 1.10. Al momento dell'installazione è già stata creata un'istanza della risorsa personalizzata VMRuntime
. Tuttavia, è disabilitata per impostazione predefinita.
Abilita il runtime VM su GDC:
sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
- KUBECONFIG_PATH: percorso del file di configurazione Kubernetes del cluster utente di Google Distributed Cloud
Verifica che l'
VMRuntime
sia abilitata:kubectl wait --for=jsonpath='{.status.ready}'=true vmruntime vmruntime
Possono essere necessari alcuni minuti prima che il
VMRuntime
sia pronto. In caso contrario pronto, controllalo alcune volte con brevi ritardi. L'output dell'esempio seguente mostra cheVMRuntime
è pronto:vmruntime.vm.cluster.gke.io/vmruntime condition met
Installa il virtctl plug-in per
kubectl
:sudo -E bmctl install virtctl
L'esempio di output seguente mostra che la procedura di installazione del plug-in
virtctl
è 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
Verifica l'installazione del plug-in
virtctl
:kubectl virt
L'output di esempio seguente mostra che il plug-in
virtctl
è disponibile per l'uso 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. ...
Esegui il deployment del carico di lavoro basato su VM
Quando esegui il deployment di una VM in Google Distributed Cloud, il runtime VM su GDC si aspetta un'immagine VM. Questa immagine funge da per la VM di cui è stato eseguito il deployment.
In questo tutorial esegui la migrazione di un carico di lavoro basato su VM Compute Engine in un
cluster Google Distributed Cloud. Questa VM di Compute Engine è stata creata
l'applicazione point of sale di esempio (PoS) è stata configurata per essere eseguita come sistema
completamente gestito di Google Cloud. In Google Cloud è stata creata un'immagine disco di questa VM insieme al carico di lavoro dell'applicazione POS. Questa immagine è stata poi esportata in un bucket Cloud Storage come
un'immagine qcow2
. Utilizzi
questa immagine qcow2
preparata nei seguenti passaggi.
Il codice sorgente in questo documento è disponibile nel repository GitHub anthos-samples. Utilizza le risorse di questo repository per completare i passaggi che seguiranno.
Esegui il deployment di MySQL
StatefulSet
. L'applicazione point of sale prevede connettersi a un database MySQL per archiviare l'inventario e i dati di pagamento. Il repository point of sale ha un manifest di esempio che esegue il deployment di un MySQLStatefulSet
, configura unConfigMap
associato e un KubernetesService
.ConfigMap
definisce le credenziali per l'istanza MySQL, ovvero le stesse credenziali passate all'applicazione di punto di vendita.kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/point-of-sale/main/k8-manifests/common/mysql-db.yaml
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 in base alla VM (
google-virtctl/pos-vm.yaml
). Puoi ispezionare il file per visualizzare la definizione diVirtualMachine
eVirtualMachineDisk
. Invece di usando il plug-invirtctl
, potresti aver eseguito il deployment del carico di lavoro della VM Definizioni di Kubernetes Resource Model (KRM), come mostrato nel file YAML creato.Una volta eseguito correttamente, il comando produce un output come il 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"
Controlla lo stato della creazione della VM.
La risorsa
VirtualMachine
è identificata dal Risorsavm.cluster.gke.io/v1.VirtualMachine
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 sono presenti i contenuti in cui viene importata l'immagine VM.
- Una VirtualMachine è l'istanza VM stessa. DataVolume viene mounted nella VirtualMachine prima dell'avvio della VM.
Controlla lo stato di VirtualMachineDisk. VirtualMachineDisk internamente crea una risorsa
DataVolume
. L'immagine VM viene importata nel DataVolume montato nella VM:kubectl get datavolume
L'esempio di output seguente mostra l'inizio dell'importazione delle immagini:
NAME PHASE PROGRESS RESTARTS AGE pos-vm-boot-dv ImportScheduled N/A 8s
Controlla lo stato di
VirtualMachine
.VirtualMachine
è in StatoProvisioning
fino all'importazione completa diDataVolume
:kubectl get gvm
L'esempio di output seguente mostra il provisioning del
VirtualMachine
:NAME STATUS AGE IP pos-vm Provisioning 1m
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'immagine del disco in fase di importazione:
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 esempio di output mostra ilPHASE
diSucceeded
:kubectl get datavolume
NAME PHASE PROGRESS RESTARTS AGE pos-vm-boot-dv Succeeded 100.0% 14m18s
Verifica che
VirtualMachine
sia stato creato correttamente:kubectl get gvm
Se la creazione è andata a buon fine,
STATUS
mostraRUNNING
, come 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 i punti di vendita. L'applicazione è configurata per avviarsi automaticamente all'avvio come servizio systemd. Puoi vedere i dati strutturati di configurazione YAML pos-systemd-services .
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 i seguenti account utente e password. Questo account è stato configurato all'interno della VM originale da cui è stata creata l'immagine per il runtime della VM su GDC VM.
- Nome utente di accesso:
abmuser
- Password:
abmworks
- Nome utente di accesso:
Controlla lo stato dei servizi applicativi point of sale. Il punto di applicazione di 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 si connette automaticamente alla stessa rete di
Pods
eServices
, consentendo una comunicazione senza interruzioni tra i carichi di lavoro VM e altre applicazioni containerizzate. Non devi fare altro per rendere l'elementoServices
di Kubernetes raggiungibile dalle VM di cui è stato eseguito il deployment Runtime VM su GDC.sudo systemctl status pos*
L'output di esempio seguente mostra lo stato dei tre servizi e della directory principale servizio di sistema,
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
Esci dalla VM. Per uscire dalla connessione alla console, utilizza la sequenza di escape
^]
premendoCtrl + ]
.
Accedi al carico di lavoro basato su VM
Se il cluster è stato configurato seguendo Esecuzione di Google Distributed Cloud on
VM di Compute Engine con caricamento manuale
Bilanciatore
guida, ha già creato una risorsa Ingress
denominata pos-ingress
. Questo
La risorsa instrada il traffico dall'indirizzo IP esterno del carico in entrata
Bilanciatore del servizio server API dell'applicazione di esempio point of sale.
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
Crea un
Service
Kubernetes che instrada il traffico alla VM. La risorsaIngress
indirizza il traffico a questoService
: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
Recupera l'indirizzo IP esterno del bilanciatore del carico
Ingress
. Il bilanciatore del caricoIngress
indirizza il traffico in base alle regole della risorsaIngress
. Tu esiste già una regolapos-ingress
per inoltrare le richieste al server APIService
.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 carico
Ingress
bilanciatore del carico:172.29.249.159 # you might have a different IP address
Accedi all'applicazione utilizzando l'indirizzo IP del bilanciatore del carico Ingress in un browser. Gli screenshot di esempio riportati di seguito mostrano il semplice chiosco point of sale con due articoli. Puoi fare clic sugli articoli più di una volta se vuoi ordinarli multipli ed effettua 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 Google Distributed Cloud utilizzando il runtime VM su GDC.
Esegui la pulizia
Puoi eliminare tutte le risorse create in questo tutorial oppure eliminare solo VM e mantieni risorse riutilizzabili. Elimina una VM in Google Distributed Cloud illustra le opzioni disponibili in dettaglio.
Elimina tutto
Elimina il runtime della VM su GDC
VirtualMachine
insieme a tutti 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 solo della VM conserva il
VirtualMachineDisk
che viene creato. Ciò consente il riutilizzo di questa immagine VM e consente di risparmiare il tempo impiegato per l'importazione 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 Compute Engine che gira su Ubuntu 20.04 LTS. L'immagine di questa VM è accessibile pubblicamente tramite pos-vm-images nel bucket Cloud Storage. Per saperne di più su come è stata configurata la VM e sulle relative l'immagine è stata creata, consulta le istruzioni nel repository point of sale.
- Quando crei una VM in un cluster Google Distributed Cloud utilizzando l'
kubectl virt create vm pos-vm
, un file YAML chiamato come VM (google-virtctl/pos-vm.yaml
) è stato creato. Puoi controllare il file per vedere la definizione dell'elementoVirtualMachine
eVirtualMachineDisk
. Anziché utilizzare il plug-invirtctl
, puoi eseguire il deployment di una VM utilizzando le definizioni KRM come mostrato nel file YAML creato.