Mises à niveau des clusters standards

Cette page explique le fonctionnement des mises à niveau automatiques et manuelles sur les clusters standards Google Kubernetes Engine (GKE). Elle fournit également 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.

Pour plus d'informations sur le fonctionnement des mises à niveau de cluster pour Autopilot, consultez la section Mises à niveau des clusters Autopilot.

Fonctionnement des mises à niveau des clusters et des pools de nœuds

Cette section explique ce qu'il se passe dans votre cluster lors des mises à niveau automatiques ou manuelles. Les mises à niveau automatiques sont initiées par GKE. GKE observe les mises à niveau automatiques et manuelles de tous les clusters GKE et intervient en cas de problème.

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.

Si vous enregistrez votre cluster dans une version disponible, les nœuds exécutent la même version de GKE que le cluster, sauf pendant une brève période (généralement quelques jours, selon la version actuelle) entre la fin de la mise à niveau du plan de contrôle du cluster et le début de la mise à niveau d'un pool de nœuds, ou si le plan de contrôle a été mis à niveau manuellement. Consultez les notes de version pour plus d'informations.

Mise à niveau des clusters

Cette section explique ce qu'il se passe lorsque GKE met à niveau automatiquement votre cluster ou lorsque vous lancez une mise à niveau manuelle.

  • Les clusters zonaux ne disposent que d'un seul plan de contrôle. Lors de la mise à niveau, vos charges de travail continuent de s'exécuter, mais vous ne pouvez pas en déployer de nouvelles ou modifier des charges de travail existantes, ni apporter d'autres modifications à la configuration du cluster.

  • 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é. Lors de la mise à niveau, le cluster reste hautement disponible et les instances dupliquées du plan de contrôle ne sont indisponibles que pendant leur mise à niveau.

Si vous configurez un intervalle ou une exclusion de maintenance, ils sont pris en compte dans la mesure du possible.

Mise à niveau des pools de nœuds

Cette section explique ce qu'il se passe lorsque GKE met à niveau automatiquement votre pool de nœuds ou lorsque vous lancez une mise à niveau manuelle.

GKE met automatiquement à niveau un par un les pools de nœuds d'un cluster. Vous pouvez également mettre à niveau manuellement un ou plusieurs pools de nœuds en parallèle. Par défaut, les nœuds d'un pool sont mis à niveau un par un, dans un ordre arbitraire. Dans un pool de nœuds répartis sur plusieurs zones, les mises à niveau s'effectuent zone par zone. Dans une zone, les nœuds seront mis à niveau dans un ordre indéterminé.

Avec les mises à niveau du pool de nœuds GKE, vous pouvez choisir entre deux stratégies de mise à niveau intégrées configurables où vous pouvez ajuster le processus de mise à niveau en fonction des besoins de votre environnement de cluster. Pour en savoir plus sur les stratégies de mises à niveau de la surutilisation et de mises à niveau bleu-vert, consultez la section Stratégies de mise à niveau.

Lors d'une mise à niveau du pool de nœuds, vous ne pouvez pas modifier la configuration du cluster, sauf si vous annulez la mise à niveau.

GKE respecte les intervalles de maintenance et les exclusions lors des mises à niveau automatiques lorsque cela est possible. Les mises à niveau manuelles contournent les intervalles de maintenance et les exclusions configurées.

Comment mettre à niveau les nœuds

Lors de la mise à niveau d'un pool de nœuds, la façon dont les nœuds sont mis à niveau dépend de la stratégie de mise à niveau du pool de nœuds et de comment elle est configurée. Cependant, les étapes de base restent cohérentes. Pour mettre à niveau un nœud, GKE supprime les pods du nœud afin de pouvoir le mettre à niveau.

Lorsqu'un nœud est mis à niveau, voici ce qui se produit avec les pods :

  1. Le nœud est marqué comme non ordonnançable de sorte que Kubernetes ne programme pas de nouveaux pods dessus.
  2. Le nœud est ensuite drainé, ce qui signifie que les pods sont supprimés. Pour les mises à niveau de la surutilisation, GKE respecte les paramètres PodDisruptionBudget et GracefulTerminationPeriod du pod pendant une heure au maximum. Avec les mises à niveau bleu-vert, ce délai peut être prolongé si vous configurez un temps d'évaluation plus long.
  3. Le plan de contrôle replanifie les pods gérés par les contrôleurs sur d'autres nœuds. Les objets qui ne peuvent pas être reprogrammés restent en phase "En attente" jusqu'à ce qu'ils puissent être planifiés.

