Mise à niveau des clusters Autopilot

Cette page explique le fonctionnement des mises à niveau automatiques sur les clusters Autopilot de Google Kubernetes Engine (GKE). En outre, elle fournit des liens vers des informations supplémentaires sur les tâches et les paramètres associés. Vous pouvez utiliser ces informations pour maintenir vos clusters à jour, stables et sécurisés, tout en minimisant les perturbations de vos charges de travail.

Mises à niveau automatiques du plan de contrôle et des nœuds

Les mises à jour automatiques sont activées sur tous les clusters Autopilot. GKE lance des mises à niveau automatiques lorsque les versions de GKE sont sélectionnées pour la mise à niveau automatique, observe les mises à niveau automatiques sur tous les clusters et intervient en cas de problème, par exemple lorsque des nœuds sont non opérationnels. Vous ne pouvez pas désactiver les mises à niveau automatiques, mais vous pouvez contrôler leur calendrier de déploiement à l'aide des intervalles et exclusions de maintenance.

Pour mettre à niveau un cluster, GKE met à jour la version du plan de contrôle et des nœuds. Les clusters sont mis à niveau vers une version mineure plus récente (par exemple, 1.24 vers 1.25) ou une version du correctif plus récente (par exemple, 1.24.2-gke.100 vers 1.24.5-gke.200). Pour en savoir plus, consultez la page Gestion des versions et compatibilité GKE.

Tous les clusters Autopilot sont enregistrés dans une version disponible. Par conséquent, GKE met automatiquement à jour le plan de contrôle et les nœuds pour exécuter la même version de GKE.

GKE met à niveau le plan de contrôle d'un cluster avant de mettre à niveau les nœuds.

Mises à niveau automatiques du plan de contrôle

Tous les clusters Autopilot sont des clusters régionaux. Les clusters régionaux disposent de plusieurs instances dupliquées du plan de contrôle. Une seule instance dupliquée est mise à niveau à la fois, dans un ordre indéterminé. Cela garantit que le cluster reste hautement disponible lors des mises à niveau automatiques. Chaque instance dupliquée du plan de contrôle n'est indisponible que pendant la mise à niveau.

Si vous configurez un intervalle ou une exclusion de maintenance, GKE respecte la configuration si possible.

GKE ne peut pas créer de nœuds lorsqu'une mise à niveau du plan de contrôle est en cours. Si vous déployez des pods nécessitant de nouveaux types de nœuds lorsqu'une mise à niveau du plan de contrôle est en cours, des retards peuvent survenir jusqu'à la fin de la mise à niveau.

Mises à niveau automatiques des nœuds

Après avoir mis à niveau votre plan de contrôle de cluster Autopilot, GKE met à jour les nœuds vers la même version de GKE.

Dans Autopilot, GKE regroupe les nœuds présentant des caractéristiques similaires. GKE utilise les mises à niveau de surutilisation pour les nœuds Autopilot, en mettant à niveau jusqu'à 20 nœuds d'un groupe en même temps. Le nombre précis de nœuds mis à niveau simultanément varie pour garantir la haute disponibilité des nœuds et des charges de travail.

Les mises à niveau de nœuds peuvent prendre plusieurs heures en fonction du nombre de nœuds et de la configuration des charges de travail s'exécutant sur les nœuds. Par exemple, les configurations suivantes peuvent contribuer à des mises à niveau plus longues :

Si vous configurez un intervalle ou une exclusion de maintenance, GKE respecte la configuration si possible.

Lorsque GKE met à niveau un nœud, les étapes suivantes ont lieu :

  1. GKE crée un nœud de surutilisation avec la nouvelle version de GKE et attend que le nœud de surutilisation s'enregistre auprès du plan de contrôle.
  2. GKE sélectionne un nœud existant (le nœud cible) à mettre à niveau.
  3. GKE confine le nœud cible, ce qui empêche les nouveaux pods d'être placés sur le nœud cible.
  4. GKE draine le nœud cible, évinçant les pods existants du nœud cible.

  5. GKE replanifie les pods gérés par un contrôleur de charge de travail sur d'autres nœuds disponibles. Les pods qui ne peuvent pas être reprogrammés restent à l'état PENDING jusqu'à ce que GKE puisse les reprogrammer.

  6. GKE supprime le nœud cible.

