Chapitre 9. Mise à jour d'un cluster à l'aide du CLI
Vous pouvez mettre à jour, ou mettre à niveau, un cluster OpenShift Container Platform au sein d'une version mineure en utilisant l'OpenShift CLI (oc). Vous pouvez également mettre à jour un cluster entre des versions mineures en suivant les mêmes instructions.
9.1. Conditions préalables
-
Avoir accès au cluster en tant qu'utilisateur avec des privilèges
admin. Voir Utilisation de RBAC pour définir et appliquer des autorisations. - Disposez d'une sauvegarde etcd récente au cas où votre mise à jour échouerait et que vous deviez restaurer votre cluster dans un état antérieur.
- La prise en charge des travailleurs RHEL7 est supprimée dans OpenShift Container Platform 4.12. Vous devez remplacer les travailleurs RHEL7 par des travailleurs RHEL8 ou RHCOS avant de mettre à niveau OpenShift Container Platform 4.12. Red Hat ne prend pas en charge les mises à jour RHEL7 à RHEL8 sur place pour les travailleurs RHEL ; ces hôtes doivent être remplacés par une installation de système d'exploitation propre.
- S'assurer que tous les opérateurs précédemment installés via Operator Lifecycle Manager (OLM) sont mis à jour à leur dernière version dans leur dernier canal. La mise à jour des opérateurs garantit qu'ils disposent d'un chemin de mise à jour valide lorsque les catalogues OperatorHub par défaut passent de la version mineure actuelle à la suivante lors d'une mise à jour du cluster. Voir Mise à jour des opérateurs installés pour plus d'informations.
- Assurez-vous que tous les pools de configuration de machines (MCP) sont en cours d'exécution et ne sont pas en pause. Les nœuds associés à un MCP en pause sont ignorés lors du processus de mise à jour. Vous pouvez mettre les MCP en pause si vous exécutez une stratégie de mise à jour par déploiement canarien.
- Si votre cluster utilise des informations d'identification gérées manuellement, mettez à jour les ressources du fournisseur de cloud pour la nouvelle version. Pour plus d'informations, notamment sur la manière de déterminer s'il s'agit d'une exigence pour votre cluster, voir Préparation de la mise à jour d'un cluster avec des informations d'identification gérées manuellement.
-
Veillez à résoudre toutes les conditions de
Upgradeable=Falseafin que le cluster puisse être mis à jour vers la version mineure suivante. Une alerte s'affiche en haut de la page Cluster Settings lorsqu'un ou plusieurs opérateurs de cluster ne peuvent pas être mis à niveau. Vous pouvez toujours passer à la prochaine mise à jour de correctifs disponible pour la version mineure que vous utilisez actuellement. - Examinez la liste des API qui ont été supprimées dans Kubernetes 1.25, migrez tous les composants concernés pour utiliser la nouvelle version de l'API et fournissez l'accusé de réception de l'administrateur. Pour plus d'informations, voir Préparation de la mise à jour vers OpenShift Container Platform 4.12.
-
Si vous exécutez un opérateur ou si vous avez configuré une application avec le budget d'interruption des pods, il se peut que vous subissiez une interruption pendant le processus de mise à niveau. Si
minAvailableest défini à 1 dansPodDisruptionBudget, les nœuds sont vidés pour appliquer les configurations de machine en attente, ce qui peut bloquer le processus d'éviction. Si plusieurs nœuds sont redémarrés, tous les pods peuvent s'exécuter sur un seul nœud, et le champPodDisruptionBudgetpeut empêcher la vidange des nœuds.
Important
- Lorsqu'une mise à jour n'aboutit pas, l'opérateur de version de cluster (CVO) signale l'état des composants bloquants tout en essayant de réconcilier la mise à jour. Le retour de votre cluster à une version précédente n'est pas pris en charge. Si votre mise à jour n'aboutit pas, contactez l'assistance de Red Hat.
-
L'utilisation de la section
unsupportedConfigOverridespour modifier la configuration d'un opérateur n'est pas prise en charge et peut bloquer les mises à jour de la grappe. Vous devez supprimer ce paramètre avant de pouvoir mettre à jour votre cluster.
Ressources supplémentaires
