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

Avant de commencer, assurez-vous de disposer du rôle d'accès à la plateforme IAM Opérateur ou Administrateur. Si vous n'êtes pas sûr de votre rôle d'accès, accédez à Gérer → Accès (IAM) → Utilisateurs dans la console IBM Cloud, ou adressez-vous à l'administrateur de votre compte.

Si une rotation de certificats d'autorité de certification (CA) est en cours, la mise à jour principale est bloquée jusqu'à ce que la rotation soit terminée. Vérifiez l'état d'avancement de toute rotation en cours avant de commencer.

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

1. Consultez les informations de version deRed Hat OpenShift on IBM Cloud et effectuez les mises à jour marquées Update before master.

2. Vérifiez les avertissements utiles sur Kubernetes, tels que les avis de dépréciation.

3. 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.

4. Mettez à jour votre serveur API et les composants principaux associés à l'aide de la console d' IBM Cloud ou en exécutant la commandeibmcloud oc cluster master update CLI.

5. 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.

6. 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 les versions client oc dont le numéro de version diffère de deux versions ou plus par rapport à la version serveur (n +/- 2). Pour actualiser votre configuration locale, exécutez ibmcloud oc cluster config -c CLUSTER_NAME_OR_ID, puis vérifiez avec oc version --client.

Une fois la mise à jour du nœud maître terminée, mettez à jour vos nœuds de travail. La méthode dépend du type de votre infrastructure :

1. Mise à jour des nœuds de travail classiques: utilise une mise à jour progressive contrôlée par une ConfigMap et la commande worker update.
2. Mise à jour des nœuds de travail VPC — Les nœuds de travail bare metal VPC sont mis à jour sur place à l'aide de worker reload; les nœuds de travail VSI VPC doivent utiliser worker replace --update. La procédure de mise à jour progressive ConfigMap n'est pas encore prise en charge pour les nœuds de travail VPC.

Prérequis

Avant de mettre à jour vos nœuds de travail d’infrastructure classique, effectuez les étapes préalables suivantes.

Lors de la mise à jour d'un nœud de travail, l'image du nœud de travail est réinstallée et toutes les données qui ne sont pas stockées sur un support de stockage persistant sont définitivement supprimées. Vérifiez que toutes les données que vous devez conserver sont stockées en dehors du nœud de travail avant de commencer.

Si vous avez installé l' Portworx dans votre cluster, vous devez mettre à jour la configuration de l' Portworx avant de mettre à jour les nœuds de travail.

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

Utilisez une commande ConfigMap pour effectuer une mise à jour progressive de vos nœuds de travail classiques. L' ConfigMap e vous permet de contrôler le nombre de nœuds pouvant être indisponibles simultanément, par zone ou par région. Si la règle par défaut de 20 % d'indisponibilité est acceptable pour votre cluster, vous pouvez ignorer les étapes 3 et 4 (création de ConfigMap ) et passer directement à l'étape 5 pour appliquer la mise à jour en utilisant le comportement par défaut.

1. Effectuez les étapes prérequises.

2. Affichez la liste des noeuds worker disponibles et notez leur adresse IP privée.

   ibmcloud oc worker ls --cluster CLUSTER
   

3. 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
   

4. Créez une mappe de configuration et définissez les règles d'indisponibilité applicables à vos noeuds worker. L' ConfigMap prend en charge jusqu'à 15 vérifications nommées. Chaque contrôle cible un ensemble de nœuds de travail en fonction de leur étiquette et définit le pourcentage maximal de ces nœuds pouvant être indisponibles simultanément. L'exemple suivant présente une vérification de zone (zonecheck.json), une vérification de région (regioncheck.json), une vérification de repli par défaut (defaultcheck.json) et un modèle pour les vérifications personnalisées. Pour chaque vérification, choisissez l'un des identifiants de nœud de travail que vous avez récupérés à l'étape précédente afin d'identifier les nœuds cibles.

   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éfinissez jusqu'à 15 vérifications 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 que le vidage soit terminé. 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.

5. Créez la mappe de configuration dans votre cluster.

   oc apply -f <filepath/configmap.yaml>
   

6. Vérifiez que la mappe de configuration est créée.

   oc get configmap --namespace kube-system
   

7. Mettez à jour les noeuds worker.

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

8. 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
   

9. Confirmez que la mise à jour est terminée en examinant la version Kubernetes de vos noeuds worker.

   oc get nodes
   

10. Vérifiez que vous n'avez pas de nœuds de travail en double. Il arrive parfois que, suite à une mise à jour, les anciens clusters affichent des nœuds de travail en double avec un statut NotReady. Pour supprimer ces doublons, voir la section de traitement des incidents.

Mise à jour des noeuds worker classiques dans la console

Une fois l’ ConfigMap e configurée pour la première fois, vous pouvez mettre à jour les nœuds de travail à l’aide de la console IBM Cloud. La console respecte les règles d’indisponibilité que vous avez définies dans l’ ConfigMap.

1. Suivez les étapes préalables et configurez un fichier ConfigMap pour contrôler la manière dont vos nœuds de travail sont mis à jour.
2. Dans le menu de la console IBM Cloud , cliquez sur Conteneurs > Clusters.
3. Sur la page Clusters, cliquez sur votre cluster.
4. 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.
5. Dans la barre de menus, cliquez sur Mettre à jour.

