Tutoriel : Déployer une VM existante dans un cluster à l'aide de l'environnement d'exécution de VM sur GDC

L'environnement d'exécution de VM sur GDC vous permet de déployer des charges de travail de machine virtuelle (VM) directement dans une installation du logiciel Distributed Cloud pour Bare Metal uniquement. Dans ce tutoriel, vous allez migrer un exemple d'application de point de vente, qui représente un terminal de point de vente, d'une VM Compute Engine vers un cluster Bare Metal, et accéder à son interface Web.

Le déploiement utilise une image disque préconfigurée dans laquelle la charge de travail s'exécute en tant que service systemd. Vous pouvez également suivre ces étapes pour préparer et déployer vos propres applications basées sur des VM.

Objectifs

Avant de commencer

Pour suivre les instructions de ce document, vous devez disposer des ressources suivantes :

  • Accès à un cluster Bare Metal version 1.12.0 ou ultérieure créé en suivant le guide Installer avec un équilibreur de charge manuel. Ce document configure les ressources réseau afin que vous puissiez accéder à la charge de travail exécutée dans la VM via un navigateur. Si vous n'avez pas besoin de ce comportement, vous pouvez suivre ce document en utilisant n'importe quelle installation de Distributed Cloud (logiciel uniquement) pour Bare Metal.
  • Un poste de travail qui répond aux exigences suivantes :
    • Il doit avoir accès à votre cluster à l'aide de la CLI bmctl.
    • Il doit avoir accès à votre cluster à l'aide de la CLI kubectl.

Activer l'environnement d'exécution de VM sur GDC et installer le plug-in virtctl

La définition de ressource personnalisée de l'environnement d'exécution de VM sur GDC fait partie de tous les clusters Bare Metal depuis la version 1.10. Une instance de la ressource personnalisée VMRuntime est déjà créée lors de l'installation. Toutefois, il est désactivé par défaut.

  1. Activez l'environnement d'exécution de VM sur GDC :

    sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
    • KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig du cluster d'utilisateur.

  2. Vérifiez que VMRuntime est activé :

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

    La préparation de VMRuntime peut prendre quelques minutes. Si elle n'est pas prête, vérifiez plusieurs fois à de courts intervalles. L'exemple de résultat suivant montre que VMRuntime est prêt :

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

  3. Installez le plug-in virtctl pour kubectl :

    sudo -E bmctl install virtctl

    L'exemple de résultat suivant montre que le processus d'installation du plug-in virtctl est terminé :

    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. Vérifiez l'installation du plug-in virtctl :

    kubectl virt

    L'exemple de sortie suivant montre que le plug-in virtctl est disponible pour une utilisation avec 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.
...

Déployer la charge de travail basée sur une VM

Lorsque vous déployez une VM dans une installation du logiciel Distributed Cloud uniquement pour Bare Metal, l'environnement d'exécution de VM sur GDC attend une image de VM. Cette image sert de disque de démarrage pour la VM déployée.

Pour migrer une VM existante vers le cluster, vous devez d'abord créer une image disque de cette VM. Ensuite, l'image doit être hébergée dans un dépôt auquel le cluster peut accéder. Enfin, l'URL de cette image peut être utilisée pour créer la VM. L'environnement d'exécution de VM sur GDC attend des images au format qcow2. Si vous fournissez un autre type d'image, l'image est automatiquement convertie au format qcow2. Pour éviter les conversions répétitives et permettre la réutilisation, vous pouvez convertir une image de disque virtuel et héberger l'image qcow2.

Dans les étapes suivantes, vous allez utiliser une image qcow2 préconfigurée dans laquelle l'exemple de charge de travail a été créé en tant qu'image disque de VM dans Google Cloud et exporté vers un bucket Cloud Storage.

