Mettre à niveau les clusters

Lorsque vous installez une nouvelle version de bmctl, vous pouvez mettre à niveau les clusters existants créés avec une version antérieure. La mise à niveau d'un cluster vers la dernière version de GKE sur bare metal apporte des fonctionnalités et des correctifs supplémentaires. Cela garantit également que votre cluster reste compatible. Vous pouvez mettre à niveau des clusters d'administrateur, hybrides, autonomes ou d'utilisateur à l'aide de la commande bmctl upgrade cluster. Vous pouvez également utiliser kubectl.

Pour en savoir plus sur le processus de mise à niveau, consultez la section Cycle de vie et étapes des mises à niveau des clusters.

Planifier votre mise à niveau

Cette section contient des informations et des liens vers des informations à prendre en compte avant de mettre à niveau un cluster.

Bonnes pratiques

Pour en savoir plus sur la préparation d'une mise à niveau de cluster, consultez la page Bonnes pratiques pour la mise à niveau des clusters GKE sur bare metal.

Mettre à niveau les vérifications préliminaires

Les vérifications préliminaires sont exécutées lors de la mise à niveau du cluster, pour valider l'état des nœuds. La mise à niveau du cluster s'interrompt si les vérifications préliminaires échouent. Pour en savoir plus sur les vérifications préliminaires, consultez la page Comprendre les vérifications préliminaires.

Vous pouvez vérifier si les clusters sont prêts pour une mise à niveau en effectuant une vérification préliminaire avant d'exécuter la mise à niveau. Pour en savoir plus, consultez la section Vérifications préliminaires pour les mises à niveau.

Problèmes connus

Pour en savoir plus sur les problèmes potentiels liés aux mises à niveau des clusters, consultez la page Problèmes connus liés aux clusters Anthos sur bare metal et sélectionnez la catégorie de problème Mises à niveau et mises à jour.

Configurer les options de mise à niveau

Avant de commencer une mise à niveau du cluster, vous pouvez configurer les options de mise à niveau suivantes, qui contrôlent le fonctionnement du processus de mise à niveau:

Mises à niveau sélectives des pools de nœuds de calcul: mettez à niveau des pools de nœuds de calcul spécifiques indépendamment du reste du cluster.
Mises à niveau en parallèle: configurez le processus de mise à niveau pour mettre à niveau simultanément des groupes de nœuds ou des pools de nœuds.

Ces options peuvent réduire le risque d'interruption des applications et des services critiques et réduire considérablement la durée globale de la mise à niveau. Ces options sont particulièrement utiles pour les grands clusters comportant de nombreux nœuds et pools de nœuds qui exécutent des charges de travail importantes. Pour en savoir plus sur ces options et sur leur utilisation, consultez les sections suivantes.

Mises à niveau sélectives des pools de nœuds de calcul

Par défaut, l'opération de mise à niveau du cluster met à niveau chaque nœud et pool de nœuds du cluster. La mise à niveau d'un cluster peut être perturbatrice et prendre du temps, car elle entraîne le drainage de chaque nœud, ainsi que le redémarrage et la replanification de tous les pods associés. Cette section explique comment inclure ou exclure certains pools de nœuds de calcul pour une mise à niveau d'un cluster afin de minimiser l'interruption des charges de travail. Cette fonctionnalité ne s'applique qu'aux clusters d'utilisateur, hybrides et autonomes, car les clusters d'administrateur n'autorisent pas les pools de nœuds de calcul.

Vous pouvez utiliser des mises à niveau sélectives de pools de nœuds dans les situations suivantes:

Pour récupérer les correctifs de sécurité sans interrompre les charges de travail:vous pouvez ne mettre à niveau que les nœuds de votre plan de contrôle (et les nœuds de votre équilibreur de charge) pour appliquer des corrections de failles Kubernetes sans perturber vos pools de nœuds de calcul.
Pour confirmer le bon fonctionnement d'un sous-ensemble mis à niveau de nœuds de calcul avant de mettre à niveau tous les nœuds de calcul:vous pouvez mettre à niveau vos pools de nœuds de calcul de manière sélective pour vous assurer que les charges de travail s'exécutent correctement sur un pool de nœuds mis à niveau avant de mettre à niveau un autre pool de nœuds.
Pour réduire l'intervalle de maintenance:la mise à niveau d'un cluster volumineux peut prendre beaucoup de temps et il est difficile de prévoir avec précision le moment où la mise à niveau sera terminée. La durée de mise à niveau du cluster est proportionnelle au nombre de nœuds mis à niveau. Réduire le nombre de nœuds mis à niveau en excluant les pools de nœuds réduit le temps de mise à niveau. Vous effectuez plusieurs mises à niveau, mais des intervalles de maintenance plus courts et plus prévisibles peuvent faciliter la planification.

