Cycle de vie et étapes des mises à niveau du cluster

Lorsque vous mettez à niveau Google Distributed Cloud, le processus de mise à niveau implique plusieurs étapes et composants. Pour vous aider à surveiller l'état de la mise à niveau, ou à diagnostiquer et résoudre les problèmes, il est utile de savoir ce qui se passe lorsque vous exécutez la commande bmctl upgrade cluster. Ce document détaille les composants et les étapes d'une mise à niveau d'un cluster.

Présentation

Le processus de mise à niveau déplace votre cluster Google Distributed Cloud de sa version actuelle vers une version supérieure.

Ces informations de version sont stockées aux emplacements suivants dans le cadre de la ressource personnalisée de cluster du cluster d'administrateur:

  • status.anthosBareMetalVersion: définit la version actuelle du cluster.

  • spec.anthosBareMetalVersion: définit la version cible. Il est défini lorsque le processus de mise à niveau commence à s'exécuter.

Une opération de mise à niveau réussie rapproche status.anthosBareMetalVersion de spec.anthosBareMetalVersion afin que tous deux affichent la version cible.

Décalage entre les versions du cluster

Le décalage entre les versions d'un cluster correspond à la différence de versions entre un cluster de gestion (hybride ou administrateur) et ses clusters d'utilisateur gérés. Lorsque vous ajoutez ou mettez à niveau un cluster d'utilisateur, les règles de version suivantes s'appliquent:

1.29

Les règles suivantes s'appliquent aux clusters d'utilisateur gérés par un cluster d'administrateur ou un cluster hybride de version 1.29:

  • Les versions du cluster d'utilisateur ne peuvent pas être supérieures à la version du cluster de gestion (administrateur ou hybride).

  • (1.29 Preview) Les clusters d'utilisateur peuvent correspondre à une version mineure jusqu'à deux versions inférieures à la version du cluster de gestion. Par exemple, un cluster d'administrateur version 1.29 peut gérer un cluster d'utilisateur 1.16. Cette gestion du décalage de version n-2 est disponible en tant que fonctionnalité Preview pour gérer les clusters dans la version 1.29.

  • (1.29 Aperçu) Pour un cluster de gestion donné, les clusters d'utilisateur n'ont pas besoin d'avoir la même version mineure les uns que les autres. Par exemple, un cluster d'administrateur de version 1.29 peut gérer les clusters d'utilisateur de la version 1.29, de la version 1.28 et de la version 1.16. Cette gestion du décalage entre les versions est disponible en tant que fonctionnalité de preview pour gérer les clusters dans la version 1.29.

    La fonctionnalité de gestion multi-asymétrie Preview vous offre plus de flexibilité pour planifier les mises à niveau de votre parc. Par exemple, vous n'êtes pas obligé de mettre à niveau tous les clusters d'utilisateur de la version 1.16 vers la version 1.28 avant de pouvoir mettre à niveau votre cluster d'administrateur vers la version 1.29.

1.28 et versions antérieures

Les règles suivantes s'appliquent aux clusters d'utilisateur gérés par un cluster d'administrateur ou un cluster hybride de version 1.28 ou antérieure:

  • Les versions du cluster d'utilisateur ne peuvent pas être supérieures à la version du cluster de gestion (administrateur ou hybride).

  • La version des clusters d'utilisateur peut être antérieure d'une version mineure à une version du cluster de gestion. Par exemple, un cluster d'administrateur version 1.28 ne peut pas gérer un cluster d'utilisateur dans la version 1.15.

  • Pour un cluster de gestion donné, tous les clusters d'utilisateur gérés doivent utiliser la même version mineure.

Pour en savoir plus sur les règles d'asymétrie des versions pour les pools de nœuds, consultez la page Règles de gestion des versions des pools de nœuds.

Règles relatives aux versions

Lorsque vous téléchargez et installez une nouvelle version de bmctl, vous pouvez mettre à jour vos clusters d'administrateur, vos clusters hybrides, vos clusters autonomes et vos clusters d'utilisateur créés ou mis à jour avec une version antérieure de bmctl. Les clusters ne peuvent pas revenir à une version antérieure.

