Les trois plans
Dans les conversations quotidiennes, “la prod” désigne généralement le plan cluster (les applications qui servent les clients). Quand on parle de “le serveur de monitoring” ou de “GitLab”, on désigne le plan services internes.
Le schéma d’ensemble
Ce diagramme montre comment les trois plans s’articulent, du trafic entrant jusqu’aux sauvegardes.Ce qu’il faut retenir
Un seul cluster pour les clients
Tout ce qui sert les clients tourne dans un seul cluster Kubernetes hébergé à Helsinki. C’est le coeur opérationnel de la plateforme.
Le cluster est déclaratif
Le cluster n’est jamais modifié à la main. Il reflète en permanence l’état du dépôt
argo-production sur GitHub. Toute modification manuelle serait écrasée.Images depuis ghcr.io
Les images conteneur viennent du registre GitHub Container Registry (ghcr.io). Elles sont construites automatiquement par GitHub Actions à chaque push.
Services internes isolés
Les outils internes (code, secrets, ERP, ordonnanceur, supervision) tournent sur une machine séparée gérée avec docker compose. Ils ne sont pas dans le cluster Kubernetes.
Trafic via Cloudflare et Traefik
Le trafic entrant passe obligatoirement par Cloudflare (DNS, TLS, WAF), puis par un load balancer Hetzner, avant d’atteindre Traefik qui route vers les applications.
Pour toute question sur l’architecture globale ou pour signaler une erreur dans ce schéma, contactez l’équipe DevOps : devops@kaeyros-analytics.com.