Les clusters Anthos sur Bare Metal sont désormais Google Distributed Cloud (logiciel uniquement) pour Bare Metal. Pour en savoir plus, consultez la présentation du produit.

Cette page a été traduite par l'API Cloud Translation.

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 Google Distributed Cloud offre des fonctionnalités et des correctifs supplémentaires à votre cluster. 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 ou de kubectl.

Pour en savoir plus sur le processus de mise à niveau et les règles de gestion des versions, consultez la section Cycle de vie et étapes des mises à niveau de cluster.

Cette page est destinée aux administrateurs, aux architectes et aux opérateurs qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Planifier votre mise à niveau

Cette section contient des informations et des liens vers des informations que vous devez prendre en compte avant de mettre à niveau un cluster. Pour en savoir plus sur les mises à niveau, y compris les règles de gestion des versions pour les clusters et les pools de nœuds, consultez la section Cycle de vie et étapes des mises à niveau de cluster.

Bonnes pratiques

Pour vous aider à vous préparer à une mise à niveau de cluster, consultez la page Bonnes pratiques pour les mises à niveau de clusters Google Distributed Cloud.

Mettre à niveau les requêtes 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 requêtes préliminaires, consultez la section Comprendre les requêtes préliminaires.

Vous pouvez vérifier si les clusters sont prêts à être mis à niveau en exécutant la requête préliminaire avant de lancer la mise à niveau. Pour en savoir plus, consultez la section Requêtes préliminaires aux mises à niveau.

Problèmes connus

Pour en savoir plus sur les problèmes potentiels liés aux mises à niveau de clusters, consultez la section Problèmes connus de Google Distributed Cloud pour bare metal et sélectionnez la catégorie de problèmes Mises à niveau et mises à jour.

Configurer les options de mise à niveau

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

Mises à niveau sélectives des pools de nœuds de calcul: mettez à niveau des pools de nœuds de calcul spécifiques séparément du reste du cluster.
Mises à niveau parallèles : 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 de perturbations des applications et services critiques, et réduire considérablement le temps de mise à niveau global. Ces options sont particulièrement utiles pour les grands clusters comportant de nombreux nœuds et pools de nœuds exécutant des charges de travail importantes. Pour en savoir plus sur la fonction de ces options et 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 chaque pool de nœuds du cluster. Une mise à niveau de cluster peut être perturbatrice et prendre du temps, car elle entraîne l'épuisement de chaque nœud et le redémarrage et la reprogrammation de tous les pods associés. Cette section explique comment inclure ou exclure des pools de nœuds de calcul sélectionnés pour une mise à niveau de cluster afin de minimiser les perturbations de la charge 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 travail.

Vous pouvez utiliser des mises à niveau sélectives de pool de nœuds dans les cas suivants:

Pour récupérer les correctifs de sécurité sans perturber les charges de travail : vous ne pouvez mettre à niveau que les nœuds de votre plan de contrôle (et les nœuds de l'équilibreur de charge) pour appliquer les correctifs 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 afin de 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 la période de maintenance:la mise à niveau d'un grand cluster peut prendre du temps, et il est difficile de prévoir précisément quand elle sera terminée. La durée de la mise à niveau du cluster est proportionnelle au nombre de nœuds mis à niveau. Réduire le nombre de nœuds mis à niveau en excluant des pools de nœuds réduit le temps de mise à niveau. Vous effectuez plusieurs mises à niveau, mais les intervalles de maintenance plus courts et plus prévisibles peuvent vous aider à planifier.

Décalage de deux versions mineures pour le pool de nœuds

Pour les clusters version 1.28 et ultérieures, la version d'un pool de nœuds de calcul peut être antérieure à celle du cluster (plan de contrôle) de deux versions mineures maximum. Avec la compatibilité avec le décalage de version n-2, vous pouvez également sauter une version mineure lorsque vous mettez à niveau un pool de nœuds de calcul à partir de deux versions mineures derrière celle du cluster vers la même version mineure que le cluster.

Cette prise en charge du décalage de version n-2 pour les pools de nœuds de calcul vous offre plus de flexibilité pour planifier les mises à niveau de votre parc.

Par exemple, si vous disposez d'un cluster en version 1.31, vous pouvez avoir des pools de nœuds de calcul pour les versions 1.31, 1.30 et 1.29.

Avant de pouvoir mettre à niveau un cluster, tous les pools de nœuds de calcul doivent être à une version compatible à la fois avec la version actuelle du cluster et la version cible du cluster.

Par exemple, si vous disposez d'un cluster en version 1.29 et de pools de nœuds de calcul en versions 1.29, 1.28 et 1.16, vous devez mettre à niveau les pools de nœuds version 1.16 vers la version 1.28 ou 1.29 avant de pouvoir mettre à jour le cluster vers la version 1.30.

Pour en savoir plus, y compris sur les listes des versions de pool de nœuds de calcul compatibles avec une version de cluster donnée (applicable à la version 1.29 et versions antérieures), consultez la section Règles de gestion des versions des pools de nœuds.

1,30

Dans la version 1.30, la compatibilité avec le décalage de version n-2 pour les pools de nœuds de calcul est disponible en disponibilité générale pour tous les types de clusters. Cette fonctionnalité est activée par défaut pour les clusters en version 1.30.

Les pools de nœuds de n'importe quelle version de correctif des versions mineures 1.28 et 1.29 peuvent être mis à niveau vers n'importe quelle version de correctif en version 1.30, si la version du pool de nœuds est identique ou inférieure à celle du cluster.

1,29

Dans la version 1.29, la compatibilité avec le décalage de version n-2 pour les pools de nœuds de calcul est disponible en disponibilité générale pour tous les types de clusters. Cette fonctionnalité est activée par défaut pour les clusters en version 1.29.

Lorsque nous passons cette fonctionnalité de la version bêta publique à la version en disponibilité générale, les clusters hybrides nécessitent toujours l'annotation bêta dans la situation suivante. Si vous disposez d'un cluster hybride version 1.28.x avec un pool de nœuds de calcul version 1.16.y, vous devez ajouter l'annotation preview.baremetal.cluster.gke.io/two-minor-version-node-pool: enable au cluster avant de le mettre à niveau vers la version 1.29.z :

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:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.28.400-gke.77
  ...

1.28

La compatibilité avec le décalage de version n-2 pour les pools de nœuds de calcul est disponible en preview dans la version 1.28. Pour activer cette fonctionnalité d'aperçu, 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é d'aperçu, le décalage maximal de version 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 pour la mise à niveau sélective des pools de nœuds de calcul, consultez la section Règles de gestion des versions des pools de nœuds dans le "Cycle de vie" et les étapes des mises à niveau du cluster.

Mettre à niveau le plan de contrôle de votre cluster et des 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 :
- Définissez anthosBareMetalVersion dans la spécification NodePool sur la version de mise à niveau cible du cluster.
- Omettez le champ anthosBareMetalVersion de la spécification NodePool ou définissez-la sur une chaîne vide. Par défaut, les pools de nœuds de calcul sont inclus dans les mises à niveau de cluster.
Pour les pools de nœuds de calcul que vous souhaitez exclure de la mise à niveau, définissez anthosBareMetalVersion sur la version actuelle (avant la mise à niveau) du cluster :
Poursuivez la mise à niveau comme décrit dans la section 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. 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 à la version 1.30.0 et 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.31.200-gke.58, mais que vous souhaitiez que wpool02 reste à la version 1.30.0.

L'extrait de 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.31.200-gke.58
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.31.200-gke.58
  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.30.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 de cluster, vous pouvez exécuter une mise à niveau de cluster qui les met à niveau vers la version cible du cluster. Le champ anthosBareMetalVersion de la spécification NodePool des pools de nœuds de calcul qui ont été exclus d'une mise à niveau de cluster est défini sur la version précédente (avant la mise à niveau) du cluster.

Pour mettre à jour les pools de nœuds de calcul avec la version de cluster actuelle, qui a été mise à jour :

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

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.
Poursuivez la mise à niveau comme décrit dans la section 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, qui a été mise à niveau.

Par exemple, supposons que vous ayez mis à niveau votre cluster vers la version 1.31.200-gke.58, mais que le pool de nœuds wpool02 soit toujours à l'ancienne version du cluster, 1.30.0. Les charges de travail s'exécutent correctement sur le pool de nœuds mis à niveau, wpool01. Vous souhaitez donc mettre à niveau wpool02 avec 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 de 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.31.200-gke.58
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.31.200-gke.58
  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

Effectuer un rollback pour mettre à niveau un pool de nœuds

De nombreuses dépendances, telles que la compatibilité avec kubelet ou les plug-ins, peuvent affecter les performances de vos charges de travail. En cas de problème après la mise à niveau d'un pool de nœuds de calcul, vous pouvez effectuer un rollback et rétablir la version précédente du pool de nœuds.

Cette fonctionnalité n'est pas disponible pour toutes les versions de clusters compatibles:

1,30

Pour les clusters de la version 1.30 (clusters avec des nœuds de plan de contrôle en version 1.30), la fonctionnalité de rollback du pool de nœuds est disponible en disponibilité générale et activée par défaut.

1,29

La fonctionnalité de rollback du pool de nœuds est disponible en version preview pour les clusters de la version 1.29 (clusters avec des nœuds de plan de contrôle en version 1.29). Tant que cette fonctionnalité est en version preview, vous devez ajouter l'annotation suivante à la ressource Cluster pour l'activer:

preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable

1.28

La fonctionnalité de rollback du pool de nœuds n'est pas disponible pour les clusters de version mineure 1.28 ou antérieure.

Pour effectuer le rollback d'une mise à niveau d'un pool de nœuds, procédez comme suit:

`bmctl`

Lorsque vous utilisez bmctl pour effectuer un rollback de la mise à niveau d'un pool de nœuds, vous modifiez le fichier de configuration du cluster et appliquez vos modifications à l'aide de la commande bmctl update :

Modifiez les spécifications NodePool dans le fichier de configuration du cluster pour les pools de nœuds de calcul que vous souhaitez rétablir à la version précédente. Définissez anthosBareMetalVersion sur la version précédente (avant la mise à niveau) du cluster.
```
...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.30.500-gke.126
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...
```
Si plusieurs pools de nœuds de calcul sont sélectionnés pour le rollback, la valeur de spec.nodePoolUpgradeStrategy.concurrentNodePools dans la spécification du cluster détermine le nombre de pools de nœuds à annuler en parallèle. Si vous ne souhaitez pas effectuer le rollback des pools de nœuds de calcul simultanément, sélectionnez un pool de nœuds à la fois pour le rollback ou mettez à jour les paramètres nodePoolUpgradeStrategy. De même, la valeur de spec.upgradeStrategy.parallelUpgrade.concurrentNodes dans la spécification NodePool détermine le nombre de nœuds à annuler en parallèle.
Utilisez bmctl update pour appliquer vos modifications de spécification NodePool:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster que vous souhaitez mettre à jour.
- ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster de gestion (administrateur, hybride ou autonome).
Le rollback démarre automatiquement. La commande bmctl update cluster se termine immédiatement, mais le rollback continue de progresser. N'effectuez aucune autre opération sur le cluster pendant le rollback.
Lors de l'exécution du rollback, Google Distributed Cloud effectue les activités suivantes pour chaque nœud :
- Mettez le nœud en mode maintenance.
- Exécutez une tâche de réinitialisation sur le nœud pour le mettre dans un état propre.
- Exécutez les requêtes préliminaires de la machine sur le nœud.
- Exécutez une tâche d'initialisation de la machine sur le nœud pour le réinstaller à la version cible de rollback (avant la mise à niveau).
- Désactivez le mode de maintenance pour le nœud.
À la fin d'un rollback réussi, la valeur de nodePool.status.anthosBareMetalVersion dans la ressource NodePool est définie sur la version de rollback cible.

N'utilisez pas bmctl update et kubectl apply -f de manière interchangeable lorsque vous modifiez le fichier de configuration du cluster. Lorsque ces commandes sont utilisées de manière interchangeable, les contenus renseignés par l'en-tête de la spécification du cluster peuvent être supprimés par inadvertance. Par exemple, vous pouvez utiliser bmctl update pour mettre à jour le fichier de configuration du cluster afin de configurer un miroir de Registre. Le cluster est ensuite renseigné avec spec.nodeConfig.registryMirrors après la réconciliation.

Si vous essayez ensuite de modifier le cluster à l'aide de la configuration du cluster avec la commande kubectl apply -f, le spec.nodeConfig.registryMirrors renseigné par le réconciliateur sur le cluster est supprimé. Ce comportement se produit, car la configuration n'existe pas dans la spécification de configuration du cluster, mais elle existe dans le cluster.

`kubectl`

Vous pouvez effectuer un rollback de la mise à niveau d'un pool de nœuds en utilisant kubectl pour modifier directement la ressource NodePool:

Pour effectuer le rollback d'un pool de nœuds de calcul, ouvrez la ressource NodePool pour la modifier:
```
kubectl edit nodepool NODE_POOL_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- NODE_POOL_NAME : nom du pool de nœuds faisant l'objet d'un rollback.
- CLUSTER_NAMESPACE : nom de l'espace de noms dans lequel le pool de nœuds est déployé. Il s'agit de l'espace de noms du cluster.
- ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster de gestion (administrateur, hybride ou autonome).

Remplacez la valeur de spec.anthosBareMetalVersion par la version précédente (avant la mise à niveau).

...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.30.500-gke.126
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

Enregistrez et fermez la ressource personnalisée NodePool dans votre éditeur.

Le rollback démarre automatiquement. N'effectuez aucune autre opération sur le cluster pendant le rollback.
Lors de l'exécution du rollback, Google Distributed Cloud effectue les activités suivantes pour chaque nœud :
- Mettez le nœud en mode maintenance.
- Exécutez une tâche de réinitialisation sur le nœud pour le mettre dans un état propre.
- Exécutez les requêtes préliminaires de la machine sur le nœud.
- Exécutez une tâche d'initialisation de la machine sur le nœud pour le réinstaller à la version cible de rollback (avant la mise à niveau).
- Désactivez le mode de maintenance pour le nœud.
À la fin d'un rollback réussi, la valeur de nodePool.status.anthosBareMetalVersion dans la ressource NodePool est définie sur la version de rollback cible.

Mises à niveau parallèles

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

Vous pouvez utiliser deux stratégies de mise à niveau parallèles pour accélérer la mise à niveau de cluster :

Mise à niveau simultanée des nœuds:vous pouvez configurer vos pools de nœuds de calcul afin que plusieurs nœuds soient mis à niveau simultanément. Les mises à niveau simultanées des nœuds sont configurées dans la spécification NodePool (spec.upgradeStrategy.parallelUpgrade), et 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 par un. Pour en savoir plus, consultez la section Stratégie de mise à niveau des nœuds.
Mise à niveau simultanée du pool de nœuds : vous pouvez configurer votre cluster afin que plusieurs pools de nœuds soient mis à niveau simultanément. Seuls les pools de nœuds de calcul peuvent être mis à niveau simultanément. 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 afin 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 NodePool. Pour en savoir plus sur ces champs, consultez la documentation de référence des champs 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 de nœud pour les pools de nœuds de plan de contrôle ou d'équilibreur de charge. Lors d'une mise à niveau de cluster, les nœuds du plan de contrôle et des pools de nœuds d'é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 des 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 15, la valeur la plus faible étant retenue. Par exemple, si votre pool de nœuds compte 20 nœuds, vous ne pouvez pas spécifier une valeur supérieure à 10. Si votre pool de nœuds comporte 100 nœuds, 15 est la valeur maximale que vous pouvez spécifier.
Lorsque vous utilisez concurrentNodes avec minimumAvailableNodes, les valeurs combinées ne peuvent pas dépasser le nombre total de nœuds du pool de nœuds. Par exemple, si votre pool de nœuds compte 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 montre un pool de nœuds de calcul np1 avec 10 nœuds. Dans une mise à niveau, les nœuds sont mis à niveau par cinq et au moins quatre 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 des pools de nœuds

Vous pouvez configurer un cluster afin que plusieurs pools de nœuds de calcul soient mis à niveau simultanément. Le champ booléen nodePoolUpgradeStrategy.concurrentNodePools de la spécification du 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.

Ce paramètre n'a pas d'incidence sur le plan de contrôle et les pools de nœuds d'équilibrage de charge. 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 parallèle

Cette section explique comment configurer un cluster et un pool de nœuds de calcul pour les 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 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 pendant toute la mise à niveau.

Remarque :Vous ne pouvez pas spécifier de stratégie de mise à niveau de nœud pour les pools de nœuds de plan de contrôle ou d'équilibreur de charge.
Ajoutez une section nodePoolUpgradeStrategy à la spécification de 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.31.200-gke.58
  ...
  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 des pools de nœuds est définie dans les spécifications de pool de nœuds.
Mettez à niveau le cluster comme décrit dans la section Mettre à niveau des clusters d'administrateur, autonomes, hybrides ou d'utilisateur précédente.

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

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

Le tableau suivant répertorie 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 du pool de nœuds)	`1`	Mettez à niveau les nœuds de manière séquentielle, l'un après l'autre.
`upgradeStrategy.parallelUpgrade.minimumAvailableNodes` (Spécification du pool de nœuds)	La valeur par défaut de `minimumAvailableNodes` 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 s'arrête une fois que `minimumAvailableNodes` est atteint et ne se poursuit que lorsque le nombre de nœuds disponibles est supérieur à `minimumAvailableNodes`.

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

Définissez vos identifiants utilisateur en tant qu'identifiants par défaut de l'application (ADC):
```
gcloud auth application-default login
```
Suivez les instructions pour sélectionner votre compte Google pour l'ADC. Pour en savoir plus, consultez la page Configurer les identifiants par défaut de l'application.
Téléchargez la dernière version de bmctl comme décrit dans la section Téléchargements de Google Distributed Cloud.
Mettez à jour anthosBareMetalVersion dans le fichier de configuration du cluster avec la version cible de la 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 avec 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.31.200-gke.58
```
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.
Remarque :La commande bmctl upgrade ne met à jour que la valeur anthosBareMetalVersion et les annotations d'aperçu dans la ressource personnalisée du cluster. Si vous souhaitez modifier d'autres champs de la spécification du cluster, utilisez la commande bmctl update. Pour en savoir plus, consultez la page Mettre à jour les clusters.

L'opération de mise à niveau du cluster exécute des requêtes préliminaires pour valider l'état du cluster et des nœuds. La mise à niveau du cluster s'interrompt si les requêtes préliminaires échouent. Pour en savoir plus, consultez la section 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 du cluster 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, elles continuent de s'exécuter jusqu'à ce qu'elles réussissent. Lorsque toutes les vérifications d'état sont réussies, la mise à niveau est terminée.

Pour en savoir plus sur la séquence d'événements des mises à niveau de cluster, consultez la section Cycle de vie et étapes des mises à niveau de 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, les requêtes préliminaires sont exécutées dans le cadre de la mise à niveau du cluster pour valider l'état du cluster et des nœuds. 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 page 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 effectuer la mise à niveau des clusters 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 les vérifications d'état et les sauvegardes, afin de garantir le bon fonctionnement de votre cluster.

Mettre en pause et reprendre les mises à niveau

La fonctionnalité de mise en pause et de reprise de la mise à niveau vous permet de suspendre la mise à niveau d'un cluster avant qu'elle ne soit terminée. Lorsqu'une mise à niveau de cluster est suspendue, aucune nouvelle mise à niveau de nœud de calcul n'est déclenchée tant que la mise à niveau n'a pas repris.

Cette fonctionnalité est disponible en version preview pour les clusters dont tous les nœuds de plan de contrôle sont en version mineure 1.28 ou ultérieure. Cette fonctionnalité est disponible en disponibilité générale pour les clusters dont tous les nœuds de plan de contrôle sont en version mineure 1.29 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 examiner le problème.
Vos intervalles de maintenance sont courts. Vous souhaitez donc suspendre la mise à niveau entre les intervalles.

Lorsqu'une mise à niveau de cluster est suspendue, les opérations suivantes sont acceptées :

Lorsqu'un nouveau nœud est ajouté alors qu'une mise à niveau est suspendue, les jobs de vérification de l'état de la machine ne s'exécutent pas dessus tant que la mise à niveau n'a pas repris et n'est pas terminée.

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

Vous ne pouvez pas lancer une nouvelle mise à niveau de cluster tant qu'une mise à niveau de cluster active est suspendue.

Activer la mise en pause et la reprise de la mise à niveau

Google Distributed Cloud 1.31

La fonctionnalité de suspension et de reprise de la mise à niveau est activée par défaut pour les clusters dont tous les nœuds de plan de contrôle sont en version mineure 1.29 ou ultérieure.

Google Distributed Cloud 1.30

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

Pour activer la mise en pause 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: enable
spec:
...

Pour appliquer la modification, mettez à jour votre cluster :
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster que vous souhaitez mettre à jour.
- ADMIN_KUBECONFIG: pour les clusters d'administrateur, hybrides ou autonomes, saisissez le chemin d'accès au fichier kubeconfig du cluster. Pour un cluster d'utilisateur, saisissez le chemin d'accès au fichier kubeconfig du cluster d'administrateur.
Le champ nodePoolUpgradeStrategy.pause est modifiable. Vous pouvez les ajouter et les modifier à tout moment.

Suspendre une mise à niveau

Pour suspendre une mise à niveau de cluster, définissez nodePoolUpgradeStrategy.pause sur true dans la spécification 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
  ...
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
```
L'opération de 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 pause prolongée, appuyez sur Ctrl+C pour quitter bmctl. Sinon, laissez bmctl s'exécuter.

La CLI bmctl ne détecte pas les modifications de l'état de la mise à niveau en attente. Elle ne s'arrête donc pas automatiquement. Toutefois, lorsque vous quittez bmctl, la progression de la mise à niveau n'est plus enregistrée dans le fichier journal cluster-upgrade-TIMESTAMP du dossier du cluster sur votre poste de travail administrateur ni dans Cloud Logging. Par conséquent, pour les pauses courtes, vous pouvez laisser bmctl en cours d'exécution. Si vous laissez bmctl s'exécuter pendant une longue période alors que la mise à niveau est suspendue, il 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 du cluster ou supprimez nodePoolUpgradeStrategy.pause de la spécification.

Pour reprendre une mise à niveau de 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
  ...
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
```
L'opération de 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 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 des ressources individuelles:

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 utilise la version 1.16.2 de Google Distributed Cloud.