4.3. Phases de mise à jour des clusters
Dans OpenShift Container Platform, la mise à jour du cluster se fait en deux phases :
- Déploiement de la charge utile de mise à jour de la cible de l'opérateur de version de cluster (CVO)
- Mises à jour du nœud de configuration de la machine (MCO)
4.3.1. Cluster Version Operator target update payload deployment (déploiement de la charge utile de mise à jour de la cible)
Le Cluster Version Operator (CVO) récupère l'image de la mise à jour cible et l'applique au cluster. Tous les composants qui fonctionnent en tant que pods sont mis à jour au cours de cette phase, tandis que les composants hôtes sont mis à jour par l'opérateur de configuration de la machine (MCO). Ce processus peut durer de 60 à 120 minutes.
La phase CVO de la mise à jour ne redémarre pas les nœuds.
Ressources supplémentaires
4.3.2. Config Machine Mises à jour du nœud de l'opérateur
L'opérateur de configuration de machine (MCO) applique une nouvelle configuration de machine à chaque plan de contrôle et à chaque nœud de calcul. Au cours de ce processus, le MCO effectue les actions séquentielles suivantes sur chaque nœud de la grappe :
- Cordon et drainage de tous les nœuds
- Mettre à jour le système d'exploitation (OS)
- Redémarrer les nœuds
- Déconnexion de tous les nœuds et programmation des charges de travail sur le nœud
Lorsqu'un nœud est bloqué, il n'est pas possible d'y planifier des charges de travail.
La durée de ce processus dépend de plusieurs facteurs, notamment de la configuration du nœud et de l'infrastructure. Ce processus peut prendre 5 minutes ou plus par nœud.
Outre le MCO, vous devez tenir compte de l'impact des paramètres suivants :
- La durée de mise à jour des nœuds du plan de contrôle est prévisible et souvent plus courte que celle des nœuds de calcul, car les charges de travail du plan de contrôle sont réglées pour des mises à jour gracieuses et des vidanges rapides.
-
Vous pouvez mettre à jour les nœuds de calcul en parallèle en définissant le champ
maxUnavailablesur une valeur supérieure à1dans le pool de configuration de la machine (MCP). Le MCO met en cordon le nombre de nœuds spécifié dansmaxUnavailableet les marque comme indisponibles pour la mise à jour. -
Lorsque vous augmentez
maxUnavailablesur le MCP, cela peut aider le pool à se mettre à jour plus rapidement. Toutefois, simaxUnavailableest trop élevé et que plusieurs nœuds sont bloqués simultanément, les charges de travail protégées par le budget de perturbation des pods (PDB) risquent de ne pas s'écouler car aucun nœud planifiable ne peut être trouvé pour exécuter les répliques. Si vous augmentezmaxUnavailablepour le MCP, assurez-vous que vous disposez toujours d'un nombre suffisant de nœuds ordonnançables pour permettre aux charges de travail protégées par PDB de s'écouler. Avant de commencer la mise à jour, vous devez vous assurer que tous les nœuds sont disponibles. Tout nœud indisponible peut avoir un impact significatif sur la durée de la mise à jour, car l'indisponibilité du nœud affecte les budgets d'interruption de
maxUnavailableet de pod.Pour vérifier l'état des nœuds à partir du terminal, exécutez la commande suivante :
$ oc get node
Example Output
NAME STATUS ROLES AGE VERSION ip-10-0-137-31.us-east-2.compute.internal Ready,SchedulingDisabled worker 12d v1.23.5+3afdacb ip-10-0-151-208.us-east-2.compute.internal Ready master 12d v1.23.5+3afdacb ip-10-0-176-138.us-east-2.compute.internal Ready master 12d v1.23.5+3afdacb ip-10-0-183-194.us-east-2.compute.internal Ready worker 12d v1.23.5+3afdacb ip-10-0-204-102.us-east-2.compute.internal Ready master 12d v1.23.5+3afdacb ip-10-0-207-224.us-east-2.compute.internal Ready worker 12d v1.23.5+3afdacb
Si l'état du nœud est
NotReadyouSchedulingDisabled, le nœud n'est pas disponible, ce qui a une incidence sur la durée de la mise à jour.Vous pouvez vérifier l'état des nœuds à partir de la perspective Administrator dans la console web en développant Compute
Node.
Ressources supplémentaires
