Bonnes pratiques de mise à niveau des clusters

Cette page fournit des instructions pour maintenir votre cluster Google Kubernetes Engine (GKE) à jour en continu, ainsi que des recommandations pour la création d'une stratégie de mise à niveau adaptée à vos besoins et permettant d'améliorer la disponibilité et la fiabilité de vos environnements. 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.

Sinon, pour gérer les mises à niveau automatiques des clusters dans les environnements de production organisés avec des parcs, consultez la page À propos des mises à niveau des clusters avec le séquençage du déploiement.

Configurer plusieurs environnements

Dans le cadre de votre workflow de livraison des mises à jour logicielles, nous vous recommandons d'utiliser plusieurs environnements. Utiliser plusieurs environnements vous permet de minimiser les risques et les temps d'arrêt non souhaités en testant les mises à jour logicielles et d'infrastructure séparément de votre environnement de production. Vous devez au minimum disposer d'un environnement de production et d'un environnement de préproduction ou de test.

Voici les environnements recommandés :

Environnement Description
Production Utilisé pour diffuser le trafic en direct aux utilisateurs finaux dans le cadre des applications métier critiques.
Préproduction Permet de s'assurer 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 Utilisé pour des charges de travaille d'analyse comparative des performances, de test et de contrôle qualité par rapport à la version de GKE que vous utiliserez en production. Dans cet environnement, vous pouvez tester la mise à niveau du plan de contrôle et des nœuds avant la production.
Développement Utilisé pour le développement actif qui s'appuie sur la même version exécutée en production. Dans cet environnement, vous créez des correctifs et des modifications incrémentielles à déployer en production.
Canary Utilisé en tant qu'environnement de développement secondaire pour tester les nouvelles versions de Kubernetes, les fonctionnalités GKE et les API de façon à réduire le temps de production une fois que ces versions sont promues et deviennent les versions par défaut.

Enregistrer des clusters dans les canaux de publication

Kubernetes publie régulièrement de nouvelles versions pour fournir des mises à jour de sécurité, résoudre les problèmes connus et introduire de nouvelles fonctionnalités. Les canaux de publication de GKE permettent aux clients de trouver un équilibre entre stabilité et l'ensemble des fonctionnalités de la version déployée dans le cluster. Lorsque vous enregistrez un nouveau cluster dans un canal de publication, Google gère automatiquement la version et la fréquence de mise à jour du cluster et de ses pools de nœuds.

Pour maintenir les clusters à jour avec les dernières mises à jour de GKE et de Kubernetes, voici quelques environnements recommandés, ainsi que les canaux de publication dans lesquels les clusters doivent être enregistrés :

Environnement Canal de publication Description
Production Stable ou standard Pour assurer la stabilité et la maturité des versions, utilisez le canal stable ou standard pour les charges de travail en production.
Préproduction Identique à la production Pour vous assurer que vos tests révèlent la version vers laquelle votre production sera mise à niveau, utilisez le même canal de publication.
Tests
Développement
Canary Élasticité Pour tester les dernières versions de Kubernetes et prendre une longueur d'avance en testant de nouvelles fonctionnalités GKE ou API, utilisez le canal rapide. Vous pouvez optimiser votre délai de mise sur le marché lorsque la version rapide est promue sur le canal que vous utilisez pour la production.
N/A Étendu Pour 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, utilisez la version étendue. Pour en savoir plus, consultez la section Utiliser la version étendue lorsque vous avez besoin d'un support à long terme.

Les plans de contrôle du cluster sont toujours mis à niveau régulièrement, que votre cluster soit enregistré dans un canal de publication ou non.

Créer une stratégie de mise à niveau continue

Après avoir enregistré votre cluster dans un canal de publication, il est régulièrement mis à niveau vers la version qui répond à la barre de qualité et de stabilité du canal. Ces mises à jour incluent des corrections de bugs et de sécurité, qui sont appliquées de plus en plus minutieusement au niveau de chaque canal :

  • Les correctifs sont déployés de manière progressive au niveau du plan de contrôle et des nœuds de tous les canaux, ce qui vous permet de gagner du temps dans les canaux rapides et standards avant d'arriver sur le canal stable.
  • En conformité avec la stratégie Kubernetes OSS, la mise à niveau commence par le plan de contrôle et se termine par les nœuds. En d'autres termes, kubelet ne doit pas être antérieur à kube-apiserver.
  • GKE déploie automatiquement les correctifs sur les canaux en fonction de leur criticité et de leur importance.
  • La version stable ne reçoit que des correctifs critiques.