Deux écarts de version mineure du pool de nœuds

Avec la version mineure 1.28 de GKE sur Bare Metal, une version de pool de nœuds de calcul peut avoir jusqu'à deux versions mineures de retard par rapport à la version du cluster (plan de contrôle). Ce décalage de version n-2 est disponible en tant que fonctionnalité (Preview).

Pour activer cette fonctionnalité Preview, ajoutez l'annotation preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable au fichier de configuration de votre cluster:
```
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable
spec:
...
```
Si vous n'activez pas cette fonctionnalité en preview, l'écart maximal entre un pool de nœuds de calcul et le cluster est d'une version mineure.

Pour en savoir plus sur les règles de gestion des versions permettant de mettre à niveau de manière sélective les pools de nœuds de calcul, consultez la section Règles de gestion des versions des pools de nœuds dans "Cycle de vie" et les étapes des mises à niveau des clusters.

Mettre à niveau le plan de contrôle du cluster et les pools de nœuds sélectionnés

Pour mettre à niveau de manière sélective les pools de nœuds de calcul lors de la mise à niveau initiale du cluster:

Pour les pools de nœuds de calcul que vous souhaitez inclure dans la mise à niveau du cluster, apportez l'une des modifications suivantes à la spécification du pool de nœuds:
- Dans la spécification de NodePool, définissez anthosBareMetalVersion sur la version de mise à niveau de la cible du cluster.
- Omettez le champ anthosBareMetalVersion de la spécification NodePool ou définissez-le sur la chaîne vide. Par défaut, les pools de nœuds de calcul sont inclus dans les mises à niveau des clusters.
Pour les pools de nœuds de calcul que vous souhaitez exclure de la mise à niveau, définissez anthosBareMetalVersion sur la version actuelle (pré-mise à niveau) du cluster:
Continuez la mise à niveau comme décrit dans Démarrer la mise à niveau du cluster.

L'opération de mise à niveau du cluster met à niveau les nœuds suivants:
- Nœuds du plan de contrôle du cluster.
- Pool de nœuds de l'équilibreur de charge, si votre cluster en utilise un (spec.loadBalancer.nodePoolSpec). Par défaut, les nœuds de l'équilibreur de charge peuvent exécuter des charges de travail standards. Vous ne pouvez pas mettre à niveau de manière sélective un pool de nœuds d'équilibreur de charge, car il est toujours inclus dans la mise à niveau initiale du cluster.
- Pools de nœuds de calcul que vous n'avez pas exclus de la mise à niveau.

Par exemple, supposons que votre cluster soit sur la version 1.16.0 et qu'il dispose de deux pools de nœuds de calcul: wpool01 et wpool02. Supposons également que vous souhaitiez mettre à niveau le plan de contrôle et wpool01 vers la version 1.28.300-gke.131, mais que vous souhaitiez que wpool02 reste à la version 1.16.0.

L'extrait du fichier de configuration de cluster suivant montre comment modifier la configuration du cluster pour accepter cette mise à niveau partielle:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.28.300-gke.131
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.300-gke.131
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.16.0
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Mettre à niveau les pools de nœuds vers la version actuelle du cluster

Si vous avez exclu des pools de nœuds d'une mise à niveau du cluster, vous pouvez exécuter une mise à niveau du cluster qui les ramène à la version du cluster cible. Pour les pools de nœuds de calcul qui ont été exclus de la mise à niveau d'un cluster, le champ anthosBareMetalVersion dans leur spécification de nœud de nœud est défini sur la version de cluster précédente (pré-mise à niveau).

Pour faire passer les pools de nœuds de calcul à la version de cluster actuelle (mise à niveau) :

