Kubernetes dans une PME : les questions à trancher avant de créer un cluster

Un cluster Kubernetes peut être créé rapidement. Son exploitation demande beaucoup plus : mises à jour, droits, réseau, stockage, supervision et procédures d’incident. Pour une PME, le risque consiste à choisir une architecture dont le coût permanent dépasse le problème qu’elle résout.

Kubernetes est un orchestrateur de charges conteneurisées. Il organise leur exécution selon une configuration déclarée. Ce rôle est utile, mais il ne transforme pas automatiquement une application en service disponible, sûr ou rentable.

Le choix doit partir des contraintes de l’entreprise : déploiements, charge, compétences, continuité et budget. Ce dossier propose une grille technique pour décider, avec des calculs pédagogiques fictifs et des exemples qui ne constituent pas des tarifs de marché.

En bref — Avant le cluster, vérifiez le besoin d’orchestration, la capacité d’exploitation et les solutions plus simples. Dimensionnez les ressources réellement disponibles, prévoyez la perte d’un nœud et testez les mises à jour. Un service managé réduit certains travaux ; il ne supprime pas la responsabilité sur les applications et leurs données.

Le problème doit exister avant la solution

Une application web unique, une base de données et quelques tâches planifiées ne justifient pas automatiquement Kubernetes. Une plateforme applicative, un service de conteneurs ou des machines virtuelles peuvent répondre au besoin avec moins de composants à exploiter.

Les motifs à examiner sont concrets : plusieurs services déployés indépendamment, besoins de placement, variations de charge, standardisation des déploiements et contraintes d’isolation. Chaque motif doit être relié à un problème actuel ou à une trajectoire crédible, pas à une liste de fonctionnalités.

Interrogez l’équipe : combien de déploiements a-t-elle réellement effectués le mois dernier ? Combien de temps prend une reprise ? Quelles erreurs reviennent ? Quels changements sont retardés par l’infrastructure ? Les réponses orientent le choix mieux que le nombre de services annoncé sur une présentation.

La décision doit aussi distinguer compétences disponibles et compétences souhaitées. Une personne qui a monté un environnement de démonstration n’est pas nécessairement capable de gérer seule une panne de réseau ou une mise à jour majeure en production.

Il est utile d’écrire un scénario d’incident avant de retenir la solution : un nœud disparaît pendant une campagne, la personne principale est absente et la base reste disponible. Qui constate le problème ? Qui intervient ? Quelle manipulation est documentée ?

Ce cadrage rejoint le cahier des charges orienté résultats et recette. Le besoin est une continuité ou une fréquence de déploiement, pas la possession d’un cluster.

Comparer des responsabilités, pas seulement des prix de machines

Un cluster autogéré laisse à l’équipe davantage de responsabilités sur le plan de contrôle et les nœuds. Un service managé en prend une partie en charge, selon son contrat. Dans les deux cas, il reste des choix sur les charges, accès, images, données et composants ajoutés.

Établissez une matrice responsable / exécutant / preuve pour les mises à jour, sauvegardes, certificats, réseau, quotas et incidents. Une case vide signifie qu’un travail nécessaire n’a pas encore de propriétaire.

Comparez ensuite une solution plus simple sur la même base. Il serait trompeur d’inclure toutes les heures d’exploitation dans le cluster, puis de ne compter que l’hébergement pour l’alternative. Les deux scénarios doivent fournir le même service attendu.

Exemple fictif : une architecture simple coûte 500 euros d’infrastructure mensuelle et huit heures de travail à 45 euros, soit 860 euros. Une architecture Kubernetes coûte 850 euros et vingt heures, soit 1 750 euros. La différence atteint 890 euros par mois dans ces hypothèses.

Si Kubernetes libère trente heures mensuelles d’un autre travail, leur valorisation à 45 euros est de 1 350 euros. Ce gain de capacité n’est pas automatiquement une économie de trésorerie. Il faut préciser quel travail supplémentaire sera réalisé ou quelle dépense sera effectivement évitée.

La méthode de retour sur investissement et de coût complet permet de comparer ces hypothèses. Incluez la formation, la migration et les opérations exceptionnelles, puis testez un scénario où le gain de productivité est plus faible que prévu.

Dimensionner avec les ressources allouables et les contraintes de placement

Kubernetes utilise notamment les requests pour réserver une capacité lors du placement des charges. Les limites fixent des bornes d’usage selon la ressource et le mécanisme concerné. Un réglage au hasard peut provoquer une mauvaise utilisation du cluster ou des arrêts.