Recevoir des notifications concernant les nouvelles versions de GKE

Les informations sur les nouvelles versions sont publiées sur la page principale des notes de version GKE, ainsi que sur un flux RSS. Chaque canal de publication possède une page de notes de version simplifiée et dédiée (par exemple : Notes de version pour la version stable) avec des informations sur la version de GKE recommandée pour ce canal.

Pour recevoir des notifications sur les mises à niveau de GKE de manière proactive avant qu'elles ne se produisent, utilisez Pub/Sub pour vous abonner aux notifications de mise à niveau.

Une fois qu'une nouvelle version devient disponible, vous devez planifier une mise à niveau avant que la version devienne la version par défaut dans le volet. Cette approche permet davantage de contrôle et de prévisibilité en cas de besoin, car GKE ignore la mise à niveau automatique des clusters déjà mis à niveau à l'avance.

Tester et vérifier les nouvelles versions de correctif et versions mineures

Toutes les versions sont soumises aux tests internes, quel que soit le canal dans lequel elles sont déployées. Toutefois, en raison des mises à jour et des correctifs fréquemment effectués en amont pour Kubernetes et GKE, nous vous recommandons vivement de tester les nouvelles versions sur les environnements de test et/ou de préproduction avant leur déploiement dans votre environnement de production, en particulier pour les mises à niveau des versions mineures de Kubernetes.

Chaque canal de publication propose deux versions : par défaut et disponible.

  • Les nouvelles versions de correctif sont disponibles une semaine avant leur mise en service par défaut.
  • Les nouvelles versions mineures de Kubernetes sont disponibles quatre semaines avant leur mise en service par défaut.

GKE met automatiquement à niveau les clusters vers la version par défaut de manière progressive. Si vous avez besoin de davantage de contrôle sur le processus de mise à niveau, nous vous recommandons de procéder à une mise à niveau à l'avance vers une version disponible. La mise à niveau automatique de GKE ignore les clusters mis à jour manuellement.

L'approche recommandée pour automatiser et simplifier les mises à niveau fait appel aux éléments suivants :

  • Un environnement de préproduction utilisant la version disponible.
  • Des notifications de mise à niveau configurées sur le cluster afin d'informer votre équipe des nouvelles versions disponibles à tester et à certifier.
  • Un environnement de production abonné à un canal de publication et utilisant la version par défaut dans le canal.
  • Un déploiement progressif des nouvelles versions disponibles sur les clusters de production. Par exemple, s'il existe plusieurs clusters de production, la stratégie de mise à niveau progressive consiste dans un premier temps à mettre à niveau une partie de ces clusters vers la version disponible, tout en conservant les autres sur la version par défaut, puis d'effectuer des mises à niveau supplémentaires fractionnées jusqu'à ce que la totalité des clusters soit mis à jour.

Le tableau suivant récapitule les événements de déploiement et les actions recommandées :

Événement Action recommandée
La nouvelle version X est désormais disponible dans un canal. Mettez à niveau votre cluster de test manuellement, puis qualifiez et testez la nouvelle version.
La version X devient la version par défaut. GKE lance la mise à niveau automatique vers la version par défaut. Envisagez de mettre à niveau la production en amont de la flotte.
GKE lance la mise à niveau automatique des clusters. Autorisez les clusters à mettre à niveau automatiquement ou à reporter la mise à niveau à l'aide des intervalles d'exclusion de maintenance.

Stratégie de mise à niveau pour les versions de correctifs

Voici une stratégie de mise à niveau recommandée pour les versions de correctif basée sur le scénario suivant :

  • Tous les clusters sont abonnés au canal stable.
  • Les nouvelles versions disponibles sont d'abord déployées sur le cluster de préproduction.
  • Le cluster de production est automatiquement mis à niveau avec les nouvelles versions par défaut.
  • Surveillez régulièrement les nouvelles versions disponibles pour GKE.
Heure Événement Que dois-je faire ?
T – 1 semaine Une nouvelle version de correctif est disponible. Mettez à niveau l'environnement de préproduction.
T La version de correctif devient la version par défaut. Envisagez de mettre à niveau le plan de contrôle de production à l'avance pour optimiser la prévisibilité.
T GKE lance la mise à niveau des plans de contrôle vers la version par défaut. Envisagez de mettre à niveau les pools de nœuds de production à l'avance pour optimiser la prévisibilité.
T + 1 semaine GKE lance la mise à niveau des pools de nœuds du cluster vers la version par défaut. GKE met automatiquement à niveau les clusters, en ignorant les clusters mis à jour manuellement.

