Vérification de la disponibilité d'une mise à jour de version avec l'interface de ligne de commande IBM Cloud

1. Connectez-vous à IBM Cloud. Incluez l'option --sso si vous disposez d'un compte fédéré.

   ibmcloud login [--sso]
   

2. Répertoriez les clusters Satellite disponibles dans votre compte.

   ibmcloud ks cluster ls --provider satellite
   

3. Répertoriez les noeuds worker dans le cluster dont vous souhaitez mettre à jour la version. Dans la sortie, recherchez un astérisque * avec un message indiquant qu'une mise à jour de version est disponible.

   ibmcloud ks worker ls -c CLUSTER_NAME_OR_ID
   

   Exemple de sortie

   ID                Primary IP       Flavor   State    Status   Zone     Version   
   sat-worker-<ID>   <IP_address>     upi      normal   Ready    zone-1   4.5.35_1534_openshift*   
   * To update to 4.5.37_1537_openshift version, run 'ibmcloud ks worker replace'. Review and make any required version changes before you update: 'https://ibm.biz/upworker'
   

Vérification de la disponibilité d'une mise à jour de version à partir de la console IBM Cloud

1. Connectez-vous à la consoleSatellite.
2. Cliquez sur l'emplacement des hôtes à mettre à jour.
3. Cliquez sur l'onglet Hôtes.
4. Dans la liste des hôtes, cliquez sur le lien vers le Cluster de l'hôte à mettre à jour. Un nouvel onglet s'ouvre pour les détails du cluster Red Hat OpenShift on IBM Cloud.
5. Cliquez sur l'onglet Noeuds worker.
6. Dans la colonne Version, recherchez une icône d'information qui s'affiche lorsque Update available vous cliquez dessus. Si aucune mise à jour n'est disponible, aucune icône n'est présente.
7. Déterminez si la mise à jour de la version est une mise à jour majeure, mineure ou de correctif.

Appliquer les mises à jour de version aux hôtes de noeud worker un par un

1. Facultatif: Associez et affectez des hôtes supplémentaires au cluster de service pour gérer la capacité de calcul pendant la mise à jour de vos hôtes existants.

2. Identifiez vos hôtes de noeud worker. Les hôtes de noeud worker n'ont pas infrastructure répertorié dans la colonne Cluster de la sortie, mais ont le nom du cluster.

3. Mettez à jour vos noeuds worker individuellement en exécutant la commande ibmcloud ks worker update.

   ibmcloud ks worker update -c CLUSTER_NAME_OR_ID --worker WORKER_ID
   

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

   kubectl get nodes
   

   Si la mise à jour a échoué, vous devez appliquer les mises à jour de version en remplaçant les hôtes.

Appliquez des mises à jour de version à vos hôtes de noeud worker avec un objet ConfigMap

Vous pouvez déployer des mises à jour sur tous vos hôtes de noeud worker avec un objet ConfigMap. Indiquez les noeuds à mettre à jour à l'aide de libellés. Vous pouvez également spécifier

1. Facultatif: Associez et affectez des hôtes supplémentaires au cluster de service pour gérer la capacité de calcul pendant la mise à jour de vos hôtes existants.

2. Identifiez vos hôtes de noeud worker. Vos hôtes de noeud worker ne sont pas répertoriés comme Infrastructure.

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. Vous pouvez utiliser les libellés pour spécifier les noeuds worker à mettre à jour.

   kubectl get nodes -o yaml
   

   Exemple de sortie

   labels:
     arch: amd64
     beta.kubernetes.io/arch: amd64
     beta.kubernetes.io/instance-type: upi
     beta.kubernetes.io/os: linux
     failure-domain.beta.kubernetes.io/region: us-east
     failure-domain.beta.kubernetes.io/zone: us-east-2
     ibm-cloud.kubernetes.io/iaas-provider: upi
     ibm-cloud.kubernetes.io/internal-ip: 10.241.0.4
     ibm-cloud.kubernetes.io/machine-type: upi
     ibm-cloud.kubernetes.io/os: REDHAT_8_64
     ibm-cloud.kubernetes.io/region: us-east
     ibm-cloud.kubernetes.io/worker-id: sat-satellitei-5bd83963cdfedc7668c9040879c88113a134c4e7
     ibm-cloud.kubernetes.io/worker-pool-id: cbtljodw089nltg8k210-9a3f763
     ibm-cloud.kubernetes.io/worker-pool-name: default
     ibm-cloud.kubernetes.io/worker-version: 4.7.59_1583_openshift
     ibm-cloud.kubernetes.io/zone: us-east-2
     kubernetes.io/arch: amd64
     kubernetes.io/hostname: satellite-ibm-host-3
     kubernetes.io/os: linux
     node-role.kubernetes.io/master: ""
     node-role.kubernetes.io/worker: ""
     node.kubernetes.io/instance-type: upi
     node.openshift.io/os_id: rhel
     privateVLAN: "1"
     topology.kubernetes.io/region: us-east
     topology.kubernetes.io/zone: us-east-2
   

4. Créez une instance ConfigMap et définissez les règles d'indisponibilité pour vos nœuds de travail. L'exemple suivant présente deux chèques, le defaultcheck.json et un modèle de chèque. Vous pouvez utiliser cet exemple de vérification pour définir des règles pour tous les noeuds worker qui ne correspondent à aucune des vérifications que vous avez définies dans ConfigMap (defaultcheck.json). Utilisez le modèle de vérification pour créer votre propre vérification. 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. Définissez jusqu'à 10 vérifications dans une ConfigMap. Si vous ajoutez d'autres vérifications, elles sont ignorées.

   Exemple

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-cluster-update-configuration
     namespace: kube-system
   data:
     drain_timeout_seconds: "120"
     defaultcheck.json: |
       {
         "MaxUnavailablePercentage": 20
       }
     <check_name>: |
       {
         "MaxUnavailablePercentage": <value_in_percentage>,
         "NodeSelectorKey": "<node_selector_key>",
         "NodeSelectorValue": "<node_selector_value>"
       }
   

   drain_timeout_seconds

   Facultatif : 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.

   defaultcheck.json

   Lorsque vous mettez à jour des noeuds worker dans des hôtes Satellite, seuls 20% des noeuds worker du cluster peuvent être indisponibles à la fois.

   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.

   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.

   kubectl apply -f <filepath/configmap.yaml>
   

6. Vérifiez que l' ConfigMap est bien créé.

   kubectl get configmap --namespace kube-system
   

7. Mettez à jour les noeuds worker en les répertoriant par ID.

   ibmcloud ks worker update --cluster <cluster_name_or_ID> --worker <worker_node1_ID> --worker <worker_node2_ID>
   

8. Facultatif : vérifiez les événements déclenchés par l’ ConfigMap, ainsi que les éventuelles erreurs de validation survenues. Les événements peuvent être consultés dans la section Evénements de la sortie de l'interface CLI.

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

   kubectl get nodes
   

   Si la mise à jour a échoué, vous devez appliquer les mises à jour de version en remplaçant les hôtes.

10. Vérifiez que vous n'avez pas de nœuds de travail en double. Les anciens clusters peuvent afficher des nœuds de travail en double avec un statut NotReady après une mise à jour. Pour supprimer ces doublons, voir la section de traitement des incidents.