Comment remplacer un cluster EKS sans interruption ?

Dans le paysage dynamique de l'informatique du Cloud, la gestion dynamique et agile des conteneurs est devenue essentielle pour les entreprises modernes. Amazon Elastic Kubernetes Service (AWS EKS) émerge comme un élément clé de cette évolution, proposant une plateforme robuste et évolutive, mais non sans défis. Aujourd'hui, nous plongeons dans le domaine complexe du remplacement des clusters EKS, explorant les stratégies pour naviguer avec succès à travers les changements de noms et les réorganisations d'infrastructure, tout en maintenant un service continu et sans interruption.

Introduction

Dans un écosystème où la gestion dynamique des conteneurs est cruciale, Amazon Elastic Kubernetes Service (AWS EKS), comme les autres fournisseurs, Google GKE et Azure AKS, se démarque comme une solution incontournable qui offre une solution puissante, flexible et sécurisée pour orchestrer des conteneurs à grande échelle. Cependant, malgré sa flexibilité, des défis subsistent, notamment lorsqu'il s'agit d'opérations critiques telles que le changement de nom de cluster ou la modification de l'infrastructure sous-jacente (VPC, Subnets, Security Groups, etc.).

Cet article explore de près la façon de naviguer à travers ces défis en réalisant un remplacement transparent du cluster EKS, sans interruption de service. À travers l'utilisation de Terraform, Traefik, et kustomize, nous découvrons comment ces outils peuvent faciliter une transition fluide vers un nouvel environnement, offrant ainsi aux entreprises la stabilité nécessaire pour évoluer dans le monde en constante évolution de la technologie cloud.

Un premier pas dans l’architecture

Afin de pouvoir travailler sur un exemple concret de cluster, nous allons partir de l’architecture suivante:

Dans ce schéma simplifié, nous mettrons en place une architecture comprenant un réseau virtuel privé (VPC) contenant les composants suivants :

• Un nœud de contrôle EKS : Il est généré par le service EKS pour superviser et administrer le cluster Kubernetes. Le nœud de contrôle EKS joue un rôle essentiel dans la gestion de l'état du cluster, la gestion des nœuds, la planification des pods, la gestion des autorisations, ainsi que l'intégration avec d'autres services AWS, entre autres fonctions.
• Les nœuds EKS : Les nœuds EKS jouent un rôle essentiel dans l'exécution des conteneurs au sein d'un cluster EKS. Ils sont responsables de l’exécution et de la gestion des cycles de vie des pods, tout en répondant aux commandes du nœud de contrôle EKS pour garantir le bon fonctionnement de l'ensemble du cluster.
• Un Network Load Balancer (équilibreur de charge réseau): un Network Load Balancer est essentiel pour exposer et distribuer le trafic vers les services Kubernetes, assurant ainsi une disponibilité, une évolutivité et une gestion efficace du trafic pour les applications conteneurisées.

Pour rendre les applications accessibles au public, nous avons recours à une API Gateway, un élément clé dans la mise à disposition et la gestion de nos API. Cette passerelle présente plusieurs avantages, notamment en matière de sécurité, de gestion, de performances, ainsi que de simplification de l'accès aux services back-end. De plus, nous utilisons AWS Private Link pour établir une connectivité privée entre l'API Gateway et notre cluster EKS.

Infrastructure as Code

Pour la mise en place des ressources AWS de cette infrastructure, nous avons choisi d'utiliser Terraform. Conformément aux recommandations de HashiCorp et de la communauté, nous allons diviser l'infrastructure en trois projets distincts :

• Le premier projet sera chargé de déployer les ressources réseaux telles que le VPC, les subnets, les routes tables, etc.
• Le deuxième projet se concentrera sur le déploiement de toutes les ressources essentielles pour faire fonctionner le cluster EKS, y compris le nœud de contrôle EKS, les nœuds EKS, les Security Groups, le Network Load Balancer (NLB), etc.
• Le troisième projet sera dédié au déploiement de toutes les ressources nécessaires pour exposer l'API Gateway en public.

Déploiement

Nous utiliserons Kustomize pour déployer les ressources Kubernetes, pour automatiser l'ensemble du processus de déploiement, nous ferons appel à Gitlab CI.

Kustomize

Pour le déploiement des ressources Kubernetes, notre choix s'est porté sur Kustomize. Nous avons opté pour une approche simplifiée avec un projet unique qui gère le déploiement de l'ensemble des microservices applicatifs, en mettant particulièrement l'accent sur la configuration du routage grâce à Traefik.

