Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Mise à niveau de v1.5.x à v1.6.x

informations générales

Un bouton Mettre à niveau apparaît sur l’écran Dashboard chaque fois qu’une nouvelle SUSE Virtualization version à laquelle vous pouvez mettre à niveau devient disponible. Pour plus d’informations, voir Démarrer une mise à niveau.

Les clusters fonctionnant sous v1.5.x peuvent passer directement à v1.6.x car SUSE Virtualization permet un maximum d’une mise à niveau mineure pour les composants sous-jacents. v1.5.0, v1.5.1 et v1.5.2 utilisent la même version mineure de RKE2 (v1.32), tandis que v1.6.0 et v1.6.1 utilisent la version mineure suivante (v1.33). Pour plus d’informations, voir Chemins de mise à niveau.

Seuls les clients affectés par les problèmes énumérés dans la section Corrections de bogues des notes de version doivent installer v1.5.2.

Pour des informations sur la mise à niveau de SUSE Virtualization dans des environnements isolés physiquement, voir Préparer une mise à niveau isolée physiquement.

Mettez à jour l’extension UI Harvester sur SUSE Rancher Prime v2.12

Vous devez utiliser une version compatible (v1.6.x) de l’extension UI Harvester pour importer des clusters SUSE Virtualization v1.6.x sur Rancher v2.12.

Sur l’interface Rancher, allez à local → Apps → Dépôts.
Localisez le dépôt nommé harvester, puis sélectionnez ⋮ → Actualiser.
Allez à l’écran Extensions.
Localisez l’extension nommée Harvester, puis cliquez sur Mettre à jour.
Sélectionnez une version compatible, puis cliquez sur Mettre à jour.
Laissez un certain temps pour que l’extension soit mise à jour, puis actualisez l’écran.

Problèmes connus

La mise à niveau est bloquée dans l’état "Pré-drainé"

Dans certaines situations, le gestionnaire d’instances peut échouer à nettoyer une instance de moteur, même après que l’état du CR du moteur a changé en "Arrêté". Le processus de mise à niveau est bloqué dans l’état "Pré-drainé" car le pod du gestionnaire d’instances ne peut pas être supprimé tant que le PodDisruptionBudget (PDB) correspondant existe encore.

La solution de contournement consiste à supprimer le PDB du gestionnaire d’instances après avoir vérifié que tous les volumes sont sains.

Problèmes liés : #8977 et #11605

Le cluster invité est bloqué dans l’état "Mise à jour"

Un cluster invité RKE2 peut rester bloqué dans l’état "Mise à jour" après que SUSE Virtualization a été mis à niveau. Le message d’erreur suivant s’affiche sur l’interface utilisateur SUSE Virtualization :

Configuring etcd node(s) rke2-pool1-xdvfc-qf4vb: Node condition MemoryPressure is Unknown. Node condition DiskPressure is Unknown. Node condition PIDPressure is Unknown. Node condition Ready is Unknown, waiting for probes: calico, etcd, kube-apiserver, kube-controller-manager

Le problème se produit lorsque l’adresse IP du nœud invité change après la mise à niveau, ce qui provoque un dysfonctionnement d’etcd. Il est probable que la machine virtuelle sous-jacente ait été redémarrée plusieurs fois et ait reçu une nouvelle adresse IP du serveur DHCP.

Pour résoudre le problème, effectuez les étapes suivantes :

Sur l’interface utilisateur Rancher, supprimez le nœud à l’origine de l’erreur du cluster invité.
Sur l’interface utilisateur SUSE Virtualization, vérifiez l’état de la machine virtuelle sous-jacente.
Si nécessaire, redémarrez la machine virtuelle.

La machine virtuelle est supprimée, et le cluster invité tente de créer un nouveau nœud. Une fois le nœud créé, l’état du cluster invité change en "Actif".

Problème lié : #8950

La machine virtuelle arrêtée est bloquée dans l’état "Démarrage"

Un volume SUSE Storage peut osciller entre les états "Détachement" et "Détaché" après une migration à chaud. Parce que le volume n’est pas prêt, la machine virtuelle associée ne peut pas démarrer complètement.

La solution de contournement consiste à vider le status.currentMigrationNodeID du volume à l’aide de la commande suivante :

kubectl patch -n longhorn-system volume <volume> \
  --type=merge \
  --subresource status \
  -p '{"status":{"currentMigrationNodeID":""}}'