Si un nombre significatif de mises à niveau automatiques vers une version spécifique de GKE génère des nœuds non opérationnels dans l'ensemble du parc GKE, GKE arrête les mises à niveau vers cette version pendant que nous examinons le problème.

Sélection des versions pour la mise à niveau automatique

GKE publie régulièrement de nouvelles versions mineures, mais la version publiée n'est pas immédiatement sélectionnée pour des mises à niveau automatiques. Pour être considérée comme une cible de mise à niveau automatique, la version de GKE doit accumuler suffisamment d'utilisation pour prouver sa stabilité au fil du temps.

Google Cloud sélectionne ensuite cette version comme cible de mise à niveau automatique pour les clusters qui exécutent un sous-ensemble spécifique d'anciennes versions de GKE. Par exemple, peu de temps après la publication d'une nouvelle version mineure, la version mineure la plus ancienne disponible n'est généralement plus prise en charge. GKE met à niveau les clusters qui exécutent des versions mineures non compatibles vers la version cible de mise à niveau automatique.

GKE annonce les nouvelles versions cibles de mise à niveau automatique dans les notes de version. Il arrive qu'une version ne soit pas sélectionnée la même semaine pour les mises à niveau automatiques du plan de contrôle et pour celles des nœuds. GKE effectue automatiquement la mise à niveau vers de nouvelles versions de correctif au sein d'une version mineure (telle que v1.21.x).

Pour plus d'informations sur le cycle de vie et le schéma de gestion des versions, consultez la page Gestion des versions GKE et assistance.

Facteurs ayant une incidence sur le délai de déploiement des versions

Pour garantir la stabilité et la fiabilité des clusters sur les nouvelles versions, GKE suit certaines pratiques lors des déploiements de versions.

Voici quelques exemples :

  • GKE déploie progressivement les modifications dans les régions et les zones Google Cloud.
  • GKE déploie progressivement les versions de correctif sur les versions disponibles. Un temps de stabilisation est accordé au correctif dans le canal de publication rapide, puis dans le canal de publication standard, avant de le promouvoir au canal de publication stable une fois qu'il a accumulé de l'utilisation et a démontré sa stabilité. Si un problème survient avec une version de correctif pendant le temps d'évaluation sur une version disponible, cette version n'est pas promue dans la version suivante et le problème est résolu dans une version plus récente.
  • GKE déploie progressivement les versions mineures, en suivant un processus d'évaluation similaire pour les versions de correctif. Les versions mineures présentent des périodes d'évaluation plus longues, car elles apportent des modifications plus importantes.
  • GKE peut retarder les mises à niveau automatiques lorsqu'une nouvelle version affecte un groupe de clusters. Par exemple, GKE met en pause les mises à niveau automatiques des clusters détectés, car ils sont exposés à une API ou à une fonctionnalité obsolète qui sera supprimée dans la prochaine version mineure.
  • GKE peut retarder le déploiement de nouvelles versions pendant les périodes de pointe (par exemple, pendant les jours fériés) pour assurer la continuité des opérations.

Configuration de la période de mise à niveau automatique

Par défaut, les mises à niveau automatiques peuvent être effectuées à tout moment. Les mises à niveau automatiques n'entraînent que très peu de perturbations, en particulier pour les clusters Autopilot. Toutefois, certaines charges de travail peuvent nécessiter un contrôle plus précis. Vous pouvez configurer des intervalles et des exclusions de maintenance pour contrôler la période à laquelle les mises à niveau automatiques peuvent et ne peuvent pas avoir lieu.

Si vous configurez des intervalles et des exclusions de maintenance, la mise à niveau n'a lieu que pendant ces intervalles de maintenance. Si un intervalle de maintenance arrive à expiration avant la fin de la mise à niveau, GKE tente de la suspendre. GKE reprend la mise à niveau lors du prochain intervalle de maintenance disponible.

Mettre à niveau manuellement un cluster Autopilot

