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

Lorsque vous mettez à niveau GKE sur une solution Bare Metal, 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 de la mise à niveau d'un cluster.

Présentation

Le processus de mise à niveau déplace votre cluster GKE sur Bare Metal 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 et est défini lorsque le processus de mise à niveau commence à s'exécuter.

Une opération de mise à niveau réussie rapproche status.anthosBareMetalVersion et spec.anthosBareMetalVersion, de sorte que les deux affichent la version cible.

Décalage entre les versions

Le décalage de version est la différence entre les 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:

GKE sur Bare Metal

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

  • Les versions du cluster d'utilisateur ne peuvent pas être supérieures à la version du cluster de gestion (administrateur ou hybride).
  • Les clusters d'utilisateur peuvent présenter jusqu'à deux versions mineures inférieures à la version du cluster de gestion. Par exemple, un cluster d'administrateur de version 1.29 peut gérer un cluster d'utilisateur 1.16. Cette gestion des décalages de version n-2 est disponible en tant que fonctionnalité en version preview pour la gestion des clusters à partir de la version 1.29.
  • 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 version 1.29 peut gérer les clusters d'utilisateur des versions 1.29, 1.28 et 1.16. Cette gestion des décalages de version mixte est disponible en tant que fonctionnalité Preview pour la gestion des clusters dans la version 1.29.

La fonctionnalité de gestion à plusieurs décalages disponible en version 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.

GKE sur Bare Metal

Les règles suivantes s'appliquent aux clusters d'utilisateur gérés par un cluster d'administrateur ou un cluster hybride 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).
  • Les clusters d'utilisateur peuvent présenter une version mineure inférieure à la version du cluster de gestion. Par exemple, un cluster d'administrateur de version 1.28 ne peut pas gérer un cluster d'utilisateur de la version 1.15.
  • Pour un cluster de gestion donné, tous les clusters d'utilisateur gérés doivent avoir la même version mineure.

Règles relatives à la version

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.0-gke.1449 de bmctl, vous ne pouvez mettre à niveau un cluster que vers la version 1.29.0-gke.1449.

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.400-gke.77 à 1.29.0-gke.1449.

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 du pool 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:

GKE sur Bare Metal

  • La version du cluster doit être supérieure ou égale à la version du pool de nœuds de calcul.
  • Le décalage maximal de version 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, publiée chronologiquement, ne peut pas être ultérieure à celle du cluster. La version antérieure ne contient pas les détails complets de la version ultérieure, ce qui est obligatoire pour assurer la compatibilité.

    Par exemple, la version 1.16.6 publiée après la publication de la version 1.28.100-gke.146. Vous ne pouvez donc pas mettre à niveau votre cluster de la version 1.16.6 vers la version 1.28.100-gke.146 tout en conservant un pool de nœuds de calcul à 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 conserver un pool de nœuds de calcul à la version 1.16.5, vous ne pouvez pas mettre à niveau le pool de nœuds de calcul vers la version 1.16.6 tant que le cluster est sur la version 1.28.100-gke.146.

GKE sur Bare Metal

  • La version du cluster doit être supérieure ou égale à la version du pool de nœuds de calcul.
  • Le décalage maximal de version entre un pool de nœuds de calcul et le cluster est de deux versions mineures lorsque la fonctionnalité Preview (Prévisualisation) n-2 est activée. Si vous n'activez pas cette fonctionnalité, le décalage de version maximal entre un pool de nœuds de calcul et le cluster correspond à une version mineure.

  • La version des pools de nœuds de calcul, publiée chronologiquement, ne peut pas être ultérieure à celle du cluster. La version antérieure ne contient pas les détails complets de la version ultérieure, ce qui est obligatoire pour assurer la compatibilité.

    Par exemple, la version 1.16.6 publiée après la publication de la version 1.28.100-gke.146. Vous ne pouvez donc pas mettre à niveau votre cluster de la version 1.16.6 vers la version 1.28.100-gke.146 tout en conservant un pool de nœuds de calcul à 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 conserver un pool de nœuds de calcul à la version 1.16.5, vous ne pouvez pas mettre à niveau le pool de nœuds de calcul vers la version 1.16.6 tant que le cluster est sur la version 1.28.100-gke.146.

GKE sur Bare Metal

  • La version du cluster doit être supérieure ou égale à la version du pool de nœuds de calcul.
  • Le décalage maximal de version 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, publiée chronologiquement, ne peut pas être ultérieure à celle du cluster. La version antérieure ne contient pas les détails complets de la version ultérieure, ce qui est obligatoire pour assurer la compatibilité.

    Par exemple, la version 1.16.6 publiée après la publication de la version 1.28.100-gke.146. Vous ne pouvez donc pas mettre à niveau votre cluster de la version 1.16.6 vers la version 1.28.100-gke.146 tout en conservant un pool de nœuds de calcul à 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 conserver un pool de nœuds de calcul à la version 1.16.5, vous ne pouvez pas mettre à niveau le pool de nœuds de calcul vers la version 1.16.6 tant que le cluster est sur la version 1.28.100-gke.146.

Le tableau suivant répertorie les versions de pools de nœuds compatibles avec une version de cluster spécifique:

GKE sur Bare Metal

Version du cluster (plan de contrôle) Versions compatibles du pool de nœuds de calcul
1.29.0-gke.1239
  • 1.29.0-gke.1239
  • 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

GKE sur Bare Metal

Version du cluster (plan de contrôle) Versions compatibles du pool de nœuds de calcul
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

     

     

     

GKE sur Bare Metal

Version du cluster (plan de contrôle) Versions compatibles du pool de nœuds de calcul
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 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'administrateur, hybrides et autonomes, les contrôleurs de cycle de vie
  • gke-connect-agent

Les nœuds d'un cluster s'exécutent avec l'un des rôles suivants. Différents composants sont 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 des charges de travail de l'utilisateur Kubelet, environnement d'exécution du 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. Pods statiques du plan de contrôle Kubernetes (kubeapi-server, kube-scheduler, kube-controller-manager, etcd)

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

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

Haut-parleurs MetalLB

Attente du temps de pause

Le tableau suivant détaille les temps d'arrêt prévus et l'impact potentiel 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 que vous ne disposez pas d'un plan de contrôle haute disponibilité, attendez-vous à des temps d'arrêt supplémentaires. Sauf indication contraire, ce temps d'arrêt s'applique aux mises à niveau des clusters d'administrateur et d'utilisateur:

Composants Attentes en matière de temps de pause 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 tâche ansible-runner (cluster d'administrateur uniquement) Aucun temps d'arrêt Non disponible
Plan 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.
Container Network Interface (CNI, interface réseau pour conteneurs) Aucun temps d'arrêt pour les routes réseau existantes.

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

L'opérateur est drainé et mis à niveau. Temps de pause de moins de 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 de moins de 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.
Autoscaler CoreDNS et DNS (cluster d'utilisateur uniquement) CoreDNS dispose de plusieurs instances répliquées avec autoscaler. Aucun temps d'arrêt en général. 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 existants.

L'opérateur peut avoir un temps d'arrêt 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 cinq minutes de temps d'arrêt.

L'entrée configurée existante continue de fonctionner.		 Une fois la mise à niveau des nœuds du plan de contrôle terminée.
Autres opérateurs système 5 minutes d'arrêt en cas de drainage et de mise à niveau. Une fois la mise à niveau des nœuds du plan de contrôle terminée.
Charges de travail des utilisateurs Cela dépend de la configuration, par exemple si la disponibilité élevée.

Examinez vos propres déploiements de charges de travail pour comprendre l'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 fournit des informations sur l'état de la mise à niveau d'un cluster d'utilisateur. La section suivante détaille les écarts par rapport à ce flux pour les mises à niveau de clusters d'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 d'é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 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 mise à niveau du cluster, des vérifications d'état du réseau et des vérifications de l'état des nœuds.
  • Les résultats de ces vérifications supplémentaires sont combinés pour indiquer la capacité du cluster à passer à 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 comme suit:

  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.
    1. Une fois le pool de nœuds de l'équilibreur de charge mis à niveau, les pools de nœuds de calcul sont mis à niveau.

  5. Une fois tous les composants mis à niveau, les 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 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'administrateur, autonomes ou hybrides.
2 status.anthosBareMetalManifestsVersion Version du cluster à partir 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 distinct du plan de contrôle n'est spécifié dans Cluster.Spec.
3 status.anthosBareMetalVersions Mappage de version agrégée entre la version et le nombre de nœuds.
4 status.anthosBareMetalVersion État final de la version mise à niveau.

Informations sur la mise à niveau des clusters d'administrateur, hybrides et autonomes

À partir de la version 1.15.0 de bmctl, le comportement de mise à niveau par défaut des 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 que l'utilisation d'un cluster d'amorçage pour la mise à niveau ne soit pas recommandée, 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 que vous utilisez.

Mises à niveau sur place

Le processus de mise à niveau sur place par défaut 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 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 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 vers 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:

Les éléments "lifecycle-controller-manager" et "anthos-cluster-operator" sont déployés avant que le reste du cluster ne soit mis à niveau dans le même ordre que les composants du cluster d'utilisateur.

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

Effectuer une mise à 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 démarre 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 de transfert de la propriété de la gestion du cluster vers le cluster d'amorçage est appelé pivot. Le reste de la mise à niveau suit le même processus que la mise à niveau 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 retransférer 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 nécessaire pour faire pivoter le cluster pendant le processus de mise à niveau. Le cluster d'amorçage est supprimé une fois la mise à niveau du cluster effectuée.

Drainage des nœuds

Les mises à niveau des clusters GKE sur Bare Metal peuvent entraîner une interruption de l'application lorsque les nœuds sont drainés. 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 de perturbations pendant les mises à niveau.

Budgets d'interruptions de pods (PDB)

Les budgets d'interruption de pods (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 reprogrammés. Toutefois, GKE sur Bare Metal ne respecte pas les PDB lorsque les nœuds se déchargent lors d'une mise à niveau. Au lieu de cela, le processus de drainage des nœuds est la meilleure solution. Certains pods peuvent rester bloqués à l'état Terminating et refuser de libérer 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.

Étapes suivantes