Bonnes pratiques pour les mises à niveau des clusters GKE

Ce document présente les bonnes pratiques à suivre par les administrateurs de plate-forme pour gérer les mises à niveau des clusters Google Kubernetes Engine (GKE). Par défaut, GKE met automatiquement à niveau la version du plan de contrôle et des nœuds de votre cluster pour fournir de nouvelles fonctionnalités, des corrections de bugs et des correctifs de sécurité afin de garantir les performances et la sécurité de votre environnement.

Pour vous assurer que ces mises à niveau automatiques répondent à vos besoins opérationnels et minimisent les perturbations des charges de travail, GKE propose des outils qui vous permettent de contrôler au maximum le processus. Ce guide explique comment utiliser efficacement ces outils pour maintenir des performances et une disponibilité élevées. Pour comprendre les bases, consultez À propos des mises à niveau des clusters GKE.

En plus des mises à niveau de cluster, qui ne concernent que la version GKE du plan de contrôle et des nœuds, GKE effectue régulièrement des mises à jour supplémentaires du cluster. L'implémentation des bonnes pratiques décrites dans ce document peut vous aider à vous préparer à certains de ces types de modifications. Pour en savoir plus, consultez Gérer les modifications du cycle de vie des clusters pour minimiser les perturbations.

Pour obtenir un aperçu complet de toutes les bonnes pratiques GKE, consultez Bonnes pratiques pour GKE.

Checklist

Le tableau suivant récapitule les tâches expliquées en détail dans les sections suivantes. Nous vous recommandons d'effectuer ces tâches lorsque vous préparez votre environnement pour les mises à niveau de cluster.

Bonnes pratiques Tâches
Choisir l'équilibre entre la vélocité des fonctionnalités et la stabilité des mises à niveau avec les canaux de publication
Choisir le calendrier des mises à niveau avec les règles de maintenance
Contrôler le déploiement des mises à niveau sur les clusters
Contrôler le déclenchement des mises à niveau
Surveiller les mises à niveau de clusters
Minimiser les perturbations sur les charges de travail existantes lors des mises à niveau de nœuds

Choisir l'équilibre entre la vélocité des fonctionnalités et la stabilité des mises à niveau avec les canaux de publication

Avec les canaux de publication, vous choisissez un équilibre entre la vélocité des fonctionnalités et la stabilité des mises à niveau. Par défaut, les clusters GKE sont enregistrés dans la version disponible standard. Lorsque GKE met à niveau le plan de contrôle et les nœuds de votre cluster pour fournir des correctifs de sécurité, résoudre des problèmes connus et introduire de nouvelles fonctionnalités, le version disponible détermine les versions GKE exécutées par votre cluster. Par exemple, si vous souhaitez bénéficier des nouvelles fonctionnalités plus rapidement, vous pouvez choisir le canal rapide. Si vous préférez les versions plus stables, choisissez le canal stable. Pour en savoir plus sur le choix entre des canaux spécifiques, consultez Quels sont les canaux disponibles ?.

Si vous souhaitez mettre à niveau manuellement vos clusters, vous pouvez toujours choisir votre version disponible en examinant les versions disponibles et les cibles de mise à niveau automatique pour le canal avant de sélectionner une nouvelle version.

De plus, si vous souhaitez obtenir des versions de correctifs dans un version disponible dès que possible (par exemple, pour recevoir des correctifs de sécurité critiques), consultez À propos de l'obtention de versions de correctifs plus tôt.

Choisir le niveau d'assistance dont vous avez besoin pour une version mineure

GKE fournit jusqu'à 24 mois de compatibilité au total pour une version mineure une fois que la version a été mise à disposition dans le canal standard. Cette assistance inclut 14 mois d'assistance standard et environ 10 mois d'assistance étendue disponible avec le canal étendu. Pour en savoir plus sur la façon dont GKE est compatible avec une version mineure, consultez Compatibilité avec les versions mineures.

Si vous devez conserver votre cluster sur une version mineure plus longtemps tout en continuant à recevoir des correctifs de sécurité au-delà de la date de fin de l'assistance standard, ou si vous souhaitez empêcher l'application de la fin de l'assistance standard, vous pouvez également utiliser le canal étendu. Pour en savoir plus, consultez la section Utiliser la version étendue lorsque vous avez besoin d'un support à long terme.

