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, y compris pour configurer manuellement un équilibreur de charge externe. Un tutoriel associé à ce document montre comment mettre à niveau un environnement GKE multicluster à l'aide de Multi Cluster Ingress. Ce document est destiné aux administrateurs Google Cloud chargés de gérer les parcs de clusters GKE.
Nécessité de créer une architecture multicluster
Cette section explique diverses raisons pour lesquelles vous pourriez avoir besoin d'une architecture Kubernetes multicluster.
Kubernetes en tant qu'infrastructure
Ce document considère que les clusters Kubernetes sont des composants d'infrastructure. L'infrastructure est une ressource temporaire. Aucun traitement particulier ne doit être accordé à un composant d'infrastructure, car les composants sont conçus pour remplir un objectif. L'objectif de Kubernetes est de permettre aux développeurs et aux opérateurs d'automatiser et d'orchestrer la diffusion des applications et des services basés sur des conteneurs auprès des consommateurs. Les consommateurs peuvent être des équipes internes, d'autres services ou des clients externes.
Scénarios multiclusters courants
Outre le fait de concevoir Kubernetes en tant qu'infrastructure, plusieurs raisons peuvent justifier l'utilisation d'un environnement multicluster :
- Géographie. Plusieurs services doivent se trouver dans différentes régions. Placer un service au plus près du consommateur (dans sa région) offre une meilleure expérience en raison d'une plus faible latence que si le service était diffusé depuis une seule région. Un cluster Kubernetes s'exécute dans une seule région. Pour les déploiements multirégionaux, plusieurs clusters Kubernetes sont nécessaires dans différentes régions. Les environnements multicloud ou cloud hybrides nécessitent également plusieurs clusters dans chaque environnement. Les clusters Kubernetes se trouvent également au même emplacement que les sources de données (avec état) des services. Certaines applications doivent nécessairement se trouver au même emplacement (région et zone) que leur backend, par exemple un système de gestion de base de donnée relationnelle (SGBDR).
- Location et environnements. Les clusters Kubernetes sont conçus à des fins de mutualisation. Plusieurs équipes peuvent partager un seul cluster pour leurs services respectifs. Kubernetes fournit des ressources standards, telles que les espaces de noms, le contrôle des accès basé sur les rôles (RBAC), les règles de réseau et l'authentification, afin de configurer correctement les contrôles des accès dans les environnements mutualisés. Dans certains cas, des services ne peuvent pas coexister avec d'autres services sur un cluster en raison de règles d'entreprise, de confidentialité, de sécurité ou de réglementation du secteur. Dans ce cas, plusieurs clusters sont nécessaires pour isoler certains locataires dans leurs propres clusters. Les environnements (développement, préproduction et production) sont souvent créés en tant que clusters distincts. Le niveau d'accès et les types d'applications installés dans différents environnements varient rarement et doivent être conservés en tant que clusters distincts.
- Composition et fonction. Parfois, un cluster est créé pour exécuter une fonction particulière. Par exemple, les workflows de machine learning utilisent Kubeflow ou des jobs d'analyse de données pouvant nécessiter des nœuds avec des GPU ou d'autres exigences matérielles pour les clusters d'instances composés de VM Spot pour les charges de travail d'analyse par lot. Ces exigences matérielles peuvent ne pas s'appliquer à d'autres services. Ces workflows peuvent ne pas être indispensables pour les opérations de l'entreprise et nécessiter des clusters éphémères (clusters de courte durée). Les services partagés, tels que les outils d'observabilité (journalisation, métriques et traces) et de CI/CD, sont plus adaptés à leur propre cluster d'administrateur de plate-forme. Plusieurs clusters à fonction spécifique sont souvent utilisés pour les workflows qui ne sont pas essentiels à l'activité.
- Résilience. L'utilisation de plusieurs clusters permet souvent d'augmenter la résilience dans un environnement. Chaque cluster comporte une zone d'impact. Dans ce contexte, une zone d'impact désigne le nombre de services affectés par une défaillance, une mauvaise configuration ou la mise hors connexion d'un cluster en raison d'une maintenance planifiée ou non planifiée. Si vous gérez un grand nombre de clusters de petite taille, vous disposez d'un grand nombre de zones d'impact plus petites. Si un service existe dans deux clusters, ceux-ci partagent la charge de manière égale. Si un cluster se déconnecte, 50 % du trafic est affecté. Si le même service a été diffusé par un seul cluster, tout événement s'y trouvant pourrait entraîner une interruption à 100 % du service. Pour cette raison, plusieurs clusters sont couramment utilisés pour la reprise après sinistre.
Ce document porte sur la résilience des déploiements multiclusters.
Services multiclusters et services distribués
Un service distribué est un service Kubernetes déployé sur plusieurs clusters Kubernetes. Les services distribués sont des services sans état qui agissent de manière identique dans plusieurs clusters. Cela signifie qu'un service distribué a le même nom de service Kubernetes et est mis en œuvre dans le même espace de noms dans plusieurs clusters. Les services Kubernetes sont liés au cluster Kubernetes sur lequel ils s'exécutent. Si un cluster Kubernetes se déconnecte, le service Kubernetes est indisponible. Les services distribués sont extraits des clusters Kubernetes individuels. Si un ou plusieurs clusters Kubernetes sont indisponibles, le service distribué peut être en ligne et conforme à l'objectif de niveau de service (SLO).
Dans le schéma suivant, frontend est un service distribué s'exécutant sur plusieurs clusters avec le même nom de service et le même espace de noms.
Avec cette architecture, le service frontend n'est pas lié à un seul cluster. Il est représenté conceptuellement dans le schéma sous la forme d'une couche qui couvre la couche d'infrastructure du cluster Kubernetes. Si l'un des clusters qui exécute le service frontend tombe en panne, le service frontend reste en ligne.
D'autres services s'exécutent sur un seul cluster : le service accounts et le service ledger. Leur temps d'activité et leur disponibilité dépendent du temps d'activité du cluster Kubernetes dans lequel ils résident.
La résilience est l'une des raisons qui justifient les déploiements multiclusters. Les services distribués créent des services résilients sur une architecture multicluster. Les services sans état sont des candidats de choix pour les services distribués dans un environnement multicluster. Les exigences et considérations suivantes s'appliquent lorsque vous utilisez des services distribués :
Mise en réseau multicluster. Vous pouvez envoyer le trafic destiné à un service distribué aux clusters exécutant ce service à l'aide d'une technologie d'entrée multicluster, telle que Multi Cluster Ingress, ou de votre propre équilibreur de charge externe ou solution proxy. Quelle que soit l'option choisie, elle doit vous permettre de contrôler quand, où et quelle quantité de trafic est acheminée vers une instance particulière d'un service distribué. Le schéma suivant présente un équilibreur de charge envoyant le trafic vers un service distribué
frontendqui s'exécute dans deux clusters GKE.
Observabilité. Utilisez plusieurs outils pour évaluer vos SLO, principalement la disponibilité et la latence, pour un service distribué. Cette configuration fournit une vue globale des performances de chaque service sur plusieurs clusters. Bien que le service distribué ne constitue pas une ressource bien définie dans la plupart des solutions d'observabilité, vous pouvez collecter et associer des métriques de service Kubernetes. Des solutions telles que Cloud Monitoring ou des outils Open Source tels que Grafana fournissent des métriques de service Kubernetes. Les solutions de maillage de services, telles qu'Istio et Cloud Service Mesh, fournissent également des métriques de service sans instrumentation nécessaire.
Emplacement du service. Les services Kubernetes sont tolérants aux pannes au niveau du nœud au sein d'un seul cluster Kubernetes. Cela signifie qu'un service Kubernetes peut résister aux pannes de nœud. Lorsque des pannes de nœud se produisent, un nœud du plan de contrôle Kubernetes replanifie automatiquement les pods sur des nœuds opérationnels. Un service distribué est tolérant aux pannes au niveau du cluster. Par conséquent, il peut résister à des interruptions de clusters. Lorsque vous planifiez la capacité d'un service distribué, vous devez prendre en compte l'emplacement de ce service. Un service distribué n'a pas besoin de s'exécuter sur chaque cluster. Les clusters sur lesquels un service distribué s'exécute dépendent des exigences suivantes :
- Où et dans quelles régions le service est-il requis ?
- Quel est le SLO requis pour le service distribué ?
- Quel type de tolérance aux pannes est requis pour le service distribué (cluster, zonal ou régional) ? Par exemple, avez-vous besoin de plusieurs clusters dans une seule zone, ou de plusieurs clusters sur plusieurs zones au sein d'une même région ou de plusieurs régions ?
À quel niveau de pannes le service distribué doit-il résister dans le pire des cas ? Les options suivantes sont disponibles au niveau de la couche du cluster :
- N+1 (où N représente le nombre de clusters requis pour répondre aux besoins de capacité du service). Un service distribué peut résister à une seule défaillance de cluster.
- N+2. Un service distribué peut résister à deux pannes simultanées. Par exemple, une interruption planifiée et non planifiée d'un service Kubernetes dans deux clusters à la fois.
Déploiements et rollbacks. Les services distribués, tels que les services Kubernetes, permettent d'effectuer des déploiements progressifs et des rollbacks. Contrairement aux services Kubernetes, les services distribués permettent aux clusters d'être une unité de déploiement supplémentaire afin d'apporter progressivement des modifications. Les déploiements et les rollbacks dépendent également des exigences du service. Dans certains cas, vous devrez peut-être mettre à jour le service sur tous les clusters en même temps, par exemple lors d'une correction de bug. Dans d'autres cas, vous devrez peut-être déployer progressivement (ou échelonner) la modification sur un cluster à la fois. Ce déploiement progressif réduit les risques liés au service distribué en introduisant progressivement les modifications apportées au service. Toutefois, cette opération peut prendre plus de temps en fonction du nombre de clusters. Aucune stratégie de mise à niveau n'est optimale. Souvent, plusieurs stratégies de déploiement et de rollback sont utilisées en fonction des exigences du service distribué. Il est important de souligner ici que les services distribués doivent autoriser les modifications progressives et contrôlées dans l'environnement.
Continuité des opérations et reprise après sinistre (BCDR). Ces termes sont souvent utilisés conjointement. La continuité des opérations désigne la continuité des services critiques en cas d'événement majeur (planifié ou non planifié), tandis que la reprise après sinistre correspond aux mesures prises ou nécessaires pour rétablir les activités commerciales à leur état normal suite à ces événements. De nombreuses stratégies de BCDR ne sont pas traitées dans ce document. La continuité des opérations et la reprise après sinistre nécessitent un certain niveau de redondance dans les systèmes et les services. Le point essentiel des services distribués est qu'ils s'exécutent dans plusieurs emplacements (clusters, zones et régions).
Les stratégies de BCDR dépendent souvent des stratégies de déploiement et de rollback décrites précédemment. Par exemple, si des déploiements sont effectués de manière progressive ou contrôlée, l'effet d'un bug ou d'une mauvaise configuration peut être détecté rapidement sans affecter un grand nombre d'utilisateurs. À grande échelle et associées à un taux de modification rapide (par exemple, dans les pratiques modernes de CI/CD), il est fréquent que tous les utilisateurs ne reçoivent pas la même version d'un service distribué. La planification et les stratégies de BCDR dans les systèmes et les services distribués diffèrent des architectures monolithiques traditionnelles. Dans les systèmes traditionnels, une modification est apportée globalement, ce qui affecte un grand nombre, voire tous les utilisateurs. Ils doivent donc disposer d'un système redondant ou de secours en cas d'effets indésirables d'un déploiement. Dans les systèmes et les services distribués, la plupart des modifications sont apportées de manière progressive afin de n'affecter qu'un petit nombre d'utilisateurs.
Gestion du cycle de vie d'un cluster. Comme les déploiements et les rollbacks contrôlés, les services distribués permettent de gérer le cycle de vie d'un cluster. Les services distribués assurent la résilience au niveau des clusters afin que ceux-ci puissent être mis hors service pendant la maintenance. La gestion du cycle de vie d'un cluster définit un ensemble de services distribués qui ne s'applique pas aux services Kubernetes.
Le reste de ce document porte sur le cycle de vie des clusters des services distribués.
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.
Ce document porte sur la gestion du cycle de vie GKE. Vous pouvez néanmoins appliquer ces concepts à d'autres distributions de Kubernetes.
Gestion des versions et mises à niveau de GKE
Avant d'aborder les stratégies et la planification de la gestion du cycle de vie d'un cluster, il est important de comprendre de quoi est constitué une mise à niveau.
Un cluster contient deux composants : les nœuds du plan de contrôle et les nœuds de calcul. La mise à niveau d'un cluster Kubernetes nécessite que tous les nœuds soient mis à niveau vers la même version. Kubernetes suit un schéma de gestion sémantique des versions.
Les versions Kubernetes sont exprimées au format X.Y.Z:, où X est la version majeure, Y la version mineure et Z la version de correctif. Des versions mineures sont publiées environ tous les trois mois (tous les trimestres). Le projet Kubernetes conserve des branches de publication pour les trois versions mineures les plus récentes. Cela signifie qu'une version mineure Kubernetes de neuf mois n'est plus gérée et peut nécessiter des modifications de l'API lors de la mise à niveau vers la dernière version. Les mises à niveau de Kubernetes doivent être planifiées à intervalles réguliers. Nous vous recommandons de planifier les mises à niveau de GKE une fois par trimestre ou tous les deux trimestres.
Les clusters GKE sont compatibles avec l'exécution des versions de Kubernetes à partir de toute version mineure acceptée. Au moins deux versions mineures sont disponibles à tout moment.
GKE propose les types de disponibilité de cluster suivants :
- Clusters à zone unique. Un seul nœud du plan de contrôle et tous les pools de nœuds se trouvent dans une seule zone d'une même région.
- Clusters multizones. Un seul nœud du plan de contrôle se trouve dans une zone, et les pools de nœuds se trouvent dans plusieurs zones d'une même région.
- Clusters régionaux. Plusieurs nœuds du plan de contrôle et les pools de nœuds se trouvent dans plusieurs zones d'une même région.
GKE est un service géré qui propose des mises à niveau automatiques pour les nœuds du plan de contrôle et les nœuds de calcul.
Mise à niveau automatique de GKE
La mise à niveau automatique de GKE est une stratégie de cycle de vie des clusters populaire et couramment utilisée. La mise à niveau automatique de GKE permet de gérer entièrement la mise à niveau des clusters GKE avec les versions compatibles. GKE met à niveau automatiquement les nœuds du plan de contrôle et les nœuds de calcul de manière distincte :
Mises à jour automatiques du maître. Par défaut, les nœuds du plan de contrôle GKE sont automatiquement mis à jour. Les clusters à zone unique et multizones disposent d'un plan de contrôle unique (nœud du plan de contrôle). Lors des mises à niveau des nœuds du plan de contrôle, les charges de travail continuent de fonctionner. Toutefois, vous ne pouvez pas déployer de nouvelles charges de travail, modifier les charges de travail existantes ou apporter d'autres modifications à la configuration du cluster tant que la mise à niveau n'est pas terminée.
Les clusters régionaux contiennent plusieurs instances dupliquées du plan de contrôle. Les instances dupliquées sont mises à niveau une par une. Pendant la mise à niveau, le cluster reste hautement disponible et les instances répliquées du plan de contrôle ne sont indisponibles que pendant leur mise à niveau.
Mises à niveau automatiques des nœuds de calcul. Les pools de nœuds sont mis à niveau un par un. Dans un pool de nœuds, les nœuds sont mis à niveau un par un, dans un ordre indéterminé. Vous pouvez modifier le nombre de nœuds mis à niveau simultanément, mais ce processus peut prendre plusieurs heures en fonction du nombre de nœuds et de la configuration de leur charge de travail.
Stratégie de cycle de vie des mises à niveau automatiques de GKE
Nous vous recommandons d'effectuer une mise à niveau automatique de GKE dans la mesure du possible. Les mises à niveau automatiques de GKE privilégient la commodité au contrôle. Elles proposent néanmoins plusieurs moyens de déterminer quand et comment vos clusters sont mis à niveau dans certains paramètres. Vous pouvez ajuster les intervalles et les exclusions de maintenance. Les versions disponibles ont un impact sur la sélection des versions. Les stratégies de mise à niveau des nœuds influencent l'ordre et la chronologie des mises à niveau des nœuds. En dépit de ces contrôles et de ces clusters régionaux (dotés de plusieurs plans de contrôle Kubernetes), la mise à niveau automatique de GKE ne garantit pas le temps d'activité des services. Vous pouvez choisir de ne pas utiliser la fonctionnalité de mise à niveau automatique de GKE si vous avez besoin d'effectuer une ou plusieurs des opérations suivantes :
- Contrôler la version exacte des clusters GKE
- Contrôler le moment exact de la mise à niveau de GKE
- Contrôler la stratégie de mise à niveau (décrite dans la section suivante) de votre parc GKE
Gérer le 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 Gestion des 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.
Utiliser un objet Ingress multicluster pour la gestion du cycle de vie des clusters GKE
Presque toutes les stratégies dépendent de la capacité à drainer et à rediriger le trafic vers d'autres clusters lors des mises à niveau. L'objet Ingress multicluster constitue cette solution fournissant la fonctionnalité d'entrée multicluster. Un objet Ingress multicluster est un contrôleur d'entrée multicluster hébergé par Google Cloud pour 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 for 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 les environnements multiclusters GKE, vous pouvez utiliser un objet Ingress multicluster afin de transférer le trafic vers plusieurs clusters pour les stratégies de gestion du cycle de vie des clusters décrites précédemment. Vous pouvez suivre un tutoriel pour utiliser les mises à niveau de Multi Cluster Ingress pour GKE à l'aide de la stratégie bleu-vert.
Étape suivante
- En savoir plus sur l'objet Ingress multicluster.
- Découvrez comment déployer un objet Ingress multicluster sur plusieurs clusters.