Mise à jour des clusters, des noeuds worker et des composants de cluster

Passez en revue les sections suivantes pour connaître les étapes de mise à jour du maître cluster et des noeuds worker.

Mise à jour du maître

Comment savoir quand mettre à jour le master?: Vous êtes averti dans la console, les annonces et l'interface de ligne de commande lorsque des mises à jour sont disponibles. Vous pouvez également consulter régulièrement la page des versions prises en charge.
De combien de versions le maître peut-il être en retard par rapport à la dernière?: Vous ne pouvez mettre à jour le serveur API qu'avec la version qui précède sa version actuelle (n+1).
Mes nœuds de travail peuvent-ils exécuter une version plus récente que la version principale?: Vos nœuds worker ne peuvent pas exécuter une version de major.minor Kubernetes postérieure à celle du maître. En outre, vos noeuds de travail ne peuvent être qu'une seule version derrière la version maître (n-1). Tout d'abord, Mettre à jour votre maître à la dernière version de Kubernetes. Ensuite, mettez à jour les noeuds worker dans votre cluster.

Les noeuds worker peuvent exécuter des versions de correctif ultérieures à celle du maître, par exemple des versions de correctif spécifiques aux noeuds worker pour les mises à jour de sécurité.

Comment les mises à jour des correctifs sont-elles appliquées?: Par défaut, les correctifs du maître sont appliqués automatiquement sur plusieurs jours, de sorte que la version d'un correctif de maître s'affiche comme étant disponible avant d'être appliquée à votre maître. L'automatisation de la mise à jour ignore également les clusters qui ne sont pas dans un état sain ou dont les opérations sont encore en cours d'exécution. Occasionnellement, IBM peut désactiver les mises à jour automatiques pour un groupe de correctifs de maître spécifique, par exemple un correctif nécessaire uniquement si un maître est mis à jour d'une version secondaire à une autre. Dans tous ces cas, vous pouvez vérifier les informations relatives à la version de Red Hat OpenShift on IBM Cloud pour vous assurer qu'il n'y a pas d'impact potentiel et choisir d'utiliser vous-même la commande ibmcloud oc cluster master update en toute sécurité sans attendre que l'automatisation de la mise à jour s'applique.

Contrairement au maître, vous devez mettre à jour vos noeuds worker pour chaque version de correctif.

Que se passe-t-il lors de la mise à jour du master?: La haute disponibilité de votre maître est assurée par trois pods avec des répliques du maître. Les pods de maître ont des mises à jour en continu, au cours desquelles un seul pod à la fois est indisponible. Deux instances sont opérationnelles pour que vous puissiez accéder au cluster et le modifier lors de la mise à jour. Vos noeuds worker, applications et ressources continuent à s'exécuter.
Puis-je annuler la mise à jour?: Non, vous ne pouvez pas rétrogradez un cluster à une version précédente une fois que le processus de mise à jour a eu lieu. Prenez soin d'utiliser un cluster de test et de suivre les instructions afin d'éviter des problèmes potentiels avant de mettre à jour votre maître en production.
Quelle est la procédure à suivre pour mettre à jour le master?: Le diagramme suivant illustre la procédure que vous pouvez suivre pour mettre à jour le maître.

du processus de mise à jour du

du processus de mise à jour du Kubernetes

Procédure de mise à jour du maître cluster

Avant de commencer, assurez-vous que vous avez le rôle d'accès à la plateforme IAM Opérateur ou Administrateur.

Pour mettre à jour la version maître Red Hat OpenShift_majeure_ ou mineure version :

Consultez les informations de version deRed Hat OpenShift on IBM Cloud et effectuez les mises à jour marquées Update before master.
Examinez les avertissements utiles sur le site Kubernetes, tels que les avis de dépréciation.
Vérifiez pour les modules complémentaires et les plug-in installés dans votre cluster l'impact que pourrait avoir une mise à jour de la version du cluster.
- Vérification des modules complémentaires
  1. Répertoriez les modules complémentaires dans le cluster.
```
ibmcloud oc cluster addon ls --cluster CLUSTER
```
  2. Vérifiez la version de Red Hat OpenShift prise en charge pour chaque module complémentaire installé.
```
ibmcloud oc addon-versions
```
  3. Si le module complémentaire doit être mis à jour pour s'exécuter dans la version Red Hat OpenShift à laquelle vous souhaitez mettre à jour votre cluster, mettez à jour le module complémentaire.