Lorsque la version mineure atteint la fin de la période d'assistance, GKE met automatiquement à niveau votre cluster en fonction du canal de publication auquel il est enregistré, afin de garantir qu'il reste performant et sécurisé. Pour en savoir plus, consultez Mises à niveau automatiques des clusters pour la sécurité et la compatibilité. Si vous utilisez les outils décrits dans ce document pour empêcher ou retarder la mise à niveau automatique des clusters, nous vous recommandons de mettre à niveau manuellement vos clusters avant que la version mineure qu'ils exécutent n'arrive en fin de vie. Sinon, GKE met automatiquement à niveau votre cluster.

Choisir le calendrier des mises à niveau avec les règles de maintenance

Pour contrôler quand les mises à niveau peuvent et ne peuvent pas avoir lieu, utilisez les éléments suivants :

  • Intervalles de maintenance : choisissez un intervalle de temps récurrent pendant lequel GKE peut mettre à niveau votre cluster, par exemple pendant les heures creuses. Si le processus de mise à niveau se déroule au-delà de l'intervalle de maintenance, GKE tente de mettre l'opération en pause et de la reprendre lors du prochain intervalle de maintenance.
  • Exclusions de maintenance : choisissez une période spécifique pendant laquelle GKE ne peut pas mettre à niveau votre cluster, par exemple lors d'un événement commercial majeur pour une entreprise de vente au détail. Vous pouvez également utiliser des exclusions de maintenance pour reporter temporairement les mises à niveau automatiques d'un cluster lorsque, par exemple, vous remarquez un problème avec d'autres clusters mis à niveau vers une nouvelle version.
    • Pour les cas d'utilisation avancés, vous devrez peut-être effectuer manuellement certains types de mises à niveau au lieu de laisser GKE s'en charger. Vous pouvez utiliser des exclusions de maintenance pour désactiver ces types de mises à niveau automatiques. Par exemple, vous pouvez utiliser le champ d'application "Aucune mise à niveau mineure ni de nœud" pour désactiver toutes les mises à niveau mineures et toutes les mises à niveau de nœuds. Vous devez effectuer manuellement ces mises à niveau, ou GKE met à niveau vos clusters à la fin de la période de compatibilité de la version mineure.
  • Fréquence de maintenance : pour les cas d'utilisation avancés, contrôlez l'intervalle minimal entre deux mises à niveau automatiques consécutives avec le budget d'indisponibilité du cluster.

En configurant des règles de maintenance, vous pouvez améliorer la prévisibilité des mises à niveau et vous assurer qu'elles ont lieu au moment le plus opportun pour vos charges de travail.

Contrôler le déploiement des mises à niveau sur les clusters

Nous vous recommandons d'utiliser plusieurs environnements pour minimiser les risques et les temps d'arrêt non souhaités en testant les modifications logicielles et d'infrastructure séparément de votre environnement de production. Nous vous recommandons au minimum de disposer d'un environnement de production et d'un environnement de préproduction ou de test.

Voici les environnements recommandés :

Environnement Description
Production Diffuser le trafic en direct aux utilisateurs finaux pour les applications métier critiques.
Canary Testez une petite partie de l'environnement de production avant la mise à niveau de tous les clusters.
Préproduction Vérifiez que toutes les nouvelles modifications déployées à partir d'environnements précédents fonctionnent comme prévu avant que celles-ci ne soient déployées en production.
Tests Effectuez des analyses comparatives, des tests et un contrôle qualité pour les charges de travail avec la version de GKE que vous utiliserez en production.
Développement Utilisez la même version que celle exécutée en production pour le développement actif. Dans cet environnement, vous créez des correctifs et des modifications incrémentielles à déployer en production.

GKE fournit des fonctionnalités telles que le séquençage du déploiement pour vous aider à contrôler la façon dont les mises à niveau sont déployées dans ces différents environnements, comme indiqué dans la section suivante.

Utiliser le séquençage du déploiement pour déployer dans plusieurs environnements

Pour déployer progressivement de nouvelles versions de GKE dans ces environnements et entre eux, nous vous recommandons d'utiliser le séquencement des déploiements. Avec le séquençage du déploiement, tous les clusters utilisent le même version disponible et la même version mineure tout au long des étapes de déploiement. GKE déploie progressivement les nouvelles versions dans la séquence que vous configurez. Lorsque GKE déploie la nouvelle version dans vos environnements, vous pouvez vérifier que votre environnement de cluster et vos charges de travail s'exécutent comme prévu avec la nouvelle version.

