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.

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 :

Environment 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.
Test 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.
Development 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 :

Environment 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.
Test
Development
Canary Version précoce 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 temps de production lorsque la version rapide est promue sur le canal que vous utilisez pour la production.

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 les notifications sur les mises à niveau de GKE de manière proactive, nous vous recommandons les méthodes suivantes :

  1. Utilisez l'API Kubernetes Engine pour orchestrer un workflow de mise à niveau lorsqu'une mise à niveau est requise pour vos clusters.
  2. Utilisez Pub/Sub pour vous abonner aux notifications de mise à niveau avant que les mises à niveau soient se produisent.

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 rationaliser 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 (exemple de script).
Time É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 :

Time É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 Une mise à niveau réussie consiste à 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.

Planifier des intervalles de maintenance et des exclusions

Pour augmenter la prévisibilité de la mise à niveau et aligner les mises à niveau sur les heures creuses, vous pouvez contrôler 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 s'exécute au-delà de l'intervalle de maintenance défini, GKE tente de mettre l'opération en pause et de reprendre l'opération lors du prochain intervalle.

Le processus de déploiement de GKE suit un calendrier de quatre jours qui répartit le processus de déploiement sur quatre jours ouvrés et met à niveau progressivement les clusters de différentes régions. Dans un environnement multicluster, vous pouvez utiliser le déploiement de quatre jours pour prédire les modifications appliquées géographiquement à différentes régions. En outre, vous pouvez utiliser des intervalles de maintenance pour contrôler et séquencer la perturbation dans différents 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 dupliqué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 le nombre d'instances dupliquées des 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

Le processus de mise à niveau des pools de nœuds GKE implique la recréation de chaque VM du pool de nœuds. Une nouvelle VM est créée avec la nouvelle version (image mise à jour) de manière progressive. De cette façon, vous devez arrêter tous les pods exécutés sur l'ancien nœud et les déplacer vers le nouveau nœud. 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 peut ralentir les performances de la 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 d'interruption en utilisant les mises à niveau de la 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.

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 Tasks
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