Si vous avez installé l' Portworx dans votre cluster, vous devez redémarrer les pods Portworx sur les nœuds de travail mis à jour. Pour plus d'informations, voir les Limitations de Portworx.

Prérequis

Avant de mettre à jour les nœuds de travail de votre infrastructure VPC, effectuez les étapes préalables suivantes.

Pour les travailleurs VPC VSI, le nœud de travail est supprimé et remplacé par un nouveau nœud. Pour les instances bare metal VPC, le nœud est rechargé sur place. Dans les deux cas, les données qui ne sont pas stockées sur un support de stockage persistant sont définitivement supprimées. Vérifiez que toutes les données que vous devez conserver sont stockées en dehors du nœud de travail avant de commencer.

Si vous avez déployé l' Portworx dans votre cluster, suivez les étapes permettant de mettre à jour les nœuds de travail VPC avec des volumes Portworx au lieu de suivre les étapes décrites sur cette page.

Mises à jour du micrologiciel lors du redémarrage d’un serveur bare metal VPC

Lorsque vous redémarrez un nœud de travail bare metal dans un VPC, l’infrastructur IBM Cloud vérifie automatiquement si une mise à jour du micrologiciel est en attente pour ce serveur et l’applique dans le cadre du processus de redémarrage. Aucune action supplémentaire n'est requise pour déclencher la mise à jour du micrologiciel.

Tenez compte des considérations suivantes lorsque vous rechargez un nœud de travail bare metal VPC :

Temps de rechargement prolongé

Si une mise à jour du micrologiciel est appliquée pendant le rechargement, la durée totale du rechargement peut augmenter considérablement (de 30 minutes ou plus) par rapport à la durée habituelle. Planifiez vos fenêtres de maintenance en conséquence.

Aucune visibilité préalable sur les mises à jour à venir

Il n'est pas possible de savoir si une mise à jour du micrologiciel est en attente pour un nœud de travail avant d'exécuter la commande de rechargement.

Risque de perte de données

Comme pour tous les rechargements de machines bare metal VPC, les données présentes sur les disques locaux sont supprimées lors du rechargement, qu’une mise à jour du micrologiciel soit appliquée ou non. Sauvegardez toutes les données qui ne sont pas stockées sur un support de stockage persistant avant de procéder à la rechargement.

Échec du rechargement dû à une mise à jour du micrologiciel

Dans certains cas, une mise à jour du micrologiciel peut échouer, ce qui entraîne le passage du nœud de travail dans un état reload_failed (Failed to reload worker) avec les détails de statut The infrastructure firmware update has failed. (P4056). Si cela se produit :

1. Patientez quelques minutes, puis réessayez de recharger la page en relançant ibmcloud oc worker reload --cluster CLUSTER --worker WORKER-NODE-ID la commande.
2. Si l'erreur persiste après 2 ou 3 tentatives, ouvrez un dossier d'assistance sur IBM Cloud.

Avant de commencer

• Accédez à votre cluster Red Hat OpenShift.
• Vérifiez que toutes les données que vous devez conserver sont stockées sur un support de stockage persistant en dehors du nœud de travail. Les données stockées uniquement sur le nœud de travail sont perdues et ne peuvent pas être récupérées.
• Assurez-vous de disposer du rôle d’accès à la plateforme IAM Opérateur ou Administrateur. Si vous n'êtes pas sûr de votre rôle d'accès, accédez à Gérer → Accès (IAM) → Utilisateurs dans la console IBM Cloud, ou adressez-vous à l'administrateur de votre compte.

Pour mettre à jour les versions

1. 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**.
   ```sh {: pre}
       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.
   ```sh {: pre}
       ibmcloud oc worker get --cluster CLUSTER --worker WORKER-ID
       ```
   

2. Répertoriez les versions disponibles dans la zone.

   ibmcloud oc flavors --zone <zone>
   

3. 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](/docs/openshift?topic=openshift-regions-and-zones#zones-mz) ou [VPC](/docs/openshift?topic=openshift-regions-and-zones#zones-vpc).
       * Clusters classiques :
           ```sh {: pre}
           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 :
           ```sh {: pre}
           ibmcloud oc zone add vpc-gen2 --zone ZONE --cluster CLUSTER --worker-pool WORKER-POOL --subnet-id VPC-SUBNET-ID
           ```
   

4. 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
   

5. Supprimez l'ancien pool de travailleurs. Si vous supprimez une instance Classic bare metal (facturée mensuellement), vous serez facturé pour le mois entier, même si vous la supprimez en cours de mois. Les instances VPC, y compris les instances bare metal, sont facturées à l'heure.

   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é.
   ```sh {: pre}
       ibmcloud oc worker-pool ls --cluster CLUSTER
       ```
   

6. Vérifiez que les noeuds worker ont été supprimés de votre cluster.

   ibmcloud oc worker ls --cluster CLUSTER
   

7. Répétez ces étapes pour mettre à jour d'autres pools de noeuds worker ou d'autres noeuds worker autonomes vers différentes versions.

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.

Pour exécuter les commandes suivantes, vous devez disposer du rôle d'accès à la plateforme IAM IBM Cloud() pour le cluster.

Vous pouvez gérer les mises à jour automatiques du composant Fluentd de plusieurs manières indiquées ci-après.

• 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 commandeibmcloud 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`. Vos pods sont mis à jour vers la dernière version du composant Fluentd, mais Fluentd ne se mettra plus à jour automatiquement par la suite.
          Exemple de commande
  
  ```sh {: pre}
      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.