Stratégie de mise à niveau pour les nouvelles versions mineures

Voici une stratégie de mise à niveau recommandée pour les versions mineures :

Heure Événement Que dois-je faire ?
T – 3 semaines Une nouvelle version mineure est disponible Mettez à jour le plan de contrôle des tests.
T – 2 semaines
  1. En cas de réussite de la mise à niveau d'un plan de contrôle, envisagez de mettre à niveau le plan de contrôle de production à l'avance.
  2. Mettez à niveau les pools de nœuds de test.
T – 1 semaine En cas de réussite de la mise à niveau, envisagez de mettre à niveau les pools de nœuds de production à l'avance.
T La version mineure devient la version par défaut.
T GKE lance la mise à niveau des plans de contrôle de cluster vers la version par défaut. Créez un intervalle d'exclusion si vous avez besoin de tests supplémentaires ou de davantage réduire les risques avant le déploiement en production.
T + 1 semaine GKE lance la mise à niveau des pools de nœuds du cluster vers la version par défaut. GKE met automatiquement à niveau les clusters, en ignorant les clusters mis à jour manuellement.

Réduire les perturbations sur les charges de travail existantes lors d'une mise à niveau

Pour garantir la vitalité de vos clusters et la continuité de l'activité, il est essentiel de maintenir vos clusters à jour avec des correctifs de sécurité et des corrections de bugs. Les mises à jour régulières protègent vos charges de travail contre les failles et les défaillances.

Programmer des intervalles de maintenance et des exclusions

Pour augmenter la prévisibilité des mises à niveau et aligner les mises à niveau sur les heures creuses, vous pouvez contrôler à la fois les mises à niveau automatiques du plan de contrôle et des nœuds en créant un intervalle de maintenance. GKE respecte les intervalles de maintenance. Plus précisément, si le processus de mise à niveau se déroule au-delà de l'intervalle de maintenance défini, GKE tente de mettre l'opération en pause et de la reprendre lors du prochain intervalle de maintenance.

GKE suit un calendrier de déploiement sur plusieurs jours pour la mise à disposition de nouvelles versions, ainsi que la mise à niveau automatique des plans de contrôle et des nœuds du cluster dans différentes régions. Le déploiement s'étend généralement sur quatre jours ou plus et inclut un temps d'observation et de surveillance des problèmes. Dans un environnement multicluster, vous pouvez utiliser un intervalle de maintenance distinct pour chaque cluster afin de séquencer le déploiement entre vos clusters. Par exemple, vous pouvez décider de contrôler quand des clusters situés dans différentes régions reçoivent des opérations de maintenance en définissant différents intervalles de maintenance pour chaque cluster.

Les exclusions de maintenance sont un autre outil qui permet de réduire les perturbations, en particulier pendant les périodes de forte activité. Utilisez l'exclusion de maintenance pour empêcher la maintenance automatique pendant ces périodes. Les exclusions de maintenance peuvent être définies sur des clusters nouveaux ou existants. Vous pouvez également utiliser les exclusions en parallèle de votre stratégie de mise à niveau. Par exemple, vous pouvez souhaiter reporter une mise à niveau d'un cluster de production en cas d'échec d'un environnement de test ou de préproduction dû à une mise à niveau.

Définir une tolérance d'interruption

Vous connaissez peut-être le concept d'instances répliquées dans Kubernetes. Les instances dupliquées garantissent la redondance de vos charges de travail pour améliorer les performances et la réactivité. Lorsqu'elles sont définies, les instances dupliquées régissent à tout moment le nombre d'instances dupliquées de pods en cours d'exécution. Toutefois, pendant la maintenance, Kubernetes supprime les VM de nœud sous-jacentes, ce qui peut réduire le nombre d'instances dupliquées. Pour garantir que vos charges de travail disposent d'un nombre suffisant d'instances dupliquées pour vos applications, même pendant la maintenance, utilisez un budget d'interruption de pod (PDB).