Vous ne pouvez mettre à jour un cluster que vers une version qui correspond à la version de bmctl que vous utilisez. Autrement dit, si vous utilisez la version 1.29.100-gke.251 de bmctl, vous ne pouvez mettre à niveau un cluster que vers la version 1.29.100-gke.251.

Mises à niveau de versions de correctif

Pour une version mineure donnée, vous pouvez passer à n'importe quelle version de correctif supérieure. Autrement dit, vous pouvez mettre à jour un cluster de version 1.29.X vers la version 1.29.Y tant que Y est supérieur à X. Par exemple, vous pouvez passer de la version 1.28.0 à la version 1.28.100 et de la version 1.28.100 à la version 1.28.300. Nous vous recommandons, autant que possible, de procéder à la mise à niveau vers la dernière version du correctif, afin de vous assurer que vos clusters disposent des derniers correctifs de sécurité.

Mises à niveau de versions mineures

Vous pouvez mettre à jour les clusters d'une version mineure à la suivante, quelle que soit la version de correctif. Autrement dit, vous pouvez passer de la version 1.N.X à la version 1.N+1.Y, où 1.N.X est la version de votre cluster et N+1 est la prochaine version mineure disponible. Dans ce cas, les versions de correctif, X et Y, n'ont pas d'incidence sur la logique de mise à niveau. Par exemple, vous pouvez passer de 1.28.500-gke.120 à 1.29.100-gke.251.

Vous ne pouvez pas ignorer les versions mineures lors de la mise à niveau des clusters. Si vous essayez de passer à une version mineure qui est supérieure d'au moins deux versions mineures à la version du cluster, bmctl renvoie une erreur. Par exemple, vous ne pouvez pas mettre à jour un cluster de version 1.16.0 vers la version 1.29.0.

Un cluster d'administrateur peut gérer des clusters d'utilisateur qui correspondent à la même version mineure, ou à une version mineure précédente. La version d'un cluster d'utilisateur géré ne peut pas être inférieure de plus d'une version mineure à celle du cluster d'administrateur. Avant de mettre à jour un cluster d'administrateur vers une nouvelle version mineure, assurez-vous donc que tous les clusters d'utilisateur gérés correspondent à la même version mineure que le cluster d'administrateur.

Règles de gestion des versions des pools de nœuds

Lorsque vous mettez à niveau des pools de nœuds de manière sélective, les règles de version suivantes s'appliquent:

1.29

  • La version du cluster doit être supérieure ou égale à la version du pool de nœuds de calcul.

  • (1.29 GA) Le décalage maximal entre les versions entre un pool de nœuds de calcul et le cluster est de deux versions mineures.

  • La version des pools de nœuds de calcul ne peut pas être publiée chronologiquement après celle du cluster. La version précédente ne dispose pas des détails complets de la version ultérieure, ce qui est une exigence de compatibilité.

    Par exemple, la version 1.16.6 publiée après la version 1.28.100-gke.146. Par conséquent, vous ne pouvez pas mettre à niveau votre cluster de la version 1.16.6 vers la version 1.28.100-gke.146 et laisser un pool de nœuds de calcul sur la version 1.16.6. De même, si vous mettez à niveau votre cluster vers la version 1.28.100-gke.146, mais que vous avez choisi de laisser un pool de nœuds de calcul à la version 1.16.5, vous ne pouvez pas mettre à niveau ce pool vers la version 1.16.6 tant que le cluster est à la version 1.28.100-gke.146.

1.28

  • La version du cluster doit être supérieure ou égale à la version du pool de nœuds de calcul.

  • (1.28 Preview) Le décalage de version maximal entre un pool de nœuds de calcul et le cluster est de deux versions mineures lorsque le décalage de version n-2 Preview est activé. Si vous n'activez pas cette fonctionnalité, le décalage maximal entre les versions entre un pool de nœuds de calcul et le cluster est d'une version mineure.

  • La version des pools de nœuds de calcul ne peut pas être publiée chronologiquement après celle du cluster. La version précédente ne dispose pas des détails complets de la version ultérieure, ce qui est une exigence de compatibilité.

    Par exemple, la version 1.16.6 publiée après la version 1.28.100-gke.146. Par conséquent, vous ne pouvez pas mettre à niveau votre cluster de la version 1.16.6 vers la version 1.28.100-gke.146 et laisser un pool de nœuds de calcul sur la version 1.16.6. De même, si vous mettez à niveau votre cluster vers la version 1.28.100-gke.146, mais que vous avez choisi de laisser un pool de nœuds de calcul à la version 1.16.5, vous ne pouvez pas mettre à niveau ce pool vers la version 1.16.6 tant que le cluster est à la version 1.28.100-gke.146.