Modifiez les spécifications du pool de nœuds dans le fichier de configuration du cluster pour les pools de nœuds de calcul que vous souhaitez utiliser dans la version actuelle du cluster. Définissez anthosBareMetalVersion sur la version actuelle du cluster (après la mise à niveau).

Si plusieurs pools de nœuds de calcul sont sélectionnés pour la mise à niveau, la valeur de spec.nodePoolUpgradeStrategy.concurrentNodePools dans la spécification du cluster détermine le nombre de pools de nœuds mis à niveau en parallèle, le cas échéant. Si vous ne souhaitez pas mettre à niveau les pools de nœuds de calcul simultanément, sélectionnez un pool de nœuds à la fois pour la mise à niveau.
Continuez la mise à niveau comme décrit dans Démarrer la mise à niveau du cluster.

L'opération de mise à niveau du cluster ne met à niveau que les pools de nœuds de calcul précédemment exclus pour lesquels vous avez défini anthosBareMetalVersion sur la version actuelle du cluster mise à niveau.

Par exemple, supposons que vous ayez mis à niveau votre cluster vers la version 1.28.300-gke.131, mais que le pool de nœuds wpool02 utilise toujours l'ancienne version 1.16.0 du cluster, antérieure à la mise à niveau. Les charges de travail s'exécutent correctement sur le pool de nœuds mis à niveau, wpool01. Par conséquent, vous souhaitez maintenant également transférer wpool02 vers la version actuelle du cluster. Pour mettre à niveau wpool02, vous pouvez supprimer le champ anthosBareMetalVersion ou définir sa valeur sur la chaîne vide.

L'extrait du fichier de configuration de cluster suivant montre comment modifier la configuration du cluster pour accepter cette mise à niveau partielle:

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.28.300-gke.131
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.300-gke.131
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.8

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool02
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: ""
  nodes:
  - address:  10.200.1.1
  - address:  10.200.1.2
  - address:  10.200.1.3
  ...
  - address:  10.200.1.12

Mises à niveau en parallèle

Lors d'une mise à niveau de cluster par défaut classique, chaque nœud de cluster est mis à niveau de manière séquentielle, l'un après l'autre. Cette section vous explique comment configurer votre cluster et vos pools de nœuds de calcul de sorte que plusieurs nœuds soient mis à niveau en parallèle lorsque vous mettez à niveau votre cluster. La mise à niveau des nœuds en parallèle accélère considérablement les mises à niveau des clusters, en particulier pour les clusters comportant des centaines de nœuds.

Il existe deux stratégies de mise à niveau parallèle que vous pouvez utiliser pour accélérer la mise à niveau de votre cluster:

Mise à niveau simultanée de nœuds:vous pouvez configurer vos pools de nœuds de calcul de sorte que plusieurs nœuds soient mis à niveau en parallèle. Les mises à niveau parallèles des nœuds sont configurées dans la spécification NodePool (spec.upgradeStrategy.parallelUpgrade). Seuls les nœuds d'un pool de nœuds de calcul peuvent être mis à niveau en parallèle. Les nœuds des pools de nœuds du plan de contrôle ou de l'équilibreur de charge ne peuvent être mis à niveau qu'un seul à la fois. Pour en savoir plus, consultez Stratégie de mise à niveau des nœuds.
Mise à niveau simultanée des pools de nœuds:vous pouvez configurer votre cluster de sorte que plusieurs pools de nœuds soient mis à niveau en parallèle. Seuls les pools de nœuds de calcul peuvent être mis à niveau en parallèle. Les pools de nœuds du plan de contrôle et de l'équilibreur de charge ne peuvent être mis à niveau qu'un par un.

Stratégie de mise à niveau des nœuds

Vous pouvez configurer des pools de nœuds de calcul de sorte que plusieurs nœuds soient mis à niveau simultanément (concurrentNodes). Vous pouvez également définir un seuil minimal pour le nombre de nœuds pouvant exécuter des charges de travail tout au long du processus de mise à niveau (minimumAvailableNodes). Cette configuration est effectuée dans la spécification du pool de nœuds. Pour en savoir plus sur ces champs, consultez la documentation de référence sur le champ de configuration du cluster.

