Consultez le glossaire avant de lire cette documentation
Kubernetes est un système d'orchestration de conteneurs conçu pour déployer, mettre à l'échelle et gérer des applications conteneurisées de manière déclarative.
K3s est un projet open source développé à l'origine par Rancher Labs, désormais maintenu par SUSE.
C'est une distribution Kubernetes légère, optimisée pour les environnements à ressources limitées et les déploiements simplifiés.
L'utilisation de Kubernetes nous fournit un environnement reproductible, rendant les déploiements cohérents à travers différentes configurations.
La distribution K3S utilise la gestion IAC à l'aide de manifestes YAML et s'aligne sur les pratiques DevOps.
💡 Un cluster dans Kubernetes fait référence à un ensemble de machines (nœuds) qui travaillent ensemble pour exécuter des applications conteneurisées.
Il se compose de :
- **Control Plane **: gère le cluster (planification, mise à l'échelle, serveur API).
- **Nœuds de travail **: exécutent les charges de travail de l'application (conteneurs).
****Comment nous l'utilisons ****
- Assure des déploiements cohérents et reproductibles dans tous les environnements clients ;
- Simplifie l'installation sur site grâce à la légèreté de K3S ;
- Intégration transparente avec des outils GitOps tels qu'ArgoCD, pour des déploiements contrôlés et auditable ;
- Rolling Upgrades : mises à niveau sans interruption de service ;
- Automatise les déploiements d'applications et la mise à l'échelle dynamique ;
- L'isolation des clusters par client améliore la sécurité des données et la conformité ;
- Gestion des secrets et automatisation des certificats via Vault et cert-manager ;
- Infrastructure déclarative, réduisant l'erreur humaine, et définitions d'infrastructure contrôlées par version ;
- Prise en charge de la segmentation du réseau au sein du cluster ;
- Fournit des logs d'audit pour suivre toutes les actions sur le cluster, les services et les composants du Control Plane - assurant la visibilité et la traçabilité ;
- L'utilisation de conteneurs dans K3S rend les applications immuables, ce qui limite la capacité d'un attaquant à persister dans l'environnement.
Avec K3S, combiné à ArgoCD, nous pouvons rapidement déployer notre plateforme, que ce soit sur site, dans les environnements clients, ou directement sur le cloud : dans les deux cas, le système de déploiement sera le même. Cette configuration nous permet de gérer toutes les couches de l'infrastructure (réseau, stockage, configuration du système, sécurité) d'une manière unifiée et déclarative. Elle garantit un déploiement cohérent, reproductible et léger avec un minimum d'opérations manuelles.
En outre, ArgoCD extrait les modifications directement des dépôts Git et s'assure que la plateforme converge vers l'état souhaité. Cette approche élimine le besoin d'exposer une interface d'administration sur Internet ou de configurer des identifiants sur un service CI/CD tiers.
Longhorn
Longhorn est une solution de stockage par blocs distribués, native pour Kubernetes.
Elle fournit des volumes persistants avec des capacités de réplication, de snapshot et de sauvegarde, le tout géré via l'API Kubernetes.
Comment nous l'utilisons
- Permet de limiter le volume de stockage alloué à un composant ou à une application ;
- Gère de nombreux volumes persistants au sein du cluster Kubernetes ;
- Permet la réplication sur plusieurs nœuds pour assurer la haute disponibilité ;
- Gère des sauvegardes sur des supports externes (NFS, SMB, S3) ;
- Chiffrement des données au repos ;
- Intègre KubeVirt pour fournir un stockage fiable pour les données des Data Cleanrooms basées sur des VM.
Dans notre infrastructure, le DNS est à plusieurs niveaux :
- **DNS externe dans les environnements hébergés par Arkhn **: Géré par un prestataire DNS externe certifié HDS (Scaleway) pour associer les noms de domaine à l'IP d'entrée publique du cluster et s'assurer que le trafic peut être correctement acheminé vers les services exposés par le cluster K3S ;
- **DNS externe dans les environnements hébergés par le client **: Les enregistrements DNS permettant d'accéder à la plateforme sont fournis par le client ;
- **DNS interne **: Géré par CoreDNS, qui est fourni avec K3S. Il fournit une résolution de nom interne pour les services et les pods au sein du cluster. Nous modifions occasionnellement sa configuration si nécessaire.
Certificats internes
Nous utilisons cert-manager en combinaison avec Vault pour gérer et automatiser l'émission de certificats TLS internes à l'intérieur de nos clusters Kubernetes.
Cette configuration permet à des services comme Traefik d'obtenir des certificats de manière dynamique, tout en conservant un contrôle total sur leur cycle de vie.
Pourquoi cette configuration
- Centralisation de la gestion des certificats internes à l'aide de la PKI de Vault ;
- Prise en charge des certificats mTLS internes ;
- Cert-manager automatise la création de certificats internes, Vault jouant le rôle d'autorité de certification.
Comment nous l'utilisons
- Cert-Manager est déployé dans le cluster en tant que contrôleur Kubernetes ;
- Vault est configuré en tant que backend d'autorité de certification ;
- Vault signe le certificat et le renvoie à cert-manager ;
- cert-manager stocke le certificat résultant en tant que secret Kubernetes ;
- Traefik utilise ce secret pour servir le trafic HTTPS.
Certificats externes
Nous utilisons également cert-manager pour automatiser l'émission de certificats TLS publics, en combinaison avec Let's Encrypt et notre fournisseur DNS.
Cela permet l'émission et le renouvellement automatiques de certificats de confiance publics, utilisés pour exposer nos services sur internet.
Certificats fournis par le client
La plateforme supporte également les certificats fournis directement par les clients ou les partenaires. Ces certificats ne sont pas gérés dynamiquement et doivent être validés, stockés et déployés manuellement au sein du cluster.
Traefik est utilisé comme ingress controller dans nos clusters Kubernetes. Son rôle est de gérer le trafic HTTP/HTTPS entrant, et de le router en interne vers les services appropriés (qui exposent nos pods avec des points d'entrée) en fonction des règles de nom de domaine et de chemin d'accès.
Il agit comme le point d'entrée obligatoire pour tout le trafic web exposé à l'extérieur du cluster.
Comment nous l'utilisons
- Déployé par défaut dans tous les environnements avec K3S ;
- Agit comme un reverse proxy pour les services hébergé par K3S ;
- Connecté à cert-manager, pour les certificats TLS et mTLS ;
- Traefik achemine le trafic à travers les namespaces, ce qui permet un routage multi-service sous le même domaine ;
- Prise en charge du SSO avec Oauth2Proxy ;
- Réécriture d'URL.
Comment nous l'utilisons
- Utilisé principalement par l'équipe NLP pour stocker et versionner deux modèles :
- "Lighter pseudonymization"
- "Lighter structuration"
- ClearML est hébergé sur notre hébergeur HDS.
- ClearML utilise MinIO pour stocker les modèles dans S3.
- Utilisé pour l'exécution de plusieurs runs, mais principalement axé sur la persistance des modèles, et non sur l'orchestration des entraînements.
AZMonitoring est notre plateforme centralisée pour la surveillance de l'infrastructure.
L'interface principale pour les utilisateurs est Grafana**.**
Les dashboards Grafana sont conçus pour afficher les métriques de toutes les instances de la plateforme dans une interface centralisée.
À partir d'une seule interface, nous pouvons surveiller des indicateurs-clés tels que l'utilisation du disque, la charge du système ou l'activité de la base de données dans tous les environnements.
Grafana est également configuré pour envoyer des alertes via Slack lorsqu'une action urgente est nécessaire - comme un faible espace disque.
🔒 Toutes les métriques collectées sont strictement non identifiantes et ne fournissent que des informations techniques sur la santé du système.
✅ Ces métriques sont transmises de manière sécurisée, avec une liste d'autorisation d'IP et une authentification par certificat client (mTLS) pour garantir une protection stricte des données.
Nexus est un gestionnaire de dépôt utilisé pour stocker, gérer et distribuer des artéfacts logiciels. Cela nous permet de centraliser les artéfacts du projet et d'y accéder à tout moment.
Points-clés
- Prise en charge de plusieurs formats ;
- Permet de créer des dépôts hébergés ou proxy (cache de dépôts externes) ;
- Contrôle d'accès basé sur les utilisateurs et les rôles ;
- Enregistre et suit l'utilisation des artéfacts.
Comment nous l'utilisons
- Images des conteneurs ;
- Proxy utilisé pour : APT (gestionnaire de paquets Debian), Python et R ;
- Stockage des binaires ;
- Autres paquets de code (dbt, NLP…).
Nexus nous aide à réduire les téléchargements de dépendances externes et assure une disponibilité constante des artéfacts dans tous les environnements sans demander d'ouverture large des accès à internet.
GitHub est une plateforme web utilisée pour l'hébergement de code, le contrôle de version et la collaboration sur le code source à l'aide de Git.
Comment nous l'utilisons
- Hébergement du dépôt Git : l'ensemble de la plateforme de l'entreprise est hébergé sur GitHub, y compris le code de l'infrastructure, les applications, les flux de travail CI et le code DBT ;
- Révision et versionnement du code: flux de demandes d'extraction, commentaires en ligne, approbations, historique des modifications ;
- Intégration CI/CD via GitHub Actions ;
- Projet GitHub : gestion des tâches et suivi des progrès ;
- Connecté à ArgoCD pour le déploiement continu.