Vous pouvez mettre à jour manuellement la version GKE de votre plan de contrôle de cluster Autopilot. GKE met automatiquement à niveau vos nœuds afin qu'ils correspondent dès que possible à la version du plan de contrôle, sous réserve de disposer d'une disponibilité pour maintenance. Pour obtenir des instructions, consultez la page Mettre à jour manuellement le plan de contrôle. Vous ne pouvez pas gérer manuellement la version des nœuds dans les clusters Autopilot.

Vous pouvez mettre à niveau la version du plan de contrôle vers une version mineure ou de correctif compatible dans la même version disponible, ou vers une version de correctif de la même version mineure que votre cluster dans une autre version disponible.

Prenons l'exemple d'un cluster Autopilot exécutant la version 1.22.8-gke.202 de GKE dans la version disponible standard. Le comportement suivant s'applique :

  • Vous pouvez effectuer une mise à niveau vers n'importe quelle version standard.
  • Vous pouvez effectuer une mise à niveau vers n'importe quelle version de correctif de la version 1.22 dans le canal rapide.

Pour en savoir plus sur la mise à niveau en dehors de votre canal, consultez la section Exécuter des versions de correctif d'un canal plus récent.

Mises à niveau de la surutilisation

Les clusters Autopilot utilisent les mises à niveau de surutilisation pour mettre à niveau plusieurs nœuds en même temps. Les mises à niveau de surutilisation permettent à GKE de réduire l'impact des mises à niveau de version sur vos charges de travail en cours d'exécution en conservant pour elles une capacité de calcul suffisante. Autopilot gère le nombre de nœuds de surutilisation ajoutés au cluster pendant la mise à niveau. Ce nombre varie en fonction de la taille totale du cluster. GKE gère également le nombre total de nœuds cibles qui peuvent être simultanément indisponibles pendant la mise à niveau.

Le nombre de nouveaux nœuds de surutilisation et de nœuds cibles indisponibles varie pour garantir que votre cluster dispose toujours d'une capacité de calcul suffisante pour toutes les charges de travail en cours d'exécution. Des interruptions mineures peuvent se produire pendant que GKE migre les charges de travail des nœuds cibles vers les nœuds de surutilisation pendant la mise à niveau.

Pour obtenir une description de la mise à niveau de surutilisation, consultez la page Mises à niveau automatiques des nœuds.

Exigences de quota pour les mises à niveau de surutilisation

Contrairement à la recréation des nœuds, les mises à niveau de surutilisation nécessitent des ressources Compute Engine supplémentaires. L'allocation des ressources dépend de votre quota Compute Engine disponible. En fonction de votre configuration, ce quota peut limiter le nombre de mises à niveau effectuées en parallèle ou même entraîner leur échec. Une bonne pratique pour éviter les problèmes de scaling et permettre des mises à niveau plus prévisibles consiste à vous assurer que votre quota d'instances Compute Engine ne dépasse pas 90 %.

Pour plus d'informations sur les quotas, consultez la page Vérifier les ressources pour les mises à niveau des nœuds.

Recevoir des notifications de mise à niveau

GKE publie des notifications de mise à niveau sur Pub/Sub. Vous disposez ainsi d'un canal pour réceptionner les informations concernant vos clusters.

Pour en savoir plus, consultez la section Recevoir des notifications de clusters.

Mises à niveau des composants

GKE exécute des charges de travail système sur les nœuds de calcul afin de proposer des fonctionnalités spécifiques pour les clusters. Par exemple, la charge de travail du système gke-metadata-server est compatible avec la fédération d'identité de charge de travail pour GKE. GKE est responsable de l'état de ces charges de travail. Pour en savoir plus sur ces composants, consultez la documentation sur les fonctionnalités associées.

Lorsque de nouvelles fonctionnalités ou de nouveaux correctifs sont disponibles pour un composant, GKE indique la version du correctif dans laquelle ils sont inclus. Pour obtenir la dernière version d'un composant, reportez-vous à la documentation associée ou aux notes de version pour obtenir des instructions sur la mise à niveau de votre plan de contrôle ou de vos nœuds vers la version appropriée.

Étapes suivantes