Kubernetes est-il un mal nécessaire ?

Dans une démarche de Platform Engineering, l’un des premiers dilemmes est le choix de la plateforme d’exécution. Ici, on ne parle pas d’héberger directement des applications, mais bien des premières capacités de la plateforme elle-même, comme l’exposition réseau (DNS, Ingress, Certificats) ou l’observabilité.

Certains affirment : « Impossible de faire du Platform Engineering sans Kubernetes. »
Un axiome souvent répété, mais qui mérite d’être nuancé. Kubernetes peut grandement simplifier la vie… ou la compliquer.

Ayant expérimenté deux approches distinctes, nous avons pu comparer leurs forces et faiblesses. Voici comment et pourquoi nous avons fait le choix de Kubernetes pour OXP, notre plateforme orientée développeurs. Et comment nous avons refusé de baser notre autre plateforme TOC, sur K8S.

Kubernetes : le choix de OXP, notre plateforme orientée développeurs

L’équipe derrière OXP n’est pas spécialisée en Infrastructure as Code (IaC). En revanche, elle maîtrise parfaitement les conteneurs, l’orchestration et le templating de déploiement.

Le choix s’est donc imposé naturellement : une infrastructure clé en main, élastique et disponible en un clic. Nous avons opté pour un cluster K8S managé chez Scaleway (nous aurions pu choisir un autre fournisseur, mais à notre échelle, tous se valent… alors autant consommer français !🐔).

Ce choix structurant en a entraîné deux autres, logiques :

1. L’adoption de GitOps
   • Une source de vérité unique pour l’équipe.
   • Un formalisme partagé.
   • Une abstraction des mécanismes de déploiement, permettant de se concentrer sur les capacités et leur paramétrage.
   • Nous avons choisi ArgoCD, choix qui mériterait un article entier tant la comparaison avec Flux est riche.
2. L’adoption de Helm comme moteur de templating
   • Le débat Helm vs. Kustomize fait rage (alors que la solution idéale est souvent un mix des deux), mais ce choix n’est pas structurant pour la plateforme.
   • L’essentiel est ailleurs : variabiliser les capacités plateforme en fonction des environnements.

Un setup efficace pour démarrer

Ce choix initial nous a permis de poser des bases solides très rapidement :

• Un déploiement accéléré : la plupart des produits open source disposent d’un Helm chart prêt à l’emploi, nécessitant peu de paramétrage.
• Un ticket d’entrée “raisonnable” : Git + ArgoCD + Helm est un triptyque relativement simple à appréhender, du moins au démarrage.
• Un scaling et une haute disponibilité natifs : Kubernetes gère nativement l’élasticité et l’optimisation du placement des pods.
• Un uptime amélioré : la redondance des services est souvent intégrée aux Helm charts open source, garantissant une disponibilité même en phase d’expérimentation.

Mais ces avantages ont aussi leurs revers…

Les pièges de Kubernetes

Un dimensionnement difficile

K8S a tendance à surévaluer les ressources nécessaires. Beaucoup de services connaissent un pic de consommation CPU/mémoire au démarrage, forçant le cluster à allouer des ressources massives… puis à les sous-exploiter. Et les requests et limits ne permettent pas toujours de régler simplement le problème.

Avec ArgoCD, le problème est aggravé : impossible d’échelonner proprement les démarrages, ce qui engendre un effet “ruée de la horde”. Résultat : des machines surdimensionnées, et des FinOps qui font des malaises en voyant la facture.

Les pools de machines : une bonne idée  mais…

Les Cloud Providers proposent des node pools adaptés aux charges de travail hétérogènes :

• Petites instances pour les workloads légers.
• Gros nœuds CPU/mémoire pour les services gourmands (coucou Backstage et son yarn install).

En théorie, c’est séduisant. En pratique, chaque pool exige au minimum 3 nœuds, multipliant ainsi les machines sous-employées… et la facture.

Kubernetes et le cauchemar du stateful

K8S excelle sur les workloads stateless, mais devient un casse-tête dès qu’un stockage persistant est nécessaire. Héberger des bases de données ou du stockage objet en natif ? Mauvaise idée.

On finit par externaliser ces besoins via des services managés (S3, PostgreSQL), ce qui nous ramène à un paradigme IaC. Et comme Kubernetes ne gère pas nativement ces ressources, on se retrouve à bricoler des intégrations avec ArgoCD… avec plus ou moins de succès. Et même si des middleware comme Crossplane apportent un début de solution, on ajoute nécessairement une couche de complexité.

Jusqu’ici, nous avons détaillé pourquoi nous avons choisi Kubernetes pour OXP, ainsi que ses forces et limites. Mais est-ce un passage obligé pour du Platform Engineering ?

Pas forcément. Dans la seconde partie, nous explorerons une approche sans Kubernetes… et pourquoi elle peut être tout aussi pertinente.

TOC, une plateforme d’infrastructure en pure IaC

Puisque nous devons de toute façon mixer workloads Kubernetes et ressources instanciées en IaC, pourquoi ne pas aller à fond dans cette approche ?

Le principal frein, surtout pour des novices, réside dans la complexité initiale :

• Terraform et ses providers
  Chaque Cloud Provider impose sa propre grammaire (AWS, Azure, GCP…), rendant l’apprentissage fastidieux. De plus, choisir les bonnes machines est un casse-tête : le catalogue est souvent illisible pour un néophyte, avec des options et des tarifications obscures.
• Terraform ne suffit pas
  Il faut souvent lui adjoindre Ansible pour instancier et paramétrer efficacement les machines. Le débat "Ansible pilote Terraform" vs. "Terraform embarque Ansible" mériterait une série d’articles à lui seul (même si Aurélien Maury a déjà tranché !).

