8.2. Effectuer une mise à jour du déploiement du canari
Dans certains cas d'utilisation spécifiques, vous pouvez souhaiter un processus de mise à jour plus contrôlé où vous ne souhaitez pas que des nœuds spécifiques soient mis à jour en même temps que le reste de la grappe. Ces cas d'utilisation incluent, mais ne sont pas limités à :
- Vous avez des applications critiques que vous ne voulez pas voir indisponibles pendant la mise à jour. Vous pouvez tester lentement les applications sur vos nœuds par petits lots après la mise à jour.
- Vous avez une petite fenêtre de maintenance qui ne laisse pas le temps à tous les nœuds d'être mis à jour, ou vous avez plusieurs fenêtres de maintenance.
Le processus de mise à jour en continu est not un flux de travail de mise à jour typique. Dans le cas de clusters plus importants, ce processus peut prendre beaucoup de temps et nécessiter l'exécution de plusieurs commandes. Cette complexité peut entraîner des erreurs susceptibles d'affecter l'ensemble du cluster. Il est recommandé d'examiner attentivement si votre organisation souhaite utiliser une mise à jour glissante et de planifier soigneusement la mise en œuvre du processus avant de commencer.
Le processus de mise à jour en continu décrit dans cette rubrique implique :
- Création d'un ou plusieurs pools de configuration de machines (MCP) personnalisés.
- Étiqueter chaque nœud que vous ne voulez pas mettre à jour immédiatement pour déplacer ces nœuds vers les MCP personnalisés.
- Mise en pause de ces MCP personnalisés, ce qui empêche les mises à jour de ces nœuds.
- Effectuer la mise à jour du cluster.
- Désactiver un MCP personnalisé, ce qui déclenche la mise à jour de ces nœuds.
- Tester les applications sur ces nœuds pour s'assurer qu'elles fonctionnent comme prévu sur ces nœuds nouvellement mis à jour.
- Éventuellement, retirer les étiquettes personnalisées des nœuds restants par petits lots et tester les applications sur ces nœuds.
La mise en pause d'un MCP empêche l'opérateur de configuration de la machine d'appliquer des modifications de configuration sur les nœuds associés. La mise en pause d'un MCP empêche également la transmission aux nœuds associés de tout certificat ayant fait l'objet d'une rotation automatique, y compris la rotation automatique du certificat de l'autorité de certification kube-apiserver-to-kubelet-signer
.
Si le MCP est mis en pause lorsque le certificat de l'autorité de certification kube-apiserver-to-kubelet-signer
expire et que le MCO tente de renouveler automatiquement le certificat, le nouveau certificat est créé mais n'est pas appliqué aux nœuds dans le pool de configuration de la machine concernée. Cela entraîne l'échec de plusieurs commandes oc
, notamment oc debug
, oc logs
, oc exec
, et oc attach
. Vous recevez des alertes dans l'interface utilisateur d'alerte de la console Web d'OpenShift Container Platform si un MCP est mis en pause lors de la rotation des certificats.
La mise en pause d'un MCP doit être effectuée en tenant compte de l'expiration du certificat de l'autorité de certification kube-apiserver-to-kubelet-signer
et uniquement pour de courtes périodes.
Si vous souhaitez utiliser le processus de mise à jour par déploiement canarien, voir Exécution d'une mise à jour par déploiement canarien.