CNP - Cloud Native Platform

Le projet en quelques mots

Le sujet impose des contraintes fortes : la plateforme doit fonctionner sur deux clouds publics et un cloud privé, tout doit être décrit dans du code versionné, et des agents d'intelligence artificielle doivent s'intégrer au niveau de la plateforme elle-même. Chaque semestre se conclut par une soutenance avec démonstration en direct.

La promesse défendue en soutenance de mi-parcours tient en une phrase : passer de l'envoi du code à une adresse sécurisée en ligne en quelques minutes, sans demande à formuler ni intervention manuelle.

La répartition dans l'équipe

Six personnes, chacune responsable d'un domaine, avec un tableau de responsabilités tenu à jour et un suivi par tickets.

Un cloud privé sur deux machines de récupération

Les deux clouds publics du projet se commandent : on décrit ce qu'on veut, le fournisseur le fabrique. Le cloud privé, lui, doit être construit - avec le matériel réellement disponible, en l'occurrence deux stations de travail, dont l'une date de 2012.

Le système d'exploitation retenu est conçu spécifiquement pour Kubernetes : pas d'accès en ligne de commande, pas de paquets à installer, une configuration entièrement décrite dans un fichier versionné. Conséquence directe : reconstruire une machine effacée prend environ un quart d'heure, ce qui rend le cloud privé aussi reproductible que les clouds publics - la propriété que le sujet exige.

La décision d'architecture la plus disputée

Le plan initial prévoyait un unique cluster réparti sur les deux machines, pour obtenir de la haute disponibilité. Un audit extérieur est venu challenger cette approche, et je l'ai reprise entièrement. Trois arguments l'ont écartée :

• À deux machines, le mécanisme de vote interne de Kubernetes exige que les deux soient présentes pour décider. Perdre une seule machine fige l'ensemble : deux nœuds offrent une disponibilité pire qu'un seul.
• Le réseau disponible, partagé entre la réplication du stockage et le trafic applicatif, aurait saturé.
• Les disques des deux machines sont trop dissemblables : les agréger aurait aligné les performances de l'ensemble sur le maillon le plus lent.

J'ai donc proposé l'inverse : deux clusters indépendants, un par machine. On renonce à une haute disponibilité qui n'aurait de toute façon pas fonctionné, au profit d'une séparation nette des pannes - un incident sur une machine ne touche pas l'autre. La reconstruction rapide et des sauvegardes testées compensent l'absence de bascule automatique.

J'ai également documenté une faille que l'audit n'avait pas vue : le mode de stockage retenu ne comporte aucune fonction de sauvegarde, alors que le cloud privé devait justement devenir le dépositaire des données persistantes. Un dispositif de sauvegarde vers un stockage distant a donc été ajouté, avec obligation de tester la restauration.

Où en est le projet

Synthèse provisoire