Tutorial: esegui il deployment di una VM esistente in un cluster GKE Enterprise utilizzando VM Runtime su Google Distributed Cloud

Questo documento fornisce una guida passo passo per il deployment di un carico di lavoro basato su macchine virtuali (VM) in GKE su Bare Metal utilizzando VM Runtime su Google Distributed Cloud. Il carico di lavoro utilizzato in questa guida è l'applicazione point of sale di esempio. Questa applicazione rappresenta un tipico terminale POS in esecuzione sull'hardware on-premise di un negozio al dettaglio.

In questo documento eseguirai la migrazione di questa applicazione da una VM a un cluster GKE su Bare Metal e potrai accedere al frontend web dell'applicazione. Per eseguire la migrazione di una VM esistente nel cluster, devi prima creare un'immagine disco di tale VM. L'immagine deve quindi essere ospitata in un repository a cui può accedere il cluster. Infine, l'URL dell'immagine può essere usato per creare la VM. Il runtime VM su Google Distributed Cloud prevede che le immagini siano in formato qcow2. Se fornisci un tipo di immagine diverso, questa viene automaticamente convertita nel formato qcow2. Per evitare conversioni ripetitive e consentirne 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 servizio systemd. Puoi seguire gli stessi passaggi per eseguire il deployment della tua applicazione.

Obiettivi

Abilita il runtime VM su Google Distributed Cloud e installa il plug-in virtctl
Esegui il deployment del carico di lavoro basato su VM
Accedi alla VM e controlla lo stato dell'applicazione
Accedi al carico di lavoro basato su VM

Prima di iniziare

Per completare questo documento, hai bisogno delle seguenti risorse:

Accesso a un cluster GKE su Bare Metal versione 1.12.0 o successive creato seguendo la guida Esecuzione di GKE su Bare Metal su VM di Compute Engine con bilanciatore del carico manuale. Questo documento imposta le risorse di networking in modo da poter accedere al carico di lavoro in esecuzione all'interno della VM tramite un browser. Se non ti interessa questo comportamento, puoi seguire questo documento utilizzando qualsiasi GKE 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 tuo cluster utilizzando l'interfaccia a riga di comando kubectl.

Abilita VM Runtime su Google Distributed Cloud e installa il plug-in `virtctl`

La definizione di risorse personalizzate (CRD) VM Runtime on Google Distributed Cloud fa parte di tutti i cluster GKE su Bare Metal dalla versione 1.10. Un'istanza della risorsa personalizzata VMRuntime è già stata creata al momento dell'installazione. Tuttavia, è disabilitata per impostazione predefinita.

Abilita VM Runtime su Google Distributed Cloud:
```
sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
```
- KUBECONFIG_PATH: percorso del file di configurazione Kubernetes del cluster utente GKE Enterprise
Verifica che VMRuntime sia abilitato:
```
kubectl wait --for=jsonpath='{.status.ready}'=true vmruntime vmruntime
```
Possono essere necessari alcuni minuti prima che il VMRuntime sia pronto. Se non è pronta, verifica alcune volte con brevi ritardi. Il seguente output di esempio mostra che VMRuntime è pronto:
```
vmruntime.vm.cluster.gke.io/vmruntime condition met
```

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

Verifica l'installazione del plug-in virtctl:

kubectl virt

Il seguente output di esempio mostra che il plug-in virtctl può essere utilizzato 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 GKE su Bare Metal, il runtime VM su Google Distributed Cloud prevede un'immagine VM. Questa immagine funge da disco di avvio per la VM di cui è stato eseguito il deployment.

In questo tutorial eseguirai la migrazione di un carico di lavoro basato su VM di Compute Engine in un cluster GKE su Bare Metal. Questa VM di Compute Engine è stata creata e l'applicazione point of sale (PoS) di esempio è stata configurata per l'esecuzione 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 quindi esportata in un bucket Cloud Storage come immagine qcow2. Puoi utilizzare questa immagine qcow2 precedentemente preparata nei seguenti passaggi.

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