Une fois maîtrisée, une approche plus précise et efficiente que Kubernetes

Une fois ce duo infernal Terraform + Ansible dompté, les bénéfices sont nombreux :

Des machines parfaitement adaptées à chaque workload

• CPU, mémoire, disque et I/O sont taillés sur mesure.

Un contrôle total sur l’OS et ses packages

• Patch management quasi offert grâce à Ansible et ses inventaires.

Une gestion fine des accès et du réseau

• Isolation maximale, réduisant drastiquement les risques d’escalade de privilèges.

Côté FinOps, l’approche IaC est aussi plus prévisible :

• Chaque machine a un coût horaire clair.
• L’inventaire Ansible est moins élastique, rendant les coûts plus maîtrisés et projetables.
• En contrepartie, cette rigidité exige un capacity planning précis.

L’approche IaC : un choix idéal pour une équipe d’Ops… mais isolant

Ce modèle brille particulièrement quand la plateforme est confiée à une équipe d’Ops expérimentée, habituée à ces pratiques.

Mais il a aussi ses limites :

Une fracture avec le reste de l’organisation

• Devs, Sec et autres collaborateurs ne maîtrisent pas ces outils.

Une collaboration Git réduite au minimum

• L’ancienne logique "Les Ops savent, les Ops font" resurgit, avec un risque de silos et de goulots d’étranglement… voire un retour aux systèmes de tickets infernaux.

Des accélérateurs open-source moins nombreux

• La galaxie CNCF est riche et active, et ne trouve pas d’équivalent aussi fluide et dynamique côté Ansible Galaxy

La voie du 100 % managé : simplicité ou dépendance ?

Il existe une troisième approche que nous avons encore peu explorée, mais qui mérite réflexion : l’option du 100 % managé. Les trois grands Cloud Providers (AWS, Azure, GCP) proposent leur propre vision du Platform Engineering, s’appuyant massivement sur leurs services managés.

Une promesse séduisante… mais avec des compromis

Cette approche a de nombreux atouts, en particulier pour une organisation ayant choisi son CSP de référence et ne comptant pas en changer :

Des implémentations de référence accessibles

• Les blogs et documentations des CSP fourmillent de blueprints prêts à l’emploi, facilitant la mise en place rapide d’une plateforme.

Un coût d’intégration réduit

• La plupart des services natifs sont déjà interconnectés et optimisés pour fonctionner ensemble, éliminant de nombreux défis d’intégration.

Une élasticité quasi infinie

• Chaque capacité peut scaler indépendamment, sans se soucier du dimensionnement de l’infrastructure sous-jacente.

Cependant, le diable se cache dans les détails :

• Le "100 % managé" est rarement atteint
  • Dès qu’un service n’est pas couvert par le CSP, vous devrez intégrer une solution tierce. Par exemple, AWS inclut presque systématiquement ArgoCD dans ses architectures de référence, faute d’une offre GitOps maison.
• Un écosystème fermé qui dicte ses choix
  • Vous devrez vous adapter aux outils et aux paradigmes du fournisseur (IAM spécifique, formats propriétaires, limitations des services…).

Deux écueils majeurs : dépendance et coûts cachés

Un vendor lock-in presque inévitable

• Langages IaC propriétaires (PowerShell pour Azure, CDK pour AWS…).
• Formats de données souvent incompatibles entre CSP (même si certains standards émergent, comme OpenTelemetry pour l’observabilité).

Une maîtrise FinOps complexe

• Tarification opaque et éclatée (facturation par requête, par Go, par instance…).
• Une facture qui peut exploser si l’optimisation n’est pas un axe prioritaire dès le départ.

Un choix pertinent pour certains cas d’usage

Malgré ces contraintes, le 100 % managé peut être un excellent levier dans certains contextes :

• Startups ou équipes réduites qui veulent aller vite sans gérer l’infra.
• Projets courts ou temporaires, où la dépendance au fournisseur est moins critique.
• Organisations déjà "full cloud", avec des équipes expertes du CSP choisi.

En revanche, pour une plateforme devant garantir de la portabilité ou une maîtrise fine des coûts, ce choix peut rapidement devenir un piège.

Conclusion : un choix pragmatique et évolutif

Faut-il impérativement adosser le Platform Engineering à Kubernetes ? Faut-il au contraire tout miser sur l’Infrastructure as Code (IaC) ? Ou encore adopter une approche 100 % managée pour bénéficier des services natifs des Cloud Providers ?

Ces trois stratégies – Kubernetes et GitOps, l’infrastructure en pure IaC, et le tout managé – ont chacune leurs forces et leurs limites. Il n’existe pas de vérité absolue, seulement des compromis à arbitrer en fonction de trois grands facteurs :

• Les objectifs de la plateforme : Doit-elle être ultra-flexible ? Facilement maintenable ? Économiquement optimisée ? Doit-il y avoir une ou deux plateformes ?
• Les compétences de l’équipe : Une équipe à l’aise avec Kubernetes en exploitera mieux les capacités, tandis qu’une culture plus historiquement Ops et IaC forte trouvera dans l’IaC une meilleure maîtrise de l’infrastructure.
• La stratégie de l’entreprise : Un acteur multi-cloud devra éviter le vendor lock-in, tandis qu’un projet ancré chez un CSP pourra tirer parti de ses services managés.

Enfin, ce choix n’est pas figé dans le temps. Une organisation devrait démarrer avec une approche simple et évoluer vers plus de contrôle ou d’abstraction en fonction de sa  maturité technologique et de ses besoins.

Le vrai enjeu du Platform Engineering n’est donc pas de choisir la bonne solution, mais d’adopter une démarche itérative, alignée sur les besoins et capacités de l’entreprise, et capable d’évoluer au fil du temps.