- Vérification des plug-in
  1. Dans le catalogue Helm, recherchez les plug-ins que vous avez installés dans votre cluster.
  2. Dans le menu latéral, développez la section SOURCES & FICHIER TAR.
  3. Téléchargez et ouvrez le code source.
  4. Vérifiez dans les fichiers README.md ou RELEASENOTES.md les versions prises en charge.
  5. Si le plug-in doit être mis à jour pour s'exécuter dans la version Red Hat OpenShift à laquelle vous voulez mettre à jour votre cluster, mettez à jour le module complémentaire en suivants les instructions du plug-in.
Mettez à jour votre serveur API et les composants maîtres associés en utilisant la console IBM Cloud ou en exécutant la commande CLI ibmcloud oc cluster master update.
Patientez quelques minutes, puis confirmez que la mise à jour est terminée. Examinez la version du serveur d'API sur le tableau de bord Clusters d'IBM Cloud ou exécutez la commande ibmcloud oc cluster ls.
Installez la version deoc cli qui correspond à la version du serveur d'API qui s'exécute dans le maître. Kubernetes ne prend pas en charge oc les versions du client qui sont éloignées de deux versions ou plus de la version du serveur (n +/- 2).

Une fois la mise à jour du maître terminée, vous pouvez mettre à jour vos noeuds worker, en fonction du type de fournisseur d'infrastructure de cluster dont vous disposez.

Mise à jour des noeuds worker classiques.
Mise à jour des noeuds worker de VPC.

Mise à jour des noeuds worker classiques

Vous constatez qu'une mise à jour est disponible pour vos noeuds worker dans un cluster d'infrastructure classique. Qu'est-ce que cela signifie ? Comme les mises à jour de sécurité et les correctifs sont mis en place pour le serveur d'API et d'autres composants du maître, vous devez vérifier que les noeuds worker soient toujours synchronisés. Vous pouvez effectuer deux types de mise à jour : mise à jour uniquement de la version de correctif ou mise à jour de la version major.minor avec la version de correctif.

Correctif : une mise à jour de correctif de noeud worker inclut des correctifs de sécurité. Vous pouvez mettre à jour le noeud worker classique vers le dernier correctif à l'aide de la commande ibmcloud oc worker reload ou des commandes update. N'oubliez pas que la commande update met également à jour le noeud worker vers la même version major.minor que le noeud maître et la dernière version de correctif, si une mise à jour de version major.minor est également disponible.
Major.minor : une mise à jour major.minor déplace la version Kubernetes du noeud worker vers la même version que le maître. Ce type de mise à jour inclut souvent des modifications de l'API Kubernetes ou d'autres comportements pour lesquels vous devez préparer votre cluster. N'oubliez pas que vos nœuds de travail ne peuvent être qu'une seule version derrière la version maître (n-1). Vous pouvez mettre à jour le noeud de travail classique sur le même correctif à l'aide de la commande ibmcloud oc worker update.

Pour plus d'informations, voir Types de mise à jour.

Qu'advient-il de mes applications lors d'une mise à jour?: Si vous exécutez des applications dans le cadre d'un déploiement sur des noeuds worker faisant l'objet d'une mise à jour, les applications sont replanifiées sur d'autres noeuds worker dans le cluster. Ces noeuds worker peuvent se trouver dans des pools de noeuds worker différents ou, si vous disposez de noeuds worker autonomes, les applications peuvent être planifiées sur ces noeuds. Pour éviter toute interruption d'application, vous devez veiller à ce que le cluster dispose d'une capacité suffisante pour traiter la charge de travail.
Comment puis-je contrôler le nombre de nœuds de travail qui tombent en panne à la fois lors d'une mise à jour ou d'un rechargement?: Si vous avez besoin que tous vos noeuds worker soient opérationnels, envisagez de redimensionner votre pool de noeuds worker ou d'ajouter des noeuds worker autonomes pour ajouter des noeuds worker supplémentaires. Vous pourrez supprimer ces noeuds supplémentaires une fois la mise à jour terminée.

En outre, vous pouvez créer une carte de configuration Kubernetes qui spécifie le nombre maximum de nœuds de travail qui peuvent être indisponibles à un moment donné, par exemple lors d'une mise à jour. Les noeuds worker sont identifiés par leur libellé. Vous pouvez utiliser les libellés fournis par IBM ou des libellés personnalisés que vous avez ajoutés au noeud worker.

Les règles de mappe de configuration Kubernetes sont utilisées pour la mise à jour des noeuds worker uniquement. Ces règles n'ont pas d'impact sur les rechargements de noeud worker, ce qui signifie que le rechargement a lieu immédiatement à la demande.

Que se passe-t-il si je décide de ne pas définir de carte de configuration?: Lorsque la mappe de configuration n'est pas définie, la valeur par défaut est utilisée. Par défaut, un maximum de 20% de tous vos nœuds de travail dans chaque cluster ne peuvent pas être disponibles pendant le processus de mise à jour.

Prérequis