Problèmes liés : #8949 et #11479

Nœuds bloqués dans l’état "Attente de redémarrage" en raison d’une erreur de configuration réseau

Les nœuds peuvent rester bloqués dans l’état Waiting Reboot pendant une mise à niveau si les critères suivants sont remplis :

SUSE Virtualization v1.2.1 ou une version antérieure a été initialement installée, et les nœuds ont été mis à niveau de manière incrémentielle.
Le champ vlan_id dans le paramètre install.management_interface est soit défini sur 1, soit vide.

Le problème se produit en raison d’une erreur de configuration réseau, comme l’indique le message yaml: line did not find expected key dans les journaux des nœuds.

Lors de la mise à niveau, le fichier /oem/90_custom.yaml est mis à jour pour refléter les changements dans le comportement de v1.5.x, qui a ajouté les VLANs 2–4094 à mgmt-br et mgmt-bo. Deux scripts dans ce fichier (/etc/wicked/scripts/setup_bond.sh et /etc/wicked/scripts/setup_bridge.sh) peuvent être tronqués par une opération sed s’ils utilisent le format généré par gopkg.in/yaml.v2, qui a été utilisé dans l’installateur des versions SUSE Virtualization antérieures à 1.2.2. L’opération sed supprime la ligne bridge vlan add vid 2-4094 dev $INTERFACE. Ce problème de troncature n’affecte pas les scripts qui utilisent le format généré par gopkg.in/yaml.v3.

Voici le contenu du script /etc/wicked/scripts/setup_bond.sh dans le fichier /oem/90_custom.yaml :

Généré à partir de gopkg.in/yaml.v2 :

