Bernstein

Bernstein est un projet Epitech (Tek3, module Advanced DevOps) qui consiste a orchestrer une application distribuee sur un cluster Kubernetes multi-noeuds, en utilisant Traefik comme reverse proxy et load balancer. L'application de reference est une application de vote classique en cinq composants : Poll (Flask/Python) qui recueille les votes et les pousse dans une file Redis, un Worker (Java) qui consomme cette file et ecrit les resultats dans une base PostgreSQL, et Result (Node.js) qui affiche les resultats agreges.

Le travail consiste a ecrire l'integralite des manifestes YAML necessaires au deploiement : deux bases de donnees (Redis et PostgreSQL, non repliquees, toujours redemarrees, exclues du routage Traefik), trois services applicatifs (poll et result repliques en deux instances avec limite memoire de 128 Mo, worker non replique avec 256 Mo), un load balancer Traefik replique en deux instances avec acces a l'API interne de Kubernetes, et un outil de supervision cAdvisor deploye en DaemonSet sur tous les noeuds.

Une contrainte de haute disponibilite impose que les instances repliquees d'un meme service s'executent sur des noeuds distincts. Les variables d'environnement communes doivent etre centralisees dans une ConfigMap Kubernetes, tandis que les identifiants sensibles (POSTGRES_USER, POSTGRES_PASSWORD) doivent obligatoirement passer par un Secret. Traefik expose son proxy HTTP et son dashboard d'administration a la fois en interne au cluster et sur des NodePort specifiques accessibles depuis l'hote.

Le postgres necessite egalement la definition d'un volume persistant sur /var/lib/postgresql/data pour survivre aux redemarrages de pod. L'ensemble du deploiement suit un ordre precis (cadvisor, puis postgres, puis redis, puis les trois services applicatifs avec leurs ingress, puis enfin Traefik), et une etape manuelle de creation de table SQL est necessaire apres le premier deploiement.

L'environnement recommande est un cluster K3s (Minikube etant insuffisant car limite au mono-noeud), deployable localement ou via un fournisseur de Kubernetes managed comme Amazon EKS, Google GKE ou Digital Ocean. L'evaluation est entierement automatisee et repose sur l'analyse statique des fichiers de configuration livres, dont la liste exacte (dix-neuf fichiers YAML nommes selon une convention stricte) est imposee par le sujet.