Mises à jour EUS vers EUS d'OpenShift : un runbook de Control Plane Only update

Ce qu'est une Control Plane Only update

Red Hat désigne les versions mineures paires d'OpenShift Container Platform, comme 4.20 et 4.22, comme des versions Extended Update Support (EUS). Beaucoup d'équipes exploitent la production sur des versions EUS et ne passent que de l'une à la suivante. Cet article suit la documentation d'OpenShift Container Platform 4.22 pour ce passage. Consultez la documentation de vos propres versions avant de vous fier à un détail de ce texte.

Les mises à jour mineures sont séquentielles : un cluster ne peut pas aller directement de 4.20 à 4.22, il doit passer par 4.21. Une Control Plane Only update, autrefois appelée mise à jour EUS-to-EUS, rend cela supportable. Vous mettez en pause les machine config pools de vos nœuds worker et personnalisés, laissez le plan de contrôle passer en 4.21 puis en 4.22, et réactivez les pools à la fin. Les nœuds en pause ne sont mis à jour qu'une fois, directement en 4.22, et ne redémarrent donc qu'une fois au lieu de deux. Cela ne fonctionne qu'entre versions mineures paires.

Deux règles de calendrier découlent du processus de Red Hat. Le chemin n'est proposé qu'une fois les mises à jour entre toutes les versions concernées disponibles dans les canaux stable, et Red Hat documente un délai typique de 45 à 90 jours après la disponibilité générale d'une nouvelle version mineure avant que ses chemins de mise à jour n'arrivent dans les canaux stable, avec une promotion simultanée dans les canaux EUS. C'est une estimation, pas une échéance garantie. Si le chemin de mise à jour n'est pas encore proposé, la réponse est d'attendre, pas de forcer.

Lisez les deux notes de version, pas seulement la cible

Les prérequis commencent par la lecture des notes de version de 4.21 et de 4.22, ainsi que des notes de version et cycles de vie de chaque produit en couches et de chaque Operator du cluster. Même si les nœuds worker sautent 4.21, le plan de contrôle ne le saute pas, et chaque étape a sa propre préparation.

Pour ce couple de versions, les guides de mise à jour de 4.21 et de 4.22 n'indiquent aucune suppression d'API Kubernetes, ce qui écarte un blocage courant. Cela n'exclut pas d'autres changements incompatibles, dépréciations ou exigences de compatibilité des Operators, que couvrent les notes de version. L'étape de 4.21 à 4.22 en ajoute un autre sur certaines plateformes : sur les clusters vSphere, par exemple, où le paramètre managedBootImages n'a pas été configuré, la mise à jour est bloquée jusqu'à ce qu'un administrateur prenne acte du nouveau comportement par défaut des images de démarrage mises à jour ou désactive explicitement la fonction pour les nœuds de calcul. Les clusters utilisant des volumes vSphere in-tree ont aussi besoin de vSphere 7.0u3L+ ou 8.0u2+ avant le début de la mise à jour. Découvrir cela en réunion de planification coûte quelques minutes. Le découvrir au milieu d'une fenêtre de maintenance coûte la fenêtre.

Vérifiez que le cluster est prêt

OpenShift ne lance pas de mise à jour mineure tant que chaque cluster Operator ne signale pas Upgradeable à True, et l'alerte ClusterNotUpgradeable vous prévient quand l'un d'eux ne le fait pas. Traitez aussi d'abord les alertes critiques. La commande en lecture seule oc adm upgrade recommend résume les alertes actives et les risques de mise à jour connus pour votre cluster. Ses vérifications fondées sur les alertes exigent une authentification par jeton : avec le kubeconfig de l'installateur et l'identité system:admin fondée sur certificat, la commande s'exécute quand même, mais signale le jeton manquant et saute ces vérifications.

Ne choisissez que des cibles recommandées par l'OpenShift Update Service. Une cible affichée comme mise à jour conditionnelle comporte un risque connu qui s'applique à votre cluster ; à moins d'avoir besoin de cette version précise, Red Hat conseille d'attendre un chemin recommandé.

Vérifiez ensuite la capacité. Par défaut, les nœuds sont drainés un par un, puisque maxUnavailable vaut 1, et Red Hat recommande de ne pas modifier cette valeur pour le pool du plan de contrôle. Tous les nœuds doivent être disponibles avant de commencer, les autres nœuds doivent avoir de la place pour les pods déplacés, et les PodDisruptionBudgets doivent permettre à ces pods de bouger. Un budget qui ne tolère aucune interruption bloque le drainage d'un nœud aussi sûrement qu'une panne. Mettez à jour la CLI oc vers la version cible avant chaque étape, et faites une sauvegarde etcd avant de commencer.

Les Operators décident de la durée

La mise à jour du cluster est la partie scriptée. C'est sur les Operators que les Control Plane Only updates bloquent le plus souvent. Avant chaque étape, chaque Operator installé via Operator Lifecycle Manager (OLM) doit être mis à jour vers une version compatible avec la version cible, afin de conserver un chemin de mise à jour valide lorsque les catalogues par défaut passent à la version mineure suivante. Red Hat fournit l'Operator Update Information Checker pour confirmer quelles versions de cluster chaque version d'un Operator prend en charge.

