Cloud · 04/06/2026
Kubernetes sur site : à partir de quelle taille ça se défend
Exploiter un orchestrateur de conteneurs chez soi n'est pas un projet, c'est une charge permanente. Le rythme de publication du projet impose deux à trois montées de version par an, et chacune touche le réseau, le stockage, les certificats et les composants annexes. La question n'est donc pas de savoir si l'on sait l'installer, mais si l'on sait le tenir cinq ans.
Le débat est mal posé quand il oppose une technologie à une autre. Il se pose correctement en heures d'exploitation par mois et en compétences disponibles le jour où la personne qui a tout installé part en congés. Un orchestrateur sur site est un excellent choix pour une organisation qui livre souvent, avec plusieurs équipes ; c'est une charge disproportionnée pour une organisation qui déploie douze services stables une fois par mois.
La charge permanente, poste par poste
Le projet publie trois versions mineures par an et assure environ quatorze mois de correctifs par version. En pratique, une organisation qui ne veut pas exploiter de version non supportée réalise deux à trois montées de version par an. Chacune n'est pas un simple changement de numéro : elle entraîne la vérification des interfaces obsolètes utilisées par les applications, la compatibilité du greffon réseau, celle du greffon de stockage, celle du contrôleur d'entrée, et le renouvellement de certificats internes.
À cela s'ajoutent des tâches qui ne s'arrêtent jamais. La sauvegarde du magasin de configuration du cluster, avec une restauration testée, sans laquelle une erreur d'administration devient définitive. La gestion du registre d'images, sa purge, et la surveillance des vulnérabilités des images de base. L'observabilité, qui représente souvent autant de composants que le cluster lui-même. Enfin la gestion des ressources, car un cluster mal cadré consomme surtout de la mémoire réservée et jamais utilisée.
| Poste | Fréquence | Ce qui casse quand on l'oublie |
|---|---|---|
| Montée de version | Deux à trois fois par an | Interfaces retirées, greffons incompatibles |
| Sauvegarde du magasin de configuration | Quotidienne, restauration testée | Perte définitive de l'état du cluster |
| Certificats internes | Annuelle au minimum | Cluster injoignable du jour au lendemain |
| Registre et images de base | Continue | Vulnérabilités reconduites à chaque déploiement |
Le seuil, exprimé en organisation
Le seuil ne se lit pas en nombre de conteneurs. Il se lit en trois indicateurs organisationnels. Le premier est le nombre d'équipes qui doivent déployer indépendamment les unes des autres : en dessous de trois, la coordination manuelle reste moins coûteuse que l'outillage. Le deuxième est la fréquence de livraison : si les mises en production sont mensuelles et planifiées, l'automatisation apporte peu. Le troisième est le besoin d'isolation entre environnements ou entre clients, qui justifie à lui seul un orchestrateur dès qu'il devient contractuel.
Le quatrième indicateur est humain et il prime sur les trois autres : il faut au moins deux personnes capables de conduire une montée de version et de restaurer un cluster, pas une seule. Une compétence unique dans une organisation est une panne à retardement, indépendamment de la technologie concernée.
Les formats intermédiaires qu'on oublie
Entre les machines virtuelles gérées à la main et un cluster complet, il existe des marches intermédiaires souvent suffisantes. Une distribution légère, installée sur trois nœuds, couvre l'essentiel des besoins d'une organisation moyenne avec une charge d'exploitation nettement inférieure. Un ordonnanceur simple posé sur quelques machines virtuelles répond au besoin de redémarrage automatique sans introduire de couche réseau supplémentaire. Et un service managé chez un opérateur retire la charge de la couche de contrôle tout en laissant la maîtrise des applications.
Le choix entre ces marches dépend surtout de ce que l'équipe exploite déjà. Une organisation qui vient de reprendre en main sa couche de virtualisation a rarement les moyens d'absorber une seconde transition la même année, question que nous avons posée en détail dans notre analyse des chemins ouverts après la refonte des licences de virtualisation.
Les erreurs qui coûtent le plus
La première consiste à traiter le réseau comme un détail. Le choix du greffon réseau détermine la politique de filtrage entre pods, la façon dont les adresses sont attribuées et la compatibilité avec l'existant. Une organisation qui a déjà mené un plan d'adressage propre s'en sort bien mieux, sujet que nous avons développé dans notre note sur la migration IPv6 commencée par le plan d'adressage.
La deuxième consiste à ne pas tenir d'inventaire des applications déployées, de leurs propriétaires et de leurs dépendances. Un cluster devient très vite un endroit où des choses tournent sans que personne ne sache pourquoi, ce que nous décrivons à propos de la tenue d'une CMDB vivante.
La troisième consiste à installer sans prévoir la sortie. Les définitions d'objets sont portables en théorie, beaucoup moins dès qu'on utilise des contrôleurs spécifiques ou des services managés attachés. La question se traite au même endroit que le reste des conditions de sortie, comme nous l'expliquons à propos de la clause de réversibilité.
Le détail qui coûte cher
Un cluster mal dimensionné coûte surtout en ressources réservées et jamais consommées. Les demandes de mémoire fixées au doigt mouillé multiplient le besoin matériel par deux ou trois. Réviser ces valeurs sur la base des mesures réelles est l'action au meilleur rendement de toute la chaîne, avant même de discuter du nombre de nœuds. Le raisonnement est le même que celui appliqué aux factures de plateforme dans notre méthode pour lire une facture cloud à l'envers.