Créer et gérer une VM avec KubeVirt

Une fois KubeVirt installé, une machine virtuelle est une ressource Kubernetes comme une autre : on la décrit dans un manifeste VirtualMachine, on contrôle son démarrage avec runStrategy, et on la pilote avec virtctl. Ce guide crée une VM, l'initialise avec cloud-init et s'y connecte. Public : débutant à intermédiaire. Version : v1.8.

Ce que vous allez apprendre

Écrire un manifeste VirtualMachine minimal.
Contrôler le cycle de vie avec runStrategy et virtctl.
Injecter identifiants et configuration avec cloud-init.
Accéder à la VM en console et en SSH.

Prérequis

Un cluster avec KubeVirt installé et virtctl disponible (voir le guide d'installation).
En lab sans /dev/kvm, l'émulation activée (le boot est plus lent).

Le manifeste d'une VM

Une VM se compose d'un domaine (le matériel virtuel : disques, mémoire, interfaces) et de volumes (les sources de disques). Voici une VM cirros avec un disque système et un disque cloud-init.

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: demo
spec:
  runStrategy: Manual            # on pilote start/stop explicitement
  template:
    metadata:
      labels:
        kubevirt.io/vm: demo
    spec:
      domain:
        devices:
          disks:
          - name: os
            disk: { bus: virtio }
          - name: cloudinit
            disk: { bus: virtio }
        resources:
          requests: { memory: 256Mi }
      volumes:
      - name: os
        containerDisk:
          image: quay.io/kubevirt/cirros-container-disk-demo
      - name: cloudinit
        cloudInitNoCloud:
          userData: |
            #cloud-config
            password: kubevirt
            chpasswd: { expire: False }

Deux objets se ressemblent mais ne jouent pas le même rôle : la VirtualMachine est la définition stable (elle survit aux redémarrages), et la VirtualMachineInstance (VMI) est l'instance en cours d'exécution, créée quand la VM démarre.

Contrôler le démarrage avec runStrategy

Le champ runStrategy décide quand la VM doit tourner. Il remplace l'ancien spec.running booléen.

runStrategy	Comportement
`Always`	La VM tourne en permanence ; redémarrée si elle s'arrête
`RerunOnFailure`	Relancée seulement après un échec, pas après un arrêt propre
`Manual`	Démarrage et arrêt pilotés à la main (via virtctl)
`Halted`	Toujours arrêtée
`Once`	Démarrée une fois, non relancée ensuite

Avec Manual, la VM créée reste arrêtée tant qu'on ne la démarre pas :

kubectl apply -f demo-vm.yaml
kubectl get vm demo
# NAME   AGE   STATUS    READY
# demo   0s    Stopped   False

Piloter le cycle de vie avec virtctl

virtctl déclenche les transitions. Au démarrage, une VMI apparaît et reçoit une IP dans le réseau de pods.

virtctl start demo
# VM demo was scheduled to start
kubectl get vmi demo
# NAME   PHASE     IP            NODENAME                    READY
# demo   Running   10.42.0.18    k3d-kubevirt-lab-server-0   True

virtctl stop demo
# VM demo was scheduled to stop
kubectl get vm demo
# NAME   STATUS    READY
# demo   Stopped   False

virtctl restart demo combine les deux, et virtctl pause/unpause gèlent l'exécution sans détruire la VMI.

Injecter de la configuration avec cloud-init

Le volume cloudInitNoCloud fournit à la VM un cloud-init au premier boot : mot de passe, clés SSH, paquets, scripts. Dans le manifeste ci-dessus, on fixe le mot de passe du compte par défaut.

En pratique, injectez une clé SSH au lieu d'un mot de passe :

          userData: |
            #cloud-config
            ssh_authorized_keys:
              - ssh-ed25519 AAAA... votre-cle

Pour des images cloud complètes (Fedora, Ubuntu, Debian), cloud-init configure aussi le réseau, l'hostname et les paquets, exactement comme sur un cloud public.

Accéder à la VM

Trois accès, selon le besoin.

virtctl console demo     # console série (quitter : Ctrl+])
virtctl vnc demo         # console graphique (nécessite un client VNC local)
virtctl ssh cirros@demo  # SSH via le tunnel virtctl, sans exposer la VM

Sur cette image cirros, le compte par défaut est cirros et le mot de passe est celui posé par cloud-init (kubevirt). Exposer la VM sur le réseau (Service, NodePort) relève du guide réseau.

Dépannage

La VM reste Stopped avec runStrategy: Manual : c'est attendu, lancez virtctl start.
La VMI reste Scheduling : ressources insuffisantes ou émulation non activée en lab. Voir kubectl describe vmi demo.
cloud-init ignoré : le volume cloudInitNoCloud doit être attaché comme disque (entrée dans domain.devices.disks), sinon la VM ne le lit pas.
Console qui ne répond pas : le boot en émulation est lent ; patientez avant virtctl console.

À retenir

Une VM se décrit dans un manifeste VirtualMachine ; l'exécution est portée par la VMI.
runStrategy contrôle le démarrage ; Manual laisse la main à virtctl.
virtctl start/stop/restart pilote le cycle de vie ; la VMI reçoit une IP de pod.
cloud-init (cloudInitNoCloud) initialise identifiants, clés SSH et configuration au premier boot.
L'accès se fait en console, VNC ou SSH via virtctl, sans exposer la VM.

Prochaines étapes

Le hub KubeVirt et son parcours

Architecture et concepts

La virtualisation KVM

Panorama de la virtualisation