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 apporte des fonctionnalités et des correctifs supplémentaires à votre cluster. Cela garantit également que votre cluster reste compatible. Vous pouvez mettre à niveau un cluster d'administrateur, hybride, autonome ou d'utilisateur à l'aide de la commande bmctl upgrade cluster, ou vous pouvez utiliser 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 du cluster.

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 les mises à niveau des clusters Google Distributed Cloud.

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 exécutant la 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 de Google Distributed Cloud pour Bare Metal et sélectionnez la catégorie de problème Mises à niveau et mises à jour.

Configurer les options de mise à niveau

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

Ces options peuvent réduire le risque d'interruptions 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 les pools de nœuds exécutant des charges de travail importantes. Pour en savoir plus sur le fonctionnement 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 pool de nœuds du cluster. Une mise à niveau d'un cluster peut être perturbatrice et chronophage, car elle entraîne le drainage de chaque nœud, ainsi que le redémarrage et la reprogrammation 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 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 calcul.

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

  • Pour appliquer les correctifs de sécurité sans perturber les charges de travail:vous pouvez uniquement mettre à niveau les nœuds du 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 vérifier le bon fonctionnement d'un sous-ensemble de nœuds de calcul mis à niveau avant de mettre à niveau tous les nœuds de calcul:avant de mettre à niveau un autre pool de 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.

  • 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édire avec précision la date de fin d'une mise à niveau. Le temps de mise à niveau du cluster est proportionnel au nombre de nœuds mis à niveau. La réduction du 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 petits et plus prévisibles peuvent faciliter la planification.

Décalage entre les versions du pool de nœuds avec deux versions mineures

Pour les clusters de version 1.28 ou ultérieure, la version d'un pool de nœuds de calcul peut être jusqu'à deux versions mineures par rapport à la version du cluster (plan de contrôle). Avec la prise en charge du décalage entre les versions n-2, vous pouvez également ignorer une version mineure lorsque vous mettez à niveau un pool de nœuds de calcul de deux versions mineures derrière le cluster vers la même version mineure que le cluster.

La prise en charge du décalage entre les versions 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 de version 1.28, vous pouvez disposer de pools de nœuds de calcul sous certaines versions 1.28, 1.16 et 1.15. Pour mettre à niveau votre cluster vers la version 1.29, vous devez d'abord mettre à niveau tout pool de nœuds de calcul 1.15 vers une version compatible avec le cluster de la version 1.28 antérieure à la mise à niveau. Vous n'êtes pas obligé de mettre à niveau les pools de nœuds de calcul de la version 1.16 vers la version 1.28 pour pouvoir mettre à niveau votre cluster vers la version 1.29. Une fois le cluster mis à niveau vers la version 1.29, lorsque vous décidez de mettre à niveau les pools de nœuds de calcul de la version 1.16 vers la version 1.29, vous pouvez effectuer la mise à niveau en une seule étape, en ignorant la version 1.28.

Pour en savoir plus et obtenir la liste des versions de pools de nœuds de calcul compatibles avec une version de cluster donnée, consultez la section Règles de gestion des versions des pools de nœuds.

1.29

Dans la version 1.29, la prise en charge du décalage entre les versions n-2 pour les pools de nœuds de calcul est en disponibilité générale pour tous les types de clusters. Cette fonctionnalité est activée par défaut pour les clusters dans la version 1.29.

Lors du passage de cette fonctionnalité de la version Preview publique à la version en disponibilité générale, les clusters hybrides nécessitent toujours l'annotation d'aperçu dans les situations suivantes. Si vous disposez d'un cluster hybride 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 prise en charge du décalage entre la version n-2 pour les pools de nœuds de calcul est disponible en version 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 entre les versions 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 étapes des mises à niveau du cluster".

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:

  1. 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 NodePool, définissez anthosBareMetalVersion sur la version de mise à niveau 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.

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

  3. Poursuivez la mise à niveau comme décrit dans la section Lancer 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 un pool de nœuds de l'équilibreur de charge de manière sélective. 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 utilise la version 1.28.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.29.100-gke.251, mais que vous souhaitiez que wpool02 reste à la version 1.28.0.

L'extrait de fichier de configuration de cluster suivant montre comment modifier la configuration du cluster pour prendre en charge 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.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  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.28.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 les pools de nœuds d'une mise à niveau du cluster, vous pouvez exécuter une mise à niveau de cluster qui les ramène à la version du cluster cible. Pour les pools de nœuds de calcul exclus d'une mise à niveau du cluster, le champ anthosBareMetalVersion de la spécification NodePool est défini sur la version de cluster précédente (avant la mise à niveau).

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

  1. Modifiez les spécifications NodePool dans le fichier de configuration du cluster pour les pools de nœuds de calcul que vous souhaitez utiliser avec 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.

  2. Poursuivez la mise à niveau comme décrit dans la section Lancer 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 de cluster actuelle mise à niveau.

