Prérequis d'infrastructure¶
Ce que le client met à disposition avant que l'installation de la plateforme TRADEVAL puisse démarrer. La version remise au client est un document Word généré depuis cette même source ; cette page en est la version consultable.
Le déploiement s'appuie sur Kubernetes, sur des nœuds Talos Linux v1.13, avec une couche de données en cluster installée sur des machines virtuelles dédiées, hors du cluster.
Capacité visée¶
Le dimensionnement décrit ici soutient 1 000 utilisateurs simultanés en consultation.
Il dérive d'une campagne de charge du 2026-08-08 : la configuration a tenu 900 utilisateurs simultanés à 177 requêtes par seconde pour 1,02 % d'échec. Le palier de 1 000 est obtenu par la marge processeur et mémoire ajoutée au dimensionnement mesuré, pas par extrapolation d'un point de rupture.
Modèle de déploiement¶
Le cluster Kubernetes¶
Sept machines virtuelles : trois nœuds de contrôle qui portent l'API et l'état du cluster, trois nœuds de calcul qui portent les applications et le stockage répliqué Longhorn, et un serveur de rebond pour l'administration.
La couche de données¶
Treize machines virtuelles, hors du cluster. Le cycle de vie d'une base n'est pas celui d'un pod : une mise à jour de Talos, un drain de nœud ou une éviction mémoire sont des événements normaux pour un service sans état, et des incidents pour une base.
Chaque service est déployé en cluster, jamais en machine unique. Une machine isolée porterait à elle seule l'indisponibilité de toute la plateforme.
L'exposition publique¶
Aucun port entrant n'est ouvert sur le cluster depuis Internet. Un composant interne,
cloudflared, ouvre une connexion sortante chiffrée vers le réseau Cloudflare, qui assure
en amont la terminaison TLS, le filtrage applicatif et la protection anti-DDoS.
Trois adresses seulement sont publiques : le hub, le portail des usagers et la page d'authentification. Le portail interne n'apparaît nulle part sur Internet.
La conséquence est à retenir pour l'équipe réseau : ce qui doit être autorisé n'est pas un flux entrant vers le cluster, mais un flux sortant depuis le cluster.
Ressources à mettre à disposition¶
Capacité de virtualisation¶
| Ressource | Quantité |
|---|---|
| Cœurs physiques | 48 |
| Mémoire | 384 Gio |
| Stockage NVMe | 8 To |
| Réseau | 2 interfaces 10 GbE |
| Hyperviseur | VMware ESXi 8.0 ou supérieur |
| Serveurs physiques | 3, recommandé |
Les vingt machines totalisent 84 vCPU pour 48 cœurs physiques, soit un rapport de 1,75. Ce surengagement processeur est volontaire : les vingt machines n'atteignent pas leur pic au même instant. La mémoire, elle, n'est pas surengagée.
Machines virtuelles¶
Digitek Consulting crée et configure ces vingt machines. Le tableau détaille leur consommation, dont le total détermine la capacité demandée ci-dessus.
| Rôle | Nb | vCPU | Mémoire | Disques |
|---|---|---|---|---|
| Nœud control-plane Kubernetes | 3 | 4 | 16 Gio | 100 Go NVMe (système) |
| Nœud worker Kubernetes | 3 | 8 | 32 Gio | 100 Go NVMe (système) + 250 Go NVMe (stockage répliqué) |
| Serveur de rebond | 1 | 2 | 8 Gio | 100 Go |
| Nœud PostgreSQL | 3 | 4 | 16 Gio | 500 Go NVMe |
| Nœud etcd | 3 | 2 | 8 Gio | 100 Go NVMe |
| Courtier Kafka | 3 | 4 | 16 Gio | 200 Go NVMe |
| Nœud MinIO | 4 | 4 | 16 Gio | 500 Go NVMe |
| Total | 20 | 84 | 336 Gio | environ 5,9 To |
Second disque obligatoire sur chaque worker
Le disque de 250 Go dédié au stockage répliqué doit être un disque virtuel distinct du disque système, et non une partition de celui-ci. La couche de stockage du cluster ne peut pas démarrer autrement.
Deux répliques d'un même composant, comme deux nœuds PostgreSQL, ne doivent jamais partager un espace de stockage physique : la mise en cluster ne protégerait alors de rien.
Adressage réseau¶
| Élément | Rôle | À fournir |
|---|---|---|
| Adresses des machines virtuelles | adressage individuel des vingt machines | 20 adresses IP fixes |
| Point d'accès PostgreSQL | adresse stable du nœud principal, qui suit le basculement | 1 adresse IP fixe |
| Point d'accès control-plane | administration du cluster | 1 adresse IP fixe |
| Adresse virtuelle du cluster | point d'entrée unique de la plateforme | 1 adresse IP fixe |
| Plage d'adresses virtuelles | publication des services de la plateforme | 10 adresses contiguës minimum, incluant la précédente |
| Sous-réseau des conteneurs | réseau interne au cluster | 1 plage privée /16 non utilisée sur le réseau |
| Sous-réseau des services | réseau interne au cluster | 1 plage privée /12 non utilisée sur le réseau |
Les deux dernières plages sont internes au cluster mais ne doivent chevaucher aucun réseau existant, sous peine de rendre certaines destinations inaccessibles depuis la plateforme.
Nom de domaine et messagerie¶
Un nom de domaine dédié, délégué au fournisseur DNS Cloudflare avant le démarrage, et l'identifiant de zone correspondant. Le compte Cloudflare sert à deux usages : l'émission automatique des certificats TLS et l'établissement du tunnel de publication.
Le compte fournit aussi un jeton d'accès à l'API, limité à cette seule zone, avec exactement deux permissions, ni plus ni moins : modification des enregistrements DNS de la zone, et lecture de la zone. Ce jeton sert uniquement à l'émission des certificats. La validation passe par le DNS et non par le web, car elle seule permet de couvrir tous les sous-domaines sans exposer publiquement chacun des services internes.
Un relais SMTP joignable depuis le cluster, avec son adresse d'expédition, son port et ses identifiants. Sans ce relais la plateforme fonctionne, mais n'émet aucune notification, et ce défaut ne produit aucune erreur visible.
Flux réseau¶
Les flux ci-dessous doivent tous être autorisés. Les trois premiers ne sont détectables qu'une fois l'installation commencée : leur validation préalable évite d'interrompre la fenêtre d'intervention. « Les six nœuds du cluster » désigne les trois control-plane et les trois workers, à l'exclusion du serveur de rebond.
| Depuis | Vers | Port | Rôle |
|---|---|---|---|
| Les six nœuds du cluster et le poste opérateur | Résolveurs DNS publics | 53 | Résolution de noms. À valider avant le démarrage |
| Les six nœuds du cluster et le poste opérateur | Registres d'images et dépôt de la plateforme | 443 | Téléchargement des composants. À valider avant le démarrage |
Le cluster (cloudflared) |
Réseau Cloudflare | 7844 UDP et TCP | Tunnel de publication. Sans ce flux sortant, la plateforme publique ne démarre pas. À valider avant le démarrage |
| Poste opérateur | Nœuds control-plane | 50000 | Administration Talos |
| Poste opérateur | Adresse virtuelle du cluster | 6443 | Administration Kubernetes |
| Les six nœuds du cluster | Couche de données PostgreSQL, Kafka, MinIO | 5432, 9092, 9000 | Accès à la couche de données |
| Machines de la couche de données, entre elles | Machines de la couche de données | 5432, 2379 et 2380, 9092, 9000 | Réplication PostgreSQL, arbitrage etcd, réplication Kafka et MinIO. Flux internes indispensables à la haute disponibilité |
| Les six nœuds du cluster | Relais de messagerie | 25 ou 587 | Notifications de la plateforme et alertes de supervision |
| Les vingt machines | Serveur de temps NTP | 123 | Synchronisation horaire. Une dérive d'horloge fait perdre le quorum aux clusters et invalide les certificats |
| Postes internes du client | Adresse virtuelle du cluster | 443 | Accès aux portails internes depuis le réseau interne |
Les destinations du flux 443 sont nommées, une règle par catégorie n'étant pas applicable
par une équipe réseau : github.com, factory.talos.dev, charts.longhorn.io,
charts.external-secrets.io, grafana.github.io, prometheus-community.github.io, le
registre d'images de la plateforme et les registres publics des images amont.
factory.talos.dev
Cette destination porte l'image d'installation des nœuds, avec l'extension iSCSI sans laquelle le stockage répliqué ne démarre pas. Elle sert aussi à chaque montée de version : le flux reste nécessaire après l'installation.
Accès à fournir¶
L'accès à l'interface web de VMware permet à Digitek Consulting de créer et configurer les vingt machines virtuelles, sans intervention du client à chaque étape.
Répartition des responsabilités¶
La sauvegarde, la supervision et la restauration des vingt machines virtuelles sont assurées par Digitek Consulting, comme leur création et leur exploitation. Le client n'a pas à administrer le cluster ni la couche de données.
Une seule dépendance subsiste de ce côté : une sauvegarde qui ne quitte pas le serveur ne protège de rien. Le client met donc à disposition un espace de sauvegarde situé hors de l'hôte de virtualisation, vers lequel Digitek Consulting exporte les sauvegardes.
Liste de contrôle avant démarrage¶
- [ ] Capacité de virtualisation disponible : 48 cœurs, 384 Gio, 8 To NVMe
- [ ] Hyperviseur VMware ESXi 8.0 ou supérieur, deux interfaces 10 GbE
- [ ] Trois serveurs physiques, ou décision assumée de n'en fournir qu'un
- [ ] Vingt adresses IP fixes réservées
- [ ] Points d'accès PostgreSQL et control-plane réservés, une adresse IP fixe chacun
- [ ] Adresse virtuelle du cluster et plage de dix adresses contiguës réservées
- [ ] Deux plages privées internes choisies, sans chevauchement avec le réseau existant
- [ ] Nom de domaine délégué à Cloudflare, identifiant de zone et jeton d'API communiqués
- [ ] Flux du tableau ci-dessus autorisés, dont les sorties 53, 443 et 7844 testées
- [ ] Relais SMTP joignable, avec adresse d'expédition et identifiants
- [ ] Serveur de temps NTP joignable depuis les vingt machines
- [ ] Accès à l'interface web VMware ouvert à Digitek Consulting
- [ ] Espace de sauvegarde hors de l'hôte de virtualisation disponible
- [ ] Second disque virtuel distinct provisionné sur chacun des trois workers