Esegui il deployment di un StatefulSet MySQL. L'applicazione point of sale si aspetta di connettersi a un database MySQL per archiviare i dati di inventario e pagamento. Il repository point of sale dispone di un manifest di esempio che esegue il deployment di un StatefulSet MySQL, configura un ConfigMap associato e un Service di Kubernetes. ConfigMap definisce le credenziali per l'istanza MySQL, che sono le stesse credenziali passate all'applicazione point of sale.
```
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 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 esaminare il file per vedere la definizione di VirtualMachine e VirtualMachineDisk. Anziché utilizzare il plug-in virtctl, potresti aver eseguito il deployment del carico di lavoro VM utilizzando le definizioni del modello di risorse Kubernetes, come mostrato nel file YAML creato.

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

La risorsa VirtualMachine è identificata dalla risorsa vm.cluster.gke.io/v1.VirtualMachine nel runtime VM su Google Distributed Cloud. Il formato breve è 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 nella VirtualMachine prima dell'avvio della VM.
Controlla lo stato di VirtualMachineDisk. VirtualMachineDisk crea internamente una risorsa DataVolume. L'immagine VM viene importata nel DataVolume, che viene montato nella VM:
```
kubectl get datavolume
```
Il seguente output di esempio mostra l'inizio dell'importazione dell'immagine:
```
NAME              PHASE             PROGRESS   RESTARTS   AGE
pos-vm-boot-dv    ImportScheduled   N/A                   8s
```
Controlla lo stato di VirtualMachine. VirtualMachine è nello stato Provisioning fino a quando il DataVolume non viene importato completamente:
```
kubectl get gvm
```
Il seguente output di esempio mostra il provisioning di VirtualMachine:
```
NAME      STATUS         AGE     IP
pos-vm    Provisioning   1m
```
Attendi che l'immagine VM sia stata importata completamente in DataVolume. Continua a controllare l'avanzamento durante l'importazione dell'immagine:
```
kubectl get datavolume -w
```
Il seguente output di esempio mostra l'immagine disco che viene importata:
```
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
...
```
Quando l'importazione è completata e viene creato il campo DataVolume, il seguente output di esempio mostra il valore 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 ha una dimensione di circa 5 GB e l'importazione richiede fino a 15 minuti.
Verifica che VirtualMachine sia stato creato correttamente:
```
kubectl get gvm
```
Se la creazione è riuscita, STATUS mostrerà 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 point of sale. 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.

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 richiede 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 password. Questo account è stato configurato nella VM originale da cui è stata creata l'immagine per il runtime VM su Google Distributed Cloud VirtualMachine.
- Nome utente di accesso: abmuser
- Password: abmworks

Controllare lo stato dei servizi per applicazioni POS. L'applicazione point of sale include tre servizi: API, inventario e pagamenti. Questi servizi vengono tutti 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 viene connessa automaticamente alla stessa rete di Pods e Services, consentendo una comunicazione fluida tra i carichi di lavoro delle VM e altre applicazioni containerizzate. Non devi fare nulla per rendere raggiungibile il Services di Kubernetes dalle VM di cui è stato eseguito il deployment tramite runtime VM Anthos.

sudo systemctl status pos*

Il seguente output di esempio mostra lo stato dei tre servizi e del servizio di sistema radice, 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 della console, utilizza la sequenza di escape ^] premendo Ctrl + ].

Accedi al carico di lavoro basato su VM

Se il cluster è stato configurato seguendo la guida Esecuzione di GKE su Bare Metal su VM di Compute Engine con bilanciatore del carico manuale, ha già una risorsa Ingress denominata pos-ingress creata. Questa risorsa instrada il traffico dall'indirizzo IP pubblico del bilanciatore del carico Ingress al servizio server API dell'applicazione di esempio point of sale.

Se il cluster non ha 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

anthos-bm-gcp-terraform/resources/manifests/pos-ingress.yaml

Visualizza su GitHub

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

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

Il seguente output di esempio conferma la creazione di un servizio:

service/api-server-svc created

anthos-vmruntime/pos-service.yaml

Visualizza su GitHub

apiVersion: v1
kind: Service
metadata:
  name: api-server-svc
spec:
  selector:
    kubevirt/vm: pos-vm
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8081

Ottieni l'indirizzo IP pubblico 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
```
Il seguente output di esempio mostra l'indirizzo IP del bilanciatore del carico Ingress:
```
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. I seguenti screenshot di esempio mostrano il chiosco point of sale semplice 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 mostra che hai eseguito correttamente il deployment di un carico di lavoro tradizionale basato su VM in un cluster Anthos utilizzando il runtime VM su Google Distributed Cloud.

UI dell'applicazione point of sale (fai clic sull'immagine per ingrandirla)

Esegui la pulizia

Puoi eliminare tutte le risorse create in questo tutorial o eliminare solo la VM e mantenere le risorse riutilizzabili. L'opzione Delete a VM in GKE on Bare Metal spiega in dettaglio le opzioni disponibili.

Elimina tutto

Elimina il runtime VM su Google Distributed Cloud VirtualMachine insieme a tutte le risorse:

kubectl virt delete vm pos-vm --all

Il seguente output di esempio 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 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 dedicato all'importazione dell'immagine durante la creazione di una nuova VM.
```
kubectl virt delete vm pos-vm
```
Il seguente output di esempio 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 ulteriori informazioni su come è stata configurata la VM e su come è stata creata l'immagine, consulta le istruzioni nel repository point of sale.
Quando crei una VM in un cluster Anthos utilizzando il comando kubectl virt create vm pos-vm, viene creato un file YAML in base alla 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 indicato nel file YAML creato.