Les produits en couches s'intercalent entre les mises à jour du cluster. L'exemple de Red Hat pour OpenShift Data Foundation est : mettre en pause les pools worker, mettre à jour le cluster en 4.21, mettre à jour ODF vers sa version 4.21, mettre à jour le cluster en 4.22, mettre à jour ODF en 4.22, puis réactiver les pools. Dressez la liste de chaque Operator avec sa version actuelle, ses versions compatibles et le moment de la séquence où il change, et traitez cette liste comme une partie du dossier de changement.

Clusters qui exécutent des machines virtuelles

Si le cluster exécute OpenShift Virtualization, une étape supplémentaire précède la première mise à jour. Notez la valeur actuelle de workloadUpdateMethods, puis videz-la. OpenShift Virtualization ne migre ni n'évince alors aucune machine virtuelle pendant que le plan de contrôle traverse la 4.21.

OpenShift Virtualization suit ensuite le cluster. Après l'étape 4.21, il se met à jour vers le dernier z-stream de sa version intermédiaire, et il faut attendre que le HyperConverged Operator signale de nouveau Upgradeable avant de lancer l'étape 4.22. Avec la stratégie d'approbation Automatic par défaut, ces mises à jour s'appliquent seules ; avec l'approbation Manual, chacune doit être approuvée. Après l'étape 4.22 et la mise à jour correspondante d'OpenShift Virtualization, restaurez la valeur de workloadUpdateMethods notée, vérifiez les migrations de VM, et seulement ensuite réactivez les pools.

La séquence

La séquence documentée, en CLI ou dans la console web, est courte. Mettez à jour les Operators OLM vers des versions compatibles avec la cible. Vérifiez que tous les machine config pools sont à jour et qu'aucun n'est en cours de mise à jour. Passez le canal du cluster à eus-4.22. Mettez en pause tous les pools sauf celui du plan de contrôle, qui ne peut pas l'être. Mettez à jour vers la dernière version 4.21 et vérifiez que la mise à jour est terminée. Mettez de nouveau à jour les Operators si nécessaire. Mettez à jour vers 4.22 et vérifiez. Réactivez les pools, et vérifiez que chacun est signalé à jour.

Seule la réactivation redémarre les nœuds worker : c'est donc l'étape à caler sur le calendrier de l'activité. Si le cluster comprend des machines de calcul RHEL, il faut exécuter le playbook de mise à jour sur chacune lorsqu'elle passe à l'état NotReady. Donnez à chaque étape un responsable, une vérification qui prouve qu'elle est terminée et une condition d'arrêt écrite.

Gardez la pause courte

Des pools en pause ne sont pas un endroit sûr pour attendre. Tant qu'un pool est en pause, le Machine Config Operator ne peut pousser aucune configuration vers ses nœuds, y compris le bundle de confiance mis à jour après la rotation automatique de la CA kube-apiserver-to-kubelet-signer. La pause ne casse rien à elle seule, mais dès que l'API server utilise un certificat client signé par le nouveau signataire, les nœuds en pause peuvent le rejeter, et des commandes comme oc logs, oc exec, oc debug et oc attach échouent. Et si des pools restent en pause après la mise à jour, le cluster ne peut passer à aucune version mineure ultérieure, et certaines tâches de maintenance sont bloquées.

Tant que les pools ne sont pas réactivés, certaines fonctions et corrections de 4.21 et 4.22 ne sont pas disponibles sur les nœuds en pause. Si un problème apparaît en 4.21, avant la seconde étape, le corriger peut exiger que les nœuds en pause terminent d'abord la mise à jour vers 4.21. C'est le retour à une mise à jour normale avec deux redémarrages : acceptez-le plutôt que de garder les pools en pause en cherchant une autre voie. Sur les grands clusters, les pools personnalisés peuvent être réactivés par étapes, en commençant par un petit pool canary, à condition que tous finissent à la même version.

Prévoyez l'absence de retour arrière du cluster

Revenir à une version précédente d'un cluster OpenShift n'est pas pris en charge. Cela concerne la version du cluster : le retour arrière au niveau applicatif et la reprise après sinistre documentée sont une autre question. Une sauvegarde etcd protège contre un cluster devenu irrécupérable, mais Red Hat indique clairement qu'une restauration etcd n'est pas un mécanisme de retour arrière, qu'elle est destructive et qu'elle est un dernier recours. Si une mise à jour ne parvient pas à se terminer, la voie prise en charge est le support Red Hat.

Tout ce qui rendrait un retour arrière inutile se passe donc avant la mise à jour : une répétition sur un cluster hors production avec les mêmes Operators aux mêmes versions, la séquence des Operators et des produits en couches écrite, la capacité et les PodDisruptionBudgets vérifiés, les accusés de réception administrateur donnés, et un dossier de support prêt à ouvrir. La fenêtre de maintenance doit préciser qui peut suspendre le changement et sur quels signaux. Pour les charges applicatives, la reprise passe par la sauvegarde et la restauration propres à l'application, testées à l'avance, pas par une restauration du cluster.

Notre approche

Nous traitons une mise à jour EUS vers EUS comme un changement planifié, avec un runbook : des prérequis propres à chaque version vérifiés dans la documentation des versions exactes, une liste de compatibilité des Operators, une répétition, des conditions d'arrêt convenues à l'avance et une pause aussi courte que le plan le permet. Les runbooks de mise à jour et les preuves de tests de reprise font partie des livrables documentés de notre pratique Kubernetes et OpenShift, et les mises à jour contrôlées sont comprises dans le support de plateforme, dans la couverture convenue.