CI/CD

Afin de rendre le déploiement de l'infrastructure et des ressources Kubernetes plus simple et plus efficace, nous avons fait le choix d'intégrer GitLab CI à notre processus. En suivant les bonnes pratiques, nous avons configuré GitLab CI pour automatiser les pipelines Terraform en divisant le processus en deux étapes distinctes : la planification (Plan) et l'application (Apply). De plus, GitLab CI est également utilisé pour déployer les ressources Kubernetes en une seule étape, simplifiant ainsi l'ensemble du processus de déploiement.

Contraintes

Le remplacement d'un cluster EKS est une opération complexe qui nécessite une gestion minutieuse des contraintes, que nous pouvons classer en deux catégories distinctes : les exigences SLA et les contraintes techniques.

En ce qui concerne les exigences SLA, il est impératif de garantir une transition en douceur sans aucune interruption de service, ainsi qu'aucun impact négatif sur les indicateurs de performance clés comme les KPI fonctionnels. Il est également essentiel de qualifier le nouveau cluster à l'avance pour s'assurer qu'il répond aux exigences opérationnelles.

D'un point de vue technique, diverses contraintes doivent être prises en considération. Il est essentiel de noter que le renommage du cluster EKS ainsi que des Security Groups est impossible à chaud. De même, il n'est pas possible de migrer directement vers la version la plus récente sans passer par les versions intermédiaires. 

Il est impératif de ne procéder à aucune modification du DNS lié à l'API Gateway, tout comme aux API keys associées à l'API Gateway, afin de maintenir la cohérence et le bon fonctionnement de l'environnement.

Solution

Pour répondre aux contraintes énoncées précédemment, nous avons opté pour un déploiement Blue/Green de l'ensemble de l'infrastructure exposée précédemment. Pour faciliter la compréhension de cette solution, nous allons la décomposer en plusieurs étapes.

Préparation et déploiement de la nouvelle infrastructure

Architecture

Pour mettre en œuvre une stratégie de déploiement Blue/Green, il a été nécessaire de reproduire les ressources qui ne peuvent pas être mutualisables. Dans notre situation, une nouvelle version a été créée pour les éléments suivants :

• API Gateway
• Private Link
• Network Load Balancer
• Le noeud de contrôle EKS
• Noeuds EKS :
  • Autoscaling Group
  • Launch Template
  • Security Group

Les ressources mutualisables telles que le VPC, les subnets, les route tables, etc., n'ont pas été dupliquées.

Déploiement

Pour implémenter cette architecture, des modifications seront apportées à deux de nos projets Terraform, ainsi qu'à leurs pipelines CI/CD :

• Le projet responsable du déploiement du cluster EKS.
• Le projet responsable du déploiement de l’API Gateway.

Des modifications ont également été apportées au projet Kustomize.

Pour chaque projet, nous avons adopté une méthode de migration distincte en raison des contraintes énoncées ci-dessous.

Déploiement du nouveau cluster

Pour déployer un nouveau cluster avec toutes les ressources secondaires nécessaires, nous avons créé une nouvelle branche "feature" contenant toutes les modifications destinées au cluster. À ce stade, le pipeline de déploiement n'a pas été modifié.

En utilisant le pipeline de CI/CD, nous avons déployé le Terraform dans un nouveau workspace temporaire, évitant ainsi tout impact sur le cluster existant.

Déploiement de la nouvelle API Gateway

Pour mettre en place une nouvelle API Gateway, nous avons créé une branche "temporary" qui inclut toutes les ressources dupliquées avec une nouvelle entrée DNS. Toutes ces ressources sont considérées comme temporaires et seront supprimées ultérieurement. À ce point, aucune modification n'a été apportée au pipeline de déploiement.

À la différence du cluster où toutes les ressources nécessitaient un remplacement, dans le projet API Gateway, seule une ressource doit être remplacée : le Private Link. Pour accomplir cela, nous avons utilisé le pipeline CI/CD pour déployer via Terraform dans le même workspace, en nous assurant minutieusement qu'aucun impact ne se produise sur les anciennes ressources.

Nous avons opté pour le même workspace, car nous devrons basculer les ressources Terraform du Private Link au moment de la mise en service.

Déploiement du Kustomize

À présent, l'infrastructure est opérationnelle. Néanmoins, l'Ingress de Kubernetes ne parvient pas à reconnaître la nouvelle entrée DNS ajoutée ultérieurement.

