Lorsque vous effectuez une mise à niveau de Google Distributed Cloud, le processus de mise à niveau implique plusieurs étapes et composants. Pour surveiller l'état de la mise à niveau ou pour 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écrit les composants et les étapes d'une mise à niveau de cluster.
Présentation
Le processus de mise à niveau fait passer votre cluster Google Distributed Cloud de sa version actuelle à une version supérieure.
Ces informations sur la version sont stockées aux emplacements suivants dans la ressource personnalisée du cluster dans le cluster d'administrateur :
status.anthosBareMetalVersion: définit la version actuelle du cluster.spec.anthosBareMetalVersion: définit la version cible et est paramétré lorsque le processus de mise à niveau commence à s'exécuter.
Une opération de mise à niveau réussie effectue un rapprochement de status.anthosBareMetalVersion vers spec.anthosBareMetalVersion afin que les deux affichent la version cible.
Décalage entre les versions du cluster
Le décalage entre les versions du cluster est 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.30
Les règles suivantes s'appliquent aux clusters d'utilisateur gérés par un cluster d'administrateur ou un cluster hybride en version 1.30 :
Les versions de cluster d'utilisateur ne peuvent pas être supérieures à celles du cluster de gestion (administrateur ou hybride).
(1.30 DG) Les clusters d'utilisateur peuvent être jusqu'à deux versions mineures en dessous de la version du cluster de gestion. Par exemple, un cluster d'administrateur en version 1.30 peut gérer un cluster d'utilisateur en version 1.28. Cette capacité de gestion des décalages entre les versions n-2 est disponible en disponibilité générale pour la gestion des clusters en version 1.30.
(1.30 DG) Pour un cluster de gestion donné en version 1.30, les clusters d'utilisateur n'ont pas besoin d'avoir la même version mineure. Par exemple, un cluster d'administrateur en version 1.30 peut gérer les clusters d'utilisateur en versions 1.30, 1.29 et 1.28.
La capacité de gestion de plusieurs écarts de versions 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.28 vers la version 1.29 avant de pouvoir mettre à niveau votre cluster d'administrateur vers la version 1.30.
1.29
Les règles suivantes s'appliquent aux clusters d'utilisateur gérés par un cluster d'administrateur ou un cluster hybride en version 1.29 :
Les versions de cluster d'utilisateur ne peuvent pas être supérieures à celles du cluster de gestion (administrateur ou hybride).
(1.29 Preview) Les clusters d'utilisateur peuvent être jusqu'à deux versions mineures en dessous de la version du cluster de gestion. Par exemple, un cluster d'administrateur en version 1.29 peut gérer un cluster d'utilisateur en version 1.16. Cette gestion des décalages entre les versions n-2 est disponible en tant que fonctionnalité preview pour la gestion des clusters en version 1.29.
(1.29 Preview) Pour un cluster de gestion donné, les clusters d'utilisateur n'ont pas besoin d'avoir la même version mineure. Par exemple, un cluster d'administrateur en version 1.29 peut gérer les clusters d'utilisateur en versions 1.29, 1.28 et 1.16. Cette gestion des décalages entre les versions mixte est disponible en tant que fonctionnalité preview pour la gestion des clusters en version 1.29.
La capacité de gestion de plusieurs écarts de versions en 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 en version 1.28 ou antérieure :
Les versions de cluster d'utilisateur ne peuvent pas être supérieures à celles du cluster de gestion (administrateur ou hybride).
Les clusters d'utilisateur peuvent être jusqu'à une version mineure en-dessous de la version du cluster de gestion. Par exemple, un cluster d'administrateur en version 1.28 ne peut pas gérer un cluster d'utilisateur en version 1.15.
Pour un cluster de gestion donné, tous les clusters d'utilisateur gérés doivent avoir la même version mineure.
Pour en savoir plus sur les règles d'écarts de version concernant les pools de nœuds, consultez la section Règles de gestion des versions des pools de nœuds.
Règles de 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. Par exemple, si vous utilisez la version 1.30.100-gke.96 de bmctl, vous ne pouvez mettre à niveau un cluster que vers la version 1.30.100-gke.96.
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.30.X vers la version 1.30.Y tant que Y est supérieur à X. Par exemple, vous pouvez passer de la version 1.29.0 à la version 1.29.100 et de la version 1.29.100 à la version 1.29.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 la version 1.29.500-gke.163 à la version 1.30.100-gke.96.
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.28.0 vers la version 1.30.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.30
La version du cluster doit être supérieure ou égale à celle 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.
Les pools de nœuds de calcul peuvent avoir n'importe quelle version de correctif d'une version mineure compatible.
1.29
La version du cluster doit être supérieure ou égale à celle du pool de nœuds de calcul.
(1.29 DG) Le décalage maximal de version entre un pool de nœuds de calcul et le cluster est de deux versions mineures.
Les pools de nœuds de calcul ne peuvent pas avoir une version chronologiquement ultérieure à la version du cluster. La version antérieure n'a pas tous les détails nécessaires pour la version ultérieure, ce qui est une exigence de compatibilité.
Par exemple, la version 1.16.6 a été publiée après la version 1.28.100-gke.146. Vous ne pouvez donc pas passer de la version 1.16.6 à la version 1.28.100-gke.146 et laisser un pool de nœuds de calcul en 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 en version 1.16.5, vous ne pouvez pas mettre à niveau le pool de nœuds de calcul vers la version 1.16.6 lorsque le cluster est en version 1.28.100-gke.146.
1.28
La version du cluster doit être supérieure ou égale à celle du pool de nœuds de calcul.
(1.28 Preview) 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 de décalage de version n-2 est activée. Si vous n'activez pas cette fonctionnalité, le décalage maximal de version entre un pool de nœuds de calcul et le cluster est d'une version mineure.
Les pools de nœuds de calcul ne peuvent pas avoir une version chronologiquement ultérieure à la version du cluster. La version antérieure n'a pas tous les détails nécessaires pour la version ultérieure, ce qui est une exigence de compatibilité.
Par exemple, la version 1.16.6 a été publiée après la version 1.28.100-gke.146. Vous ne pouvez donc pas passer de la version 1.16.6 à la version 1.28.100-gke.146 et laisser un pool de nœuds de calcul en 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 en version 1.16.5, vous ne pouvez pas mettre à niveau le pool de nœuds de calcul vers la version 1.16.6 lorsque le cluster est en version 1.28.100-gke.146.
1.16
La version du cluster doit être supérieure ou égale à celle 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.
Les pools de nœuds de calcul ne peuvent pas avoir une version chronologiquement ultérieure à la version du cluster. La version antérieure n'a pas tous les détails nécessaires pour la version ultérieure, ce qui est une exigence de compatibilité.
Par exemple, la version 1.16.6 a été publiée après la version 1.28.100-gke.146. Vous ne pouvez donc pas passer de la version 1.16.6 à la version 1.28.100-gke.146 et laisser un pool de nœuds de calcul en 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 en version 1.16.5, vous ne pouvez pas mettre à niveau le pool de nœuds de calcul vers la version 1.16.6 lorsque le cluster est en version 1.28.100-gke.146.
Le tableau suivant liste les versions de pool de nœuds compatibles autorisées pour une version de cluster spécifique :
1.30
Pour les pools de nœuds ayant une version mineure compatible, version 1.29 ou version 1.28, toutes les versions de correctif sont compatibles avec les clusters ayant n'importe quelle version de correctif de la version mineure 1.30.
1.29
| Version du cluster (plan de contrôle) | Versions de pool de nœuds de calcul compatibles (versions ajoutées en gras) | |||
|---|---|---|---|---|
| 1.29.500-gke.162 |
|
|
|
|
| 1.29.400-gke.86 |
|
|
|
|
| 1.29.300-gke.185 |
|
|
|
|
| 1.29.200-gke.243 |
|
|
|
|
| 1.29.100-gke.251 |
|
|
|
|
| 1.29.0-gke.1449 |
|
|
|
|
1.28
| Version du cluster (plan de contrôle) | Versions de pool de nœuds de calcul compatibles (versions ajoutées en gras) | |||
|---|---|---|---|---|
| 1.28.1000-gke.60 |
|
|
|
|
| 1.28.900-gke.112 |
|
|
|
|
| 1.28.800-gke.111 |
|
|
|
|
| 1.28.700-gke.150 |
|
|
|
|
| 1.28.600-gke.163 |
|
|
|
|
| 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
| Version du cluster (plan de contrôle) | Versions de pool de nœuds de calcul compatibles (versions ajoutées en gras) | |||
|---|---|---|---|---|
| 1.16.12 |
|
|
|
|
| 1.16.11 |
|
|
|
|
| 1.16.10 |
|
|
|
|
| 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 |
|
|
||
Mettre à niveau des 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 selon 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 d'utilisateur | 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 des clusters et les modules complémentaires de la plate-forme Google Kubernetes Engine (GKE) édition Enterprise | 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) édition Enterprise tels que stackdriver-log-aggregator et gke-connect-agent |
| Équilibreur de charge du plan de contrôle | Exécute HAProxy et Keepalived pour acheminer le trafic vers kube-apiserver, et exécute des "speakers" MetalLB pour revendiquer des adresses IP virtuelles |
Pods statiques de l'équilibreur de charge du plan de contrôle (HAProxy, Keepalived)
Speakers MetalLB |
Temps d'arrêt attendus
Le tableau suivant détaille les temps d'arrêt attendus et l'impact potentiel lors de la mise à niveau des clusters. Ce tableau part 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é, attendez-vous à des temps d'arrêt supplémentaires. Sauf indication contraire, ces temps d'arrêt s'appliquent à la fois aux mises à niveau des clusters d'administrateur et d'utilisateur :
| Composants | Temps d'arrêt attendus | À quel moment |
|---|---|---|
Serveur d'API du plan de contrôle Kubernetes (kube-apiserver), etcd, et programmeur |
Aucun temps d'arrêt | N/A |
Contrôleurs de cycle de vie et job ansible-runner (cluster d'administrateur uniquement) |
Aucun temps d'arrêt | N/A |
Plan de contrôle Kubernetes loadbalancer-haproxy et keepalived |
Temps d'arrêt temporaire (moins d'une à deux 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 d'arrêt devrait ê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. |
| CNI (Container Network Interface) | Pas de 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 d'arrêt inférieur à cinq 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. Temps d'arrêt inférieur à cinq minutes.
Pas de 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. En général, il n'y a pas de temps d'arrêt. | Une fois la mise à niveau des nœuds du plan de contrôle terminée. |
| Approvisionneur de volume local | Pas de temps d'arrêt pour les volumes persistants provisionnés existants.
L'opérateur peut subir 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. 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 | Cinq minutes de temps d'arrêt lors du drainage et de la mise à niveau. | Une fois la mise à niveau des nœuds du plan de contrôle terminée. |
| Charges de travail de l'utilisateur | Dépend de la configuration, par exemple si elle est hautement disponible. Examinez vos propres déploiements de charges de travail pour comprendre l'impact potentiel. |
Lorsque le ou les nœuds de calcul sont mis à niveau. |
Détails concernant la mise à niveau des clusters d'utilisateur
Cette section décrit l'ordre des mises à niveau des composants et les informations d'état d'une mise à niveau de cluster d'utilisateur. La section suivante décrit 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 de cluster d'utilisateur :
Le schéma précédent détaille les étapes d'une mise à niveau :
- La commande
bmctl upgrade clustercrée une ressource personnaliséePreflightCheck. - Cette vérification préliminaire exécute des vérifications supplémentaires, telles que les vérifications de mise à niveau du cluster, les vérifications d'état du réseau et les vérifications d'état des nœuds.
- Les résultats de ces vérifications supplémentaires sont combinés pour indiquer si le cluster peut être mis à niveau vers la version cible.
Si les vérifications préliminaires aboutissent et qu'il n'y a pas de problèmes bloquants, les composants du cluster sont mis à niveau dans l'ordre spécifié, comme illustré dans le schéma suivant :
Dans le schéma précédent, les composants sont mis à niveau dans l'ordre suivant :
- La mise à niveau commence par la mise à jour du champ
spec.anthosBareMetalVersion. - Les équilibreurs de charge du plan de contrôle sont mis à niveau.
- Le pool de nœuds du plan de contrôle est mis à niveau.
- En parallèle, GKE Connect est mis à niveau, les modules complémentaires de cluster sont mis à niveau, et le pool de nœuds de l'équilibreur de charge est mis à niveau.
- Une fois le pool de nœuds de l'équilibreur de charge mis à niveau, les pools de nœuds de calcul sont mis à niveau.
Une fois tous les composants mis à niveau, les vérifications d'état du cluster sont exécutées.
Les vérifications d'état continuent de s'exécuter jusqu'à ce que toutes les vérifications réussissent.
Lorsque toutes les vérifications d'état sont réussies, 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 ces champs pour suivre 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. Le 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 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 du plan de contrôle distinct n'est spécifié dans Cluster.Spec. |
| 3 | status.anthosBareMetalVersions |
Mappage de version agrégé de numéros de version et de nœuds. |
| 4 | status.anthosBareMetalVersion |
État final de la version mise à niveau. |
Détails concernant 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 pour les clusters autogérés (administrateur, hybride ou autonome) 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 exigences en ressources, ce qui rend les mises à niveau de 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 est toujours 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 diffèrent 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 à celui 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 d'état du 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 sont exécutées avant la mise à jour des composants, comme illustré dans le schéma suivant : lifecycle-controller-manager passe à 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 :
Si l'opération réussit, anthos-cluster-operator effectue un rapprochement de la version cible de spec.anthosBareMetalVersion vers status.anthosBareMetalVersion.
Effectuer une mise à niveau avec un cluster d'amorçage
La procédure de mise à niveau d'un cluster d'administrateur, hybride ou autonome est semblable à la procédure de mise à niveau d'un cluster d'utilisateur décrite 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 de passation 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 la mise à niveau du cluster d'utilisateur.
Pendant le processus de mise à niveau, les ressources du cluster cible demeurent non actualisées. 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 la gestion du cluster une fois la mise à niveau terminée, le cluster "pivote" les ressources du cluster d'amorçage vers le cluster mis à niveau. Aucune étape manuelle n'est requise pour "pivoter" le cluster lors du 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 de clusters Google Distributed Cloud peuvent entraîner des interruptions d'application lorsque les nœuds sont drainés. Ce processus de drainage entraîne l'arrêt de tous les pods exécutés sur un nœud et leur redémarrage sur les nœuds restants du cluster.
Les déploiements peuvent être utilisés pour tolérer ce type d'interruption. Un déploiement peut spécifier que plusieurs instances répliquées d'une application ou d'un service doivent s'exécuter. Lorsqu'une application comporte plusieurs instances répliquées, les interruptions lors des mises à niveau devraient être minimes, voire inexistantes.
PodDisruptionBudgets (PDB)
Lorsque vous mettez à niveau un cluster, Google Distributed Cloud utilise le flux du mode Maintenance pour drainer les nœuds.
À partir de la version 1.29, les nœuds sont drainés avec l'API Eviction, qui respecte les PodDisruptionBudgets (PDB). Les PDB peuvent être utilisés pour s'assurer qu'un nombre défini d'instances répliquées s'exécute toujours dans le cluster dans des conditions normales.
Les PDB vous permettent de limiter les interruptions d'une charge de travail lorsque ses pods doivent être reprogrammés. Le drainage des nœuds basé sur l'éviction est disponible en version DG pour la version 1.29.
Dans les versions 1.28 et antérieures, Google Distributed Cloud ne respecte pas les PDB lorsque les nœuds sont drainés lors d'une mise à niveau. À la place, le processus de drainage du nœud est réalisé de la façon la plus optimale possible. Certains pods peuvent rester bloqués dans un é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 Passer des nœuds en mode maintenance.
Étape suivante
- Consultez les bonnes pratiques pour les mises à niveau de Google Distributed Cloud.
- Mettre à niveau Google Distributed Cloud
- Résoudre les problèmes de mise à niveau des clusters