"#!/bin/sh\n\nACTION=$1\nINTERFACE=$2\n\ncase $ACTION in\n\tpost-up)\n\t\t#
inherit MAC address\n\t\tip link set dev mgmt-br address $(ip -json link show
dev $INTERFACE | jq -j '.[0][\"address\"]')\n\n\t\t# accept all vlan, PVID=1
by default\n\t\tbridge vlan add vid 2-4094 dev $INTERFACE\n\t\t;;\n\nesac\n"
```

Généré à partir de gopkg.in/yaml.v3 :

#!/bin/sh
ACTION=$1
INTERFACE=$2
case $ACTION in
        post-up)
                # inherit MAC address
                ip link set dev mgmt-br address $(ip -json link show dev $INTERFACE | jq -j '.[0]["address"]')
                #accept all vlan,PVID=1 by default
                bridge vlan add vid 2-4094 dev $INTERFACE
                ;;
esac

Voici le contenu du script /etc/wicked/scripts/setup_bridge.sh dans le fichier /oem/90_custom.yaml :

Généré à partir de gopkg.in/yaml.v2 :

"#!/bin/sh\n\nACTION=$1\nINTERFACE=$2\n\ncase $ACTION in\n\tpre-up)\n\t\t#
enable vlan-aware\n\t\tip link set dev $INTERFACE type bridge vlan_filtering 1\n\t\t\t;;\n\n\tpost-up)\n\t\t#
accept all vlan, PVID=1 by default\n\t\tbridge vlan add vid 2-4094 dev $INTERFACE
self\n\t\tbridge vlan add vid 2-4094 dev mgmt-bo\n\t\t;;\n\nesac\n"

Généré à partir de gopkg.in/yaml.v3 :

#!/bin/sh
ACTION=$1
INTERFACE=$2
case $ACTION in
        pre-up)
               #enable vlan-aware
               ip link set $INTERFACE type bridge vlan_filtering 1
               ;;
        post-up)
                #accept all vlan, PVID=1 by default
                bridge vlan add vid 2-4094 dev $INTERFACE self
                bridge vlan add vid 2-4094 dev mgmt-bo
                ;;
esac

La solution de contournement consiste à remplacer le contenu obsolète du script. Utilisez les scripts dans le fichier /oem/90_custom.yaml générés à partir de gopkg.in/yaml.v3. Une fois les scripts mis à jour, la mise à niveau est reprise.

Problème connexe : #9033

Connectivité réseau perdue sur les interfaces VLAN secondaires du réseau de cluster `mgmt`.

La version SUSE Virtualization v1.6.0 a introduit un changement pour réduire le provisionnement inutile des VLAN. Auparavant, toutes les interfaces VLAN secondaires étaient attachées au pont mgmt-br et à l’interface mgmt-bo. Maintenant, seules les interfaces VLAN nécessaires sont attachées. Par conséquent, lorsqu’un cluster est mis à niveau vers v1.6.x, toutes les interfaces VLAN secondaires qui étaient précédemment attachées à mgmt-br et mgmt-bo sont supprimées des hôtes de gestion.

Les charges de travail qui dépendent de ces interfaces perdront la connectivité réseau.

Pour plus d’informations, voir problème #7650.

Après la mise à niveau vers v1.6.x, effectuez les étapes suivantes :

Vérifiez les VLAN attachés à mgmt-br et mgmt-bo en exécutant la commande suivante sur les hôtes de gestion :
```
bridge vlan show
```
Cette commande ne renvoie que le VLAN principal de mgmt-br et mgmt-bo.
Ajoutez manuellement les VLAN secondaires requis au pont mgmt-br et à l’interface mgmt-bo en ajoutant les commandes suivantes au fichier /oem/90_custom.yaml :
- section /etc/wicked/scripts/setup_bond.sh
  bridge vlan add vid <vlan-id> dev $INTERFACE
- section /etc/wicked/scripts/setup_bridge.sh
  bridge vlan add vid <vlan-id> dev $INTERFACE self bridge vlan add vid <vlan-id> dev mgmt-bo
  Vous devez inclure une commande distincte pour chaque ID de VLAN distinct. Assurez-vous que le placeholder vlan-id est remplacé par l’ID réel.
Une fois le fichier /oem/90_custom.yaml mis à jour, redémarrez les hôtes de gestion.
Vérifiez que tous les VLAN requis ont été ajoutés en exécutant la commande suivante sur les hôtes :
```
bridge vlan show
```

Exemple de scénario de mise à niveau

Dans l’exemple suivant, un cluster v1.5.x a été initialement installé avec une interface VLAN principale (ID VLAN : 2021). Pour ajouter une interface VLAN secondaire (ID VLAN : 2113), le fichier /oem/99_vlan-ifcfg.yaml a été créé sur les hôtes de gestion avec le contenu suivant :

stages:
  initramfs:
    - name: "Host VLAN interface mgmt-br.353"
      files:
        - path: /etc/sysconfig/network/ifcfg-mgmt-br.2113
          owner: 0
          group: 0
          permissions: 384
          content: |
            STARTMODE='onboot'
            BOOTPROTO='static'
            IPADDR='10.255.113.150/24'
            VLAN_ID='2113'
            ETHERDEVICE='mgmt-br'
            VLAN='yes'
            DEFROUTE='no'

L’attente typique est qu’une sous-interface VLAN supplémentaire soit créée sur l’interface mgmt (mgmt-br.2113) et qu’une adresse IPv4 lui soit assignée. De plus, cette sous-interface et l’interface principale (mgmt-br.2021) sont toutes deux censées être utilisées pour la connectivité L3 après la mise à niveau du cluster vers v1.6.x.

En réalité, après la mise à niveau vers v1.6.0, la sous-interface VLAN est créée mais le VLAN secondaire (ID VLAN : 2113) est supprimé du pont mgmt-br et de l’interface mgmt-bo. Après un redémarrage, seul l’ID VLAN principal est assigné au pont mgmt-br et à l’interface mgmt-bo (en utilisant le fichier /oem/90_custom.yaml).

Pour atténuer les effets de ce changement, vous devez effectuer la solution de contournement décrite dans la section précédente. Cela implique d’identifier les interfaces VLAN secondaires et d’ajouter ensuite celles nécessaires au pont mgmt-br et à l’interface mgmt-bo.

Les machines virtuelles en cours d’exécution affichent le message `Restart action is required`

L’interface utilisateur SUSE Virtualization peut afficher le message Restart action is required for the virtual machine configuration change to take effect pour certaines machines virtuelles en cours d’exécution dans les situations suivantes :

SUSE Virtualization est mis à niveau de v1.5.x à v1.6.x.
L’extension UI de Harvester est mise à jour vers v1.6.x.
Les clusters SUSE Virtualization sont importés dans Rancher v2.12.x.

Vous devez redémarrer la machine virtuelle pour appliquer les modifications de configuration et effacer le message.

Le message apparaît parce que l’interface utilisateur dans SUSE Virtualization v1.6.0 et les versions ultérieures expose la condition RestartRequired, qui était auparavant uniquement visible dans la configuration YAML de la machine virtuelle. Cette visibilité est essentielle pour des fonctionnalités telles que la connexion à chaud de l’UC et de la mémoire, qui impliquent des modifications de configuration qui ne prennent effet qu’après le redémarrage de la machine virtuelle.

La condition RestartRequired a été introduite pour gérer un décalage d’état causé par la méthode de synchronisation d’adresse MAC héritée. Dans les versions antérieures à v1.6.0, le contrôleur KubeVirt appliquait automatiquement un correctif réintégrant l’adresse MAC de l’instance de machine virtuelle dans la spécification lors du processus de création. Cela garantissait que l’adresse MAC restait cohérente lors des redémarrages. Cependant, comme la spécification a été modifiée pendant que la machine virtuelle était active, le contrôleur a ajouté la RestartRequired condition pour signaler qu’un redémarrage manuel était nécessaire pour synchroniser l’état.

La machine virtuelle ne peut pas être migrée en direct vers le nœud cible.

Suite à une mise à niveau vers v1.6.x, certaines machines virtuelles peuvent rester dans l’état redémarrage en attente. Ces machines virtuelles ne peuvent pas être migrées en direct vers le nœud cible spécifié tant qu’elles ne sont pas redémarrées.

La solution de contournement consiste à redémarrer les machines virtuelles. Une fois redémarrées, les migrations en direct spécifiques au nœud suivantes fonctionneront.

Problème connexe : #9739

La fonctionnalité `cpu-feature.node.kubevirt.io/ipred-ctrl=true` apparaît lors de la mise à niveau.

Harvester migre les machines virtuelles en direct pour garantir un temps d’arrêt nul lors des mises à niveau de nœud. Si votre cluster utilise l’un des modèles d’UC suivants, vous pouvez remarquer l’apparition d’un indicateur de fonctionnalité temporaire (cpu-feature.node.kubevirt.io/ipred-ctrl=true) pendant la mise à niveau.

Intel® Xeon® Gold 5418Y
Intel® Xeon® Silver 4509Y

Bien que ce drapeau de fonctionnalité soit automatiquement supprimé des nœuds après la mise à niveau, le sélecteur de nœud correspondant est conservé dans la configuration de la machine virtuelle. Cette incompatibilité entre les exigences de la machine virtuelle et les étiquettes du nœud entraîne l’échec des migrations en direct ultérieures.

Pour résoudre ce problème, effectuez l’une des actions suivantes avant de commencer la mise à niveau :

Option 1 : Configurer un modèle d’UC commun pour les machines virtuelles.
Option 2 : Interrompez le labeller KubeVirt en ajoutant l’annotation node-labeller.kubevirt.io/skip-node aux nœuds, puis supprimez l’annotation après la mise à niveau. Bien que plus complexe, cette option est utile si les machines virtuelles ne peuvent pas être redémarrées. Pour plus d’informations, voir Dépannage des problèmes de migration en direct des VM causés par des sélecteurs de nœuds.

Changement du comportement VLAN par défaut pour les interfaces de pod secondaires

Dans les versions v1.6.0 et antérieures, les pods avec des interfaces réseau secondaires (telles que les réseaux de VM et les réseaux de stockage) étaient automatiquement assignés à l’ID VLAN 1 et à l’ID VLAN configuré dans le réseau VLAN. Cette configuration à double ID VLAN permettait au SUSE Virtualization pont réseau de transférer le trafic non étiqueté vers les interfaces veth de ces pods.

Ce comportement a changé dans v1.6.1, qui utilise v1.8.0 du plugin de pont CNI. Les interfaces de pod secondaires sont désormais associées uniquement à l’ID VLAN attribué au réseau de VM. Comme l’ID VLAN 1 n’est plus ajouté, le pont ne peut pas transférer le trafic non étiqueté vers ces interfaces.

Le changement affecte les clusters mis à niveau de v1.5.x à v1.6.1 si le port de commutation externe est configuré comme un port d’accès envoyant des trames non étiquetées. La mise à jour de la configuration du commutateur externe pour utiliser un port trunk résout le problème. Les pods avec des interfaces secondaires qui sont attachées à des réseaux non étiquetés ou associées à l’ID VLAN 1 ne sont pas affectés.

Problème connexe : #8816