Par exemple, supposons que vous ayez mis à niveau votre cluster vers la version 1.29.100-gke.251, mais que le pool de nœuds wpool02 se trouve toujours sur l'ancienne version de cluster de pré-mise à niveau 1.28.0. Les charges de travail s'exécutant correctement sur le pool de nœuds mis à niveau, wpool01, vous souhaitez également appliquer wpool02 à la version de cluster actuelle. Pour mettre à niveau wpool02, vous pouvez supprimer le champ anthosBareMetalVersion ou définir sa valeur sur une chaîne vide.

L'extrait de fichier de configuration de cluster suivant montre comment modifier la configuration du cluster pour prendre en charge 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.29.100-gke.251
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.29.100-gke.251
  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 le kubelet ou les plug-ins, peuvent affecter les performances de vos charges de travail. Si vous rencontrez un problème après la mise à niveau d'un pool de nœuds de calcul, vous pouvez effectuer un rollback vers sa version précédente.

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 dans la version 1.29). Tant que cette fonctionnalité est en version preview, vous devez ajouter l'annotation preview.baremetal.cluster.gke.io/worker-node-pool-upgrade-rollback: enable à la ressource Cluster pour l'activer.

Pour effectuer un rollback de la 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:

  1. Modifiez les spécifications NodePool dans le fichier de configuration du cluster pour les pools de nœuds de calcul dont vous souhaitez effectuer un rollback vers la version précédente. Définissez anthosBareMetalVersion sur la version précédente du cluster (avant la mise à niveau).

    ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: wpool01
  namespace: cluster-user001
spec:
  clusterName: user001
  anthosBareMetalVersion: 1.28.600-gke.163
  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 faisant l'objet d'un rollback 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 faisant l'objet d'un rollback en parallèle.

  2. Utilisez bmctl update pour appliquer les modifications apportées aux spécifications 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.

  3. Lors de l'exécution du rollback, Google Distributed Cloud effectue les activités suivantes pour chaque nœud:

    • Mettre le nœud en mode maintenance
    • Exécutez un job de réinitialisation sur le nœud pour rétablir son état propre.
    • Exécutez des vérifications préliminaires de la machine sur le nœud.
    • Exécutez une tâche machine-init sur le nœud pour le réinstaller à la version de rollback (avant la mise à niveau) de la cible.
    • Retirez le nœud du mode maintenance.

    À la fin d'un rollback réussi, la valeur de nodePool.status.anthosBareMetalVersion dans la ressource NodePool est définie sur la version cible du rollback.

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:

  1. Pour effectuer un 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 pour lequel vous effectuez 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).

  2. 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.28.600-gke.163
  nodes:
  - address:  10.200.0.1
  - address:  10.200.0.2
  - address:  10.200.0.3
  ...

  3. Enregistrez et fermez la ressource NodePool dans votre éditeur.

    Le rollback démarre automatiquement.

  4. Lors de l'exécution du rollback, Google Distributed Cloud effectue les activités suivantes pour chaque nœud:

    • Mettre le nœud en mode maintenance
    • Exécutez un job de réinitialisation sur le nœud pour rétablir son état propre.
    • Exécutez des vérifications préliminaires de la machine sur le nœud.
    • Exécutez une tâche machine-init sur le nœud pour le réinstaller à la version de rollback (avant la mise à niveau) de la cible.
    • Retirez le nœud du mode maintenance.

    À la fin d'un rollback réussi, la valeur de nodePool.status.anthosBareMetalVersion dans la ressource NodePool est définie sur la version cible du rollback.

Mises à niveau parallèles

