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


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

In questo documento eseguirai la migrazione di questa applicazione da una VM a un cluster GKE on Bare Metal e accedi al frontend web dell'applicazione. Per eseguire la migrazione di una VM esistente nel cluster, devi prima creare un'immagine disco di quella VM. L'immagine deve quindi essere ospitata in un repository accessibile al cluster. Infine, l'URL dell'immagine può essere usato per creare la VM. Il runtime VM su GDC prevede che le immagini siano in formato qcow2. Se fornisci un tipo di immagine diverso, verrà convertito automaticamente nel formato qcow2. Per evitare conversioni ripetitive e per consentire il riutilizzo, puoi convertire un'immagine di 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 questi stessi passaggi per eseguire il deployment della tua applicazione.

Obiettivi

Prima di iniziare

Per completare questo documento, sono necessarie le seguenti risorse:

  • Accesso a un cluster Google Distributed Cloud versione 1.12.0 o successiva creato seguendo la guida Esecuzione di Google Distributed Cloud su VM di Compute Engine con bilanciatore del carico manuale. Questo documento configura le risorse di networking 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 Google Distributed Cloud.
  • Una workstation che soddisfi i seguenti requisiti:
    • Ha accesso al cluster tramite l'interfaccia a riga di comando bmctl.
    • Ha accesso al cluster tramite l'interfaccia a riga di comando kubectl.

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

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

  1. Abilita il runtime VM su GDC:

    sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
    
    • KUBECONFIG_PATH: percorso del file di configurazione Kubernetes del cluster utente Google Distributed Cloud
  2. Verifica che l'VMRuntime sia abilitata:

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

    Potrebbero essere necessari alcuni minuti prima che il VMRuntime sia pronto. In caso contrario, verifica qualche volta 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 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 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 Google Distributed Cloud, 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 eseguirai la migrazione di un carico di lavoro basato su VM di Compute Engine in un cluster GKE on Bare Metal. Questa VM di Compute Engine è stata creata e l'applicazione point of sale (PoS) di esempio è stata configurata per essere eseguita come servizio di sistema. In Google Cloud è stata creata un'immagine disco di questa VM insieme al carico di lavoro dell'applicazione PoS. Questa immagine è stata quindi esportata in un bucket Cloud Storage come immagine qcow2. Potrai usare questa immagine qcow2 preparata nei seguenti passaggi.

Il codice sorgente in questo documento è disponibile nel repository GitHub anthos-samples. Puoi utilizzare le risorse di questo repository per completare i passaggi che seguono.

  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 ha un manifest di esempio che esegue il deployment di un StatefulSet MySQL, configura un ConfigMap associato e un Service di Kubernetes. L'ConfigMap definisce le credenziali per l'istanza MySQL, ovvero le stesse credenziali trasmesse all'applicazione point of sale.

    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 VM utilizzando l'immagine qcow2 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 denominato in base alla VM (google-virtctl/pos-vm.yaml). Puoi controllare il file per visualizzare 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 di Kubernetes Resource Model (KRM), come mostrato nel file YAML creato.

    Una volta eseguita correttamente, il comando produce un output come l'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 risorsa vm.cluster.gke.io/v1.VirtualMachine in runtime VM su GDC. Il formato breve è 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 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 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 rimarrà nello stato Provisioning fino a quando 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 guardare l'avanzamento durante l'importazione dell'immagine:

    kubectl get datavolume -w
    

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

    Dopo il completamento dell'importazione e la creazione dell'elemento DataVolume, l'output di esempio seguente mostra il valore 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 point of sale. L'applicazione è configurata per avviarsi automaticamente all'avvio come servizio di sistema. Puoi vedere i file di configurazione dei servizi di sistema nella directory pos-systemd-services.

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

    • Nome utente di accesso: abmuser
    • Password: abmworks
  2. Controlla lo stato dei servizi applicativi point of sale. 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 tutti tra loro tramite localhost. Tuttavia, l'applicazione si connette al database MySQL utilizzando un mysql-db Kubernetes Service creato nel passaggio precedente. Questo comportamento significa che la VM viene connessa automaticamente alla stessa rete di Pods e Services, consentendo una comunicazione senza interruzioni tra i carichi di lavoro VM e altre applicazioni containerizzate. Non devi fare altro per rendere l'elemento Services di 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 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
    
  3. 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 Google Distributed Cloud on Compute Engine VM con bilanciamento 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 server API dell'applicazione di esempio point of sale.

  1. 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
    
    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 di 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 Service:

    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 delle risorse Ingress. Esiste 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 di carico Ingress in un browser. Gli screenshot di esempio che seguono mostrano il semplice kiosk point of sale con due elementi. 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 basato su VM in un cluster Google Distributed Cloud utilizzando il runtime VM su GDC.

UI dell'applicazione point of sale
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 conservare le risorse riutilizzabili. Elimina una VM in Google Distributed Cloud illustra in dettaglio le opzioni disponibili.

Elimina tutto

  • Elimina il runtime VM su 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 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 speso per 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 di 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 come è stata creata la relativa immagine, consulta le istruzioni nel repository point of sale.
  • Quando crei una VM in un cluster Google Distributed Cloud utilizzando il comando kubectl virt create vm pos-vm, viene creato un file YAML con nome della VM (google-virtctl/pos-vm.yaml). Puoi controllare il file per vedere 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.