Dans un budget d'interruption de pod, vous pouvez définir un nombre (ou un pourcentage) de pods pouvant être arrêtés, même si l'arrêt des pods fait baisser le nombre d'instances dupliquées actuel en dessous de la valeur souhaitée. Ce processus peut accélérer le drainage du nœud en supprimant la nécessité d'attendre que les pods migrés deviennent totalement opérationnels. À la place, le drainage expulse les pods d'un nœud selon la configuration PDB, ce qui permet au déploiement de déployer des pods manquants sur d'autres nœuds disponibles. Une fois le PDB 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. GKE suit un PDB pendant 60 minutes maximum.

Contrôler les mises à niveau du pool de nœuds

Avec GKE, vous pouvez choisir une stratégie de mise à niveau de nœuds pour déterminer le mode de mise à niveau des nœuds de vos pools de nœuds. Par défaut, les pools de nœuds utilisent les mises à niveau de la surutilisation. Avec les mises à niveau de la surutilisation, le processus de mise à niveau des pools de nœuds GKE implique la recréation de chaque VM dans le pool de nœuds. Une nouvelle VM est créée avec la nouvelle version (image mise à niveau) de manière progressive. Cela implique d'arrêter tous les pods exécutés sur l'ancien nœud et de les déplacer vers les nouveaux nœuds. Vos charges de travail peuvent s'exécuter avec une redondance suffisante (instances dupliquées), et vous pouvez compter sur Kubernetes pour déplacer et redémarrer des pods si nécessaire. Toutefois, un nombre d'instances dupliquées temporairement réduit peut perturber votre activité et ralentir les performances de charge de travail jusqu'à ce que Kubernetes soit à nouveau à l'état souhaité (c'est-à-dire, jusqu'à atteindre le nombre minimal d'instances dupliquées nécessaires). Vous pouvez éviter ce type de perturbation à l'aide des mises à niveau de surutilisation.

Lors d'une mise à niveau avec mise à niveau de surutilisation activée, GKE sécurise d'abord les ressources (machines) nécessaires à la mise à niveau, puis crée un nœud mis à niveau, draine uniquement l'ancien nœud, et l'arrête. Ainsi, la capacité attendue reste intacte tout au long du processus de mise à niveau.

Pour les clusters volumineux dans lesquels le processus de mise à niveau peut prendre plus de temps, vous pouvez accélérer le processus en effectuant une mise à niveau simultanée de plusieurs nœuds à la fois. Utilisez la mise à niveau de la surutilisation avec maxSurge=20, maxUnavailable=0 pour indiquer à GKE de mettre à niveau 20 nœuds à la fois, sans utiliser la capacité existante.

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

Si vous souhaitez conserver plus longtemps votre cluster sur une version mineure, suivez les bonnes pratiques d'enregistrement de votre cluster dans le canal étendu. Avec ce canal, GKE est compatible avec une version mineure pendant environ 24 mois. Pour en savoir plus, consultez la page Obtenir un support à long terme avec le canal étendu.

Pour tirer le meilleur parti du canal, nous vous recommandons de respecter les bonnes pratiques suivantes. 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.

Conserver temporairement 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 canal de publication vers le canal étendu pour continuer à recevoir les correctifs de sécurité tout en vous préparant à la mise à niveau vers 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 à 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 versions mineures successives une à deux fois par an. Par exemple, passez de la version 1.30 à la version 1.31 puis à la version 1.32.

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

Quand ne pas utiliser la version étendue

Pour utiliser la version étendue aux fins prévues par cette règle, 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 indéfiniment votre cluster sur une version mineure, enregistrez votre cluster dans le canal étendu et n'effectuez aucune autre action. Toutes les versions mineures finissent par ne plus être compatibles et GKE met automatiquement à niveau les clusters à partir de versions mineures non compatibles. Ainsi, GKE met à niveau ce cluster d'une version mineure non compatible vers une version mineure qui ne sera bientôt plus compatible, ce qui correspond en moyenne à environ tous les quatre mois. Cela signifie que le cluster reçoit des mises à niveau de versions mineures aussi fréquemment sur d'autres canaux de publication, mais reçoit ultérieurement de nouvelles fonctionnalités.

Checklist

Le tableau suivant récapitule les tâches recommandées pour une stratégie de mise à niveau visant à maintenir les clusters GKE à jour en continu :

Bonne pratique Tâches
Configurer plusieurs environnements
Enregistrer des clusters dans les canaux de publication
Créer une stratégie de mise à niveau continue
Réduire les perturbations aux charges de travail existantes

Étape suivante