La stratégie de mise à niveau des nœuds ne s'applique qu'aux pools de nœuds de calcul. Vous ne pouvez pas spécifier de stratégie de mise à niveau des nœuds pour les pools de nœuds du plan de contrôle ou de l'équilibreur de charge. Lors de la mise à niveau d'un cluster, les nœuds du plan de contrôle et des pools de nœuds de l'équilibreur de charge sont mis à niveau de manière séquentielle, un par un. Les pools de nœuds du plan de contrôle et les pools de nœuds de l'équilibreur de charge sont spécifiés dans la spécification du cluster (controlPlane.nodePoolSpec.nodes et loadBalancer.nodePoolSpec.nodes).

Lorsque vous configurez des mises à niveau parallèles pour les nœuds, tenez compte des restrictions suivantes:

La valeur de concurrentNodes ne peut pas dépasser 50 % du nombre de nœuds dans le pool de nœuds ni le nombre fixe de 15, selon la valeur la plus faible. Par exemple, si votre pool de nœuds comporte 20 nœuds, vous ne pouvez pas spécifier de valeur supérieure à 10. Si votre pool de nœuds comporte 100 nœuds, la valeur maximale que vous pouvez spécifier est 15.
Lorsque vous utilisez concurrentNodes avec minimumAvailableNodes, les valeurs combinées ne peuvent pas dépasser le nombre total de nœuds dans le pool de nœuds. Par exemple, si votre pool de nœuds comporte 20 nœuds et que minimumAvailableNodes est défini sur 18, concurrentNodes ne peut pas dépasser 2. De même, si concurrentNodes est défini sur 10, minimumAvailableNodes ne peut pas dépasser 10.

L'exemple suivant présente un pool de nœuds de calcul np1 comportant 10 nœuds. Lors d'une mise à niveau, les nœuds doivent être mis à niveau 5 à la fois et au moins 4 nœuds doivent rester disponibles pour que la mise à niveau puisse se poursuivre:

apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  - address:  10.200.0.4
  - address:  10.200.0.5
  - address:  10.200.0.6
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  - address:  10.200.0.10 
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 4

Stratégie de mise à niveau du pool de nœuds

Vous pouvez configurer un cluster de sorte que plusieurs pools de nœuds de calcul soient mis à niveau en parallèle. Le champ booléen nodePoolUpgradeStrategy.concurrentNodePools de la spécification de cluster indique si tous les pools de nœuds de calcul d'un cluster doivent être mis à niveau simultanément. Par défaut (1), les pools de nœuds sont mis à niveau de manière séquentielle, l'un après l'autre. Lorsque vous définissez concurrentNodePools sur 0, chaque pool de nœuds de calcul du cluster est mis à niveau en parallèle.

Les pools de nœuds du plan de contrôle et de l'équilibrage de charge ne sont pas affectés par ce paramètre. Ces pools de nœuds sont toujours mis à niveau de manière séquentielle, un par un. Les pools de nœuds du plan de contrôle et les pools de nœuds de l'équilibreur de charge sont spécifiés dans la spécification du cluster (controlPlane.nodePoolSpec.nodes et loadBalancer.nodePoolSpec.nodes).

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...

Effectuer une mise à niveau en parallèle

Cette section explique comment configurer un cluster et un pool de nœuds de calcul pour des mises à niveau parallèles.

Pour effectuer une mise à niveau parallèle des pools de nœuds de calcul et des nœuds d'un pool de nœuds de calcul, procédez comme suit:

Ajoutez une section upgradeStrategy à la spécification de NodePool.

Vous pouvez appliquer ce fichier manifeste séparément ou dans le fichier de configuration du cluster lorsque vous effectuez une mise à jour du cluster.

Exemple :
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
  - address:  10.200.0.30
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
      minimumAvailableNodes: 10