1.16

  • La version du cluster doit être supérieure ou égale à la version du pool de nœuds de calcul.

  • Le décalage maximal entre les versions entre un pool de nœuds de calcul et le cluster est d'une version mineure.

  • La version des pools de nœuds de calcul ne peut pas être publiée chronologiquement après celle du cluster. La version précédente ne dispose pas des détails complets de la version ultérieure, ce qui est une exigence de compatibilité.

    Par exemple, la version 1.16.6 publiée après la version 1.28.100-gke.146. Par conséquent, vous ne pouvez pas mettre à niveau votre cluster de la version 1.16.6 vers la version 1.28.100-gke.146 et laisser un pool de nœuds de calcul sur la version 1.16.6. De même, si vous mettez à niveau votre cluster vers la version 1.28.100-gke.146, mais que vous avez choisi de laisser un pool de nœuds de calcul à la version 1.16.5, vous ne pouvez pas mettre à niveau ce pool vers la version 1.16.6 tant que le cluster est à la version 1.28.100-gke.146.

Le tableau suivant répertorie les versions de pool de nœuds compatibles autorisées pour une version de cluster spécifique:

1.29

Version du cluster (plan de contrôle) Versions compatibles des pools de nœuds de calcul
1.29.100-gke.251
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.0-gke.1449
  • 1.29.0-gke.1449
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0

1.28

Version du cluster (plan de contrôle) Versions compatibles des pools de nœuds de calcul
1.28.500-gke.120
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.400-gke.77
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.300-gke.131
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.200-gke.118
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.100-gke.146
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.0-gke.425
  • 1.28.0-gke.425
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

     

     

     

1.16

Version du cluster (plan de contrôle) Versions compatibles des pools de nœuds de calcul
1.16.9
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.8
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.7
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.6
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.5
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.4
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.3
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.2
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.1
  • 1.16.1
  • 1.16.0
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.0
  • 1.16.0
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

Mettre à niveau les composants

Les composants sont mis à niveau au niveau du nœud et au niveau du cluster. Au niveau du cluster, les composants suivants sont mis à niveau:

  • Composants de cluster pour la mise en réseau, l'observabilité et le stockage
  • Pour les clusters d'administration, hybrides et autonomes : les contrôleurs de cycle de vie.
  • gke-connect-agent

Les nœuds d'un cluster s'exécutent sous l'un des rôles suivants, avec différents composants mis à niveau en fonction du rôle du nœud:

Rôle du nœud Fonction Composants à mettre à niveau
Nœud de calcul Exécute les charges de travail des utilisateurs Kubelet, environnement d'exécution de conteneur (Docker ou containerd)
Plan de contrôle Exécute le plan de contrôle Kubernetes, les contrôleurs de cycle de vie du cluster et les modules complémentaires de la plate-forme Google Kubernetes Engine (GKE) Enterprise Edition Pods statiques du plan de contrôle Kubernetes (kubeapi-server, kube-scheduler, kube-controller-manager, etcd)

Contrôleurs de cycle de vie tels que lifecycle-controllers-manager et anthos-cluster-operator

Modules complémentaires de la plate-forme Google Kubernetes Engine (GKE) Enterprise, comme stackdriver-log-aggregator et gke-connect-agent
Équilibreur de charge du plan de contrôle Exécute HAProxy et Keepafid qui diffusent du trafic vers kube-apiserver, et exécuter des enceintes MetalLB pour revendiquer des adresses IP virtuelles Pods statiques de l'équilibreur de charge du plan de contrôle (HAProxy, KeepaHosted)

Haut-parleurs MetalLB

Estimation des temps d'arrêt