L’application doit être mesurée sur des charges représentatives. Une consommation moyenne faible ne décrit pas un pic de mémoire. Le CPU et la mémoire ne se comportent pas de la même manière : une pression mémoire peut provoquer l’arrêt d’un processus, tandis qu’une limite CPU peut contraindre son exécution.

Prenons un exemple fictif de dix pods demandant chacun 0,5 cœur de CPU et 1 Gio de mémoire. Le total demandé est de 5 cœurs et 10 Gio. Trois nœuds disposant chacun de 3,5 cœurs allouables donnent 10,5 cœurs. Après la perte d’un nœud, il reste 7 cœurs.

La somme semble suffisante pour le CPU, mais elle ne prouve pas que les dix pods peuvent être replacés. Il faut vérifier la mémoire, les ressources système, les contraintes d’affinité, les volumes et la capacité de chaque nœud. Deux ressources libres sur des nœuds différents ne se combinent pas pour accueillir un pod unique.

Ajoutez une marge pour les composants du cluster et les déploiements. Pendant une mise à jour progressive, des instances nouvelles et anciennes peuvent coexister. Une architecture dimensionnée seulement pour l’état stable peut manquer de place au moment du changement.

Mesurez également les quotas et les délais de création de nouveaux nœuds. L’autoscaling ne garantit pas une capacité instantanée, et il ne résout pas un quota atteint ou une zone indisponible. Le scénario de charge doit inclure le temps nécessaire pour obtenir des ressources.

Sondes et déploiements : éviter les redémarrages qui aggravent l’incident

Trois mécanismes ont des rôles différents. La readiness indique si une instance doit recevoir du trafic. La liveness sert à détecter une situation justifiant un redémarrage. La startup probe permet de gérer un démarrage lent avant les autres vérifications, lorsqu’elle est configurée.

Une sonde de vie ne devrait pas conclure que l’application est irrécupérable à chaque indisponibilité temporaire d’une dépendance. Si tous les pods redémarrent pendant une panne de base de données, le cluster peut produire une boucle de redémarrage sans corriger la cause.

Définissez un comportement pour chaque état : démarrage, dégradation, saturation et arrêt. Une instance qui se ferme doit cesser de recevoir de nouvelles demandes et disposer du temps nécessaire pour terminer ou interrompre proprement les opérations en cours.

Les déploiements doivent intégrer la compatibilité des versions. Une nouvelle application qui exige immédiatement un schéma de base incompatible peut empêcher le retour à la version précédente. Séparez, lorsque nécessaire, l’évolution du schéma et l’activation de la fonction.

Test de recette	Question à vérifier
Démarrage lent	Le trafic attend-il que l’application soit prête ?
Dépendance indisponible	L’application reste-t-elle contrôlable sans redémarrages inutiles ?
Arrêt d’un pod	Les demandes en cours sont-elles traitées selon la règle prévue ?
Nouvelle version défectueuse	Le déploiement s’arrête-t-il et le retour est-il possible ?
Ressources insuffisantes	L’équipe voit-elle les charges qui ne peuvent pas être placées ?

Ces tests doivent porter sur les parcours métier critiques. Le fait qu’un pod soit « Running » n’indique pas qu’un client peut terminer sa commande ou retrouver son dossier.

Plusieurs réplicas ne suffisent pas à garantir la continuité

Deux réplicas placés sur le même nœud partagent un risque. Plusieurs nœuds dans une même zone peuvent partager une autre dépendance. La répartition doit correspondre aux pannes que l’entreprise souhaite tolérer.

Un PodDisruptionBudget encadre certaines interruptions volontaires de pods. Il ne protège pas automatiquement contre toutes les pannes, ni contre l’indisponibilité d’une dépendance externe. Sa configuration doit rester compatible avec les opérations de maintenance.

Les données constituent souvent le point difficile. Recréer un conteneur ne recrée pas une base saine. Les volumes persistants ont leurs propres modes d’accès, contraintes de zone et procédures de restauration. Une application avec état demande une stratégie explicite.

Vérifiez les dépendances communes : DNS, accès aux images, certificats, base de données et passerelle réseau. Un cluster réparti sur plusieurs nœuds peut rester inutilisable lorsqu’un de ces services échoue.

La continuité mérite une répétition : perdre un nœud dans un environnement adapté, mesurer le temps de reprise et contrôler les opérations en cours. Le résultat doit distinguer redémarrage technique et retour du service métier.

Un objectif de disponibilité doit être associé à un coût et à une preuve. Choisir davantage de composants redondants sans tester les points communs peut augmenter les dépenses tout en laissant le principal risque intact.