Dans 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 explique comment configurer le cluster et les pools de nœuds de calcul afin 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, en particulier pour les clusters comportant des centaines de nœuds.

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

  • Mise à niveau simultanée des nœuds:vous pouvez configurer vos pools de nœuds de calcul pour que plusieurs nœuds soient mis à niveau en parallèle. Les mises à niveau parallèles des nœuds sont configurées selon la spécification du pool de nœuds (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 du plan de contrôle ou des pools de nœuds de l'équilibreur de charge ne peuvent être mis à niveau qu'un à la fois. Pour en savoir plus, consultez Stratégie de mise à niveau des nœuds.

  • Mise à niveau simultanée du pool de nœuds:vous pouvez configurer votre cluster pour 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 pour 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 de pool de nœuds. Pour en savoir plus sur ces champs, consultez la documentation de référence sur les 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 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 les 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 du pool de nœuds ou le nombre fixe 15, selon la valeur la plus petite. Par exemple, si votre pool de nœuds comporte 20 nœuds, vous ne pouvez pas spécifier une valeur supérieure à 10. Si votre pool de nœuds comporte 100 nœuds, vous pouvez spécifier 15 au maximum.

  • 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 montre un pool de nœuds de calcul np1 comportant 10 nœuds. Lors d'une mise à niveau, cinq nœuds sont mis à niveau à la fois, 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 du pool de nœuds

Vous pouvez configurer un cluster pour 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 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:

  1. Ajouter une section upgradeStrategy à la spécification de pool de nœuds.

    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.

  2. 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.29.100-gke.251
  ...
  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 NodePool.

  3. 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 pour la mise à niveau parallèle

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

Le tableau suivant répertorie les champs de mise à niveau parallèles 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 par défaut de minimumAvailableNodes dépend de la valeur de concurrentNodes.
  • Si vous ne spécifiez pas concurrentNodes, minimumAvailableNodes par défaut correspond aux deux tiers de la taille du pool de nœuds.
  • Si vous spécifiez concurrentNodes, minimumAvailableNodes par défaut correspond à la taille du pool de nœuds moins concurrentNodes.
 La mise à niveau se bloque une fois que minimumAvailableNodes est atteint et ne continue 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 la mise à 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.

  1. Téléchargez la dernière version de bmctl, comme décrit dans la section Téléchargements Google Distributed Cloud.

  2. Dans le fichier de configuration du cluster, mettez à jour anthosBareMetalVersion 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.29.100-gke.251

  3. 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 est interrompue si les vérifications préliminaires échouent. Pour obtenir des informations de dépannage, consultez Résoudre les problèmes d'installation ou de mise à niveau d'un 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, 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 des événements des mises à niveau des clusters, consultez la section Cycle de vie et étapes des mises à niveau des clusters.

kubectl

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

  1. Modifiez le fichier de configuration du cluster pour définir anthosBareMetalVersion sur la version cible de la mise à niveau.

  2. 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 du fichier de configuration du cluster modifié.

    Comme pour le processus de mise à niveau avec bmctl, des vérifications préliminaires sont exécutées dans le cadre 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 page Résoudre les problèmes d'installation ou de mise à niveau d'un cluster.

Bien que vous n'ayez pas besoin de la dernière version de bmctl pour mettre à niveau les 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 la vérification de l'état et les sauvegardes, afin de vous assurer que votre cluster reste en bon état de fonctionnement.

Suspendre et reprendre les mises à niveau

La fonctionnalité de suspension et de reprise de la mise à niveau vous permet de suspendre une mise à niveau d'un cluster avant qu'elle ne se termine. Lorsqu'une mise à niveau de cluster est suspendue, aucune nouvelle mise à niveau des nœuds de calcul n'est déclenchée tant que la mise à niveau n'est pas réactivée.

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. La fonctionnalité est 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 au niveau des charges de travail du cluster lors de la mise à niveau et vous souhaitez suspendre la mise à niveau pour examiner le problème.

  • Vous avez des intervalles de maintenance courts et vous souhaitez suspendre la mise à niveau entre deux intervalles.

Lorsqu'une mise à niveau d'un 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 tâches de vérification de la machine ne sont pas exécutées sur celui-ci tant que la mise à niveau n'a pas été relancée et 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 d'un cluster lorsqu'une mise à niveau active d'un cluster est suspendue.

Activer la suspension et la reprise de la mise à niveau

Google Distributed Cloud 1.29

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

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

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

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

  2. Pour appliquer la modification, mettez à jour votre cluster:

    bmctl update CLUSTER_NAME

    Le champ nodePoolUpgradeStrategy.pause est modifiable. Vous pouvez l'ajouter et le modifier à tout moment.

Suspendre une mise à niveau

Pour suspendre la mise à niveau d'un cluster, définissez nodePoolUpgradeStrategy.pause sur true dans la spécification du cluster.

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

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

  2. Pour appliquer la modification, mettez à jour votre cluster:

    bmctl update CLUSTER_NAME

    L'opération de mise à niveau est suspendue. Aucune nouvelle mise à niveau des nœuds n'est déclenchée.

  3. Si vous avez utilisé bmctl pour lancer la mise à niveau et que vous prévoyez une suspension durable, appuyez sur Ctrl+C pour quitter bmctl. Sinon, continuez à exécuter bmctl.

    La CLI bmctl ne détecte pas les modifications de l'état de suspension de la mise à niveau. Elle ne se ferme donc pas automatiquement. Toutefois, lorsque vous quittez bmctl, la mise à niveau de la journalisation s'interrompt jusqu'au fichier journal cluster-upgrade-TIMESTAMP situé dans le dossier du cluster sur 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 alors que la mise à niveau est suspendue, elle finit par expirer.

Reprendre une migration suspendue

Pour reprendre la mise à niveau d'un cluster suspendu, définissez nodePoolUpgradeStrategy.pause sur false dans la spécification du cluster ou supprimez nodePoolUpgradeStrategy.pause de la spécification.

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

  1. Définissez nodePoolUpgradeStrategy.pause sur le fichier de configuration du cluster, puis 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.

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

  3. 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 sur l'é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

  4. 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 présente les détails de BareMetalMachine pour le 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.