Kubernetes est-il vraiment nécessaire ?

Je vais me faire un peu détester avec cet article, et tant mieux. Depuis quelques années, Kubernetes est devenu le réflexe par défaut dès que l’on parle de production. On le voit dans les offres d’emploi, dans les roadmaps DevOps, dans les architectures dessinées sur les tableaux blancs. Seulement voilà : la grande majorité des équipes que je croise n’ont aucun besoin réel d’un orchestrateur de containers. Pire, elles se retrouvent à payer un coût d’exploitation énorme pour une complexité qui n’apporte aucun bénéfice à leurs utilisateurs.

Kubernetes est un outil, pas un standard.

On doit savoir quand ne pas utiliser un outil.

Cet article est un plaidoyer pragmatique et un peu tranché. Je vais essayer de répondre à la question sans religion : quand Kubernetes est-il justifié, quand est-il un pur gaspillage, et quoi utiliser à la place.

D’où part ma position

Je veux être transparent sur mon point de vue avant d’argumenter, parce que ça conditionne la suite. Je suis développeur, j’administre mes propres serveurs, et je maintiens un petit cluster k3s dans mon home lab pour apprendre. K3s, c’est la distribution Kubernetes allégée de Rancher, qui tient dans 100 Mo binaires et tourne sur des Raspberry Pi ou un vieux PC. C’est dans ce contexte que je me suis familiarisé avec Kubernetes : non pas sur une grosse infra, mais sur quelques machines modestes, pour le plaisir de comprendre.

Cette expérience m’a appris deux choses. D’abord, Kubernetes est extrêmement bien pensé sur le plan conceptuel : declarative config, self-healing, rolling updates, tout ça est elegant. Ensuite, et c’est le point important : maintenir un cluster, même un modeste k3s, demande une attention constante. Et si c’est déjà vrai à petite échelle, imaginez ce que ça représente pour une équipe qui n’a personne de vraiment formé.

Je ne déteste pas Kubernetes. Je pense simplement qu’il est massivement sur-utilisé, au détriment de la simplicité opérationnelle.

Ce que Kubernetes résout vraiment

Pour comprendre quand Kubernetes est utile, il faut d’abord comprendre ce qu’il résout. Ce n’est pas un simple lanceur de containers. C’est un système qui orchestre l’état désiré d’un ensemble de services répartis sur plusieurs machines. Les problèmes qu’il adresse sont réels et précis.

Le scaling horizontal de services sans état. Si vous avez un service web qui doit passer de 3 replicas à 50 en une minute, et revenir à 3 le soir, un orchestrateur devient presque indispensable. Le HPA (Horizontal Pod Autoscaler) fait ça automatiquement en regardant le CPU, la mémoire ou des métriques custom. Faire la même chose à la main, sans l’orchestrateur, exige un montage fragile.

La haute disponibilité. Avec plusieurs nodes, si un serveur tombe, Kubernetes reschedule automatiquement les pods ailleurs. Un deployment avec 3 replicas réparties sur 3 nodes vous donne un service qui survit à la perte d’un ou deux serveurs. Dans un monde où chaque minute de downtime coûte cher, c’est un argument de poids.

Les rolling updates et rollbacks. Déployer une nouvelle version sans couper le service, avec la possibilité de revenir en arrière en une commande, c’est un vrai confort. kubectl set image et kubectl rollout undo font le travail proprement, en pourcentage progressif.

La découverte de services et le load balancing interne. Le DNS interne et les Services Kubernetes rendent les communications entre microservices relativement simples, avec le load balancing inclus.

La gestion multi-tenant. Si vous devez héberger plusieurs applications, plusieurs équipes, avec des quotas de ressources distincts, des Namespaces et des ResourceQuota deviennent très pratiques.

Tous ces points sont légitimes. Le problème est que ces problèmes n’existent pas pour tout le monde, et que Kubernetes impose son coût même quand on n’utilise qu’une fraction de ses capacités.

Quand Kubernetes est justifié

Soyons précis. Voici les situations dans lesquelles, à mon avis, Kubernetes se défend parfaitement.

Au moins deux ou trois services en interaction

Si vous avez une application découpée en plusieurs services (API, worker, cron, front) qui doivent communiquer, se redéployer indépendamment et évoluer séparément, l’orchestration commence à prendre du sens. Le problème du “comment je déploie 4 containers qui se parlent” est exactement celui que Kubernetes résout.

Une charge qui varie fortement

Un e-commerce avec des pics le jour des soldes, un service SaaS qui monte quand un gros client arrive : si votre trafic varie d’un facteur 10 ou 100 entre le creux et le pic, le scaling automatique est un vrai avantage. Vous n’avez pas à payer pour la capacité de pointe toute l’année.

Une exigence de haute disponibilité

Si votre service génère de l’argent en continu, qu’une coupure de 10 minutes coûte plus cher qu’un administrateur à temps plein, l’HA devient une exigence économique, pas un luxe. Kubernetes, avec multi-nodes et réplication, vous donne cette résilience.

Une équipe d’ingénieurs de plateforme

