# Kubernetes ou serveur unique pour 500 sites : un an de métriques

> 500 sites municipaux, deux architectures testées sur une année complète. Le cluster Kubernetes autogéré a-t-il justifié son coût et sa complexité face à un serveur unique bien réglé ?

- Auteur : Clément Hadrot
- Publié le : 2025-09-11
- Mis à jour le : 2025-09-11
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/kubernetes-serveur-unique-500-sites-metriques/

## L’essentiel

- Un an de métriques réelles sur les deux architectures en parallèle
- Le serveur unique gagne en coût, Kubernetes gagne en isolation des pics
- Le point de bascule dépend du nombre de sites à fort trafic simultané

500 sites de mairies et d'intercommunalités, hébergés sur une même infrastructure mutualisée : la question posée par ce réseau n'était pas théorique mais budgétaire autant que technique. Fallait-il migrer vers un cluster Kubernetes autogéré, capable d'isoler chaque site dans son propre pod et de répartir la charge dynamiquement, ou rester sur un serveur unique, robuste et bien réglé, où tous les sites cohabitent sur la même pile PHP-FPM et MySQL ?

Plutôt que de trancher sur la théorie, les deux architectures ont tourné en parallèle pendant un an, avec un tiers du réseau basculé sur Kubernetes et le reste conservé sur le serveur unique existant, pour comparer coût réel, latence et résilience aux pics dans des conditions de production identiques.

## Ce que Kubernetes a réellement changé

Le cluster, composé de trois nœuds avec autoscaling horizontal, isolait chaque site municipal dans son propre pod avec des limites de ressources dédiées. En théorie, un pic de trafic sur le site d'une mairie ne pouvait plus affecter les 499 autres, contrairement au serveur unique où un pool PHP-FPM partagé pouvait se retrouver saturé par un seul site mal comporté.

En pratique, sur l'année observée, ce scénario de contagion ne s'est produit qu'à deux reprises sur le serveur unique, les deux fois lors d'une période électorale où un site communal concentrait un trafic dix fois supérieur à sa moyenne habituelle. Le reste de l'année, la charge globale du réseau restait suffisamment stable pour qu'un dimensionnement correct du pool PHP-FPM absorbe les variations sans isolation stricte.

> L'essentiel à retenir : Un an de métriques réelles sur les deux architectures en parallèle ; Le serveur unique gagne en coût, Kubernetes gagne en isolation des pics ; Le point de bascule dépend du nombre de sites à fort trafic simultané

## Le coût, poste par poste

| Poste | Serveur unique (167 sites) | Cluster Kubernetes (167 sites) |
| --- | --- | --- |
| Infrastructure mensuelle | 420 € | 980 € |
| Temps d'administration mensuel | 6 h | 18 h |
| Latence moyenne (hors pics) | 180 ms | 210 ms |
| Latence en pic (période électorale) | 1 400 ms sur le site concerné, propagé | 320 ms, isolé au site concerné |

Le surcoût mensuel de Kubernetes, de l'ordre de 2,3 fois le coût du serveur unique équivalent, s'explique par la redondance des trois nœuds, l'orchestration elle-même, et surtout le temps d'administration supplémentaire : gestion des manifestes, surveillance des ressources par pod, mises à jour de la couche d'orchestration en plus des mises à jour WordPress classiques.

## La latence moyenne, un résultat contre-intuitif

Contrairement à l'attente initiale, la latence moyenne hors pic était légèrement meilleure sur le serveur unique, grâce à un cache d'objets Redis partagé entre tous les sites et à l'absence de surcouche réseau entre les pods. Le cluster Kubernetes ajoutait un coût de routage interne (kube-proxy, service mesh léger) qui se payait sur chaque requête, même en l'absence de tout pic.

- Le serveur unique bénéficie d'un cache d'objets mutualisé, plus efficace qu'un cache par pod isolé.
- Kubernetes gagne uniquement quand l'isolation empêche une contagion de charge entre sites, un événement rare mais réel.
- La complexité opérationnelle de Kubernetes n'est absorbée sans risque que par une équipe déjà formée à cet écosystème.

## Où se situe le point de bascule

Après un an de données, le seuil qui s'est dégagé n'est pas un nombre de sites, mais un nombre de sites à fort trafic simultané potentiel. Un réseau de 500 petits sites municipaux à trafic homogène et prévisible n'a que peu à gagner de l'isolation Kubernetes. Un réseau qui compterait, par exemple, cinquante sites avec des pics imprévisibles et désynchronisés justifierait davantage l'investissement.

> Nous ne recommandons plus Kubernetes par défaut pour un réseau de sites municipaux : nous le recommandons quand l'historique de trafic montre des pics isolés et imprévisibles sur un sous-ensemble significatif des sites, pas avant.

## Ce que le serveur unique a dû apprendre

Le maintien du serveur unique n'a pas été passif : un mécanisme de limitation de débit par site a été ajouté au niveau de nginx, pour éviter qu'un pic isolé ne consomme la totalité du pool PHP-FPM partagé, une forme d'isolation légère qui a capté une bonne partie du bénéfice de Kubernetes sans son coût.

```
limit_req_zone $site_id zone=par_site:10m rate=30r/s;

server {
    location / {
        limit_req zone=par_site burst=50 nodelay;
    }
}
```

## Le choix qui s'impose

Sur ce réseau de 500 sites, le serveur unique bien réglé, complété par une limitation de débit par site, a été retenu comme architecture cible, avec un budget réservé pour basculer progressivement les sites à trafic imprévisible vers un cluster plus restreint si leur nombre venait à croître. Un an de métriques a montré qu'une architecture plus simple, correctement dimensionnée, l'emporte tant que le scénario qui justifie la complexité ne s'est pas encore matérialisé à grande échelle.