Ces dernières années, l’adoption des architectures microservices et l’utilisation de Kubernetes en production sont montées en flèche. Cette augmentation rapide de la demande a poussé de nombreuses entreprises à franchir le pas et à migrer leurs applications en production sur Kubernetes.
Au cours de ces années, nous avons aidé plusieurs entreprises à migrer des applications déployées sur des VM traditionnelles vers Kubernetes.
Dans cet article, nous allons vous présenter les étapes de la migration vers Kubernetes et les points à vérifier avant de commencer une migration.
1 – Récolter les informations liés à l’application à migrer :
Tout d’abord nous devons avoir une vision technique claire de l’application, une documentation qui décrit les différents aspects techniques ou une personne connaissant très bien l’application est nécessaire pour répondre à ces questions, qui sont primordiales pour la migration :
- Quelles sont les dépendances de l’application ?
D’abord il faut déterminer les différentes dépendances au niveau réseau de l’application, avec quels services l’application doit communiquer . Il faut prendre en compte les interactions que l’application initie avec d’autres services (outbound) ainsi que les interactions faisant appel à l’application (inbound). À cette étape, il est préférable de répertorier tous les flux dans une matrice.
- Votre application utilise-elle les sticky sessions ?
- Les sticky sessions ou session persistantes, sont un processus dans lequel un équilibreur de charge crée une affinité entre un client et un serveur réseau spécifique pour la durée d’une session, (c’est-à-dire le temps qu’une adresse IP spécifique passe sur un site Web). L’utilisation de sessions persistantes peut aider à améliorer l’expérience utilisateur et à optimiser l’utilisation des ressources réseau.
- Ne pas implémenter des sessions persistantes dans le cluster causera des problèmes aux utilisateurs car votre application aura plusieurs réplicas, que vous pouvez gérer dans une infrastructure basée sur Kubernetes.
- Votre application est-elle stateful ou stateless ?
Une application stateless, ne dépend pas d’un volume persistant, dans ce cas la seule chose dont votre cluster est responsable est le code et les autres contenus statiques qui y sont hébergés. C’est tout, pas de modification des bases de données, pas d’écritures et pas de fichiers restants lorsque le pod est supprimé.
Les applications stateful impliquent généralement une base de données, telle que Cassandra, MongoDB ou MySQL, et y traitent une lecture et/ou une écriture. En règle générale, cela implique que les demandes soient traitées sur la base des informations fournies. L’historique des requêtes précédentes a un impact sur l’état actuel ; par conséquent, le serveur doit accéder et conserver les informations d’état générés lors du traitement de la demande précédente, c’est pourquoi on l’appelle avec état.
La migration d’une application stateless est en général plus facile que la migration d’une application statefull.
Dans le cas d’une application stateful, vous devez savoir quels fichiers sont avec état et où ils sont stockés sur le système de fichiers. Par conséquent, quelqu’un qui a une bonne connaissance de l’application est obligatoire.
À part ces trois questions primordiales pour la migration, vous devez savoir comment l’application est configurée (comme par exemple les variables d’environnement) et comment lancer l’application.
2 – Définir une stratégie de migration
Lorsque nous migrions une application dans kubernetes, et suite à la première étape ou nous avons recueilli toutes les informations liés à l’application, nous pouvons définir une stratégie de migration.
Il existe en général 2 options :
1 – Migrer la base de données vers un autre emplacement et migrer l’application
2 – Migrer uniquement l’application.
Dans le premier cas, vous aurez une coupure sur votre application car vous ne voulez pas perdre de données pendant la migration. dans ce cas vous pouvez adopter les étapes suivantes :
1- Déployez votre application dans le cluster Kubernetes ;
2- Créer une page Maintenance
3 – Rediriger le trafic vers cette page de maintenance
4- Créer un dump ou une copie de vos données
5- Si votre application est stateful, récupérez les volumes avec les states
6- Restaurer les données dans la nouvelle base de données
7- Restaurez les volumes avec état dans la nouvelle application ;
8- Rediriger le trafic vers la nouvelle application avec une modification des enregistrements DNS.
Dans le second cas, vous n’aurez pas de temps d’arrêt car vous utilisez la même base de données. Vous pouvez adopter ces étapes :
1- Déployez la nouvelle application dans le cluster ;
2- Modifier les enregistrements DNS pour rediriger le trafic vers la nouvelle application
3 – Rendre votre application prête pour la migration :
Une fois les questions d’architectures et de dépendances passés, il faut désormais rendre votre application prête à être migrer sur kubernetes :
1- Si votre application est stateful, nous recommandons de retravailler le code afin de rendre l’application stateless, l’application sera plus simple à migrer et vous évitez ainsi d’utiliser des composants d’infrastructures pour la gestion d’état.
2 – Dockeriser votre application : de nos jours, ce n’est pas une partie difficile à mettre en œuvre. Il existe de nombreuses images Docker prêtes à l’emploi pour de nombreux frameworks et runtimes d’application. Vous pouvez trouver des exemples et des documents sur la façon de dockeriser votre composant pour chaque langage de programmation moderne. L’effort principal ici est d’ajuster/remplacer/trouver des bibliothèques qui fonctionnent sous Linux. De plus, certaines modifications de code peuvent être nécessaires. Ensuite, vous préparez simplement les fichiers docker et testez qu’ils fonctionnent
4 – Mettre en place un processus CI/CD :
L’objectif d’une migration sur kubernetes, est de rendre votre application monolithe en microservices et d’ainsi permettre une innovation moins douloureuse et plus rapide de votre produit.
Afin de rendre vos déploiements dans kubernetes plus fiable nous recommandons de mettre en place un processus CI/CD avant votre migration :
Le processus CI/CD souhaité est illustré dans le schéma ci-dessous.
1. L’établissement d’un processus CI/CD commence par de nouvelles modifications dans le référentiel de code source.
2. Ensuite, le moteur CI/CD démarre et exécute le processus de génération.
3. Le résultat de la construction est une image Docker prête à être déployée avec des fichiers d’application. Cette image est transmise au registre Docker.
4. Le moteur CI/CD lance le processus de déploiement en mettant à jour la version de l’image pour le déploiement K8s correspondant.
5. Kubernetes met à jour les pods et extrait une nouvelle image d’application du registre Docker.
5 – Préparer votre cluster Kubernetes :
Dans cette étape vous allez créer votre cluster kubernetes. Vous pouvez créer votre cluster sur GKE ou EKS par exemple, selon le cloud provider que vous utilisez.
Dans cette étape vous allez créer vos manifestes kubernetes et ainsi créer votre cluster.
6 – Migration et tests de charge :
Avant de le migrer, il est recommandé de réfléchir au dimensionnement pour s’adapter à votre trafic de production, afin d’éviter les temps d’arrêt. Pour ce faire, vous pouvez adopter 2 approches :
- Dimensionner l’application telle qu’elle était sur les machines virtuelles ;
- Dimensionnement en fonction des tests de charge.
Évidemment, nous recommandons la deuxième approche, car vous testez l’application dans le nouvel environnement et vous pouvez simuler un trafic plus important que la production. Ainsi, vous saurez exactement, par exemple, combien d’utilisateurs votre application peut ingérer.
Sii vous n’avez pas le temps de charger les tests, cela ne bloque pas la migration, mais soyez prudent avec l’autre approche pour vous assurer que votre application peut gérer le trafic de production.
Conclusion :
Pour migrer sereinement vers Kubernetes, nous vous recommandons de suivre ces étapes afin d’assurer que votre application est prête, que le CI/CD est en place et que votre nouvelle infrastructure est capable de supporter un grand nombre d’utilisateurs.
Vous pouvez avoir une vue d’ensemble des bonnes pratiques sur kubernetes en production dans cet article : https://pisquare.fr/best-practices-deploiement-dapplications-en-production-dans-kubernetes/
