Red Hat SummitChapitre 7. Mise à jour de la virtualisation OpenShift
Découvrez comment Operator Lifecycle Manager (OLM) fournit des mises à jour de flux z et de versions mineures pour OpenShift Virtualization.
Le Node Maintenance Operator (NMO) n'est plus livré avec OpenShift Virtualization. Vous pouvez installer le NMO à partir de OperatorHub dans la console web d'OpenShift Container Platform, ou en utilisant la CLI d'OpenShift (
oc).Vous devez effectuer l'une des tâches suivantes avant de mettre à jour OpenShift Virtualization 4.11 à partir d'OpenShift Virtualization 4.10.2 et des versions ultérieures :
- Sortir tous les nœuds du mode maintenance.
-
Installez l'ONM autonome et remplacez la ressource personnalisée (CR)
nodemaintenances.nodemaintenance.kubevirt.iopar une CRnodemaintenances.nodemaintenance.medik8s.io.
7.1. À propos de la mise à jour de la virtualisation OpenShift
- Operator Lifecycle Manager (OLM) gère le cycle de vie de l'opérateur de virtualisation OpenShift. L'opérateur Marketplace, qui est déployé lors de l'installation d'OpenShift Container Platform, met les opérateurs externes à la disposition de votre cluster.
- OLM fournit un flux z et des mises à jour de versions mineures pour OpenShift Virtualization. Les mises à jour des versions mineures sont disponibles lorsque vous mettez à jour OpenShift Container Platform vers la version mineure suivante. Vous ne pouvez pas mettre à jour OpenShift Virtualization vers la version mineure suivante sans d'abord mettre à jour OpenShift Container Platform.
- Les abonnements à OpenShift Virtualization utilisent un canal de mise à jour unique nommé stable. Le canal stable assure la compatibilité des versions d'OpenShift Virtualization et d'OpenShift Container Platform.
Si la stratégie d'approbation de votre abonnement est définie sur Automatic, le processus de mise à jour démarre dès qu'une nouvelle version de l'opérateur est disponible dans le canal stable. Il est fortement recommandé d'utiliser la stratégie d'approbation Automatic pour maintenir un environnement supportable. Chaque version mineure d'OpenShift Virtualization n'est prise en charge que si vous exécutez la version correspondante d'OpenShift Container Platform. Par exemple, vous devez exécuter OpenShift Virtualization 4.12 sur OpenShift Container Platform 4.12.
- Bien qu'il soit possible de sélectionner la stratégie d'approbation Manual, cela n'est pas recommandé car cela risque de compromettre le support et la fonctionnalité de votre cluster. Avec la stratégie d'approbation Manual, vous devez approuver manuellement chaque mise à jour en attente. Si les mises à jour d'OpenShift Container Platform et d'OpenShift Virtualization ne sont pas synchronisées, votre cluster ne sera plus supporté.
- Le délai d'exécution d'une mise à jour dépend de votre connexion réseau. La plupart des mises à jour automatiques s'effectuent en quinze minutes.
- La mise à jour d'OpenShift Virtualization n'interrompt pas les connexions réseau.
- Les volumes de données et les revendications de volumes persistants qui leur sont associées sont préservés lors de la mise à jour.
Si vous avez des machines virtuelles en cours d'exécution qui utilisent le stockage hostpath provisioner, elles ne peuvent pas être migrées en direct et peuvent bloquer une mise à jour du cluster OpenShift Container Platform.
En guise de solution, vous pouvez reconfigurer les machines virtuelles de manière à ce qu'elles puissent être mises hors tension automatiquement lors d'une mise à jour du cluster. Supprimez le champ evictionStrategy: LiveMigrate et définissez le champ runStrategy sur Always.
7.1.1. A propos des mises à jour de la charge de travail
Lorsque vous mettez à jour OpenShift Virtualization, les charges de travail des machines virtuelles, y compris libvirt, virt-launcher, et qemu, se mettent à jour automatiquement si elles prennent en charge la migration en direct.
Chaque machine virtuelle possède un pod virt-launcher qui exécute l'instance de machine virtuelle (VMI). Le pod virt-launcher exécute une instance de libvirt, qui est utilisée pour gérer le processus de la machine virtuelle (VM).
Vous pouvez configurer la manière dont les charges de travail sont mises à jour en modifiant la strophe spec.workloadUpdateStrategy de la ressource personnalisée (CR) HyperConverged. Il existe deux méthodes de mise à jour des charges de travail : LiveMigrate et Evict.
Comme la méthode Evict arrête les pods VMI, seule la stratégie de mise à jour LiveMigrate est activée par défaut.
Lorsque LiveMigrate est la seule stratégie de mise à jour activée :
- Les IMV qui prennent en charge la migration en direct sont migrées pendant le processus de mise à jour. L'invité de la VM se déplace dans un nouveau pod avec les composants mis à jour activés.
Les IMV qui ne prennent pas en charge la migration en direct ne sont pas interrompues ni mises à jour.
-
Si un IMV dispose de la stratégie d'éviction
LiveMigratemais ne prend pas en charge la migration en direct, il n'est pas mis à jour.
-
Si un IMV dispose de la stratégie d'éviction
Si vous activez à la fois LiveMigrate et Evict:
-
Les IMV qui prennent en charge la migration en direct utilisent la stratégie de mise à jour
LiveMigrate. -
Les IMV qui ne prennent pas en charge la migration en direct utilisent la stratégie de mise à jour
Evict. Si une IMV est contrôlée par un objetVirtualMachinedont la valeurrunStrategyestalways, une nouvelle IMV est créée dans un nouveau module avec des composants mis à jour.
Tentatives de migration et délais d'attente
Lors de la mise à jour des charges de travail, la migration en direct échoue si un pod est dans l'état Pending pendant les périodes suivantes :
- 5 minutes
-
Si le pod est en attente parce qu'il est
Unschedulable. - 15 minutes
- Si le pod est bloqué dans l'état d'attente pour une raison quelconque.
Lorsqu'une IMV ne parvient pas à migrer, le site virt-controller essaie de la migrer à nouveau. Il répète ce processus jusqu'à ce que toutes les IMV migrables soient exécutées sur les nouveaux pods virt-launcher. Cependant, si une IMV est mal configurée, ces tentatives peuvent se répéter indéfiniment.
Chaque tentative correspond à un objet de migration. Seules les cinq tentatives les plus récentes sont conservées dans une mémoire tampon. Cela permet d'éviter que les objets de migration ne s'accumulent sur le système tout en conservant des informations pour le débogage.
7.1.2. À propos des mises à jour EUS-to-EUS
Chaque version mineure paire d'OpenShift Container Platform, y compris les versions 4.10 et 4.12, est une version EUS (Extended Update Support). Cependant, comme la conception de Kubernetes impose des mises à jour en série des versions mineures, vous ne pouvez pas passer directement d'une version EUS à la suivante.
Après avoir mis à jour la version EUS source vers la prochaine version mineure impaire, vous devez séquentiellement mettre à jour OpenShift Virtualization vers toutes les versions z-stream de cette version mineure qui se trouvent sur votre chemin de mise à jour. Lorsque vous avez mis à jour vers la dernière version z-stream applicable, vous pouvez alors mettre à jour OpenShift Container Platform vers la version mineure EUS cible.
Lorsque la mise à jour d'OpenShift Container Platform réussit, la mise à jour correspondante pour OpenShift Virtualization devient disponible. Vous pouvez maintenant mettre à jour OpenShift Virtualization vers la version EUS cible.
7.1.2.1. Préparation de la mise à jour
Avant de commencer une mise à jour EUS-to-EUS, vous devez :
- Mettez en pause les pools de configuration des machines des nœuds de travail avant de lancer une mise à jour EUS vers EUS afin que les travailleurs ne soient pas redémarrés deux fois.
- Désactivez les mises à jour automatiques de la charge de travail avant de commencer le processus de mise à jour. Cela permet d'éviter qu'OpenShift Virtualization ne migre ou n'expulse vos machines virtuelles (VM) jusqu'à ce que vous mettiez à jour votre version cible d'EUS.
Par défaut, OpenShift Virtualization met automatiquement à jour les workloads, tels que le pod virt-launcher, lorsque vous mettez à jour l'OpenShift Virtualization Operator. Vous pouvez configurer ce comportement dans la strophe spec.workloadUpdateStrategy de la ressource personnalisée HyperConverged.
En savoir plus sur la préparation d'une mise à jour EUS-to-EUS.