Le code source de ce document est disponible dans le dépôt GitHub anthos-samples. Vous utiliserez les ressources de ce dépôt pour effectuer les étapes suivantes.

  1. Déployez un StatefulSet MySQL. L'application de point de vente doit se connecter à une base de données MySQL pour stocker les informations d'inventaire et de paiement. Le dépôt du point de vente contient un exemple de fichier manifeste qui déploie un StatefulSet MySQL, configure un ConfigMap associé et un Service Kubernetes. ConfigMap définit les identifiants de l'instance MySQL, qui sont les mêmes identifiants que ceux transmis à l'application de point de vente.

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

  2. Déployez la charge de travail de VM à l'aide de l'image qcow2 préconfigurée :

    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

    Cette commande crée un fichier YAML nommé d'après la VM (google-virtctl/pos-vm.yaml). Vous pouvez inspecter le fichier pour voir la définition de VirtualMachine et VirtualMachineDisk. Au lieu d'utiliser le plug-in virtctl, vous auriez pu déployer la charge de travail de VM à l'aide des définitions du modèle de ressource Kubernetes (KRM), comme indiqué dans le fichier YAML créé.

    Lorsque la commande s'exécute correctement, elle génère une sortie semblable à l'exemple suivant, qui explique les différentes ressources créées :

    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. Vérifiez l'état de création de la VM.

    La ressource VirtualMachine est identifiée par la ressource vm.cluster.gke.io/v1.VirtualMachine dans l'environnement d'exécution de VM sur GDC. Le nom abrégé est gvm.

    Lorsque vous créez une VM, les deux ressources suivantes sont créées :

    • Un VirtualMachineDisk est le disque persistant dans lequel le contenu de l'image de VM est importé.
    • Une VirtualMachine est l'instance de VM elle-même. Le DataVolume est installé dans la VirtualMachine avant le démarrage de la VM.

    Vérifiez l'état de VirtualMachineDisk. VirtualMachineDisk crée en interne une ressource DataVolume. L'image de VM est importée dans le DataVolume installé dans la VM :

    kubectl get datavolume

    L'exemple de résultat suivant montre le début de l'importation de l'image :

    NAME              PHASE             PROGRESS   RESTARTS   AGE
pos-vm-boot-dv    ImportScheduled   N/A                   8s

  4. Vérifiez l'état du VirtualMachine. Le VirtualMachine est à l'état Provisioning jusqu'à ce que le DataVolume soit complètement importé :

    kubectl get gvm

    L'exemple de résultat suivant montre le provisionnement de VirtualMachine :

    NAME      STATUS         AGE     IP
pos-vm    Provisioning   1m

  5. Attendez que l'image de VM soit entièrement importée dans DataVolume. Continuez à surveiller la progression pendant l'importation de l'image :

    kubectl get datavolume -w

    L'exemple de résultat suivant montre l'image disque en cours d'importation :

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

    Une fois l'importation terminée et l'élément DataVolume créé, l'exemple de résultat suivant affiche l'élément PHASE de Succeeded :

    kubectl get datavolume

    NAME              PHASE             PROGRESS   RESTARTS   AGE
pos-vm-boot-dv    Succeeded         100.0%                14m18s

  6. Vérifiez que VirtualMachine a bien été créé :

    kubectl get gvm

    Si la création a réussi, STATUS affiche RUNNING, comme illustré dans l'exemple suivant, ainsi que l'adresse IP de la VM :

    NAME      STATUS    AGE     IP
pos-vm    Running   40m     192.168.3.250

Se connecter à la VM et vérifier l'état de l'application

L'image utilisée pour la VM inclut l'exemple d'application de point de vente. L'application est configurée pour démarrer automatiquement au démarrage en tant que service systemd. Vous pouvez consulter les fichiers de configuration des services systemd dans le répertoire pos-systemd-services.

  1. Connectez-vous à la console de VM. Exécutez la commande suivante et appuyez sur Entrée⏎ après l'affichage du message Successfully connected to pos-vm… :

    kubectl virt console pos-vm

    Cette commande génère l'exemple de résultat suivant, qui vous invite à saisir les identifiants :

    Successfully connected to pos-vm console. The escape sequence is ^]

pos-from-public-image login:

    Utilisez le compte utilisateur et le mot de passe suivants. Ce compte a été configuré dans la VM d'origine à partir de laquelle l'image de la ressource VirtualMachine de l'environnement d'exécution de VM sur GDC a été créée.

    • Identifiant de connexion : abmuser
    • Mot de passe : abmworks

  2. Vérifiez l'état des services de l'application de point de vente. L'application de point de vente comprend trois services : API, Inventory et Payments. Ces services s'exécutent tous en tant que services système.

    Les trois services se connectent les uns aux autres via localhost. Toutefois, l'application se connecte à la base de données MySQL à l'aide d'un service Kubernetes mysql-db créé à l'étape précédente. Ce comportement signifie que la VM est automatiquement connectée au même réseau que Pods et Services, ce qui permet une communication fluide entre les charges de travail de la VM et les autres applications conteneurisées. Vous n'avez rien d'autre à faire pour que le Services Kubernetes soit accessible depuis les VM déployées à l'aide de l'environnement d'exécution de VM sur GDC.

    sudo systemctl status pos*

    L'exemple de résultat suivant montre l'état des trois services et du service système racine, 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. Quittez la VM. Pour quitter la connexion à la console, utilisez la séquence d'échappement ^] en appuyant sur Ctrl + ].

