3.2. À propos du service de mise à jour OpenShift
L'OpenShift Update Service (OSUS) fournit des recommandations de mise à jour à OpenShift Container Platform, y compris Red Hat Enterprise Linux CoreOS (RHCOS). Il fournit un graphique, ou diagramme, qui contient le site vertices des opérateurs de composants et le site edges qui les relie. Les arêtes du graphique indiquent les versions que vous pouvez mettre à jour en toute sécurité. Les sommets sont des charges utiles de mise à jour qui spécifient l'état prévu des composants du cluster géré.
Le Cluster Version Operator (CVO) dans votre cluster vérifie avec l'OpenShift Update Service pour voir les mises à jour valides et les chemins de mise à jour basés sur les versions actuelles des composants et les informations dans le graphique. Lorsque vous demandez une mise à jour, le CVO utilise l'image de la version de cette mise à jour pour mettre à jour votre cluster. Les artefacts de version sont hébergés dans Quay en tant qu'images de conteneur.
Pour permettre à OpenShift Update Service de ne fournir que des mises à jour compatibles, un pipeline de vérification des versions pilote l'automatisation. Chaque artefact de version est vérifié pour sa compatibilité avec les plateformes cloud et les architectures système prises en charge, ainsi qu'avec d'autres packages de composants. Une fois que le pipeline a confirmé l'adéquation d'une version, l'OpenShift Update Service vous informe qu'elle est disponible.
Le service de mise à jour d'OpenShift affiche toutes les mises à jour recommandées pour votre cluster actuel. Si un chemin de mise à jour n'est pas recommandé par OpenShift Update Service, cela peut être dû à un problème connu avec la mise à jour ou la version cible.
Deux contrôleurs fonctionnent en mode de mise à jour continue. Le premier contrôleur met continuellement à jour les manifestes de charge utile, applique les manifestes au cluster et produit l'état de déploiement contrôlé des opérateurs pour indiquer s'ils sont disponibles, en cours de mise à niveau ou s'ils ont échoué. Le second contrôleur interroge le service de mise à jour OpenShift pour déterminer si des mises à jour sont disponibles.
Seule la mise à niveau vers une version plus récente est prise en charge. L'inversion ou le retour à une version antérieure de votre cluster n'est pas pris en charge. Si votre mise à jour échoue, contactez l'assistance Red Hat.
Au cours du processus de mise à jour, le MCO (Machine Config Operator) applique la nouvelle configuration aux machines de votre cluster. Le MCO bloque le nombre de nœuds spécifié dans le champ maxUnavailable du pool de configuration de la machine et les marque comme étant indisponibles. Par défaut, cette valeur est définie sur 1. Le MCO met à jour les nœuds concernés par ordre alphabétique de zone, sur la base de l'étiquette topology.kubernetes.io/zone. Si une zone comporte plusieurs nœuds, les nœuds les plus anciens sont mis à jour en premier. Pour les nœuds qui n'utilisent pas de zones, comme dans les déploiements bare metal, les nœuds sont mis à niveau par âge, les nœuds les plus anciens étant mis à jour en premier. Le MCO met à jour le nombre de nœuds spécifié par le champ maxUnavailable du pool de configuration de la machine à la fois. Le MCO applique ensuite la nouvelle configuration et redémarre la machine.
Si vous utilisez des machines Red Hat Enterprise Linux (RHEL) en tant que travailleurs, le MCO ne met pas à jour le kubelet car vous devez d'abord mettre à jour l'API OpenShift sur les machines.
Avec la spécification de la nouvelle version appliquée à l'ancien kubelet, la machine RHEL ne peut pas revenir à l'état Ready. Vous ne pouvez pas terminer la mise à jour tant que les machines ne sont pas disponibles. Toutefois, le nombre maximal de nœuds indisponibles est défini de manière à ce que les opérations normales du cluster puissent se poursuivre avec ce nombre de machines hors service.
Le service de mise à jour OpenShift est composé d'un opérateur et d'une ou plusieurs instances d'application.