Avant de mettre à jour vos noeuds worker d'infrastructure classique, consultez les étapes prérequises.

Les mises à jour des noeuds worker peuvent provoquer l'indisponibilité de vos services et applications. La machine de votre noeud worker est réimagée et les données sont supprimées si elles ne sont pas stockées hors du pod.

Pour obtenir les correctifs et correctifs de sécurité les plus récents, assurez-vous de mettre à jour vos noeuds worker vers le dernier correctif dès sa mise à disposition. Pour plus d'informations sur les dernières mises à jour, consultez les informations de version deRed Hat OpenShift on IBM Cloud.
Accédez à votre cluster Red Hat OpenShift.
Mettez à jour le maître. La version du nœud worker ne peut pas être postérieure à la version du serveur d'API qui s'exécute dans votre maître Kubernetes.
Effectuez les modifications signalées par Mise à jour après le maître dans le fichier Guide de préparation de version Red Hat OpenShift.
Si vous souhaitez appliquer une mise à jour du correctif, consultez les informations relatives à la version du site Red Hat OpenShift on IBM Cloud.
Envisagez d'ajouter des nœuds de travail supplémentaires afin que votre cluster dispose d'une capacité suffisante pour reprogrammer vos charges de travail pendant la mise à jour. Pour plus d'informations, voir Ajout de noeuds worker à des clusters classiques ou Ajout de noeuds worker à des clusters de VPC.
Assurez-vous que vous avez le rôle d'accès à la plateforme IAM Opérateur ou Administrateur.

Mise à jour des noeuds worker classiques dans l'interface CLI

Configurez une mappe de configuration afin d'effectuer une mise à jour en continu de vos noeuds worker classiques.

Effectuez les étapes prérequises.
Affichez la liste des noeuds worker disponibles et notez leur adresse IP privée.
```
ibmcloud oc worker ls --cluster CLUSTER
```

Affichez les libellés d'un noeud worker. Vous pouvez identifier les libellés des noeuds worker dans la section Labels de la sortie de l'interface CLI. Chaque libellé est constitué de deux éléments NodeSelectorKey et NodeSelectorValue.

oc describe node PRIVATE-WORKER-IP

Exemple de sortie

NAME:               10.184.58.3
Roles:              <none>
Labels:             arch=amd64
                beta.kubernetes.io/arch=amd64
                beta.kubernetes.io/os=linux
                failure-domain.beta.kubernetes.io/region=us-south
                failure-domain.beta.kubernetes.io/zone=dal12
                ibm-cloud.kubernetes.io/encrypted-docker-data=true
                ibm-cloud.kubernetes.io/iaas-provider=softlayer
                ibm-cloud.kubernetes.io/machine-type=u3c.2x4.encrypted
                kubernetes.io/hostname=10.123.45.3
                privateVLAN=2299001
                publicVLAN=2299012
Annotations:        node.alpha.kubernetes.io/ttl=0
                volumes.kubernetes.io/controller-managed-attach-detach=true
CreationTimestamp:  Tue, 03 Apr 2022 15:26:17 -0400
Taints:             <none>
Unschedulable:      false

Créez une mappe de configuration et définissez les règles d'indisponibilité applicables à vos noeuds worker. L'exemple suivant présente quatre vérifications, zonecheck.json, regioncheck.json, defaultcheck.json, et un modèle de vérification. Vous pouvez utiliser ces exemples de contrôle pour définir des règles pour les nœuds de travail dans une zone spécifique (zonecheck.json), une région (regioncheck.json) ou pour tous les nœuds de travail qui ne correspondent à aucune des vérifications que vous avez définies dans la mappe de configuration (defaultcheck.json). Utilisez le modèle de contrôle pour créer votre propre contrôle. Pour chaque vérification, vous devez choisir un des libellés de noeud worker obtenus à l'étape précédente pour identifier un noeud worker.

Pour chaque vérification, vous ne pouvez définir qu'une seule valeur pour NodeSelectorKey et NodeSelectorValue. Si vous souhaitez définir des règles pour plusieurs régions, zones ou d'autres libellés de noeud worker, créez une nouvelle vérification. Définir jusqu'à 15 contrôles dans une carte de configuration. Si vous ajoutez des vérifications supplémentaires, un seul noeud worker est rechargé à la fois jusqu'à ce que tous les noeuds worker demandés soient mis à jour.

Exemple
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: ibm-cluster-update-configuration
  namespace: kube-system