Accéder à la charge de travail basée sur une VM

Si votre cluster a été configuré en suivant le guide Installer avec un équilibreur de charge manuel, il dispose d'une ressource Ingress appelée pos-ingress déjà créée. Cette ressource achemine le trafic de l'adresse IP externe de l'équilibreur de charge d'entrée vers le service de serveur d'API de l'exemple d'application de point de vente.

  1. Si votre cluster ne dispose pas de cette ressource Ingress, créez-la en appliquant le fichier manifeste suivant :

    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. Créez un Service Kubernetes qui achemine le trafic vers la VM. La ressource Ingress achemine le trafic vers ce Service :

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

    L'exemple de résultat suivant confirme la création d'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. Obtenez l'adresse IP externe de l'équilibreur de charge Ingress. L'équilibreur de charge Ingress achemine le trafic en fonction des règles de la ressource Ingress. Vous disposez déjà d'une règle pos-ingress pour transférer les requêtes au serveur d'API Service. Ce Service transfère les requêtes à la VM :

    INGRESS_IP=$(kubectl get ingress/pos-ingress -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo $INGRESS_IP

    L'exemple de résultat suivant montre l'adresse IP de l'équilibreur de charge Ingress :

    172.29.249.159 # you might have a different IP address

  4. Accédez à l'application en utilisant l'adresse IP de l'équilibreur de charge d'entrée dans un navigateur. Les captures d'écran suivantes montrent la borne de point de vente avec deux articles. Vous pouvez cliquer sur les articles (plusieurs fois si vous souhaitez en commander plusieurs) et passer une commande à l'aide du bouton Payer. Cette expérience montre que vous avez déployé avec succès une charge de travail basée sur une VM dans un cluster à l'aide de l'environnement d'exécution de VM sur GDC.

Interface utilisateur de l'application de point de vente
UI de l'application de point de vente (cliquez sur l'image pour l'agrandir)

Effectuer un nettoyage

Vous pouvez supprimer toutes les ressources créées dans ce tutoriel ou ne supprimer que la VM et conserver les ressources réutilisables. Supprimer une VM explique en détail les options disponibles.

Tout supprimer

  • Supprimez l'environnement d'exécution de VM sur GDC VirtualMachine ainsi que toutes les ressources :

    kubectl virt delete vm pos-vm --all

    L'exemple de résultat suivant confirme la suppression :

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

Supprimer uniquement la VM

  • Si vous ne supprimez que la VM, le VirtualMachineDisk créé est conservé. Cela permet de réutiliser cette image de VM et de gagner du temps lors de l'importation de l'image lors de la création d'une VM.

    kubectl virt delete vm pos-vm

    L'exemple de résultat suivant confirme la suppression :

    vm "pos-vm" used the following resources:
    gvm: pos-vm
    VirtualMachineDisk: pos-vm-boot-dv
Start deleting the resources:
    Deleted gvm "pos-vm".

Étape suivante

  • La VM d'origine utilisée dans ce guide est une instance Compute Engine qui exécute Ubuntu 20.04 LTS. L'image de cette VM est accessible publiquement via le bucket Cloud Storage pos-vm-images. Pour en savoir plus sur la configuration de la VM et la création de son image, consultez les instructions du dépôt point-of-sale.
  • Lorsque vous créez une VM dans un cluster à l'aide de la commande kubectl virt create vm pos-vm, un fichier YAML portant le nom de la VM (google-virtctl/pos-vm.yaml) est créé. Vous pouvez inspecter le fichier pour voir la définition de VirtualMachine et de VirtualMachineDisk. Au lieu d'utiliser le plug-in virtctl, vous pouvez déployer une VM à l'aide de définitions KRM, comme indiqué dans le fichier YAML créé.