Si vous configurez un nouvel environnement, utilisez le séquençage du déploiement avec des étapes personnalisées (preview). Cette nouvelle version du séquençage du déploiement vous permet de diviser le déploiement d'une nouvelle version sur un parc en plusieurs étapes. Avec cette approche, GKE peut, par exemple, mettre à niveau un environnement Canary en production avant de mettre à niveau le reste de la production. Pour une version en disponibilité générale de la fonctionnalité qui utilise un modèle plus linéaire sans étapes personnalisées, consultez À propos des mises à niveau de cluster avec séquencement du déploiement.

Tester les mises à niveau mineures et de correctifs GKE

GKE met automatiquement à niveau les clusters vers un nouveau correctif toutes les semaines. Toutefois, les mises à niveau des versions mineures ne sont effectuées qu'environ trois fois par an. Les nouvelles versions mineures de Kubernetes introduisent un plus grand nombre de modifications par rapport aux correctifs de la même version mineure. Nous vous recommandons d'être particulièrement vigilant lors du déploiement des mises à niveau des versions mineures dans vos environnements, afin de vous assurer que la nouvelle version mineure fonctionne comme prévu avec vos clusters et vos charges de travail.

Effectuer des vérifications avant de mettre à niveau votre cluster

Avant d'effectuer des mises à niveau automatiques des clusters, GKE qualifie les nouvelles versions pendant une durée qui dépend du version disponible et vérifie l'état de préparation du cluster.

Avant de mettre à niveau les clusters, nous vous recommandons de procéder comme suit :

  • Pour toutes les mises à niveau, y compris les mises à niveau mineures et de type correctif :
    • Consultez les notes de version de GKE pour connaître les problèmes et trouver le journal des modifications des nouvelles versions mineures et de correctifs.
    • Consultez les problèmes connus de GKE pour identifier les problèmes liés à l'environnement de votre cluster et à la nouvelle version.
  • Pour les mises à niveau mineures, consultez également les points suivants :
    • Vérifiez les abandons d'API. Pour en savoir plus, consultez les notes de version de GKE pour la nouvelle version, le journal des modifications de Kubernetes et la section Fonctionnalités et API obsolètes.
    • Assurez-vous que le décalage de version entre le plan de contrôle et les nœuds est compatible. GKE permet d'exécuter des nœuds dont la version est antérieure de deux versions mineures à celle du plan de contrôle. Pour en savoir plus, consultez le Règlement sur l'asymétrie des versions GKE.
  • Pour les mises à niveau de nœuds :

Contrôler le déclenchement des mises à niveau

Par défaut, GKE met automatiquement à niveau les clusters vers de nouvelles versions à intervalles réguliers. Toutefois, vous pouvez également utiliser les mises à niveau manuelles pour mettre à niveau votre cluster exactement quand vous le souhaitez et contrôler la version exécutée par votre cluster.

Vous pouvez procéder comme suit :

  • Mettez à niveau manuellement votre cluster.

  • Effectuez des actions pour les mises à niveau automatiques ou manuelles des nœuds en cours, y compris les suivantes :

    • Annuler une mise à niveau
    • Reprenez une mise à niveau.
    • Effectuez le rollback d'une mise à niveau.
    • Terminez une mise à niveau en cours.

Si vous souhaitez mieux contrôler le processus de mise à niveau, nous vous recommandons de configurer des exclusions de maintenance, puis d'effectuer des mises à niveau manuelles si nécessaire. Pour en savoir plus sur les mises à niveau manuelles et les autres actions que vous pouvez effectuer pour les mises à niveau en cours, consultez Mettre à niveau manuellement un cluster ou un pool de nœuds.

Surveiller les mises à niveau de clusters

Pour vous assurer que les mises à niveau de GKE se déroulent comme prévu et que l'environnement de votre cluster reste performant et disponible, utilisez les outils suivants pour surveiller les mises à niveau de cluster. Pour rester informé de l'état de vos clusters, utilisez des outils tels que les notifications, les insights et recommandations, et les journaux. Nous vous recommandons tout particulièrement de prêter attention aux notifications de fin de prise en charge, de début de mise à niveau et de mise à niveau planifiée avec activation pour les mises à niveau des versions mineures. Configurez des règles d'alerte pour vous assurer de recevoir ces notifications.