```
Dans cet exemple, la valeur du champ concurrentNodes est 5, ce qui signifie que cinq nœuds sont mis à niveau en parallèle. Le champ minimumAvailableNodes est défini sur 10, ce qui signifie qu'au moins 10 nœuds doivent rester disponibles pour les charges de travail tout au long de la mise à niveau.

Remarque :Vous ne pouvez pas spécifier de stratégie de mise à niveau des nœuds pour les pools de nœuds du plan de contrôle ou de l'équilibreur de charge.
Ajoutez une section nodePoolUpgradeStrategy à la spécification Cluster dans le fichier de configuration du cluster.
```
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user001
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user001
  namespace: cluster-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.28.300-gke.131
  ...
  nodePoolUpgradeStrategy:
    concurrentNodePools: 0
  ...
```
Dans cet exemple, le champ concurrentNodePools est défini sur 0, ce qui signifie que tous les pools de nœuds de calcul sont mis à niveau simultanément lors de la mise à niveau du cluster. La stratégie de mise à niveau des nœuds dans les pools de nœuds est définie dans les spécifications du pool de nœuds.
Mettez à niveau le cluster comme décrit dans la section précédente Mettre à niveau des clusters d'administrateur, autonomes, hybrides ou d'utilisateur.

Valeurs par défaut de la mise à niveau en parallèle

Les mises à niveau parallèles sont désactivées par défaut et les champs associés sont modifiables. À tout moment, vous pouvez supprimer les champs ou les définir sur leurs valeurs par défaut afin de désactiver la fonctionnalité avant une mise à niveau ultérieure.

Le tableau suivant liste les champs de mise à niveau parallèle et leurs valeurs par défaut:

Champ	Valeur par défaut	Signification
`nodePoolUpgradeStrategy.concurrentNodePools` (spécification du cluster)	`1`	Mettez à niveau les pools de nœuds de calcul de manière séquentielle, l'un après l'autre.
`upgradeStrategy.parallelUpgrade.concurrentNodes` (spécification NodePool)	`1`	Mettez à niveau les nœuds de manière séquentielle, l'un après l'autre.
`upgradeStrategy.parallelUpgrade.minimumAvailableNodes` (spécification NodePool)	La valeur `minimumAvailableNodes` par défaut dépend de la valeur de `concurrentNodes`. Si vous ne spécifiez pas `concurrentNodes`, `minimumAvailableNodes` correspond par défaut à 2/3 de la taille du pool de nœuds. Si vous spécifiez `concurrentNodes`, `minimumAvailableNodes` correspond par défaut à la taille du pool de nœuds moins `concurrentNodes`.	La mise à niveau se bloque une fois que la valeur `minimumAvailableNodes` est atteinte et ne se poursuit que lorsque le nombre de nœuds disponibles est supérieur à `minimumAvailableNodes`.

Démarrer la mise à niveau du cluster

Cette section contient des instructions pour mettre à niveau des clusters.

`bmctl`

Lorsque vous téléchargez et installez une nouvelle version de bmctl, vous pouvez mettre à niveau vos clusters d'administrateur, hybrides, autonomes et d'utilisateur créés avec une version antérieure. Pour une version donnée de bmctl, un cluster ne peut être mis à jour que vers la même version.

Téléchargez la dernière version de bmctl, comme décrit dans la section Téléchargements de GKE sur une solution Bare Metal.
Mettez à jour anthosBareMetalVersion dans le fichier de configuration du cluster vers la version cible de mise à niveau.

La version cible de la mise à niveau doit correspondre à la version du fichier bmctl téléchargé. L'extrait de fichier de configuration de cluster suivant montre le champ anthosBareMetalVersion mis à jour vers la dernière version:
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  type: admin
  # Anthos cluster version.
  anthosBareMetalVersion: 1.28.300-gke.131
```
Exécutez la commande bmctl upgrade cluster pour effectuer la mise à niveau :
```
bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster à mettre à niveau.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
L'opération de mise à niveau du cluster exécute des vérifications préliminaires pour valider l'état du cluster et celui du nœud. La mise à niveau du cluster ne se poursuit pas si les vérifications préliminaires échouent. Pour obtenir des informations de dépannage, consultez la page Résoudre les problèmes d'installation ou de mise à niveau du cluster.

Une fois tous les composants du cluster mis à niveau, l'opération de mise à niveau effectue des vérifications de l'état du cluster. Cette dernière étape permet de vérifier que le cluster est en bon état de fonctionnement. Si le cluster ne réussit pas toutes les vérifications d'état, celles-ci continuent de s'exécuter jusqu'à ce qu'elles réussissent. Une fois toutes les vérifications d'état effectuées, la mise à niveau se termine correctement.

Pour en savoir plus sur la séquence d'événements pour les mises à niveau d'un cluster, consultez la section Cycle de vie et étapes des mises à niveau d'un cluster.

`kubectl`

Pour mettre à niveau un cluster avec kubectl, procédez comme suit:

Modifiez le fichier de configuration du cluster pour définir anthosBareMetalVersion sur la version cible de la mise à niveau.
Pour lancer la mise à niveau, exécutez la commande suivante :
```
kubectl apply -f CLUSTER_CONFIG_PATH
```
Remplacez CLUSTER_CONFIG_PATH par le chemin d'accès au fichier de configuration du cluster modifié.

Comme pour le processus de mise à niveau avec bmctl, des vérifications préliminaires sont exécutées lors de la mise à niveau du cluster pour valider l'état du cluster et celui du nœud. Si les vérifications préliminaires échouent, la mise à niveau du cluster est interrompue. Pour résoudre les échecs, examinez le cluster et les journaux associés, car aucun cluster d'amorçage n'est créé. Pour en savoir plus, consultez la section Résoudre les problèmes d'installation ou de mise à niveau du cluster.

Bien que vous n'ayez pas besoin de la dernière version de bmctl pour mettre à niveau les regroupements avec kubectl, nous vous recommandons de télécharger la dernière version de bmctl. Vous avez besoin de bmctl pour effectuer d'autres tâches, telles que des vérifications de l'état et des sauvegardes, afin de garantir que votre cluster reste en bon état de fonctionnement.

Suspendre et réactiver les mises à niveau

Avec la version mineure 1.28 de GKE sur Bare Metal, vous pouvez suspendre et reprendre une mise à niveau du cluster. Lorsqu'une mise à niveau d'un cluster est suspendue, aucune nouvelle mise à niveau de nœud n'est déclenchée tant que la mise à niveau n'est pas réactivée. Cette fonctionnalité n'est disponible que pour les clusters comportant tous les nœuds de plan de contrôle à la version mineure 1.28 ou ultérieure.

Vous pouvez suspendre une mise à niveau pour les raisons suivantes:

Vous avez détecté un problème avec les charges de travail du cluster lors de la mise à niveau et vous souhaitez suspendre la mise à niveau pour l'examiner.
Vos intervalles de maintenance sont courts. Vous souhaitez donc suspendre la mise à niveau entre les intervalles.

Lorsqu'une mise à niveau d'un cluster est suspendue, les opérations suivantes sont prises en charge:

Lorsqu'un nouveau nœud est ajouté alors qu'une mise à niveau est suspendue, les tâches de vérification des machines ne sont pas exécutées tant que la mise à niveau n'est pas réactivée et terminée.

Lorsque la mise à niveau du cluster est suspendue, les opérations de cluster suivantes ne sont pas compatibles:

Vous ne pouvez pas lancer une nouvelle mise à niveau du cluster lorsqu'une mise à niveau active du cluster est suspendue.

Activer la suspension et la reprise de la mise à niveau

Tant que la fonctionnalité de suspension et de reprise de la mise à niveau est en version preview, vous pouvez l'activer avec une annotation dans la ressource de cluster.

Pour activer la suspension et la reprise de la mise à niveau, procédez comme suit:

Ajoutez l'annotation preview.baremetal.cluster.gke.io/upgrade-pause-and-resume au fichier de configuration de votre cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
    preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
spec:
...

Pour appliquer la modification, mettez à jour votre cluster:
```
bmctl update CLUSTER_NAME
```
Le champ nodePoolUpgradeStrategy.pause est modifiable. Vous pouvez l'ajouter et le mettre à jour à tout moment.

Suspendre une mise à niveau

Vous suspendez la mise à niveau d'un cluster en définissant nodePoolUpgradeStrategy.pause sur true dans les spécifications du cluster.

Pour suspendre une mise à niveau active d'un cluster, procédez comme suit:

Ajoutez nodePoolUpgradeStrategy.pause au fichier de configuration du cluster et définissez-le sur true:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
        preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: true
  ...

Si vous avez utilisé bmctl pour lancer la mise à niveau, vous avez besoin d'une nouvelle fenêtre de terminal pour effectuer l'étape suivante.

Pour appliquer la modification, mettez à jour votre cluster:
```
bmctl update CLUSTER_NAME
```
La mise à niveau est suspendue. Aucune nouvelle mise à niveau de nœud n'est déclenchée.
Si vous avez utilisé bmctl pour lancer la mise à niveau et que vous prévoyez une suspension prolongée, appuyez sur Ctrl+C pour quitter bmctl. Sinon, laissez bmctl s'exécuter.

La CLI bmctl ne détecte pas les changements d'état d'interruption de la mise à niveau. Elle ne se ferme donc pas automatiquement. Toutefois, lorsque vous quittez bmctl, la progression de la mise à niveau s'arrête dans le fichier journal cluster-upgrade-TIMESTAMP situé dans le dossier du cluster de votre poste de travail administrateur, ainsi que dans Cloud Logging. Par conséquent, pour de courtes pauses, vous pouvez continuer à exécuter bmctl. Si vous laissez bmctl s'exécuter pendant une période prolongée pendant que la mise à niveau est suspendue, elle finit par expirer.

Reprendre une mise à niveau suspendue

Pour reprendre une mise à niveau de cluster suspendue, définissez nodePoolUpgradeStrategy.pause sur false dans la spécification de cluster ou supprimez nodePoolUpgradeStrategy.pause de la spécification.

Pour reprendre une mise à niveau d'un cluster suspendue, procédez comme suit:

Définissez nodePoolUpgradeStrategy.pause sur le fichier de configuration du cluster et définissez-le sur false:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: baremetal-demo
  namespace: cluster-baremetal-demo
  annotations:
        preview.baremetal.cluster.gke.io/upgrade-pause-and-resume
spec:
  ...
  nodePoolUpgradeStrategy:
    pause: false
  ...

Vous pouvez également supprimer le champ pause, car il est défini par défaut sur false.

Pour appliquer la modification, mettez à jour votre cluster:
```
bmctl update CLUSTER_NAME
```
La mise à niveau reprend là où elle s'était arrêtée.
Pour vérifier l'état de la mise à niveau, commencez par obtenir la liste des ressources dont le fichier status contient anthosBareMetalVersion:
```
kubectl get RESOURCE --kubeconfig ADMIN_KUBECONFIG --all_namespaces
```
Remplacez les éléments suivants :
- RESOURCE: nom de la ressource que vous souhaitez obtenir. Les ressources Cluster, NodePool et BareMetalMachine contiennent toutes des informations d'état anthosBareMetalVersion.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
L'exemple suivant montre le format de la réponse pour les ressources personnalisées BareMetalMachine. Chaque BareMetalMachine correspond à un nœud de cluster.
```
NAMESPACE              NAME         CLUSTER        READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
cluster-nuc-admin001   192.0.2.52   nuc-admin001   true    baremetal://192.0.2.52   192.0.2.52   1.28.0        1.28.0
cluster-nuc-user001    192.0.2.53   nuc-user001    true    baremetal://192.0.2.53   192.0.2.53   1.16.2        1.16.2
cluster-nuc-user001    192.0.2.54   nuc-user001    true    baremetal://192.0.2.54   192.0.2.54   1.16.2        1.16.2
```

Pour vérifier la status.anthosBareMetalVersion (version actuelle de la ressource), récupérez les détails de chaque ressource:

kubectl describe RESOURCE RESOURCE_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --namespace CLUSTER_NAMESPACE

L'exemple suivant montre les détails BareMetalMachine du nœud de cluster avec l'adresse IP 192.0.2.53:

Name:         192.0.2.53
Namespace:    cluster-nuc-user001
...
API Version:  infrastructure.baremetal.cluster.gke.io/v1
Kind:         BareMetalMachine
Metadata:
  Creation Timestamp:  2023-09-22T17:52:09Z
  ...
Spec:
  Address:                    192.0.2.53
  Anthos Bare Metal Version:  1.16.2
  ...
Status:
  Anthos Bare Metal Version:  1.16.2

Dans cet exemple, le nœud se trouve dans la version 1.16.2 de GKE sur une solution Bare Metal.