Le processus de mise à niveau du pool de nœuds peut prendre quelques heures en fonction de la stratégie de mise à niveau, du nombre de nœuds et de la configuration de leurs charges de travail.

Considérations relatives à la durée de mise à niveau des nœuds

Les configurations pouvant ralentir la mise à niveau des nœuds incluent :

Stratégies de mise à niveau des nœuds

GKE propose des stratégies configurables intégrées qui déterminent la méthode de mise à niveau du pool de nœuds. Pour en savoir plus sur les types de modifications qui utilisent une stratégie de mise à niveau des nœuds, consultez les sections Quand GKE utilise-t-il les mises à niveau de la surutilisation et Quand GKE utilise-t-il les mises à niveau bleu-vert.

Mises à niveau de la surutilisation

Par défaut, la stratégie de mise à niveau de la surutilisation est utilisée pour les mises à niveau du pool de nœuds. Les mises à niveau de la surutilisation utilisent une méthode progressive pour mettre à niveau les nœuds. Cette stratégie est optimale pour les applications capables de gérer des modifications incrémentielles sans interruption. Avec cette stratégie, les nœuds sont mis à niveau dans une fenêtre glissante. Avec les paramètres, vous pouvez modifier le nombre de nœuds pouvant être mis à niveau simultanément et contrôler le niveau de perturbation des mises à niveau, afin de trouver le juste équilibre entre vitesse et perturbation pour les besoins de votre environnement.

Mises à niveau bleu-vert

L'autre approche est d'utiliser les mises à niveau bleu-vert, dans lesquelles deux environnements séparés (l'environnement d'origine et le nouveau environnement) sont gérés en même temps, ce qui facilite le rollback. Les mises à niveau bleu-vert nécessitent davantage de ressources et sont plus adaptées aux applications plus sensibles aux modifications. Avec cette stratégie, les charges de travail sont migrées progressivement de l'environnement "bleu" d'origine vers le nouvel environnement "vert" et disposent d'un temps d'évaluation suffisant pour les valider avec la nouvelle configuration. Si nécessaire, un rollback rapide des charges de travail peut être effectué vers l'environnement "bleu" existant.

Pour en savoir plus sur le fonctionnement des stratégies de mise à niveau des nœuds, consultez la page Stratégies de mise à niveau des nœuds.

Ressources nécessaires pour les stratégies de mise à niveau de nœuds

Les mises à niveau de la surutilisation créent des nœuds supplémentaires si maxSurge est défini sur une valeur supérieure à 0 et les mises à niveau bleu-vert doublent temporairement le nombre de nœuds dans un pool de nœuds. Cela nécessite des ressources supplémentaires, soumises à un quota Compute Engine, à une disponibilité des ressources et à une capacité de réservation. Si votre pool de nœuds ne dispose pas de ressources suffisantes, les mises à niveau peuvent prendre plus de temps ou échouer.

Pour savoir comment vous assurer que votre projet dispose de suffisamment de ressources pour les mises à niveau des nœuds et savoir comment procéder si votre environnement est limité en ressources, consultez la page Vérifier que les ressources sont nécessaires pour les mises à niveau des nœuds.

Mise à niveau automatique

Lorsque vous créez un cluster standard, la mise à niveau automatique est activée par défaut sur le cluster et ses pools de nœuds.

GKE est responsable de la sécurisation du plan de contrôle de votre cluster et met à niveau vos clusters lorsque vous sélectionnez une nouvelle version GKE pour la mise à niveau automatique. La sécurité de l'infrastructure est une priorité élevée pour GKE. Ces plans de contrôle sont mis à niveau régulièrement et ne peuvent pas être désactivés. Toutefois, vous pouvez appliquer des intervalles et des exclusions de maintenance afin de suspendre temporairement les mises à niveau pour les plans de contrôle et les nœuds.