Consultez les ressources suivantes pour en savoir plus sur les mises à niveau actuelles :

Minimiser les perturbations sur les charges de travail existantes lors des mises à niveau de nœuds

En plus des bonnes pratiques générales décrites dans les sections précédentes, nous vous recommandons d'envisager une configuration avancée supplémentaire pour personnaliser davantage le processus de mise à niveau en fonction de l'environnement de votre cluster et des besoins de vos charges de travail.

Autres considérations pour des profils de charge de travail spécifiques

Certains types de charges de travail et d'environnements de cluster nécessitent une préparation supplémentaire pour les mises à niveau de cluster. Si votre charge de travail correspond à une ou plusieurs des catégories suivantes, tenez compte de ces considérations supplémentaires :

  • Charges de travail exécutées sur des machines qui ne migrent pas à chaud : les nœuds GKE, qui sont des instances Compute Engine que GKE crée en votre nom, nécessitent régulièrement une maintenance de l'infrastructure sous-jacente. La plupart des instances Compute Engine peuvent être migrées à chaud, ce qui signifie que les charges de travail en cours d'exécution ne sont pas interrompues lors de cette maintenance. Toutefois, certains types de machines ne peuvent pas migrer à chaud, ce qui signifie que les charges de travail exécutées sur les nœuds GKE peuvent être perturbées. Il est important de noter que les accélérateurs, tels que les GPU et les TPU pour les charges de travail d'IA/ML, ne peuvent pas être migrés à chaud. Pour en savoir plus, consultez Gérer les perturbations des nœuds GKE qui ne migrent pas à chaud.
  • Charges de travail avec capacité limitée : si vos charges de travail utilisent des types de machines dont la capacité est limitée, vous devez prendre des précautions supplémentaires lorsque vous mettez à niveau des clusters. Pour en savoir plus, consultez Vérifier les ressources pour les mises à niveau des nœuds.
  • Charges de travail avec état : si vos charges de travail sont avec état et ont des exigences spécifiques pour l'arrêt et le redémarrage, vous devez prendre des précautions supplémentaires lorsque vous effectuez des mises à niveau de cluster. Pour en savoir plus, consultez S'assurer que les charges de travail sont prêtes en cas de perturbation.

Consultez les sections suivantes pour comprendre comment utiliser les outils disponibles pour mettre à niveau ces types de charges de travail.

Choisir une stratégie de mise à niveau des nœuds

En mode GKE Standard, GKE propose différentes stratégies de mise à niveau des nœuds qui déterminent la façon dont les nœuds individuels de votre pool de nœuds sont mis à niveau. En choisissant une stratégie de mise à niveau pour votre pool de nœuds Standard, vous pouvez choisir le processus offrant le juste équilibre entre vitesse, perturbation de la charge de travail, atténuation des risques et optimisation des coûts. Vous pouvez également configurer les paramètres de la stratégie pour répondre au mieux à vos besoins. En mode GKE Autopilot, GKE gère les mises à niveau des nœuds. Vous n'avez pas besoin de choisir la stratégie spécifique utilisée. Pour en savoir plus, consultez À propos des stratégies de mise à niveau des nœuds.

Définir une tolérance d'interruption

Utilisez des budgets d'interruption de pod (PDB) pour vous assurer que vos charges de travail conservent une redondance suffisante lorsque GKE recrée les nœuds lors des mises à niveau, ce qui peut réduire temporairement le nombre de répliques pour une charge de travail.

Si un PDB est défini, GKE n'arrête pas les pods de votre application si le nombre de pods est égal ou inférieur à une limite configurée. Les mises à niveau GKE respectent un PDB pendant 60 minutes maximum. De plus, GKE vous avertit si le drainage d'un nœud est bloqué par un PDB ou si le délai d'expiration du PDB est atteint et que les pods seront supprimés de force malgré la violation du PDB. Pour en savoir plus, consultez Événements perturbateurs lors de la mise à niveau d'un pool de nœuds.

Utiliser l'arrêt progressif pour arrêter une application

