Chapitre 10. Effectuer une mise à jour du déploiement du canari
Dans certains cas, vous pouvez souhaiter un déploiement plus contrôlé d'une mise à jour vers les nœuds de travail afin de garantir que les applications stratégiques restent disponibles pendant toute la durée de la mise à jour, même si le processus de mise à jour entraîne une défaillance de vos applications. En fonction des besoins de votre organisation, vous pouvez mettre à jour un petit sous-ensemble de nœuds de travail, évaluer la santé du cluster et de la charge de travail pendant un certain temps, puis mettre à jour les nœuds restants. C'est ce que l'on appelle communément une mise à jour canary. Il se peut également que vous souhaitiez intégrer les mises à jour des nœuds de travail, qui nécessitent souvent un redémarrage de l'hôte, dans des fenêtres de maintenance définies plus petites, lorsqu'il n'est pas possible de prendre une grande fenêtre de maintenance pour mettre à jour l'ensemble de la grappe en une seule fois.
Dans ce cas, vous pouvez créer plusieurs pools de configuration de machines (MCP) personnalisés afin d'empêcher la mise à jour de certains nœuds de travail lors de la mise à jour de la grappe. Une fois le reste de la grappe mis à jour, vous pouvez mettre à jour ces nœuds de travail par lots au moment opportun.
Par exemple, si vous avez un cluster de 100 nœuds avec une capacité excédentaire de 10, des fenêtres de maintenance qui ne doivent pas dépasser 4 heures, et que vous savez qu'il ne faut pas plus de 8 minutes pour drainer et redémarrer un nœud de travail, vous pouvez utiliser les MCP pour atteindre vos objectifs. Par exemple, vous pouvez définir quatre MCP, nommés workerpool-canary, workerpool-A, workerpool-B et workerpool-C, avec respectivement 10, 30, 30 et 30 nœuds.
Au cours de votre première fenêtre de maintenance, vous devez mettre en pause le MCP pour workerpool-A, workerpool-B, et workerpool-C, puis lancer la mise à jour du cluster. Cela met à jour les composants qui s'exécutent au-dessus d'OpenShift Container Platform et les 10 nœuds qui sont membres du MCP workerpool-canary, car ce pool n'a pas été mis en pause. Les trois autres MCP ne sont pas mis à jour, car ils étaient en pause. Si, pour une raison quelconque, vous déterminez que la santé de votre cluster ou de votre charge de travail a été affectée négativement par la mise à jour de workerpool-canary, vous devez alors boucler et drainer tous les nœuds de ce pool tout en maintenant une capacité suffisante jusqu'à ce que vous ayez diagnostiqué le problème. Lorsque tout fonctionne comme prévu, vous évaluez la santé du cluster et de la charge de travail avant de décider de remettre en pause, et donc de mettre à jour, workerpool-A, workerpool-B, et workerpool-C successivement au cours de chaque fenêtre de maintenance supplémentaire.
Bien que la gestion des mises à jour des nœuds ouvriers à l'aide de MCP personnalisés offre une certaine souplesse, elle peut s'avérer fastidieuse 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 les besoins de votre organisation et de planifier soigneusement la mise en œuvre du processus avant de commencer.
Il n'est pas recommandé de mettre à jour les MCP vers différentes versions d'OpenShift Container Platform. Par exemple, ne mettez pas à jour un MCP de 4.y.10 à 4.y.11 et un autre à 4.y.12. Ce scénario n'a pas été testé et pourrait entraîner un état indéfini du cluster.
La mise en pause d'un pool de configuration machine empêche l'opérateur de configuration 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 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 MCO ne peut pas pousser les certificats nouvellement renouvelés vers ces nœuds. 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 Alerting 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.
10.1. À propos du processus de mise à jour du déploiement du canari et des PCM
Dans OpenShift Container Platform, les nœuds ne sont pas considérés individuellement. Les nœuds sont regroupés en pools de configuration de machines (MCP). Il y a deux MCP dans un cluster OpenShift Container Platform par défaut : un pour les nœuds du plan de contrôle et un pour les nœuds de travail. Une mise à jour d'OpenShift Container Platform affecte tous les MCPs simultanément.
Pendant la mise à jour, l'opérateur de configuration de la machine (MCO) draine et cordonne tous les nœuds d'un MCP jusqu'au nombre de nœuds spécifié sur maxUnavailable (s'il est spécifié), par défaut 1. La vidange et le cordonage d'un nœud déschedule tous les pods sur le nœud et marque le nœud comme inschedulable. Une fois le nœud vidé, le Machine Config Daemon applique une nouvelle configuration de machine, qui peut inclure la mise à jour du système d'exploitation (OS). La mise à jour du système d'exploitation nécessite le redémarrage de l'hôte.
Pour empêcher la mise à jour de nœuds spécifiques et, par conséquent, leur vidange, leur cordon et leur mise à jour, vous pouvez créer des MCP personnalisés. Ensuite, mettez ces MCP en pause pour vous assurer que les nœuds associés à ces MCP ne sont pas mis à jour. Le MCO ne met pas à jour les MCP mis en pause. Vous pouvez créer un ou plusieurs MCP personnalisés, ce qui vous permet de mieux contrôler l'ordre dans lequel vous mettez à jour ces nœuds. Après avoir mis à jour les nœuds du premier MCP, vous pouvez vérifier la compatibilité de l'application, puis mettre à jour progressivement les autres nœuds vers la nouvelle version.
Pour garantir la stabilité du plan de contrôle, la création d'un MCP personnalisé à partir des nœuds du plan de contrôle n'est pas prise en charge. L'opérateur de configuration de la machine (MCO) ignore tout MCP personnalisé créé pour les nœuds du plan de contrôle.
Vous devez bien réfléchir au nombre de MCP que vous créez et au nombre de nœuds dans chaque MCP, en fonction de la topologie de déploiement de votre charge de travail. Par exemple, si vous devez intégrer des mises à jour dans des fenêtres de maintenance spécifiques, vous devez savoir combien de nœuds OpenShift Container Platform peut mettre à jour dans une fenêtre. Ce nombre dépend des caractéristiques uniques de votre cluster et de votre charge de travail.
Vous devez également tenir compte de la capacité supplémentaire dont vous disposez dans votre cluster. Par exemple, si vos applications ne fonctionnent pas comme prévu sur les nœuds mis à jour, vous pouvez boucler et drainer ces nœuds dans le pool, ce qui déplace les pods d'application vers d'autres nœuds. Vous devez tenir compte de la capacité supplémentaire dont vous disposez pour déterminer le nombre de MCP personnalisés dont vous avez besoin et le nombre de nœuds dans chaque MCP. Par exemple, si vous utilisez deux MCP personnalisés et que 50 % de vos nœuds se trouvent dans chaque pool, vous devez déterminer si l'exécution de 50 % de vos nœuds offre une qualité de service (QoS) suffisante pour vos applications.
Vous pouvez utiliser ce processus de mise à jour avec tous les processus de mise à jour documentés d'OpenShift Container Platform. Cependant, le processus ne fonctionne pas avec les machines Red Hat Enterprise Linux (RHEL), qui sont mises à jour à l'aide des playbooks Ansible.
