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

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

La définition de la ressource personnalisée de l'environnement d'exécution des 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 ce n'est pas le cas, vérifiez plusieurs fois en espaçant les vérifications. L'exemple de résultat suivant indique 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 peut être utilisé 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 de Google Distributed Cloud (logiciel uniquement) sur bare metal, l'environnement d'exécution de VM sur GDC attend une image de VM. Cette image sert de disque de démarrage à la VM déployée.

Dans ce tutoriel, vous allez migrer une charge de travail basée sur une VM Compute Engine vers un cluster. Cette VM Compute Engine a été créée, et l'exemple d'application de point de vente (PoS) a été configuré pour s'exécuter en tant que service systemd. Une image disque de cette VM ainsi que la charge de travail de l'application PoS ont été créées dans Google Cloud. Cette image a ensuite été exportée dans un bucket Cloud Storage en tant qu'image qcow2. Vous utiliserez cette image qcow2 prédéfinie dans les étapes suivantes.

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 sur l'inventaire et le 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 identifiants 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 la VM à l'aide de l'image qcow2 prédéfinie:

   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 des VirtualMachine et VirtualMachineDisk. Au lieu d'utiliser le plug-in virtctl, vous auriez pu déployer la charge de travail de la VM à l'aide de définitions du modèle de ressources 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 la 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. Sa forme abrégée 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é.
   • Un 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 la VM est importée dans le DataVolume, qui est installé dans la VM:

   kubectl get datavolume
   

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

   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 VirtualMachine en cours de provisionnement:

   NAME      STATUS         AGE     IP
   pos-vm    Provisioning   1m
   

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

   kubectl get datavolume -w
   

   L'exemple de résultat suivant montre l'image de 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 le DataVolume créé, l'exemple de sortie suivant affiche le 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⏎ une fois que le message Successfully connected to pos-vm… s'affiche:

   kubectl virt console pos-vm
   

   Cette commande produit l'exemple de sortie 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 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, inventaire et paiements. Tous ces services s'exécutent 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 VM et d'autres applications conteneurisées. Vous n'avez rien d'autre à faire pour rendre le Services Kubernetes 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 affiche 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 vous avez configuré votre cluster en suivant le guide Installer avec un équilibreur de charge manuel, une ressource Ingress appelée pos-ingress a déjà été créée. Cette ressource achemine le trafic depuis l'adresse IP externe de l'équilibreur de charge Ingress vers le service de serveur d'API de l'application exemple 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 sortie 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 vers le 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 affiche 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 à l'aide de l'adresse IP de l'équilibreur de charge d'entrée dans un navigateur. Les captures d'écran suivantes montrent le point de vente avec deux articles. Vous pouvez cliquer sur les articles (plusieurs fois si vous souhaitez en commander plusieurs) et passer commande à l'aide du bouton Payer. Cette expérience montre que vous avez réussi à déployer une charge de travail basée sur des VM dans un cluster à l'aide de l'environnement d'exécution de VM sur GDC.