Le tableau suivant détaille le temps d'arrêt prévu et l'impact potentiel lors de la mise à niveau des clusters. Dans ce tableau, nous partons du principe que vous disposez de plusieurs nœuds de cluster et d'un plan de contrôle haute disponibilité. Si vous exécutez un cluster autonome ou si vous ne disposez pas d'un plan de contrôle haute disponibilité, prévoyez un temps d'arrêt supplémentaire. Sauf indication contraire, ce temps d'arrêt s'applique aux mises à niveau des clusters d'administrateur et d'utilisateur:

Composants Attentes concernant les temps d'arrêt En cas de temps d'arrêt
Serveur d'API du plan de contrôle Kubernetes (kube-apiserver), etcd et programmeur Aucun temps d'arrêt Non disponible
Contrôleurs de cycle de vie et job ansible-runner (cluster d'administrateur uniquement) Aucun temps d'arrêt Non disponible
Plans de contrôle Kubernetes loadbalancer-haproxy et keepalived Temps d'arrêt temporaire (moins de 1 à 2 minutes) lorsque l'équilibreur de charge redirige le trafic. Début du processus de mise à niveau.
Observabilité pipeline-stackdriver et metrics-server Opérateur drainé et mis à niveau. Le temps de pause doit être inférieur à cinq minutes.

Les DaemonSets continuent de fonctionner sans temps d'arrêt.		 Une fois la mise à niveau des nœuds du plan de contrôle terminée.
Interface réseau de conteneur (CNI) Aucun temps d'arrêt pour les routes réseau existantes.

Le DaemonSet a été déployé deux par deux sans temps d'arrêt.

L'opérateur est drainé et mis à niveau. Temps de pause inférieur à 5 minutes.		 Une fois la mise à niveau des nœuds du plan de contrôle terminée.
MetalLB (cluster d'utilisateur uniquement) Opérateur drainé et mis à niveau. Le temps de pause est inférieur à cinq minutes.

Aucun temps d'arrêt pour le service existant		 Une fois la mise à niveau des nœuds du plan de contrôle terminée.
CoreDNS et autoscaler DNS (cluster d'utilisateur uniquement) CoreDNS dispose de plusieurs instances répliquées avec autoscaler. Généralement aucun temps d'arrêt. Une fois la mise à niveau des nœuds du plan de contrôle terminée.
Approvisionneur de volume local Aucun temps d'arrêt pour les volumes persistants provisionnés (PV) existants.

Le temps d'arrêt de l'opérateur peut être de cinq minutes.		 Une fois la mise à niveau des nœuds du plan de contrôle terminée.
Istio / Entrée L'opérateur Istio est drainé et mis à niveau. Environ 5 minutes de temps d'arrêt

Les entrées configurées existantes continuent de fonctionner.		 Une fois la mise à niveau des nœuds du plan de contrôle terminée.
Autres opérateurs système Temps d'arrêt de 5 minutes lorsque les appareils sont vidés et mis à niveau. Une fois la mise à niveau des nœuds du plan de contrôle terminée.
Charges de travail utilisateur Cela dépend de la configuration (disponibilité élevée, par exemple).

Examinez vos propres déploiements de charges de travail pour comprendre leur impact potentiel.		 Lorsque les nœuds de calcul sont mis à niveau.

Détails de la mise à niveau du cluster d'utilisateur

Cette section détaille l'ordre des mises à niveau des composants et les informations sur l'état d'une mise à niveau du cluster d'utilisateur. La section suivante détaille les écarts par rapport à ce flux pour les mises à niveau de clusters administrateur, hybrides ou autonomes.

Le schéma suivant illustre le processus de vérification préliminaire pour une mise à niveau d'un cluster d'utilisateur:

La vérification préliminaire du cluster exécute des vérifications de l'état supplémentaires sur le cluster avant le début du processus de mise à niveau.

Le schéma précédent détaille les étapes qui se produisent lors d'une mise à niveau:

  • La commande bmctl upgrade cluster crée une ressource personnalisée PreflightCheck.
  • Cette vérification préliminaire exécute des vérifications supplémentaires, telles que des vérifications de la mise à niveau du cluster, des vérifications de l'état du réseau et des vérifications de l'état des nœuds.
  • Les résultats de ces vérifications supplémentaires se combinent pour indiquer la capacité du cluster à être mis à niveau vers la version cible.

Si les vérifications préliminaires aboutissent et qu'il n'y a pas de problème bloquant, les composants du cluster sont mis à niveau dans un ordre spécifié, comme illustré dans le schéma suivant:

Les équilibreurs de charge du plan de contrôle et le pool de nœuds du plan de contrôle sont mis à niveau, puis GKE Connect, les modules complémentaires du cluster, ainsi que le pool de nœuds de l'équilibreur de charge et les pools de nœuds de calcul sont mis à niveau.

Dans le schéma précédent, les composants sont mis à niveau dans l'ordre suivant:

  1. La mise à niveau commence par la mise à jour du champ spec.anthosBareMetalVersion.
  2. Les équilibreurs de charge du plan de contrôle sont mis à niveau.
  3. Le pool de nœuds du plan de contrôle est mis à niveau.
  4. En parallèle, GKE Connect est mis à niveau, les modules complémentaires du cluster et le pool de nœuds de l'équilibreur de charge sont mis à niveau.
    1. Une fois le pool de nœuds de l'équilibreur de charge mis à niveau, les pools de nœuds de calcul le sont également.

  5. Une fois tous les composants mis à niveau, des vérifications de l'état du cluster sont exécutées.

    Les vérifications de l'état continuent de s'exécuter jusqu'à ce qu'elles soient toutes validées.

  6. Une fois toutes les vérifications d'état effectuées, la mise à niveau est terminée.

Chaque composant possède son propre champ d'état dans la ressource personnalisée du cluster. Vous pouvez vérifier l'état dans les champs suivants pour comprendre la progression de la mise à niveau:

Séquence Nom du champ Signification
1 status.controlPlaneNodepoolStatus L'état est copié à partir de l'état du pool de nœuds du plan de contrôle. Ce champ inclut les versions des nœuds des pools de nœuds du plan de contrôle
2 status.anthosBareMetalLifecycleControllersManifestsVersion Version de lifecycles-controllers-manager appliquée au cluster. Ce champ n'est disponible que pour les clusters d'administration, autonomes ou hybrides.
2 status.anthosBareMetalManifestsVersion Version du cluster issue du dernier fichier manifeste appliqué.
2 status.controlPlaneLoadBalancerNodepoolStatus L'état est copié à partir de l'état du pool de nœuds de l'équilibreur de charge du plan de contrôle. Ce champ est vide si aucun équilibreur de charge de plan de contrôle distinct n'est spécifié dans Cluster.Spec.
3 status.anthosBareMetalVersions Mappage des versions agrégées des versions aux numéros de nœuds.
4 status.anthosBareMetalVersion État final de la version mise à niveau.

Détails de la mise à niveau des clusters pour les administrateurs, les clusters hybrides et les clusters autonomes

À partir de la version 1.15.0 de bmctl, le comportement de mise à niveau par défaut pour les clusters autogérés (administrateurs, hybrides ou autonomes) est une mise à niveau sur place. Autrement dit, lorsque vous mettez à niveau un cluster vers la version 1.15.0 ou une version ultérieure, la mise à niveau utilise des contrôleurs de cycle de vie, au lieu d'un cluster d'amorçage, pour gérer l'ensemble du processus de mise à niveau. Cette modification simplifie le processus et réduit les besoins en ressources, ce qui rend les mises à niveau des clusters plus fiables et évolutives.

Bien qu'il ne soit pas recommandé d'utiliser un cluster d'amorçage pour la mise à niveau, cette option reste disponible. Pour utiliser un cluster d'amorçage lors de la mise à niveau, exécutez la commande bmctl upgrade avec l'option --use-bootstrap=true. Les étapes de la mise à niveau sont différentes selon la méthode utilisée.

Mises à niveau sur place

Le processus par défaut de mise à niveau sur place pour les clusters autogérés est semblable au processus de mise à niveau des clusters d'utilisateur. Toutefois, lorsque vous utilisez le processus de mise à niveau sur place, une nouvelle version de preflightcheck-operator est déployée avant l'exécution de la vérification préliminaire et des vérifications de l'état du cluster:

Une nouvelle version de l'opérateur preflightcheck-operator est déployée avant que la vérification préliminaire du cluster n'exécute des vérifications d'état supplémentaires sur le cluster.

Comme pour la mise à niveau du cluster d'utilisateur, le processus de mise à niveau commence par la mise à jour du champ Cluster.spec.anthosBareMetalVersion avec la version cible. Deux étapes supplémentaires s'exécutent avant la mise à jour des composants, comme illustré dans le schéma suivant: lifecycle-controller-manager se met à niveau vers la version cible, puis déploie la version cible de anthos-cluster-operator. Ce anthos-cluster-operator effectue les étapes restantes du processus de mise à niveau:

Le contrôleur de cycle de vie et l'opérateur anthos-cluster sont déployés avant la mise à niveau du reste du cluster, dans le même ordre que les composants du cluster d'utilisateur.

En cas de réussite, anthos-cluster-operator rapproche la version cible de spec.anthosBareMetalVersion à status.anthosBareMetalVersion.

Mettre à niveau avec un cluster d'amorçage

Le processus de mise à niveau d'un cluster d'administrateur, hybride ou autonome est semblable à celui d'un cluster d'utilisateur décrit dans la section précédente.

La principale différence est que la commande bmctl upgrade cluster lance un processus pour créer un cluster d'amorçage. Ce cluster d'amorçage est un cluster temporaire qui gère le cluster hybride, d'administrateur ou autonome lors d'une mise à niveau.

Le processus permettant de transférer la propriété de la gestion du cluster au cluster d'amorçage est appelé pivot. Le reste de la mise à niveau suit le même processus que celui du cluster d'utilisateur.

Pendant le processus de mise à niveau, les ressources du cluster cible restent obsolètes. La progression de la mise à niveau n'est reflétée que dans les ressources du cluster d'amorçage.

Si nécessaire, vous pouvez accéder au cluster d'amorçage pour surveiller et déboguer le processus de mise à niveau. Le cluster d'amorçage est accessible via bmctl-workspace/.kindkubeconfig.

Pour transférer à nouveau la propriété de la gestion du cluster une fois la mise à niveau terminée, le cluster fait pivoter les ressources du cluster d'amorçage vers le cluster mis à niveau. Aucune étape manuelle n'est requise pour faire pivoter le cluster pendant le processus de mise à niveau. Le cluster d'amorçage est supprimé une fois sa mise à niveau terminée.

Drainage de nœud

Les mises à niveau des clusters Google Distributed Cloud peuvent entraîner des perturbations d'application en raison du drainage des nœuds. Ce processus de drainage entraîne l'arrêt et le redémarrage de tous les pods exécutés sur un nœud sur les nœuds restants du cluster.

Les déploiements peuvent être utilisés pour tolérer de telles perturbations. Un déploiement peut spécifier plusieurs instances répliquées d'une application ou d'un service à exécuter. Une application comportant plusieurs instances répliquées ne devrait subir que peu ou pas d'interruptions lors des mises à niveau.

PodDisruptionBudgets (PDB)

Lorsque vous mettez à niveau un cluster, Google Distributed Cloud utilise le flux de mode de maintenance pour drainer les nœuds.

À partir de la version 1.29, les nœuds sont drainés par l'API Eviction, qui respecte les PodDisruptionBudgets (PDB). Les PDB permettent de garantir qu'un nombre défini d'instances répliquées s'exécutent toujours dans le cluster dans des conditions d'exécution normales. Les PDB vous permettent de limiter les interruptions d'une charge de travail lorsque ses pods doivent être replanifiés. Le drainage de nœuds basé sur l'éviction est disponible en disponibilité générale à partir de la version 1.29.

Dans les versions 1.28 et antérieures, Google Distributed Cloud ne respecte pas les PDB lorsque les nœuds se drainent lors d'une mise à niveau. À la place, le processus de drainage des nœuds s'effectue de façon optimale. Certains pods peuvent rester bloqués à l'état Terminating et refuser de quitter le nœud. La mise à niveau se poursuit, même avec des pods bloqués, lorsque le processus de drainage sur un nœud prend plus de 20 minutes.

Pour en savoir plus, consultez la section Placer des nœuds en mode maintenance.

Étapes suivantes