Vous pouvez configurer l'arrêt progressif pour vous assurer que les charges de travail ont suffisamment de temps pour se préparer à l'arrêt. Lors des mises à niveau de nœuds, GKE respecte les paramètres d'arrêt progressif pendant 60 minutes maximum avec les mises à niveau de la surutilisation par défaut, et pendant 24 heures maximum avec les mises à niveau bleu-vert et les mises à niveau bleu-vert avec autoscaling (aperçu).

Pour en savoir plus sur la configuration des paramètres d'arrêt progressif, consultez Configurer GKE pour arrêter correctement vos charges de travail.

Utiliser la version étendue lorsque vous avez besoin d'un support à long terme

Si vous souhaitez conserver votre cluster sur une version mineure plus longtemps, suivez la bonne pratique consistant à enregistrer votre cluster dans le canal étendu. Avec ce canal, GKE est compatible avec une version mineure pendant environ 24 mois. Avec le canal Extended, vous contrôlez les mises à niveau des versions mineures. GKE n'effectue des mises à niveau automatiques à la fin de la période d'assistance que si vous ne lancez pas vous-même la mise à niveau. Pour en savoir plus, consultez Obtenir un support à long terme avec le canal étendu.

Si vous n'avez pas besoin de rester sur une version mineure plus longtemps que la période d'assistance standard, mais que vous souhaitez tout de même contrôler les mises à niveau des versions mineures, utilisez plutôt les exclusions de maintenance avec le champ d'application "Aucune mise à niveau mineure".

Pour tirer le meilleur parti de ce canal, nous vous recommandons de suivre les bonnes pratiques ci-dessous. Certaines de ces bonnes pratiques nécessitent d'effectuer des actions manuelles, telles que la mise à jour manuelle d'un cluster et la modification du canal de publication d'un cluster. Consultez les scénarios compatibles suivants, ainsi que la section Quand ne pas utiliser le canal étendu.

Rester temporairement sur une version mineure plus longtemps

Si vous devez conserver temporairement un cluster sur une version mineure pendant une période plus longue que la période d'assistance standard de 14 mois, par exemple pour limiter l'utilisation d'API obsolètes supprimées dans la version mineure suivante, procédez comme suit. Vous pouvez déplacer temporairement le cluster d'un autre version disponible vers le canal étendu pour continuer à recevoir des correctifs de sécurité tout en vous préparant à passer à la version mineure suivante. Lorsque vous êtes prêt à effectuer la mise à niveau vers la version mineure suivante, vous devez mettre à niveau manuellement le cluster, puis le replacer dans le canal de publication d'origine.

Mises à niveau de versions mineures une ou deux fois par an

Si vous souhaitez bénéficier d'une perturbation minimale pour votre cluster tout en continuant à recevoir de nouvelles fonctionnalités lorsque votre cluster est prêt à être mis à niveau vers une nouvelle version mineure, procédez comme suit :

  • Enregistrez un cluster dans le canal étendu.
  • Effectuez deux mises à niveau de version mineure successives une ou deux fois par an. Par exemple, passez de la version 1.33 à la version 1.34, puis à la version 1.35.

Ce processus permet de s'assurer que le cluster reste sur une version mineure disponible et reçoit les fonctionnalités des nouvelles versions mineures, mais ne reçoit les mises à niveau de version mineure que lorsque vous décidez que le cluster est prêt.

Quand ne pas utiliser le canal étendu

Pour utiliser la version étendue aux fins prévues, vous devez effectuer une action manuelle. Le scénario suivant illustre les conséquences de l'utilisation du canal Étendu sans gestion active de la version mineure de votre cluster.

Ne rien faire et recevoir des mises à niveau mineures à la même fréquence

Si vous souhaitez conserver votre cluster sur une version mineure pour toujours, enregistrez-le dans le canal étendu et n'effectuez aucune autre action. Toutes les versions mineures finissent par devenir non compatibles, et GKE met automatiquement à niveau les clusters à partir des versions mineures non compatibles. Ainsi, GKE met à niveau ce cluster d'une version mineure non compatible vers une version mineure qui le sera bientôt, ce qui représente une mise à niveau environ tous les quatre mois. Cette approche signifie que le cluster reçoit des mises à niveau de version mineure aussi fréquemment que sur les autres canaux de publication, mais qu'il reçoit les nouvelles fonctionnalités plus tard.

Étapes suivantes