Jimmy

Scolaire

Fleetman — déploiement d'une application microservices sur Kubernetes

Déploiement et adaptation en binôme d'une application microservices existante sur un cluster Kubernetes multi-nœuds — manifests, persistance, réplication et tolérance à la perte d'un nœud.

Terminé
Schéma : un cluster Kind compte un nœud de contrôle, qui expose les NodePort, et deux workers ; le placement des pods est laissé à Kubernetes. Dans le namespace fleetman, l'utilisateur atteint l'interface web (NodePort 30080), qui appelle la passerelle d'API (NodePort 30020). En parallèle, le simulateur publie des positions dans ActiveMQ, que le tracker consomme avant de les enregistrer dans MongoDB, sur un volume persistant de 1 Gi. Interface web, passerelle et tracker ont deux réplicas ; simulateur, ActiveMQ et MongoDB n'ont qu'une instance. Des alias ExternalName du namespace default renvoient vers plusieurs services du namespace fleetman.
Architecture du déploiement KubernetesVue simplifiée du déploiement de Fleetman, application fournie par le cours, sur un cluster Kind à un nœud de contrôle et deux workers. L'interface web, la passerelle d'API et le tracker sont répliqués, tandis que MongoDB, ActiveMQ et le simulateur restent des instances uniques. La perte d'un worker a été testée pour les composants répliqués.

Ma contribution

Projet réalisé en binôme, dont j'ai assuré l'essentiel de l'implémentation technique : configuration du cluster Kind, manifests Kubernetes, persistance, exposition des services, réplication, dépannage inter-namespace et automatisation PowerShell. Nous avons ensuite validé ensemble le comportement de l'application lors de la perte d'un worker.

Points clés

  • Application prévue pour Docker Compose, réécrite en manifests Kubernetes
  • Composants critiques répliqués, perte d'un worker testée
  • Panne de communication entre namespaces diagnostiquée et corrigée par des Services ExternalName
  • Déploiement, nettoyage et opérations courantes automatisés en PowerShell

Objectif

Fleetman est une application de suivi de flotte en microservices, fournie par le cours et prévue pour Docker Compose. Le travail consistait à la déployer sur un cluster Kubernetes multi-nœuds : écrire les manifests, isoler les composants, persister les données et garder l’application disponible si l’un des nœuds de travail tombe. Le sujet portait sur le déploiement et l’exploitation, pas sur le développement de l’application.

Architecture

Le cluster est construit avec Kind : un nœud de contrôle et deux workers, chacun sous la forme d’un conteneur Docker. C’est un vrai cluster Kubernetes multi-nœuds, mais de laboratoire — pas un environnement de production.

L’application tourne dans un namespace dédié. Elle comprend un simulateur de positions, une file de messages ActiveMQ, un service qui consomme ces positions et les enregistre dans MongoDB, une passerelle d’API et l’interface web. Chaque composant a son Deployment et son Service : ClusterIP pour les échanges internes, NodePort pour exposer l’interface web et la passerelle d’API hors du cluster. Les données de MongoDB sont conservées sur un volume persistant (PersistentVolumeClaim).

Réplication et perte d’un worker

L’interface web, la passerelle d’API et le service de suivi des positions tournent chacun en deux réplicas, répartis entre les deux workers. La perte d’un worker a été testée : les composants répliqués continuent de servir l’application depuis l’autre nœud.

Cette tolérance ne couvre pas tout. MongoDB et ActiveMQ restent des instances uniques (MongoDB sur un seul volume persistant). Ce sont les limites assumées du projet, pas une architecture entièrement hautement disponible.

Dépannage : une communication rompue entre namespaces

Après le déplacement de l’application dans son namespace dédié, l’interface web n’arrivait plus à joindre l’API. En cause : certaines dépendances restaient référencées dans le namespace default, où les services n’existaient plus, ce qui rompait la communication entre composants. J’ai créé dans default des Services de type ExternalName qui redirigent vers les services réels du namespace dédié, d’abord pour la passerelle d’API, puis pour les autres services concernés. Un second problème venait de la version d’image utilisée pour l’interface web, prévue pour Docker Compose : la remplacer par la bonne version a rétabli son fonctionnement sous Kubernetes.

Automatisation

En plus du sujet, j’ai écrit trois scripts PowerShell présentés avec le rendu : le premier crée le cluster et déploie l’application dans l’ordre, le deuxième détruit l’environnement, et un menu regroupe le déploiement, la destruction et les vérifications d’état. Le projet se reconstruit ainsi de façon reproductible, en une commande.