Dans le modèle de responsabilité partagée de GKE, vous êtes chargé d'assurer la sécurité de vos nœuds, conteneurs et pods. La mise à niveau automatique des nœuds est activée par défaut. Bien que cette pratique ne soit pas recommandée, vous pouvez désactiver la mise à niveau automatique des nœuds. La désactivation des mises à niveau automatiques des nœuds ne bloque pas la mise à niveau du plan de contrôle de votre cluster. Si vous désactivez les mises à niveau automatiques des nœuds, vous devez vous assurer que les nœuds du cluster exécutent une version compatible avec la version du cluster et que celle-ci respecte les règles de compatibilité de la version de Kubernetes et du décalage de version.

Pour mieux contrôler le moment où une mise à niveau automatique a lieu (ou ne doit pas avoir lieu), vous pouvez configurer des intervalles et des exclusions de maintenance.

La version des pools de nœuds d'un cluster ne peut pas être antérieure de plus de deux versions mineures à la version du plan de contrôle, afin de maintenir la compatibilité avec l'API du cluster. La version du pool de nœuds détermine également les versions des packages logiciels installés sur chaque nœud. Nous vous recommandons de mettre à jour les pools de nœuds conformément à la version du cluster.

Si vous enregistrez votre cluster dans une version disponible, les nœuds exécutent toujours la même version de GKE que le cluster lui-même, sauf pendant une brève période (généralement quelques jours, selon la version actuelle) entre la mise à niveau du plan de contrôle du cluster et le début de la mise à niveau d'un pool de nœuds donné. Consultez les notes de version pour plus d'informations.

Sélection des versions pour la mise à niveau automatique

De nouvelles versions de GKE sont disponibles régulièrement, mais une version n'est pas immédiatement sélectionnée pour une mise à niveau automatique. Lorsqu'une version GKE a accumulé suffisamment de temps d'utilisation du cluster pour prouver sa stabilité, GKE la sélectionne en tant que cible de mise à niveau automatique pour les clusters exécutant un sous-ensemble d'anciennes versions.

Les nouvelles cibles de mise à niveau automatique sont annoncées dans les notes de version. Avant qu'une version disponible ne soit sélectionnée pour la mise à niveau automatique, vous pouvez effectuer une mise à niveau manuelle. Il arrive qu'une version soit sélectionnée pour la mise à niveau automatique du cluster et pour celle du nœud au cours de différentes semaines.

En principe, peu de temps après la mise à disposition générale d'une nouvelle version mineure, la version mineure la plus ancienne disponible n'est plus compatible. Les clusters exécutant des versions mineures qui ne sont plus compatibles sont automatiquement mis à niveau vers la version mineure suivante.

Dans une version mineure (telle que v1.14.x), les clusters peuvent être automatiquement mis à niveau vers une nouvelle version corrective.

Les versions disponibles vous permettent de contrôler la version du cluster et du pool de nœuds en fonction de sa stabilité plutôt que de la gérer directement.

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 d'évaluation est accordé au correctif dans la version précoce, puis dans la version disponible avant d'être promue en version stable une fois qu'elle 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 pour préserver la sécurité de l'infrastructure. Les mises à niveau automatiques n'entraînent que très peu de perturbations, en particulier pour les clusters régionaux. 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.

Effectuer une mise à niveau manuelle

Vous pouvez à tout moment demander à effectuer une mise à niveau manuelle de votre cluster ou de ses pools de nœuds vers une version disponible et compatible. Les mises à niveau manuelles contournent les intervalles et les exclusions de maintenance configurées.

Lorsque vous mettez à niveau manuellement un cluster, sa disponibilité varie selon s'il est régional ou non :

  • Pour les clusters zonaux, le plan de contrôle n'est pas disponible lorsqu'il est mis à niveau. Dans la plupart des cas, les charges de travail s'exécutent normalement. Toutefois, elles ne peuvent pas être modifiées pendant la mise à niveau.

  • Pour les clusters régionaux, une instance dupliquée du plan de contrôle à la fois n'est pas disponible lors de la mise à niveau, mais le cluster reste hautement disponible.