Sécuriser les chemins d’administration et de déploiement

Les droits d’accès doivent suivre le moindre privilège. Les développeurs, processus de déploiement et applications n’ont pas tous besoin des mêmes permissions. Un compte d’administration partagé complique les investigations et augmente le risque d’une erreur globale.

Les namespaces organisent les ressources, mais ne constituent pas à eux seuls une frontière de sécurité suffisante pour tous les scénarios. L’isolation dépend aussi des politiques, du réseau, des droits et du niveau de confiance entre les charges.

Définissez qui peut déployer une image, utiliser un secret, modifier une règle réseau ou créer une charge privilégiée. Les contrôles doivent s’appliquer au chemin réel de production, pas seulement au compte habituel d’un développeur.

Les images nécessitent un suivi de provenance et de vulnérabilités. Une image connue aujourd’hui peut demander une mise à jour demain. Il faut pouvoir retrouver quelles versions sont déployées et remplacer une image sans attendre une refonte complète.

Les secrets demandent des règles de stockage, d’accès, de rotation et de suppression. Leur présence dans une configuration ne les rend pas automatiquement protégés contre tous les utilisateurs autorisés à lire cette configuration.

Enfin, les traces d’administration doivent permettre d’expliquer une modification. Conservez ce qui est nécessaire au diagnostic et à l’audit, avec des accès et une durée adaptés. La sécurité ne se résume pas à installer un outil supplémentaire dans le cluster.

Le calendrier de maintenance fait partie du produit

Listez les composants avec leur version, leur responsable et leur procédure de mise à jour : Kubernetes, nœuds, réseau, stockage, ingress, supervision et outils de déploiement. Chacun peut avoir ses contraintes de compatibilité.

La répétition d’une mise à jour doit couvrir les applications représentatives. Des extensions ou des API utilisées peuvent changer ; les manifestes et automatisations doivent être vérifiés avant la production. Le retour arrière n’est pas toujours symétrique à la montée de version.

Prévoyez une fenêtre et une communication adaptées aux utilisateurs. Une opération techniquement possible sans coupure peut néanmoins perturber certains traitements longs si leur comportement n’a pas été testé.

La supervision doit montrer les symptômes utilisateurs et les causes probables : erreurs applicatives, latence, saturation, pods non placés et problèmes de stockage. Un tableau affichant uniquement le CPU des nœuds laisse de nombreux incidents invisibles.

Organisez les relais. La documentation doit permettre à une deuxième personne de reconnaître une panne, trouver les accès et exécuter les premières actions. Une architecture dépendante d’un seul expert reste fragile, même lorsque ses composants sont redondants.

Un pilote limité pour décider, pas pour justifier le choix initial

La portabilité mérite un test distinct. Déployer une image conteneurisée ailleurs peut être simple, alors que déplacer ses volumes, ses règles réseau ou ses intégrations exige un autre travail. Inventoriez les dépendances spécifiques au fournisseur et essayez de recréer un environnement à partir des configurations conservées.

Cette reconstruction doit inclure les paramètres externes, les identités, les domaines et les certificats. Un dépôt de manifestes incomplet n’est pas une preuve de reprise. Le test peut montrer qu’une partie du service est portable et qu’une autre reste dépendante d’une plateforme : ce résultat est utile s’il est explicite.

Le plan de réversibilité et de récupération des données fournit une méthode pour documenter ce périmètre. Même avec un orchestrateur standard, la sortie exige des formats, des droits et des procédures. La liberté de changer d’hébergeur doit être démontrée sur le service complet, sans déduire cette liberté du seul choix de Kubernetes.

Choisissez une charge représentative, mais dont l’arrêt reste maîtrisable. Fixez les critères avant le pilote : temps de déploiement, effort de maintenance, reprise après incident et coût complet. Comparez avec l’alternative réellement envisagée.

Mesurez le travail d’exploitation au fil des semaines. Les heures nécessaires pour résoudre un problème de réseau ou mettre à jour une extension doivent entrer dans le bilan. Les supprimer au motif qu’il s’agit d’un apprentissage donnerait une vision trop favorable.

La décision finale peut être de conserver Kubernetes, de limiter son périmètre ou de choisir une plateforme plus simple. Chacune est acceptable si elle répond au besoin avec des responsabilités et des coûts compris.

Le bon résultat n’est pas un cluster impressionnant. C’est une équipe capable de déployer, maintenir et reprendre son service avec une complexité qu’elle peut durablement assumer.