Argos

Le problème

Les outils existants pour piloter des clusters Kubernetes (Lens, k9s, Grafana) exposent la complexité de l'API Kubernetes telle quelle. En débutant sur Kubernetes, ce niveau de complexité ralentissait plus qu'il n'aidait.

Le besoin était une interface qui reste puissante mais qui absorbe cette complexité au lieu de l'exposer, utilisable aussi bien par un profil développeur que par un profil infra, technique ou non.

Options envisagées et écartées

Lens et k9s ont été écartés pour la même raison : ce sont des outils pensés pour quelqu'un qui maîtrise déjà Kubernetes, pas pour un utilisateur qui débute ou qui n'est pas technique.

Grafana a été écarté parce qu'il suppose une stack Prometheus et des exporters déjà en place à opérer en plus, ce qui représentait une infrastructure supplémentaire pour un besoin qui, au départ, restait personnel.

La décision a été de construire un outil dédié plutôt que d'adapter un outil existant, avec une philosophie d'interface proche de ce que fait Apple : simple en surface, mais puissante en dessous. L'objectif était qu'il reste utilisable aussi bien par un profil technique que non technique.

Architecture

                    +---------------+
   Navigateur -->  | Load Balancer |
                    +-------+-------+
                            |
        +----------+--------+--------+----------+
        |          |                 |          |
     Flask #1   Flask #2         Flask #3   Flask #4   (4 replicas)
        +----------+--------+--------+----------+
                            |
              +-------------+--------------+
              |                            |
        PostgreSQL                  Kubernetes API
   (sessions, historique            (multi-cluster,
    de scans, health score)          lecture / actions)
              |
              v
     Alerting (Discord, mail)

Décisions difficiles

Le passage à 4 replicas pour absorber la charge a provoqué des déconnexions permanentes. Les sessions étaient stockées en mémoire, propres à chaque process. Le load balancer, en répartissant les requêtes, envoyait régulièrement l'utilisateur vers une replica qui ne connaissait pas sa session.

Cela a déclenché une migration vers flask-session avec un backend PostgreSQL, suivie d'une migration du reste de l'état applicatif (historique de scans, health scoring) qui était lui aussi en mémoire.

En parallèle, le fichier principal de l'application (app.py) a été découpé de 1170 à 199 lignes, pour limiter la dette de code et faciliter les évolutions futures plutôt que de laisser un monolithe difficile à naviguer.

Vérification

La vérification a été manuelle : reconnexions répétées après la mise en place de flask-session avec PostgreSQL. Les déconnexions, systématiques avant le correctif, ont cessé.

Ce que je ferais autrement

Concevoir l'état partagé (sessions, historique de scans) en base dès le départ, plutôt que de découvrir le problème seulement au moment de scaler horizontalement.