Ce document explique comment créer, planifier et mettre en œuvre des mises à niveau dans un environnement Google Kubernetes Engine (GKE) multicluster. Bien que ce document utilise Multi Cluster Ingress pour les mises à niveau, les concepts peuvent être appliqués à d'autres solutions. Ce document est destiné aux administrateurs Google Cloud chargés de gérer les parcs de clusters GKE.
Gestion du cycle de vie des clusters GKE
La gestion du cycle de vie des clusters peut être définie comme les stratégies et la planification requises pour maintenir un parc de clusters Kubernetes opérationnel et mis à jour, sans enfreindre les SLO du service. Si les stratégies et la planification appropriées sont mises en place, la gestion du cycle de vie d'un cluster doit être régulière, attendue et se dérouler sans incident.
Pour en savoir plus sur la gestion de la version GKE d'un cluster, consultez À propos des mises à niveau des clusters GKE. Pour en savoir plus sur la gestion de tous les types de modifications au cours du cycle de vie d'un cluster, consultez Gérer les modifications du cycle de vie d'un cluster pour minimiser les perturbations.
Gestion du cycle de vie d'un environnement multicluster GKE
Cette section décrit différentes stratégies de gestion du cycle de vie des environnements multiclusters GKE, et explique comment les planifier.
Considérations en termes de planification et de conception
L'architecture multicluster GKE joue un rôle dans la sélection de la stratégie de gestion du cycle de vie d'un cluster. Avant d'aborder ces stratégies, il est important de discuter de certaines décisions de conception pouvant affecter ou être affectées par la stratégie de gestion du cycle de vie du cluster.
Types de clusters
Si vous utilisez la mise à niveau automatique de GKE en tant que stratégie de gestion du cycle de vie d'un cluster, le type de cluster peut se révéler important. Par exemple, les clusters régionaux disposent de plusieurs nœuds de plan de contrôle qui sont mis à niveau automatiquement un par un, tandis que les clusters zonaux n'en possèdent qu'un seul. Si vous n'utilisez pas la mise à niveau automatique de GKE et si vous considérez tous les clusters Kubernetes comme une infrastructure temporaire, le type de cluster que vous choisissez peut ne pas être important lors de la définition d'une stratégie de gestion du cycle de vie d'un cluster. Vous pouvez appliquer les stratégies décrites dans la section suivante intitulée Gestion du cycle de vie d'un environnement multicluster GKE à tout type de cluster.
Emplacement et empreinte du cluster
Tenez compte des facteurs suivants lorsque vous choisissez l'emplacement et l'empreinte du cluster :
- Zones et régions dans lesquelles les clusters doivent se trouver.
- Nombre et taille des clusters nécessaires.
Le premier facteur est généralement facile à déterminer, car les zones et les régions sont identifiées par votre entreprise en fonction des régions dans lesquelles vous proposez vos services aux utilisateurs.
Le nombre et la taille des clusters relèvent des catégories suivantes, chacune présentant des avantages et des inconvénients :
- Petit nombre de clusters volumineux. Vous pouvez opter pour la redondance et la résilience fournies par les clusters régionaux, et placer un (ou deux) grands clusters régionaux par région. L'avantage de cette approche réside dans les faibles coûts opérationnels liés à la gestion de plusieurs clusters. Néanmoins, elle présente l'inconvénient de pouvoir affecter un grand nombre de services à la fois en raison de sa zone d'impact étendue.
- Grand nombre de petits clusters. Vous pouvez créer un grand nombre de petits clusters pour réduire leur zone d'impact, car les services sont répartis sur plusieurs clusters. Cette approche est également adaptée aux clusters éphémères de courte durée (par exemple, les clusters exécutant une charge de travail par lot). L'inconvénient de cette approche est qu'elle entraîne des coûts opérationnels plus élevés, car plus de clusters doivent être mis à niveau. Un nombre de nœuds de plan de contrôle plus élevé génère également des frais supplémentaires. Vous pouvez compenser les coûts et les frais d'exploitation généraux à l'aide de l'automatisation, d'une planification et d'une stratégie prévisibles, et d'une coordination minutieuse entre les équipes et les services concernés.
Ce document ne recommande pas une approche plus qu'une autre. Ce sont des options. Dans certains cas, vous pouvez choisir les deux modèles de conception pour différentes catégories de services.
Les stratégies suivantes s'appliquent à tous les modèles de conception.
Planification des capacités
Lorsque vous planifiez des capacités, il est important de prendre en compte la stratégie de cycle de vie du cluster choisie. La planification des capacités doit tenir compte des événements normaux de chargement et de maintenance du service :
- Événements planifiés, tels que les mises à niveau de clusters
- Événements non planifiés, tels que les interruptions de clusters dues à une mauvaise configuration ou à des déploiements incorrects
Lors de la planification des capacités, vous devez prendre en compte toutes les interruptions totales ou partielles. Si vous concevez uniquement pour les événements de maintenance planifiés, tous les services distribués doivent disposer d'un cluster supplémentaire en plus de ceux nécessaires. Vous pouvez ainsi mettre les clusters hors service un par un pour les mises à niveau, sans compromettre le service. Cette approche est également appelée planification des capacités N+1. Si vous concevez pour des événements de maintenance planifiés et non planifiés, tous les services distribués doivent disposer d'au moins deux clusters supplémentaires en plus de ceux nécessaires pour gérer la capacité prévue : l'un pour l'événement planifié et l'autre pour un éventuel événement non planifié au cours de l'intervalle de maintenance planifié. Cette approche est également appelée planification des capacités N+2.
Dans les architectures multiclusters, les termes drainage et débordement sont souvent utilisés. Ces termes font référence au processus de suppression (ou de drainage) du trafic d'un cluster et de redirection (ou de débordement) du trafic vers d'autres clusters lors des mises à niveau et des événements de maintenance. Ce processus est réalisé à l'aide de solutions de mises en réseau telles que les objets Ingress multicluster ou d'autres méthodes d'équilibrage de charge. L'utilisation minutieuse du drainage et du débordement est au cœur de certaines stratégies de gestion du cycle de vie des clusters. Lorsque vous planifiez des capacités, vous devez prendre en compte le drainage et le débordement. Par exemple, lorsque vous drainez un seul cluster, vous devez déterminer si les autres clusters disposent de la capacité nécessaire pour gérer le trafic de débordement supplémentaire. Il est également important de tenir compte d'autres facteurs, y compris si la zone ou la région dispose d'une capacité suffisante, ou s'il est nécessaire d'envoyer le trafic vers une autre région (si vous utilisez un seul cluster régional par région). Le schéma suivant montre comment le trafic est supprimé (parfois appelé drainage d'un cluster) d'un cluster et envoyé vers un autre cluster exécutant le même service distribué.
Clusters et services distribués
La conception des clusters basée sur les services spécifie que l'architecture de ces clusters (nombre, taille et emplacement) est déterminée par les services qu'ils doivent exécuter. Par conséquent, l'emplacement des clusters est défini en fonction de l'emplacement dans lequel les services distribués doivent se trouver. Tenez compte des points suivants lorsque vous choisissez l'emplacement des services distribués :
- Exigence concernant l'emplacement. Dans quelles régions le service doit-il être diffusé ?
- Criticité. Dans quelle mesure la disponibilité d'un service est-elle critique pour l'entreprise ?
- SLO. Quels sont les objectifs de niveau de service du service (généralement basés sur la criticité) ?
- Résilience. À quel point le service doit-il être résilient ? Doit-il résister aux défaillances de cluster, zonales, voire régionales ?
Lors de la planification des mises à niveau d'un cluster, vous devez prendre en compte le nombre de services affectés par son drainage, ainsi que la propagation de ces services dans d'autres clusters appropriés. Les clusters peuvent être à locataire unique ou mutualisés. Les clusters à locataire unique ne diffusent qu'un seul service ou produit représenté par un ensemble de services. Les clusters à locataire unique ne partagent pas le cluster avec d'autres services ou produits. Les clusters mutualisés peuvent exécuter de nombreux services et produits, qui sont généralement partitionnés en espaces de noms.
Impact sur les équipes
Un événement de cluster peut non seulement affecter les services, mais aussi les équipes. Par exemple, l'équipe DevOps devra peut-être rediriger ou interrompre ses pipelines CI/CD lors de la mise à niveau d'un cluster. De même, les équipes d'assistance peuvent être informées des interruptions prévues. L'automatisation et les outils doivent être en place afin d'atténuer l'impact sur plusieurs équipes. La mise à niveau d'un cluster ou d'un parc de clusters doit être considérée comme une routine sans interruption lorsque toutes les équipes sont informées.
Organisation, planification et coordination
Kubernetes publie une nouvelle version mineure par trimestre et conserve les trois versions les plus récentes. Vous devez planifier soigneusement l'organisation et la planification des mises à niveau des clusters. Un accord doit être trouvé entre les propriétaires de services, les opérateurs de service et les administrateurs de la plate-forme concernant l'application de ces mises à niveau. Lorsque vous planifiez des mises à niveau, posez-vous les questions suivantes :
- À quelle fréquence effectuez-vous les mises à niveau ? Effectuez-vous des mises à niveau tous les trimestres ou à une autre fréquence ?
- Quand effectuez-vous la mise à niveau ? Effectuez-vous la mise à niveau au début du trimestre lorsque l'activité ralentit ou pendant d'autres temps d'arrêt établis par votre entreprise ?
- Quand ne devez-vous pas effectuer la mise à niveau ? Avez-vous une planification bien définie pour éviter d'effectuer des mises à niveau, par exemple lors d'événements de grande envergure tels que le Black Friday ou le Cyber Monday, ou lors de conférences importantes ou d'événements spécifiques à votre secteur.
Il est important de mettre en place une stratégie que vous communiquez clairement aux propriétaires de service, ainsi qu'aux équipes en charge des opérations et de l'assistance. Afin d'éviter toute surprise, chacun doit savoir quand et comment les clusters sont mis à niveau. Cela nécessite une coordination claire avec toutes les équipes impliquées. Plusieurs équipes interagissent avec un seul service. En règle générale, ces équipes peuvent être regroupées dans les catégories suivantes :
- Le développeur de services, chargé de créer et de coder la logique métier dans un service.
- L'opérateur de service, chargé d'exécuter le service de manière sécurisée et fiable. Les opérateurs peuvent être répartis dans plusieurs équipes, telles que les administrateurs de règles et de la sécurité, les administrateurs réseau ou les équipes d'assistance.
Toutes les personnes impliquées doivent être en communication lors des mises à niveau des clusters afin de pouvoir prendre les mesures appropriées pendant cette période. Une approche consiste à planifier les mises à niveau de la même manière qu'un incident. Vous disposez d'un chargé d'incidents, d'un salon de discussion et d'une rétrospective (même si aucun utilisateur n'est affecté). Pour en savoir plus, consultez la page Réponse aux incidents.
Stratégies de cycle de vie des clusters GKE
Cette section décrit les principales stratégies de gestion du cycle de vie des clusters, souvent utilisées dans l'architecture multicluster GKE. Il est important de noter qu'une stratégie ne peut pas s'appliquer à tous les scénarios. Vous pouvez donc en choisir plusieurs pour différentes catégories de services et besoins de l'entreprise.
Mises à niveau progressives
Le schéma suivant illustre la stratégie de mise à niveau progressive.
Un cluster GKE est drainé de tout le trafic et mis à niveau à l'aide d'un équilibreur de charge. La charge du trafic drainé est redirigée vers un autre cluster GKE.
Les mises à niveau progressives constituent la stratégie la plus simple et la plus rentable parmi les stratégies décrites dans ce document. Vous commencez avec un nombre de clusters n exécutant la version old_ver (ou actuellement en production). Vous drainez ensuite m clusters à la fois, où m est inférieur à n. Vous devez ensuite supprimer et recréer des clusters avec la nouvelle version, ou mettre à niveau les clusters drainés.
Le choix entre la suppression et la mise à niveau de nouveaux clusters dépend de la taille des clusters, ainsi que de votre perception des clusters comme infrastructure immuable. L'infrastructure immuable suppose qu'au lieu de mettre à jour en permanence un cluster, ce qui peut générer des résultats indésirables au fil du temps, vous créez des clusters et évitez tout écart de configuration imprévu.
Si vous utilisez GKE, vous pouvez créer un cluster GKE à l'aide d'une seule commande ou d'un appel d'API. La nouvelle stratégie de cluster nécessite que l'intégralité de la configuration du cluster (fichiers manifestes du cluster) soit stockée en dehors du cluster, généralement dans Git. Vous pouvez ensuite utiliser le même modèle de configuration sur le nouveau cluster. S'il s'agit d'un nouveau cluster, assurez-vous que vos pipelines CI/CD pointent vers le cluster approprié. Une fois le cluster correctement configuré, vous pouvez renvoyer le trafic progressivement vers le cluster tout en surveillant les SLO des services.
Le processus est répété pour tous les clusters. En fonction de la planification des capacités, vous pouvez mettre à niveau plusieurs clusters à la fois sans enfreindre les SLO du service.
Si vous attachez plus d'importance à la simplicité et aux coûts qu'à la résilience, appliquez la stratégie de mises à niveau progressives. Au cours de cette stratégie, vous ne dépassez jamais la capacité du parc GKE requise pour l'ensemble des services distribués.
Le schéma suivant compare la chronologie et les exigences de capacité de service lors de la mise à niveau d'un cluster GKE dans une architecture multicluster.
Le schéma ci-dessus montre que, pendant toute la durée du processus de mise à niveau de GKE, la capacité de gestion des services n'est jamais inférieure à celle requise. Lorsque le cluster GKE à mettre à niveau est mis hors service, les autres clusters effectuent un scaling à la hausse afin de gérer la charge.
Mises à niveau bleu/vert
Le schéma suivant illustre une stratégie de mise à niveau bleu/vert.
Dans le schéma ci-dessus, un nouveau cluster GKE exécutant la nouvelle version est ajouté. Un équilibreur de charge est ensuite utilisé pour envoyer le trafic vers le nouveau cluster tout en drainant lentement l'un des anciens clusters jusqu'à ce qu'aucun trafic ne lui soit envoyé. L'ancien cluster entièrement drainé peut alors être supprimé. Vous pouvez suivre le même processus pour les clusters restants.
La stratégie de mise à niveau bleu/vert apporte une résilience supplémentaire.
Cette stratégie est semblable aux mises à niveau progressives, mais elle est plus coûteuse. La seule différence est qu'au lieu de drainer les clusters existants, vous devez d'abord créer des clusters m avec la version, où m est inférieur ou égal à n. Vous devez ajouter les nouveaux clusters aux pipelines CI/CD, puis transférer progressivement le trafic tout en surveillant les SLO du service. Lorsque les nouveaux clusters reçoivent l'intégralité du trafic, vous drainez et supprimez les clusters avec l'ancienne version.
La stratégie bleu/vert pour la mise à niveau des clusters est semblable à une stratégie bleu/vert généralement utilisée pour les services. La création simultanée de plusieurs clusters augmente le coût global, mais vous permet d'accélérer le processus de mise à niveau du parc. Le coût supplémentaire ne s'applique qu'à la durée de la mise à niveau lorsque des clusters supplémentaires sont utilisés. L'avantage de créer des clusters dans un premier temps est que vous pouvez effectuer un rollback en cas d'échec. Vous pouvez également tester le nouveau cluster avant d'y envoyer le trafic en production. Étant donné que ces clusters coexistent avec leurs anciennes versions pendant une courte durée, les coûts supplémentaires sont minimes.
Si vous privilégiez la simplicité et la résilience au coût, appliquez la stratégie de mise à niveau bleu/vert. Les clusters supplémentaires sont ajoutés en premier et dépassent la capacité requise du parc GKE pendant la durée des mises à niveau.
Dans le schéma ci-dessus, l'ajout d'un nouveau cluster augmente d'abord temporairement la capacité disponible par rapport à la capacité requise, tandis qu'un autre cluster du parc est drainé et supprimé. Toutefois, après la suppression de l'un des anciens clusters (entièrement drainé), la capacité revient à la capacité nécessaire. Ce changement de capacité est mis en évidence, car il peut entraîner une augmentation des coûts avec ce modèle, en fonction du nombre et de la taille des clusters du parc.
Mises à niveau des clusters Canary
La mise à niveau des clusters Canary constitue la stratégie la plus résiliente et la plus complexe décrite dans ce document. Cette stratégie fait complètement abstraction de la gestion du cycle de vie des clusters dans la gestion du cycle de vie des services. Cela permet de minimiser les risques encourus par vos services et de les rendre plus résilients. Dans les stratégies de mises à niveau progressives et bleu/vert décrites précédemment, vous gérez l'ensemble de votre parc GKE sur une seule version. Dans cette stratégie, vous gérez deux ou trois parcs de clusters GKE exécutant différentes versions. Au lieu de mettre à jour les clusters, vous migrez progressivement les services d'un parc de clusters vers un autre. Lorsque le plus ancien des parcs GKE est drainé (ce qui signifie que tous les services ont été migrés vers le prochain parc GKE avec versions gérées), vous devez supprimer le parc.
Cette stratégie nécessite de gérer au moins deux parcs GKE : un pour la production actuelle et un autre pour la prochaine version candidate en production. Vous pouvez également gérer plus de deux parcs GKE. Les parcs supplémentaires offrent davantage de flexibilité, mais augmentent vos coûts opérationnels et autres coûts. Ces parcs supplémentaires sont différents des clusters qui se trouvent dans plusieurs environnements, par exemple des environnements de développement, de préproduction et de production. Les environnements de non-production sont très utiles pour tester les fonctionnalités et services Kubernetes avec un trafic hors production.
Cette stratégie d'utilisation des mises à niveau des clusters Canary implique que vous gérez plusieurs versions de parc GKE dans l'environnement de production. Cette méthode est semblable aux stratégies de versions Canary qui sont souvent utilisées par les services. Avec les déploiements de services Canary, le propriétaire du service peut toujours identifier les problèmes liés à une version particulière du service. Avec les clusters Canary, le propriétaire du service doit également prendre en compte les versions du parc GKE sur lesquelles leurs services sont exécutés. Une seule version de service distribué peut s'exécuter sur plusieurs versions d'un parc GKE. La migration d'un service peut se dérouler de manière progressive afin que vous puissiez voir les effets du service sur le nouveau parc avant d'envoyer tout le trafic du service vers les nouveaux clusters avec versions gérées.
Le schéma suivant montre que la gestion de différents parcs de clusters GKE peut complètement faire abstraction du cycle de vie des clusters dans le cycle de vie des services.
Le schéma ci-dessus montre la migration progressive d'un service distribué frontend d'un parc de clusters GKE vers le parc suivant exécutant la nouvelle version jusqu'à ce que l'ancien parc soit complètement drainé au fil du temps. Une fois le parc drainé, il peut être supprimé et un parc est créé. Tous les services sont migrés vers le parc suivant, en supprimant les anciens parcs au moment de leur drainage.
Si vous privilégiez par-dessus tout la résilience, appliquez la stratégie de mise à niveau des clusters Canary.
Choisir une stratégie de mise à niveau
Le schéma suivant peut vous aider à déterminer la stratégie la mieux adaptée à vos besoins en fonction des besoins du service et de l'entreprise.
Le schéma ci-dessus est un arbre de décision qui vous aide à choisir la stratégie de mise à niveau qui vous convient :
- Si vous n'avez pas besoin de contrôler complètement la version exacte et la date de la mise à niveau, vous pouvez choisir la fonctionnalité de mise à niveau automatique disponible dans GKE.
- Si votre priorité est de garantir des faibles coûts, vous pouvez choisir la stratégie de mise à niveau progressive.
- Si votre priorité est d'équilibrer les coûts et la résilience, vous pouvez choisir la stratégie bleu/vert.
- Si vous privilégiez la résilience aux coûts, vous pouvez choisir la stratégie de mise à niveau des clusters Canary.
Gestion du trafic multicluster pour le cycle de vie des clusters GKE
Pour maintenir la disponibilité des services lors des mises à niveau multiclusters, vous devez vider et rediriger le trafic entre les clusters. Vous pouvez gérer ce trafic à l'aide d'une passerelle multicluster (recommandée) ou d'un objet Multi Cluster Ingress. La passerelle multicluster succède à Multi Cluster Ingress et offre une approche plus expressive et axée sur les rôles pour la mise en réseau des services.
Utiliser une passerelle multicluster pour la gestion du cycle de vie des clusters
La passerelle multicluster (MCG, Multi-Cluster Gateway) utilise l'API Gateway pour gérer le trafic des services déployés sur plusieurs clusters GKE d'un parc.
Le contrôleur GKE Gateway est un service hébergé par Google qui surveille les ressources Gateway et HTTPRoute dans un cluster de configuration désigné. Le contrôleur provisionne et gère automatiquement l'infrastructure d'équilibrage de charge, ce qui fournit un point d'entrée unique et unifié pour les applications sur les clusters du parc. Cette architecture vous permet de dissocier le cycle de vie de l'équilibreur de charge de celui des clusters GKE individuels où résident les charges de travail.
Pour la gestion du cycle de vie des clusters GKE, la passerelle multicluster permet d'appliquer des stratégies avancées de contrôle du trafic :
- Mises à niveau bleu-vert : déployez un nouveau cluster "vert" et transférez progressivement le trafic du cluster "bleu" en modifiant les pondérations dans la ressource HTTPRoute.
- Équilibrage de charge basé sur la capacité : redirige automatiquement le trafic lorsqu'un service d'un cluster atteint sa limite de capacité définie, ce qui permet de le protéger contre la surcharge lors des mises à niveau continues.
- Basculement basé sur l'état : surveillez l'état des backends dans tous les clusters et redirigez automatiquement le trafic loin d'un cluster en cours de vidange ou présentant des problèmes.
Pour en savoir plus, suivez le tutoriel Déployer une passerelle multicluster pour la répartition pondérée du trafic.
Utiliser un objet Ingress multicluster pour la gestion du cycle de vie des clusters
L'objet Multi Cluster Ingress est une autre solution de gestion du trafic multicluster. Multi Cluster Ingress est un contrôleur d'entrée multicluster hébergé par Google Cloudpour les clusters GKE. Il permet de déployer des ressources d'équilibrage de charge partagées entre des clusters et entre des régions. L'objet Ingress multicluster est une solution permettant de transférer le trafic client vers un service distribué qui s'exécute dans de nombreux clusters au sein de plusieurs régions. Tout comme Ingress pour GKE, MCI envoie le trafic vers un service de backend à l'aide de Cloud Load Balancing. Le service de backend est le service distribué. Le service de backend envoie le trafic à plusieurs backends, qui sont des services Kubernetes s'exécutant sur plusieurs clusters GKE. Pour le trafic de service à service entre les clusters, vous pouvez utiliser des technologies de maillage de services, tels que Cloud Service Mesh ou Istio, qui offrent des fonctionnalités similaires dans les services distribués.
Pour en savoir plus, suivez le tutoriel sur la mise à niveau d'un environnement GKE multicluster avec Multi Cluster Ingress.
Étapes suivantes
- En savoir plus sur la passerelle multicluster
- En savoir plus sur Multi Cluster Ingress