Le voyage kubernetes

Trustly, Inc. (anciennement connue sous le nom de PayWithMybank) a travaillé avec l’ensemble de son opération cloud pour exécuter plus de 20 microservices depuis 2015 qui sont responsables de la connexion de ses utilisateurs avec plus de 1 000 banques dans le monde. Bien que Trustly avait une infrastructure mature et stable, le voyage a commencé en 2018 pour moderniser l’architecture d’application pour utiliser des conteneurs dans Kubernetes.

Vue d’ensemble

L’environnement de Trusty fonctionne entièrement sur Amazon Web Services (AWS). Pendant des années, il a principalement eu l’orchestration cloud en utilisant CloudFormation et Packer. Nous avons utilisé trois couches de CloudFormation : une pour le réseau, une pour le proxy inverse (Nginx) et une pour l’application. Environ deux déploiements par jour ont été effectués directement par CloudFormation. Ce modèle de déploiement continu nous a très bien servis. Appelons ce vieil environnement classique-infra.

En 2018, Trustlya commencé à étudier Kubernetes (K8s) et a remis le trafic de production vers le nouvel environnement en mai 2021. Lorsque nous avons commencé à étudier Kubernetes, il est devenu clair qu’il ne répondait pas à toutes les capacités de notre infra classique. En conséquence, nous avons recherché les outils essentiels pour notre processus au sein de la grappe. 

Mais d’abord, parlons de l’Elastic Kubernetes Service (EKS)...

EKS : Puisque nous étions sur AWS, il était logique pour nous d’utiliser l’EKS pour exécuter notre environnement sur K8. EKS est un service AWS qui fournit la sécurité et la disponibilité pour le plan de contrôle Kubernetes. Lorsque nous avons commencé en 2018, la version EKS était 1.11, ce qui a créé de nombreux problèmes et a nécessité des processus manuels pour intégrer notre VPC à l’outil EKSCTL. Par exemple, vous pouvez configurer le cluster K8s, mais vous aviez trop d’étapes manuelles pour que tout fonctionne. Au moment où nous avons lancé le cluster K8s en production en 2021, nous étions déjà à la version 1.20 de l’EKS, qui fournissait beaucoup plus de capacités d’automatisation dans EKSCTL.

Outillage

OpenSearch : Avec Kubernetes, vous devez collecter et centraliser les journaux d’une manière ou d’une autre. Pour cette raison, nous avions besoin d’un outil pour gérer les journaux d’applications dans Kubernetes. L’une des raisons pour lesquelles le projet a pris trois ans à compléter était le temps qu’il a fallu pour apprendre et déployer un cluster ElasticSearch en utilisant OpenDistroElasticSearch (au début). Nous avons récemment mis à niveau vers OpenSearch, qui est un outil robuste avec toutes les fonctionnalités nécessaires pour une gestion fiable des journaux et qui peut être intégré dans Filebeat et Logstash.

Spinnaker : Sur le chemin au déploiement de Kubernetes, nous avons remarqué des limitations aux conditions requises de déploiement. Pour résoudre ces problèmes, nous avons adopté l’outil Spinnaker, développé et maintenu par Netflix. Spinnaker nous a permis de créer un pipeline complexe et la possibilité d’avoir un déploiement bleu/vert dans notre batterie.

Terraform : Lorsque nous avons commencé notre voyage, tout notre environnement était dans CloudFormation. Nous n’avions aucune expérience avec Terraform. Pour les nouveaux environnements Kubernetes, toute la configuration du compte AWS a été créée par Terraform. Terraform est responsable de la création du VPC, des groupes de sécurité, des sous-réseaux, des tables de routage, de la passerelle nat et des ressources nécessaires pour exécuter le cluster K8s.

Eksctl : Il s’agit d’un excellent outil pour installer et configurer un cluster EKS. Il parvient à faciliter plusieurs étapes dans l’installation d’un nouveau cluster EKS.

Avec tous ces outils, il était possible de maintenir la même visibilité que nous avions dans l’infrastructure classique au sein du cluster EKS, gagnant les avantages de Kubernetes dans cette nouvelle architecture.

Le virage

Pour être prêts au dynamisme et au rythme rapide du développement de Kubernetes, nous avons conçu, à la fois dans le VPC et dans les composants associés au cluster, la possibilité d’exécuter notre application simultanément dans deux clusters (routage du trafic entre eux via ROUTE53). Cette stratégie nous a aidés à passer de l’infra classique à Kubernetes, divisant le trafic en petits pourcentages jusqu’à ce qu’il atteigne 100% de trafic sur K8s. 

Nous avons soigneusement augmenté le trafic au fil des semaines (en commençant par 1% du trafic, puis en passant à 5% du trafic). Après de nombreux ajustements et améliorations, nous avons finalement converti 100% du trafic en Kubernetes. À ce moment-là, nous étions à l’aise avec l’environnement et avons pu observer sa stabilité au cours des jours suivants.

La recette du succès de notre stratégie était de garder le journal de cluster séparé du cluster K8s. Avec cela, les deux environnements pourraient envoyer des journaux à OpenSearch, et via des balises, nous pourrions identifier le cluster dans chaque ligne de journal, facilitant le dépannage.

Conclusion

Kubernetes est un outil puissant, mais il nécessite un effort supplémentaire pour installer, configurer et maintenir, et nécessite d’autres composants pour créer un cluster K8s prêt pour la production. 

Ce premier article est un aperçu de l’architecture Kubernetes à Trustly. Si vous souhaitez voir plus de détails sur la mise à l’échelle automatique, la stratégie de vérification de l’état des pods et les meilleures pratiques Java en utilisant des conteneurs, suivez ce blog pour le contenu futur.

Denner Padilha
Responsable des opérations cloud et de sécurité, Trustly Amérique

Denner est responsable des opérations cloud et de sécurité chez Trustly. Au début de 2018, Denner s’est joint à l’équipe Trustly en tant que directeur des opérations informatiques où il était responsable de l’ensemble de l’infrastructure cloud et des opérations informatiques pour les Amériques du Nord.
Denner possède une vaste expérience dans la performance des applications, ainsi que dans l’audit de sécurité ISO27001, PCI et SSAE18 SOC Type 2. Auparavant, il a travaillé comme professeur au Brésil, enseignant des disciplines informatiques aux étudiants de premier cycle et de MBA.