Chapitre 3. Comprendre les canaux de mise à jour et les versions

Le canal fast-4.12 est mis à jour avec les nouvelles versions d'OpenShift Container Platform 4.12 dès que Red Hat déclare la version comme étant une version de disponibilité générale (GA). En tant que telles, ces versions sont entièrement prises en charge et destinées à être utilisées dans des environnements de production.

Alors que le canal fast-4.12 contient les communiqués dès que leurs errata sont publiés, les communiqués sont ajoutés au canal stable-4.12 après un certain délai. Pendant ce délai, des données sont collectées à partir de sources multiples et analysées pour détecter les signes de régression des produits. Une fois qu'un nombre significatif de points de données a été collecté, et en l'absence de signaux négatifs, ces versions sont ajoutées au canal stable.

Les clusters nouvellement installés utilisent par défaut les canaux stables.

En plus du canal stable, toutes les versions mineures paires d'OpenShift Container Platform offrent un support de mise à jour étendu (EUS). Les versions promues sur le canal stable sont également promues simultanément sur les canaux EUS. L'objectif principal des canaux EUS est de servir de commodité pour les clusters effectuant une mise à jour EUS-to-EUS.

Le canal candidate-4.12 offre un accès anticipé non supporté aux versions dès qu'elles sont construites. Les versions présentes uniquement dans les canaux candidats peuvent ne pas contenir l'ensemble des fonctionnalités des éventuelles versions GA ou des fonctionnalités peuvent être supprimées avant la GA. De plus, ces versions n'ont pas été soumises à l'assurance qualité complète de Red Hat et peuvent ne pas offrir de chemins de mise à jour vers les versions GA ultérieures. Compte tenu de ces mises en garde, le canal candidat ne convient qu'à des fins de test où la destruction et la recréation d'un cluster sont acceptables.

OpenShift Container Platform dispose d'un service de recommandation de mise à jour qui connaît la version d'OpenShift Container Platform que vous avez installée et le chemin à suivre au sein du canal pour passer à la version suivante. Les chemins de mise à jour sont également limités aux versions pertinentes pour votre canal actuellement sélectionné et ses caractéristiques de promotion.

Vous pouvez imaginer voir les communiqués suivants dans votre chaîne :

Le service recommande uniquement les mises à jour qui ont été testées et qui ne présentent aucune régression grave connue. Par exemple, si votre cluster est sur 4.12.1 et que OpenShift Container Platform suggère 4.12.4, il est recommandé de mettre à jour de 4.12.1 à 4.12.4.

Red Hat surveille les nouvelles versions et les chemins de mise à jour associés à ces versions avant et après leur ajout aux canaux pris en charge. Si une régression sérieuse est identifiée, Red Hat peut supprimer les recommandations de mise à jour concernées. Lorsque Red Hat choisit de supprimer les recommandations de mise à jour, cette action est prise simultanément dans tous les canaux concernés. La suppression des recommandations de mise à jour peut avoir lieu avant ou après que les mises à jour aient été promues dans les canaux pris en charge.

Si Red Hat supprime les recommandations de mise à jour d'une version prise en charge, une recommandation de mise à jour de remplacement sera fournie pour une version future qui corrige la régression. Il peut cependant y avoir un délai pendant que le défaut est corrigé, testé et promu à votre canal sélectionné.

À partir d'OpenShift Container Platform 4.10, lorsque les recommandations de mise à jour sont supprimées des canaux pris en charge, elles sont remplacées par des mises à jour conditionnelles qui déclarent un ou plusieurs risques connus. Chaque risque connu peut s'appliquer à tous les clusters ou uniquement aux clusters correspondant à certaines conditions. Par exemple, si le site Platform est défini sur None ou si le fournisseur CNI est défini sur OpenShiftSDN, l'opérateur de version de cluster (CVO) évalue en permanence les risques connus par rapport à l'état actuel du cluster. Si aucun risque ne correspond, la mise à jour est recommandée. Si le risque correspond, ces mises à jour sont répertoriées comme une mise à jour Supported But Not Recommended et un lien de référence est fourni. Le lien de référence aide l'administrateur du cluster à décider s'il souhaite accepter le risque et procéder à la mise à jour.

Le choix du canal approprié implique deux décisions.

Tout d'abord, sélectionnez la version mineure que vous souhaitez pour la mise à niveau de votre cluster. La sélection d'un canal correspondant à votre version actuelle garantit que vous n'appliquerez que les mises à jour du flux z et que vous ne recevrez pas de mises à jour des fonctionnalités. En sélectionnant un canal disponible dont la version est supérieure à votre version actuelle, vous vous assurez qu'après une ou plusieurs mises à jour, votre cluster aura été mis à jour vers cette version. Votre cluster ne se verra proposer que des canaux correspondant à sa version actuelle, à la version suivante ou à la version EUS suivante.

Deuxièmement, vous devez choisir votre stratégie de déploiement. Vous pouvez choisir de mettre à jour dès que Red Hat déclare une version GA en sélectionnant les canaux rapides ou vous pouvez attendre que Red Hat promeuve les versions vers le canal stable. Les recommandations de mise à jour proposées sur fast-4.12 et stable-4.12 sont toutes deux entièrement prises en charge et bénéficient de la même manière de l'analyse continue des données. Le délai de promotion avant de promouvoir une version vers le canal stable représente la seule différence entre les deux canaux. Les mises à jour des derniers flux z sont généralement promues vers le canal stable dans un délai d'une semaine ou deux, mais le délai de déploiement initial des mises à jour de la dernière version mineure est beaucoup plus long, généralement de 45 à 90 jours. Veuillez tenir compte du délai de promotion lorsque vous choisissez le canal que vous souhaitez, car l'attente de la promotion vers le canal stable peut avoir une incidence sur vos plans de programmation.

En outre, plusieurs facteurs peuvent amener une organisation à passer à la voie rapide de manière permanente ou temporaire, notamment

Si vous gérez vous-même les images de conteneurs pour vos clusters OpenShift Container Platform, vous devez consulter l'errata de Red Hat qui est associé aux versions du produit et noter tout commentaire ayant un impact sur les mises à jour. Lors d'une mise à jour, l'interface utilisateur peut vous avertir de la nécessité de passer d'une version à l'autre, vous devez donc vous assurer que vous avez sélectionné une version appropriée avant de contourner ces avertissements.

Un canal peut être commuté à partir de la console web ou de la commande adm upgrade channel:

$ oc adm upgrade channel <channel>

La console web affichera une alerte si vous passez à un canal qui n'inclut pas la version actuelle. La console web ne recommande aucune mise à jour lorsque vous êtes sur un canal sans la version actuelle. Vous pouvez toutefois revenir au canal d'origine à tout moment.

Le changement de canal peut avoir un impact sur la capacité de support de votre cluster. Les conditions suivantes peuvent s'appliquer :