Sommaire

Depuis 2013, nous hébergeons et exploitons des serveurs : aujourd'hui plus de 500 machines virtuelles et conteneurs, répartis sur sept clusters Proxmox VE. Cet automne, nous avons franchi une étape que beaucoup de nos clients développeurs attendaient : une plateforme Kubernetes à nous, construite sur Proxmox, en France. Voici pourquoi, comment, et ce que nous en retenons, y compris ce qui reste à faire.

Pourquoi Kubernetes, et pourquoi pas chez un géant du cloud

Nos clients qui développent leurs propres applications nous demandaient la même chose : déployer eux-mêmes, souvent, sans ouvrir de ticket, avec des certificats et des sauvegardes qui se gèrent seuls. Kubernetes répond à ce besoin, à condition que quelqu'un s'occupe de la plateforme en dessous.

Les offres managées des grands fournisseurs américains (EKS, GKE, AKS) font ce travail, mais avec trois inconvénients pour nos clients : une facture difficile à prévoir (trafic sortant, répartiteurs de charge, transferts entre zones), un hébergeur soumis au droit américain, et une dépendance progressive à des services propriétaires. Sur des scénarios comparables, notre équipe a mesuré qu'une plateforme équivalente sur des serveurs dédiés OVHcloud revient à environ la moitié du prix d'AWS, trafic sortant compris. Le détail du calcul est publié sur notre site technique : alternative à AWS et cloud souverain.

L'architecture en quelques lignes

  • Le socle : quatre serveurs OVHcloud sous Proxmox VE, reliés par un réseau privé, avec un stockage Ceph répliqué sur trois serveurs.
  • Deux clusters Kubernetes plutôt qu'un : un cluster pour les applications, en haute disponibilité, et un cluster de gestion qui porte les outils d'administration. Une erreur sur l'outillage ne touche pas les applications, et inversement.
  • Talos Linux sur chaque nœud : un système immuable, sans SSH, piloté uniquement par API. Moins de choses à surveiller, moins de dérive entre les nœuds.
  • Le stockage des applications passe directement par le Ceph de Proxmox, via son pilote CSI : un volume demandé par une application est répliqué trois fois et suit ses pods d'un nœud à l'autre.
  • Le réseau et l'entrée : Cilium pour le réseau des pods, Traefik pour publier les sites, cert-manager et external-dns pour que le certificat et l'enregistrement DNS se créent seuls, CrowdSec pour bloquer les adresses malveillantes devant chaque application.
  • Pour les équipes : Rancher comme console et gestion des droits, Argo CD pour que chaque fusion dans Git soit déployée automatiquement.

Le principe qui a tout guidé : si ce n'est pas dans Git, ça n'existe pas

Toute la plateforme est décrite dans un dépôt Git : les VM Proxmox et la configuration Talos avec OpenTofu, les secrets chiffrés avec SOPS et age, les composants installés par un script idempotent dans un ordre fixe. Une reconstruction complète de la plateforme tient ainsi en quatre commandes et une dizaine de minutes, ce qui permet de dormir quand un serveur tombe, et de reprendre une plateforme sans dépendre de la mémoire d'une seule personne.

Deuxième principe : une sauvegarde ne compte que si elle a été restaurée. Velero sauvegarde les objets et les volumes chaque nuit vers un stockage S3 situé hors du cluster, etcd est sauvegardé et chiffré toutes les six heures, et nous avons réellement restauré ces sauvegardes avant d'ouvrir la plateforme.

Les mises à jour, la partie que tout le monde sous-estime

Une plateforme Kubernetes qu'on ne met pas à jour vieillit vite, et devient une cible. Kubernetes publie une version mineure tous les quatre mois environ, et chaque composant autour suit son propre rythme. Nous avons donc automatisé ce travail : Renovate propose chaque nouvelle version sous forme de demande de fusion, un humain la valide, puis tuppr met à jour Talos et Kubernetes la nuit, un nœud à la fois.

Conséquence pour les équipes de développement : les nœuds redémarrent certaines nuits. Une application qui doit rester en ligne doit donc tourner avec au moins deux réplicas. C'est la règle que nous rappelons le plus souvent, avec celle-ci : toujours déclarer les ressources CPU et mémoire de chaque conteneur, pour que Kubernetes place correctement les charges et protège les voisins.

Ce que ça change pour une équipe de développement

Pour un développeur, l'objectif était simple : une application en ligne, en HTTPS, sur son propre domaine, en une vingtaine de minutes, sans demander quoi que ce soit à personne. Chaque équipe travaille dans son espace isolé (un namespace), avec ses droits. Elle déclare un déploiement, un service, une entrée avec son nom de domaine : le certificat, l'enregistrement DNS et la protection CrowdSec suivent automatiquement. Les volumes sont répliqués, les sauvegardes tournent la nuit.

Nous avons écrit pour nos clients un guide pas à pas, de la connexion au passage au GitOps, publié lui aussi sur notre site technique : déployer une application sur Kubernetes. La construction de la plateforme est détaillée dans Kubernetes sur Proxmox VE, de A à Z.

Ce que nous avons perdu, et ce qui reste à faire

Un retour d'expérience honnête doit aussi dire ce qui coûte :

  • L'élasticité : des serveurs dédiés se louent au mois et se livrent en quelques jours. On ne double pas la capacité en cinq minutes comme chez un hyperscaler. Il faut dimensionner avec de la marge, et anticiper.
  • Les services propriétaires : fonctions sans serveur, bases managées propriétaires, IA managée n'ont pas d'équivalent prêt à l'emploi. Pour une application qui en dépend fortement, la migration se compte en mois, pas en semaines.
  • Plus de « panne chez quelqu'un d'autre » : l'exploitation nous revient entièrement. C'est notre métier, mais c'est un engagement à prendre au sérieux, avec une astreinte.
  • Les chantiers ouverts : l'observabilité complète (métriques, tableaux de bord, alertes sur les sauvegardes et les mises à jour) et l'authentification unique avec double facteur sont en cours.

Pour qui est-ce pertinent ?

Pour un site vitrine ou une boutique WooCommerce, un VPS bien tenu reste plus simple et moins cher. Kubernetes devient intéressant quand vous avez plusieurs applications conteneurisées, des déploiements fréquents, une équipe qui veut de l'autonomie, ou une facture cloud qui grimpe sans que vous sachiez bien pourquoi.

Pour estimer la taille d'un cluster à partir de vos applications, nous avons mis en ligne un outil de dimensionnement Kubernetes sur Proxmox, et un calculateur Ceph pour le stockage. Et si vous utilisez déjà Kubernetes, chez un hyperscaler ou sur vos propres serveurs, et que vous voulez en reprendre le contrôle, parlons-en : la première analyse est gratuite.