C’est le critère que je considère comme le plus important et le plus souvent ignoré. Kubernetes ne s’utilise pas à temps partiel par un développeur qui fait un peu d’ops. Il demande une équipe (ou au minimum un ingénieur dédié) qui vit dedans, qui maintient les nodes, surveille le cluster, gère les upgrades, les certificats, les quotas, la sécurité RBAC. Si cette équipe n’existe pas, la dette technique est immédiate et invisible.

Une infra multi-tenant ou multi-projets

Lorsque vous hébergez plusieurs produits, plusieurs clients, avec des besoins d’isolation et de quotas, les Namespaces de Kubernetes se révèlent très utiles.

Quand Kubernetes est exagéré

Maintenant retournons la question. Voici des situations où Kubernetes est, selon moi, une erreur.

Un service unique ou presque

Une seule application, peut-être avec une base de données à côté. Vous avez un service web et un Postgres. C’est le cas de très loin le plus fréquent dans les PME et les projets perso. Kubernetes n’apporte aucun bénéfice, seulement du poids.

Une charge faible et constante

Un blog, un site vitrine, une API qui reçoit quelques centaines de requêtes par jour. Votre serveur tourne à 5% de CPU. Le scaling horizontal est une solution à la recherche d’un problème.

Une petite équipe sans ops

Vous êtes seul, ou en équipe de 2 ou 3 développeurs, et personne ne veut faire de l’infra. Kubernetes serait un poison : il faut le mettre à jour, surveiller les nodes, gérer les crash-loops, comprendre les CNI, les Ingress, les StorageClass. Tout ce temps est du temps que vous ne passez pas à améliorer votre produit.

Un site statique ou un service trivial

Si votre site est généré statiquement (comme ce blog Hexo), vous n’avez même pas besoin d’un server-side dynamique. Kubernetes est un avion de chasse pour aller chercher du pain.

Le coût humain, la vraie comptabilité

Voici mon argument central : la plupart des équipes comparent Kubernetes à rien, au lieu de le comparer aux alternatives. Elles voient le gratuit du logiciel open source et oublient le coût d’exploitation. Un cluster, même managé, c’est du temps passé :

• à suivre les releases de la version k8s et de tous les operators installés
• à gérer les expirations de certificats du cluster
• à surveiller que les nodes ne sont pas saturés
• à débugger les problèmes réseau (CNI), de stockage, de DNS
• à maintenir les manifests, les Helm charts, les pipelines de déploiement
• à répondre aux incidents qui n’existeraient pas autrement

Chacune de ces tâches n’est pas très difficile en soi. Mais additionnées, elles représentent facilement un mi-temps, souvent à temps plein. Pour une équipe qui ne tire pas de bénéfice réel de l’orchestration, c’est de la valeur purement détruite.

Le coût caché de la complexité

Parlons de la courbe d’apprentissage. Même un k3s minimal, celui de mon home lab, exige de comprendre un vocabulaire dense : Pod, Deployment, StatefulSet, Service, Ingress, ConfigMap, Secret, PersistentVolume, nodeSelector, taints, tolerations, RBAC, Namespace, Helm, operators… Chacun de ces concepts a sa raison d’être, mais chacun est une couche de complexité à intégrer.

Dans mon home lab, j’ai d’abord été emballé. Puis j’ai passé un week-end à comprendre pourquoi un pod d’un namespace ne voyait pas un service d’un autre namespace (un problème de DNS et de NetworkPolicy). J’ai appris énormément. Mais j’ai aussi réalisé que dans un projet réel avec un délai, cette courbe d’apprentissage se paie en semaines de travail.

Kubernetes résout le problème de l’orchestration distribué en introduisant un problème d’ingénierie de plateforme. Si vous n’avez pas besoin du premier, vous héritez quand même du second. C’est le piège.

Le continuum des alternatives

Heureusement, il existe un beau spectre de solutions entre un seul serveur nu et Kubernetes complet. Je vais les parcourir, de la plus simple à la plus sophistiquée, avec l’idée de ne jamais prendre plus de complexité que nécessaire.

Docker Compose

C’est ma recommandation de base pour un service ou un petit ensemble de services. Un fichier docker-compose.yml déclare vos services, leurs volumes, leurs réseaux internes, leurs variables d’environnement. Une commande docker compose up -d déploie tout, docker compose pull && docker compose up -d fait la mise à jour.

services:
  api:
    build: .
    restart: unless-stopped
    ports:
      - "8080:8080"
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/app
    depends_on:
      - db
  db:
    image: postgres:16
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: pass
volumes:
  pgdata:

C’est simple, ça se lit en 5 minutes, et c’est suffisant pour héberger des années un projet. Le seul effort de plateforme est de gérer le healthcheck et les redémarrages de Docker lui-même, ce qui se résout par un service systemd.

Un VPS nu avec systemd

Si vous ne voulez même pas de Docker, un serveur Linux avec des unités systemd fait parfaitement le travail. C’est l’option la plus transparente : pas de couche d’abstraction du tout, juste le processus et son gestionnaire.

[Unit]
Description=Mon application
After=network.target