data:
  drain_timeout_seconds: "120"
  zonecheck.json: |
    {
      "MaxUnavailablePercentage": 30,
      "NodeSelectorKey": "failure-domain.beta.kubernetes.io/zone",
      "NodeSelectorValue": "dal13"
    }
  regioncheck.json: |
    {
      "MaxUnavailablePercentage": 20,
      "NodeSelectorKey": "failure-domain.beta.kubernetes.io/region",
      "NodeSelectorValue": "us-south"
    }
  defaultcheck.json: |
    {
      "MaxUnavailablePercentage": 20
    }
  <check_name>: |
    {
      "MaxUnavailablePercentage": <value_in_percentage>,
      "NodeSelectorKey": "<node_selector_key>",
      "NodeSelectorValue": "<node_selector_value>"
    }
```
drain_timeout_seconds

Facultatif : Le délai d'attente en secondes pour la fin de la vidange. L'arrêt avec drain d'un noeud worker en toute sécurité supprime tous les pods existants du noeuds worker et replanifie les pods sur d'autres noeuds worker du cluster. Les valeurs admises sont des entiers compris entre 1 et 180. La valeur par défaut est 30.

zonecheck.json et regioncheck.json

Deux vérifications qui définissent une règle pour un ensemble de nœuds de travail que vous pouvez identifier avec les NodeSelectorKey et NodeSelectorValuespécifiés. zonecheck.json identifie les nœuds de travail en fonction de leur libellé de zone, et regioncheck.json utilise le libellé de région ajouté à chaque noeud de travail lors de l'application des accès. Dans l'exemple, 30% de tous les nœuds de travail ayant dal13 comme étiquette de zone et 20% de tous les nœuds de travail dans us-south peuvent être indisponibles lors de la mise à jour.

defaultcheck.json

Si vous ne créez pas de mappe de configuration ou si la mappe n'est pas configurée correctement, la valeur par défaut de Kubernetes est appliquée. Par défaut, seuls 20 % des noeuds worker du cluster peuvent être indisponibles à moment donné. Vous pouvez remplacer la valeur par défaut en ajoutant la vérification par défaut dans votre mappe de configuration. Dans l'exemple, chaque noeud de travail qui n'est pas spécifié dans les vérifications de zone et de région (dal13 ou us-south) peut être indisponible pendant la mise à jour.

MaxUnavailablePercentage

Nombre maximal de noeuds pouvant être indisponibles pour un libellé clé-valeur spécifique, exprimé en pourcentage. Un noeud worker est indisponible lorsqu'il est en cours de déploiement, de rechargement ou de mise à disposition. Les noeuds worker en file d'attente sont bloqués pour la mise à jour s'ils dépassent un pourcentage maximum de noeuds indisponibles défini.

NodeSelectorKey

Clé de libellé du noeud worker pour lequel vous voulez définir une règle. Vous pouvez définir des règles pour les libellés par défaut fournis par IBM, ainsi que sur les libellés de noeuds worker que vous avez créés. Si vous souhaitez ajouter une règle pour les noeuds de travail appartenant à un pool de travailleurs, vous pouvez utiliser l'étiquette ibm-cloud.kubernetes.io/machine-type.

NodeSelectorValue

Valeur de libellé que doit avoir le noeud worker pour être pris en compte dans la règle que vous définissez.
Créez la mappe de configuration dans votre cluster.
```
oc apply -f <filepath/configmap.yaml>
```
Vérifiez que la mappe de configuration est créée.
```
oc get configmap --namespace kube-system
```

Mettez à jour les noeuds worker.

ibmcloud oc worker update --cluster CLUSTER --worker WORKER-NODE-1-ID --worker WORKER-NODE-2-ID

Facultatif : vérifiez les événements déclenchés par la mappe de configuration et les éventuelles erreurs de validation. Les événements peuvent être consultés dans la section Evénements de la sortie de l'interface CLI.
```
oc describe -n kube-system cm ibm-cluster-update-configuration
```
Confirmez que la mise à jour est terminée en examinant la version Kubernetes de vos noeuds worker.
```
oc get nodes
```
Vérifiez que vous n'avez pas de nœuds de travail en double. Parfois, les clusters plus anciens peuvent répertorier les noeuds de travail en double avec un statut NotReady après une mise à jour. Pour supprimer ces doublons, voir la section de traitement des incidents.

Etapes suivantes :

Répétez le processus de mise à jour pour les autres pools de noeuds worker.
Informez les développeurs qui travaillent dans le cluster qu'ils doivent mettre à jour leur interface CLI oc vers la version du maître Kubernetes.
Si le tableau de bord Kubernetes n'affiche pas les graphiques d'utilisation, supprimez le pod kube-dashboard.

Mise à jour des noeuds worker classiques dans la console

Après avoir configuré la mappe de configuration pour la première fois, vous pouvez effectuer la mise à jour des noeuds worker en utilisant la console IBM Cloud.

Pour mettre à jour les noeuds worker à partir de la console :

Effectuez les étapes prérequises et configurez une mappe de configuration afin de contrôler le mode de mise à jour de vos noeuds worker.
Dans le menu de la console IBM Cloud , cliquez sur Conteneurs > Clusters.
Sur la page Clusters, cliquez sur votre cluster.
Dans l'onglet Noeuds worker, sélectionnez la case à cocher de chaque noeud worker que vous désirez mettre à jour. Une barre d'actions s'affiche sur la ligne d'en-tête du tableau.
Dans la barre de menus, cliquez sur Mettre à jour.

Si Portworx est installé dans votre cluster, vous devez redémarrer les pods Portworx sur les noeuds worker mis à jour. Pour plus d'informations, voir les Limitations de Portworx.

Mise à jour des noeuds worker de VPC

Vous remarquez qu'une mise à jour est disponible pour vos nœuds de travail dans un cluster VPC. Qu'est-ce que cela signifie ? Comme les mises à jour de sécurité et les correctifs sont mis en place pour le serveur d'API et d'autres composants du maître, vous devez vérifier que les noeuds worker soient toujours synchronisés. Vous pouvez effectuer deux types de mise à jour : mise à jour uniquement de la version de correctif ou mise à jour de la version major.minor avec la version de correctif.

Si Portworx est déployé dans votre cluster, suivez les étapes vers Mettre à jour les noeuds de travail VPC avec les volumes Portworx.

Si OpenShift Data Foundation est déployé dans votre cluster, suivez ces étapes pour mettre à jour les nœuds worker VPC avec OpenShift Data Foundation.

Correctif : une mise à jour de correctif de noeud worker inclut des correctifs de sécurité. Vous pouvez mettre à jour le noeud worker de VPC vers le dernier correctif à l'aide de la commande ibmcloud oc worker replace.
Major.minor : une mise à jour major.minor déplace la version Kubernetes du noeud worker vers la même version que le maître. Ce type de mise à jour inclut souvent des modifications de l'API Kubernetes ou d'autres comportements pour lesquels vous devez préparer votre cluster. N'oubliez pas que vos nœuds de travail ne peuvent avoir qu'une version de retard par rapport à la version principale (n-1). Vous pouvez mettre à jour le nœud de travail du VPC avec le même correctif en utilisant la commande ibmcloud oc worker replace avec l'option --update.

Qu'advient-il de mes applications lors d'une mise à jour?: Si vous exécutez des applications dans le cadre d'un déploiement sur des noeuds worker faisant l'objet d'une mise à jour, les applications sont replanifiées sur d'autres noeuds worker dans le cluster. Ces noeuds worker peuvent se trouver dans des pools de noeuds worker différents. Pour éviter les temps d'arrêt de votre application, vous devez vous assurer que vous disposez d'une capacité suffisante dans le cluster pour supporter la charge de travail, par exemple en redimensionnant vos pools de travailleurs. Pour plus d'informations, voir Ajout de noeuds worker à des clusters classiques ou Ajout de noeuds worker à des clusters de VPC.
Que se passe-t-il pour mon nœud de travail lors d'une mise à jour?: Votre noeud worker de VPC est remplacé en retirant l'ancien noeud worker et en mettant à disposition un nouveau noeud worker qui s'exécute au niveau du correctif mis à jour ou de la version major.minor. Le noeud worker de remplacement est créé dans la même zone, dans le même pool de noeuds worker et avec la même version que le noeud worker supprimé. Cependant, une nouvelle adresse IP privée est affectée au noeud worker de remplacement qui perd alors les libellés ou les taches personnalisés que vous avez appliqués au précédent. En revanche, les taches et les libellés d'origine du pool de noeuds worker sont toujours appliqués au noeud worker de remplacement.
Que se passe-t-il si je remplace plusieurs nœuds de travail en même temps?: Si vous remplacez plusieurs noeuds worker en même temps, ils sont supprimés et remplacés simultanément, et non un par un. Vérifiez que vous disposez de suffisamment de capacité dans votre cluster pour replanifier vos charges de travail avant de remplacer des noeuds worker.
Que se passe-t-il si un nœud de travailleurs de remplacement n'est pas créé?: Un noeud worker de remplacement n'est pas créé si la fonction de rééquilibrage automatique n'est pas activée pour le pool de noeuds worker.

Prérequis

Avant de mettre à jour vos noeuds worker d'infrastructure VPC, consultez les étapes prérequises.

Les mises à jour des noeuds worker peuvent provoquer l'indisponibilité de vos services et applications. La machine de votre noeud worker est retirée et les données sont supprimées si elles ne sont pas stockées hors du pod.

Pour obtenir les correctifs et correctifs de sécurité les plus récents, assurez-vous de mettre à jour vos noeuds worker vers le dernier correctif dès sa mise à disposition. Pour plus d'informations sur les dernières mises à jour, consultez les informations de version deRed Hat OpenShift on IBM Cloud.
Accédez à votre cluster Red Hat OpenShift.
Mettez à jour le maître. La version du nœud worker ne peut pas être postérieure à la version du serveur d'API qui s'exécute dans votre maître Kubernetes.
Effectuez les modifications signalées par Mise à jour après le maître dans le fichier Guide de préparation de version Red Hat OpenShift.
Si vous souhaitez appliquer une mise à jour du correctif, consultez les informations relatives à la version du site Red Hat OpenShift on IBM Cloud.
Assurez-vous que vous avez le rôle d'accès à la plateforme IAM Opérateur ou Administrateur.

Mise à jour des noeuds worker de VPC dans l'interface CLI

Effectuez les étapes suivantes pour mettre à jour vos nœuds de travail à l'aide de l'interface de ligne de commande.

Effectuez les étapes prérequises.
Facultatif : Augmentez la capacité de votre cluster en redimensionnant le pool de travailleurs. Les pods sur le noeud worker peuvent être replanifiés et continuent d'être exécutés sur les noeuds worker ajoutés lors de la mise à jour. Pour plus d'informations, voir Ajout de noeuds worker à des clusters classiques ou Ajout de noeuds worker à des clusters de VPC.
Répertoriez les noeuds worker de votre cluster et notez l'ID et l'adresse IP principale du noeud worker que vous souhaitez mettre à jour.
```
ibmcloud oc worker ls --cluster CLUSTER
```
Remplacez le noeud worker pour mettre à jour la version de correctif ou la version major.minor qui correspond à la version de maître.
- Pour mettre à jour le nœud de travail avec la même version de major.minor que le nœud principal, il faut inclure l'option --update.
```
ibmcloud oc worker replace --cluster CLUSTER --worker WORKER-NODE-ID --update
```
- Pour mettre à jour le nœud de travail avec la dernière version du correctif à la même version de major.minor, n'incluez pas l'option --update.
```
ibmcloud oc worker replace --cluster CLUSTER --worker WORKER-NODE-ID
```
Répétez ces étapes pour chaque noeud worker que vous devez mettre à jour.
Facultatif : Une fois que les nœuds de travail remplacés ont atteint l'état Prêt, redimensionnez le pool de travailleurs pour atteindre la capacité de cluster souhaitée. Pour plus d'informations, Ajout de noeuds worker à des clusters de VPC.

Si vous exécutez Portworx dans votre cluster de VPC, vous devez connecter manuellement votre volume Block Storage for VPC à votre nouveau noeud worker.

Mise à jour des noeuds worker de VPC dans la console

Vous pouvez mettre à jour vos noeuds worker de VPC dans la console. Avant de commencer, pensez à ajouter des nœuds de travail au cluster afin d'éviter les temps d'arrêt de vos applications.

Effectuez les étapes prérequises.
Dans le menu de la console IBM Cloud , cliquez sur Conteneurs > Clusters.
Sur la page Clusters, cliquez sur votre cluster.
Dans l'onglet Noeuds worker, sélectionnez la case à cocher de chaque noeud worker que vous désirez mettre à jour. Une barre d'actions s'affiche sur la ligne d'en-tête du tableau.
Dans la barre de menus, cliquez sur Mettre à jour.

Mise à jour des versions (types de machine)

Avant de commencer :

Accédez à votre cluster Red Hat OpenShift.
Les données sur le noeud worker sont supprimées. Envisagez de stocker vos données sur un stockage persistant en dehors du noeud worker.
Assurez-vous que vous avez le rôle d'accès à la plateforme IAM Opérateur ou Administrateur.

Pour mettre à jour les versions :

Affichez la liste des noeuds worker disponibles et notez leur adresse IP privée.
1. Affichez la liste des pools de noeuds worker disponibles dans votre cluster.
```
ibmcloud oc worker-pool ls --cluster CLUSTER
```
2. Affichez la liste des noeuds worker figurant dans le pool de noeuds worker. Notez les valeurs des zones ID et Adresse IP privée.
```
ibmcloud oc worker ls --cluster CLUSTER --worker-pool WORKER-POOL
```
3. Affichez les détails relatifs à votre noeud worker. Dans la sortie, notez la zone et l'ID du VLAN privé ou public pour les clusters classiques ou l'ID du sous-réseau pour les clusters de VPC.
```
ibmcloud oc worker get --cluster CLUSTER --worker WORKER-ID
```
Répertoriez les versions disponibles dans la zone.
```
ibmcloud oc flavors --zone <zone>
```
Créez un noeud worker avec le nouveau type de machine.
1. Créez un pool de noeuds worker avec le nombre de noeuds worker que vous désirez remplacer.
  - Clusters classiques :
```
ibmcloud oc worker-pool create classic --name WORKER-POOL --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE
```
  - Clusters VPC de génération 2 :
```
ibmcloud oc worker-pool create vpc-gen2 --name NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone NUMBER-OF-WORKERS-PER-ZONE --label LABEL
```
2. Vérifiez que le pool de noeuds worker est créé.
```
ibmcloud oc worker-pool ls --cluster CLUSTER
```
3. Ajoutez la zone de votre pool de noeuds worker que vous avez récupérée auparavant. Lorsque vous ajoutez une zone, les noeuds worker définis dans votre pool de noeuds worker sont mis à disposition dans cette zone et pris en compte pour la planification des charges de travail à venir. Si vous souhaitez répartir vos noeuds worker sur plusieurs zones, sélectionnez un emplacement multizone classique ou VPC.
  - Clusters classiques :
```
ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --private-vlan PRIVATE-VLAN-ID --public-vlan PUBLIC-VLAN-ID
```
  - Clusters VPC :
```
ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
```
Patientez jusqu'à la fin du déploiement des noeuds worker. Lorsque l'état des noeuds worker passe à Normal, le déploiement est terminé.
```
ibmcloud oc worker ls --cluster CLUSTER
```
Supprimez l'ancien noeud worker. Remarque : si vous retirez une version qui est facturée au mois (par exemple bare metal), vous êtes facturé pour le mois complet.
1. Supprimez le pool de noeuds worker associé à l'ancien type de machine. Cette opération retire tous les noeuds worker qui se trouvent dans le pool dans toutes les zones. L'exécution de ce processus peut prendre quelques minutes.
```
ibmcloud oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
```
2. Vérifiez que le pool de noeuds worker est supprimé.
```
ibmcloud oc worker-pool ls --cluster CLUSTER
```
Vérifiez que les noeuds worker ont été supprimés de votre cluster.
```
ibmcloud oc worker ls --cluster CLUSTER
```
Répétez ces étapes pour mettre à jour d'autres pools de noeuds worker ou d'autres noeuds worker autonomes vers différentes versions.

Comment les pools de noeuds worker sont-ils réduits?

Lorsque le nombre de noeuds worker dans un pool de noeuds worker est réduit, par exemple lors d'une mise à jour de noeud worker ou à l'aide de la commande ibmcloud oc worker-pool resize, les noeuds worker sont prioritaires pour la suppression en fonction de plusieurs propriétés, notamment l'état, la santé et la version.

Cette logique de priorité n'est pas pertinente pour le module complémentaire de mise à l'échelle automatique.

Le tableau suivant montre l'ordre dans lequel les noeuds worker sont prioritaires pour la suppression.

Vous pouvez exécuter la commande ibmcloud oc worker ls pour afficher toutes les propriétés de noeud worker répertoriées dans le tableau.

Priorité des noeuds worker supprimés lors de la réduction du pool de noeuds worker.
Priorité	Propriété	Description
1	Etat du noeud worker	Les noeuds worker dont l'état ne fonctionne pas ou qui ne fonctionnent pas correctement sont prioritaires pour le retrait. Cette liste affiche les états classés de la priorité la plus élevée à la priorité la plus faible: `provision_failed`, `deploy_failed`, `deleting`, `provision_pending`, `provisioning`, `deploying`, `provisioned`, `reloading_failed`, `reloading`, `deployed`.
2	Santé des nœuds worker	Les noeuds worker défaillants sont prioritaires par rapport aux noeuds worker en bonne santé. Cette liste affiche les états de santé classés de la priorité la plus élevée à la priorité la plus faible: `critical`, `warning`, `pending`, `unsupported`, `normal`.
3	Version du noeud worker	Les noeuds worker qui s'exécutent sur des versions plus anciennes ont une priorité de suppression plus élevée.
4	Cadre de placement choisi	Pour les noeuds worker exécutés sur un hôte dédié uniquement. Les noeuds worker qui s'exécutent sur un hôte dédié dont l'option `DesiredPlacementDisabled` est définie sur `true` ont une priorité plus élevée pour la suppression.
5	ordre alphabétique	Une fois les noeuds worker classés par ordre de priorité en fonction des facteurs répertoriés ci-dessus, ils sont supprimés par ordre alphabétique. Notez que, en fonction des conventions d'ID de noeud worker, les ID des noeuds worker sur les clusters classiques et VPC sont en corrélation avec l'âge, de sorte que les noeuds worker plus anciens sont supprimés en premier.

Mise à jour des composants de cluster

Votre cluster Red Hat OpenShift on IBM Cloud est livré avec des composants, par exemple, Ingress, qui s'installent automatiquement lorsque vous mettez à disposition le cluster. Par défaut, ces composants sont automatiquement mis à jour par IBM. Cependant, vous pouvez désactiver les mises à jour automatiques pour certains composants afin d'effectuer leur mise à jour manuellement indépendamment du maître et des noeuds worker.

Quels sont les composants par défaut que je peux mettre à jour séparément du cluster?

Vous pouvez éventuellement désactiver les mises à jour automatiques des composants suivants :

Fluentd pour la journalisation
Equilibreur de charge d'application (ALB) Ingress

Y a-t-il des composants que je ne peux pas mettre à jour séparément du cluster?

Oui. Votre cluster est déployé avec les composants gérés suivants et les ressources associées qui ne peuvent pas être changées, à l'exception des pods d'échelle ou des configmaps d'édition pour certains avantages de performances. Si vous essayez de modifier l'un de ces composants de déploiement, leurs paramètres d'origine sont restaurés à intervalles réguliers lorsqu'ils sont mis à jour avec le maître cluster. Toutefois, les ressources que vous créez qui sont associées à ces composants, telles que les règles réseau Calico que vous créez pour être implémentées par les composants de déploiement Calico, ne sont pas mises à jour.

calico composants
coredns composants
ibm-cloud-provider-ip
ibm-file-plugin
ibm-keepalived-watcher
ibm-master-proxy
ibm-storage-watcher
kubernetes-dashboard composants
metrics-server
Composants olm-operator et catalog (versions 1.16 et suivantes)
vpn

Puis-je installer d'autres plug-ins ou add-ons que les composants par défaut?: Oui. Red Hat OpenShift on IBM Cloud fournit d'autres plug-ins et modules complémentaires que vous pouvez choisir pour ajouter des fonctions à votre cluster. Par exemple, vous envisagerez peut-être d'utiliser les chartes Helm pour installer VPN strongSwan. Ou vous souhaiterez peut-être activer les modules complémentaires gérés par IBM dans votre cluster, par exemple, l'outil de débogage et de diagnostic. Vous devez mettre à jour ces chartes Helm et modules complémentaires séparément en suivant les instructions fournies dans les fichiers readme de la charte Helm ou en suivant les étapes de mise à jour des modules complémentaires gérés.

Gestion des mises à jour automatiques pour Fluentd

Lorsque vous créez une configuration de journalisation pour une source dans votre cluster pour l'acheminement vers un serveur externe, un composant Fluentd est créé dans le cluster. Pour modifier vos configurations de journalisation ou de filtre, le composant Fluentd doit être à la dernière version. Par défaut, les mises à jour automatiques du composant sont activées.

Vous pouvez gérer les mises à jour automatiques du composant Fluentd de plusieurs manières indiquées ci-après. Remarque: pour exécuter les commandes suivantes, vous devez avoir le rôle d' administrateur IBM Cloud IAM pour le cluster.

Vérifiez si les mises à jour automatiques sont activées en exécutant ibmcloud oc logging autoupdate get --cluster CLUSTER commande.
Désactivez les mises à jour automatiques en exécutant la commande ibmcloud oc logging autoupdate disable.
Si les mises à jour automatiques sont désactivées et que vous devez modifier votre configuration, il y a deux options possibles :
- Activez les mises à jour automatiques pour vos pods Fluentd.
```
ibmcloud oc logging autoupdate enable --cluster CLUSTER
```
- Forcez une mise à jour unique lorsque vous utilisez une commande de journalisation comportant l'option --force-update. Remarque : vos pods se mettent à jour vers la version la plus récente du composant Fluentd, mais Fluentd ne se met plus à jour automatiquement par la suite. Exemple de commande
```
ibmcloud oc logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update
```

Gestion des mises à jour automatiques pour les équilibreurs de charge d'application Ingress

Contrôlez à quel moment doit s'effectuer la mise à jour du composant d'équilibreur de charge d'application (ALB) Ingress. Pour savoir comment maintenir à jour les équilibreurs de charge d'application, voir Gestion du cycle de vie de l'équilibreur de charge d'application Ingress.

Mise à jour des modules complémentaires gérés

Les modules complémentaires de cluster gérés IBM Cloud Kubernetes Service sont un moyen facile d'améliorer votre cluster avec des fonctionnalités open-source, telles qu'Istio. La version de l'outil open source que vous ajoutez à votre cluster est testée par IBM et approuvée en vue de son utilisation dans IBM Cloud Kubernetes Service. Pour mettre à jour vers la dernière version des modules complémentaires gérés que vous avez activés dans votre cluster, voir Mise à jour des modules complémentaires gérés.