Pour remédier à cette situation, nous avons instauré une branche “temporary”, dérivée du tag correspondant à l'environnement, regroupant toutes les modifications apportées à l'entrée DNS dans la définition de l'Ingress.

En employant le pipeline de CI/CD, nous avons procédé au déploiement de Kustomize sur le nouveau cluster EKS.

Résultat

À ce stade, nous disposons de deux clusters fonctionnant de manière optimale en parallèle, chacun étant accessible via une URL distincte.

Cette configuration offre à l'équipe “Qualité” la possibilité de vérifier la performance du cluster en amont, avant de valider la transition vers le nouveau cluster.

Mise en service de la nouvelle infrastructure

Architecture

Comme mentionné dans le chapitre précédent, nous disposons actuellement de deux clusters fonctionnant parfaitement en parallèle, et le nouveau cluster a été validé par l'équipe "Qualité".

Pour effectuer la migration vers le nouveau cluster, il est nécessaire de modifier la configuration de l'Ingress dans ce cluster pour rétablir le DNS principal avant de rediriger l'ancienne API Gateway vers le nouveau Private Link, et vice-versa.

Déploiement du Kustomize

Pour harmoniser le nouveau cluster avec le cluster principal, il suffit de relancer le déploiement du tag correspondant à l'environnement.

Déploiement du cluster

Dans la phase préparatoire de la migration, un workspace Terraform temporaire a été créé pour regrouper les ressources du nouveau cluster.

Pour assurer la conservation des nouvelles ressources dans le workspace Terraform principal lors de la migration, un pipeline a été mis en place. Ce pipeline permet d'alterner le fichier "tfstate" entre les deux workspaces.

Lors de la migration effective, ce pipeline a été déclenché pour déplacer les ressources vers le workspace principal.

Déploiement de l’API Gateway

Comme évoqué précédemment, pour mettre en service le nouveau cluster, il est impératif de rediriger l'API Gateway principale vers le nouveau Private Link.

Pour ce faire, il est nécessaire d'alterner entre les deux Private Links dans Terraform et de relancer un Plan suivi d'un Apply. Ceci permet à la ressource Terraform de l'API Gateway de détecter un changement et d'appliquer la liaison entre l'API Gateway principale et le nouveau Private Link.

Le code Terraform a été modifié en intégrant les configurations "moved" et "import", facilitant ainsi le basculement entre les deux ressources.

Suppression de l'Infrastructure Obsolète Post-Migration

Après plusieurs jours de surveillance, la validation du bon fonctionnement du nouveau cluster a été obtenue. Par conséquent, nous avons entrepris la suppression des anciennes ressources ainsi que des ressources temporaires créées précédemment.

Architecture

Suite à la suppression de l'ensemble des anciennes ressources, notre infrastructure retrouve sa configuration de base, mais cette fois avec le nouveau cluster en place.

Kustomize

À la conclusion de la migration, la branche temporaire créée précédemment pour faciliter la modification de l'entrée DNS a été supprimée.

Cluster

Étant donné que l'ancien cluster n'est plus en service, nous l'avons supprimé en détruisant le workspace Terraform temporaire. En outre, la branche "feature" a été fusionnée avec la branche “Main”.

API Gateway

Les ressources temporaires, n'étant plus nécessaires, ont été supprimées en exécutant un Terraform Apply à partir de la branche "Main". La branche "temporary", devenue obsolète également, a été supprimée.

Conclusion

En adoptant la solution décrite précédemment, nous avons réussi à accomplir un remplacement transparent du cluster EKS sans aucune interruption de service. L'opération s'est déroulée de manière fluide, sans générer d'alarme pendant la migration ni d'erreurs détectées dans nos logs sur Kibana. Aucune plainte n'a été signalée par nos partenaires, ce qui se traduit par la satisfaction de notre client. Cette transition sans accroc témoigne de l'efficacité de la planification, de l'exécution précise des étapes, et de la validation réussie du nouveau cluster, aboutissant à une expérience positive pour toutes les parties impliquées.

Néanmoins, la présente solution comporte certains inconvénients. Le tableau ci-dessous propose une comparaison entre les avantages et les inconvénients de cette approche :

Malgré les inconvénients évoqués, cette solution s'est avérée la plus pertinente car elle a garanti la continuité du service et a apaisé les inquiétudes de l'équipe opérationnelle.