Vous pouvez lancer manuellement une mise à niveau de nœuds vers une version compatible avec le plan de contrôle.

Comment GKE gère l'échec des mises à niveau automatiques

Les mises à niveau automatiques du pool de nœuds peuvent échouer en raison de problèmes liés aux instances Compute Engine sous-jacentes ou à Kubernetes. Par exemple, les mises à niveau automatiques échouent dans les situations suivantes :

  • Le paramètre maxSurge configuré dépasse votre quota de ressources Compute Engine.
  • Les nouveaux nœuds de surutilisation ne sont pas enregistrés avec le plan de contrôle du cluster.
  • La suppression ou le drainage des nœuds a pris trop de temps.

Lorsque des problèmes surviennent lors des mises à niveau individuelles des nœuds, GKE relance la mise à niveau plusieurs fois, avec un intervalle croissant entre les tentatives. Si la mise à niveau des nœuds du pool de nœuds échoue, GKE n'effectue pas le rollback des nœuds mis à niveau. Au lieu de cela, GKE tente à nouveau de mettre à niveau le pool de nœuds jusqu'à ce que tous les nœuds soient mis à niveau.

Si les mises à niveau de vos nœuds échouent parce que vos requêtes de nœuds de surutilisation dépassent votre quota Compute Engine, GKE réduit le nombre de nœuds de surutilisation simultanés pour tenter de respecter le quota et poursuivre la mise à niveau.

Recevoir des notifications de mise à niveau

GKE publie dans Pub/Sub des notifications sur les événements concernant votre cluster, tels que les mises à niveau de version et les bulletins de sécurité, en fournissant un canal pour recevoir des informations de GKE sur vos clusters.

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

Vérifier les journaux de mise à niveau

Par défaut, GKE consigne les événements de mise à niveau du plan de contrôle et du pool de nœuds dans Cloud Logging. Le journal des événements de mise à niveau offre une visibilité sur le processus de mise à niveau et inclut des informations précieuses pour le dépannage si nécessaire.

Journaux de mise à niveau du plan de contrôle

Les événements de mise à niveau du cluster peuvent être interrogés à l'aide du filtre suivant :

resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

Ces journaux sont enregistrés en tant que formats de journalisation structurée. Vous pouvez utiliser les champs suivants pour obtenir les détails des événements de mise à niveau :



Champ Description
protoPayload.metadata.operationType Il existe deux types d'événements de mise à niveau de cluster : UPGRADE_MASTER et UPDATE_CLUSTER.
UPGRADE_MASTER modifie la version du plan de contrôle Kubernetes.
UPDATE_CLUSTER signifie une mise à jour ne modifiant pas la version du plan de contrôle Kubernetes.
Les deux types de mise à niveau de cluster peuvent entraîner la perte de disponibilité du plan de contrôle pour les clusters zonaux. Pour en savoir plus, consultez la section Fonctionnement des mises à niveau des clusters et des pools de nœuds.
protoPayload.methodName Ce champ indique quelle API a déclenché la mise à niveau du cluster.
google.container.v1.ClusterManager.UpdateCluster : mise à niveau manuelle du plan de contrôle
google.container.internal.ClusterManagerInternal.UpdateClusterInternal : mise à niveau automatique du plan de contrôle
google.container.v1.ClusterManager.PatchCluster : modification de la configuration du cluster.
protoPayload.metadata.previousMasterVersion Ce champ n'est utilisé que pour le type d'opération MASTER_UPGRADE et contient la version précédente du plan de contrôle utilisée avant la mise à niveau.
protoPayload.metadata.currentMasterVersion Ce champ n'est utilisé que pour le type d'opération MASTER_UPGRADE et contient le nouveau numéro de version du plan de contrôle utilisé après la mise à niveau.

Journaux de mise à niveau du pool de nœuds

Utilisez la requête suivante pour afficher les événements de mise à niveau du pool de nœuds : 

resource.type="gke_nodepool"
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"

Utilisez le champ suivant pour obtenir des détails sur l'événement de mise à niveau :

Le champ protoPayload.methodName indique si la mise à niveau a été déclenchée manuellement ou automatiquement, comme indiqué ci-dessous.

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