[Service]
User=www
WorkingDirectory=/srv/app
ExecStart=/usr/bin/node server.js
Restart=always
RestartSec=5
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Avec systemctl enable monapp, le service démarre au boot, redémarre en cas de crash, et les logs vont dans le journal. Pour une application métier classique, c’est étonnamment robuste.

Une grosse machine unique

Contre-intuitif pour certains, mais souvent excellent : au lieu de 3 petites machines orchestrées, prenez une seule grosse machine avec beaucoup de RAM et de CPU, et faites-y tourner plusieurs services. Les bases de données adorent ça (pas de réseau entre le service et Postgres), la latence diminue, et il n’y a rien à orchestrer.

Le seul risque est la perte de la machine. Mais pour beaucoup de projets, redouter la perte d’une machine est superflu : si vous avez une sauvegarde correcte, re-provisionner un serveur avec un playbook Ansible ou un script prend une heure, pas une semaine. La haute disponibilité à 3 nodes a un coût qu’il faut réellement comparer au temps de reprise après une panne sur une machine unique.

Les PaaS : Fly.io, Railway, Render, Vercel

Si vous voulez le bénéfice du déploiement sans l’infrastructure, les Plateform-as-a-Service sont excellentes. Vous poussez votre code, la plateforme gère le build, le scaling, les certificats TLS, les redémarrages. Fly.io et Railway sont de très bons exemples : ils gardent la simplicité du deploy par git mais ajoutent le scaling et la répartition.

C’est souvent le Kubernetes managé pour les gens qui n’ont pas d’équipe plateforme. Vous abandonnez le contrôle fin, mais vous gagnez un temps fou, et le coût marginal reste raisonnable pour des charges modestes.

Tableau comparatif coût / complexité

Pour synthétiser, voici un tableau qui place les options selon la charge mentale et le bénéfice apporté.

La colonne “Complexité d’exploitation” est celle que tout le monde sous-estime. Plus vous descendez dans le tableau, plus chaque déploiement et chaque mise à jour devient un projet à part entière.

Un cadre de décision (checklist)

Pour trancher en 5 minutes, je vous propose cette checklist. C’est celle que j’utilise moi-même maintenant, et elle m’a évité beaucoup de dérives.

1. Combien de services distincts devez-vous déployer ? Plus de 5 à 10 avec des besoins de scaling indépendants, Kubernetes se défend. En dessous, une solution plus simple est presque toujours meilleure.
2. Votre charge varie-t-elle réellement ? Si votre pic est stable et prévisible (ou pire, inexistant), le scaling horizontal ne sert à rien.
3. Avez-vous besoin d’une coupure nulle ? Si quelques minutes d’indisponibilité sont acceptables (avec redémarrage automatique), vous n’avez pas besoin d’un cluster multi-nodes.
4. Y a-t-il une équipe (au moins une personne à temps plein) pour maintenir le cluster ? Si non, c’est éliminatoire pour moi.
5. Avez-vous réellement plusieurs machines ? Un système avec 2 machines est un cas limite. Un cluster n’a de sens qu’à partir de 3 nodes, et encore.
6. Votre valeur est-elle dans votre produit ou dans votre infra ? Si un concurrent vous dépasse parce que vous passez vos dimanches à upgradé le cluster, vous avez perdu.

Si vous avez répondu non à plus de la moitié de ces questions, Kubernetes n’est pas pour vous aujourd’hui. Et ce n’est pas grave.

Ce que j’ai fait, concrètement

Mon home lab k3s m’a fasciné et éduqué. J’y ai appris des concepts que je réutilise partout, comme la declarative config et le self-healing. Mais pour ma production, mes projets réels, j’utilise Docker Compose sur une machine unique, avec un service systemd pour le redémarrage. Je fais un backup de la base toutes les nuits, et je peux tout reconstruire en une heure avec un playbook.

Ce choix n’est pas un renoncement : c’est un calcul de ce que mon temps vaut et de ce dont mon produit a réellement besoin. Le jour où j’aurai plusieurs services qui évoluent indépendamment et une charge qui varie, j’évoluerai vers une solution orchestrée, éventuellement managée. Mais je ne le ferai pas par réflexe, et je ne paierai pas la complexité tant qu’elle ne m’apporte pas un bénéfice mesurable.

Conclusion

Kubernetes est un outil remarquable, mais un outil de niche au sens où son coût n’est justifié que dans une configuration précise de besoins : multi-services, scaling réel, haute disponibilité, équipe dédiée, multi-tenant. Le mettre en place par défaut, sans ces besoins, c’est payer un prix élevé pour un problème qu’on n’a pas.

Avant d’adopter un orchestrateur, posez-vous la vraie question : de quoi mon application a-t-elle besoin pour servir ses utilisateurs ? La réponse est presque toujours : un déploiement fiable et simple. Et les alternatives (Docker Compose, un VPS, un PaaS, une grosse machine) répondent à ce besoin avec une fraction de la complexité.

Mon conseil final est simple : commencez petit, montez en complexité uniquement quand un besoin concret le demande, et ne laissez jamais un buzzword décider de votre architecture à votre place. La meilleure infrastructure est celle que vous comprenez et que vous savez maintenir, pas celle qui est à la mode.