Kubernetes : le grand bluff DevOps

Kubernetes 2 arrive bientôt. Et, comme prévu, nous dirons adieu à YAML. Enfin ! Ce sera aussi l'occasion d'admettre, de manière à peine voilée, que Kubernetes était – et reste – un véritable fouillis ingérable . Non pas une innovation, mais un enchevêtrement technique érigé en norme, sans que personne n'ait jamais osé s'arrêter et se demander : « Attendez, est-ce que tout cela a vraiment un sens ? »

En réalité, Kubernetes n'a jamais été conçu pour le grand public , pour les développeurs ordinaires, pour ceux qui gèrent des projets concrets avec des budgets, des échéances et des environnements de production devant fonctionner 24 h/24 et 7 j/7. Kubernetes a été imaginé par une élite technique – principalement d'anciens ingénieurs de Google – qui ont tenté de reproduire en dehors de Google les concepts de Borg , le système d'orchestration interne de l'entreprise. Le problème, c'est que Borg est un système conçu pour une échelle que la plupart des entreprises n'atteindront jamais. Et le reproduire maladroitement en dehors de ce contexte n'a engendré aucune révolution, mais seulement une complexité accrue.

Docker et le mythe du mini-cloud DIY

Pour comprendre l'origine de la confusion, revenons un instant en arrière. Docker était pertinent à ses débuts : c'était un moyen rapide d'éviter le coût des machines virtuelles et de gérer plus facilement des environnements pseudo-isolés. Parfait. Mais une grande illusion s'est ensuite installée : la possibilité de construire un mini-cloud « comme les grands acteurs » avec seulement quelques fichiers YAML et un peu de script.

Et c'est là que le château s'est effondré. Car créer et gérer un environnement conteneurisé, orchestré par Kubernetes, est loin d'être simple , et encore moins automatique. Cela requiert des compétences que tout le monde ne possède pas. En réalité, cela exige une quantité impressionnante de connaissances transversales.

• La sémantique de Kubernetes est incomparable. Elle représente l'un des écosystèmes les plus complexes de l'informatique moderne. Il ne s'agit pas seulement de comprendre les pods, les services et les déploiements, mais de maîtriser tout un univers de primitives interconnectées : ReplicaSet, StatefulSet, DaemonSet, Job, CronJob, ConfigMap, Secret, PersistentVolume, StorageClass, Ingress, NetworkPolicy, RBAC et CustomResourceDefinition. Chaque objet possède son propre cycle de vie, ses états, ses conditions et son finaliseur. La complexité est décuplée lorsqu'on considère l'interaction entre ces éléments : comment un HorizontalPodAutoscaler surveille les métriques personnalisées via le serveur de métriques, comment les contrôleurs d'admission valident et modifient les ressources entrantes, et comment le garbage collector gère les dépendances propriétaire-référence. Le modèle déclaratif exige une approche radicalement différente de la gestion impérative traditionnelle, où l'état souhaité est décrit plutôt que les étapes pour l'atteindre.

• La gestion des réseaux TCP/IP de haut niveau , avec ses superpositions, ses plugins, ses maillages de services et son DNS interne, est essentielle. Le réseau Kubernetes fonctionne sur plusieurs couches d'abstraction, ce qui exige une compréhension approfondie de la pile TCP/IP. Les réseaux de superposition comme Flannel, Calico et Weave créent des réseaux virtuels s'étendant sur des nœuds physiques, grâce à des technologies telles que VXLAN, BGP et le tunneling IP-in-IP. Les plugins CNI (Container Network Interface) gèrent l'attribution d'adresses IP aux pods, la configuration des tables de routage, les règles iptables et les ponts virtuels. Les maillages de services comme Istio, Linkerd et Consul Connect ajoutent une couche de complexité supplémentaire avec des proxys sidecar qui interceptent tout le trafic, implémentant un équilibrage de charge avancé, la protection contre les coupures de circuit, des politiques de nouvelle tentative et le TLS mutuel. Le DNS interne (CoreDNS) doit résoudre la découverte dynamique de services, gérer le découpage des zones et se synchroniser avec les registres de services externes. Le dépannage requiert une expertise en capture de paquets, en analyse des chaînes iptables, en compréhension des hooks netfilter et en débogage des tables de connexion.

• Ingénierie système Linux avancée : débogage au sein des conteneurs, traçage des processus zombies et résolution des problèmes de démarrage inexpliqué des pods. Sur AlmaLinux, l’ingénierie système Kubernetes exige une expertise Linux au niveau du noyau appliquée aux environnements conteneurisés. Le débogage au sein des conteneurs implique l’isolation des espaces de noms (PID, NET, MNT, IPC, UTS, USER), les cgroups v1/v2 pour la limitation des ressources et la mise en place de périmètres de sécurité. La gestion des processus zombies dans les conteneurs requiert une compréhension des systèmes d’initialisation (souvent tini ou dumb-init), de la gestion des signaux et de la suppression des processus. En cas d’échec de démarrage inexpliqué des pods, il est nécessaire d’analyser : les journaux kubelet, l’état d’exécution des conteneurs (containerd/CRI-O), les profils seccomp, les politiques AppArmor/SELinux sur AlmaLinux, les quotas de ressources et les règles d’affinité/anti-affinité des nœuds. Parmi les outils essentiels, on trouve nsenter pour la saisie des espaces de noms, crictl pour le débogage CRI, systemd-analyze pour l'analyse des performances, strace pour le traçage des appels système et perf pour le profilage. Sur AlmaLinux en particulier, la gestion des contextes SELinux pour les conteneurs, les règles firewalld et les dépendances des services systemd complexifie encore la situation.

• Le stockage distribué , la réplication de volumes et la persistance des données volatiles dans les environnements éphémères sont des aspects clés. Le stockage distribué dans Kubernetes répond au défi fondamental du maintien de la persistance dans un environnement conçu pour être éphémère. Les PersistentVolumes et les PersistentVolumeClaims créent une abstraction entre le stockage physique et la consommation par les applications, prenant en charge le provisionnement dynamique via StorageClass. Les systèmes de stockage distribués tels que Ceph (Rook), GlusterFS et Longhorn implémentent la réplication multi-nœuds pour une haute disponibilité, avec des algorithmes de consensus pour la cohérence. La gestion inclut les snapshots et les sauvegardes incrémentielles, le redimensionnement dynamique des volumes et la migration de données à chaud entre les nœuds. Parmi les défis spécifiques, citons les scénarios de split-brain lors du partitionnement du réseau, l'optimisation des performances pour les IOPS/le débit, la gestion des domaines de défaillance pour le placement des réplicas et le chiffrement au repos et en transit. Les pilotes CSI (Container Storage Interface) doivent gérer les opérations d'attachement/détachement, la propagation des points de montage et les spécificités du système de fichiers. Le dépannage nécessite la compréhension des périphériques de stockage par blocs, du fonctionnement interne du système de fichiers, de l'impact de la latence réseau sur le consensus distribué et de la surveillance des indicateurs de stockage pour la planification de la capacité et l'optimisation des performances.

Sans parler de toute la charge mentale associée à la gestion des mises à jour , des problèmes de sécurité , de la gestion des secrets , des déploiements automatisés , des conteneurs de registre privés , etc.

YAML, ce langage non-langage

Le manifeste de la folie Kubernetes s'incarne dans son utilisation extrême du format YAML. L'idée était de « décrire l'infrastructure », et non de la codifier. Mais comme souvent, la théorie s'est heurtée à la réalité : les fichiers YAML sont devenus longs, complexes, remplis de propriétés obligatoires et de sémantique implicite. Modifier une simple virgule pouvait entraîner la panne de tout un cluster.

Plus important encore, chaque fichier YAML dépend étroitement du comportement de l'image Docker sous-jacente. Or, cette image repose sur une ou plusieurs couches de système de fichiers issues d'une distribution Linux dont on ignore la provenance, avec des configurations souvent opaques. Résultat ? Un véritable labyrinthe d'abstractions , où il devient extrêmement difficile de prédire avec exactitude ce qui se passera lors du déploiement.

Un microservice, mille problèmes

Quiconque pensait que Kubernetes était la solution miracle pour la gestion des architectures de microservices devrait y réfléchir à deux fois. Car chaque nouveau microservice est un nouveau conteneur, avec son propre cycle de vie, sa propre configuration, son propre ensemble de variables d'environnement, son propre fichier YAML et sa propre politique réseau.

Chaque conteneur devient potentiellement une nouvelle bombe à retardement . Et qui la déclenche ? Le développeur.

Car ce sont les développeurs, et non les administrateurs système, qui préparent les images système. Or, dans la plupart des cas, les développeurs ne possèdent pas l'expertise système nécessaire pour créer un environnement sécurisé, stable et maintenable. Ils ignorent comment isoler correctement les processus, gérer les variables sensibles ou mettre en œuvre des mécanismes de journalisation ou de surveillance persistants.

Et ainsi, peu à peu, toute l'architecture se trouve parsemée de points faibles. Ce n'est plus une question de savoir si, mais quand, quelque chose explosera.

L'illusion du cloud natif

À tout cela s’ajoute un autre malentendu : la rhétorique du « cloud-native ».

Tout le monde aspire à une architecture cloud-native. Pourtant, peu savent réellement ce que cela implique. Être cloud-native ne se résume pas à placer Laravel dans un conteneur et à le qualifier de microservice. Cela implique de repenser entièrement la manière dont vous développez vos applications.

• Piloté par les événements, non synchrone.

• Apatride par conception.

• Centré sur l'API.

• Tolérant aux pannes.

• Dynamiquement évolutif.

• Avec journalisation et observabilité natives, non collées par la suite.

On ne peut pas obtenir tout cela en plaçant un monolithe dans un conteneur et en l'alimentant avec Kubernetes. Pourtant, c'est exactement ce que font beaucoup. Car l'illusion est que Kubernetes « gère tout ». Mais Kubernetes ne réfléchit pas. Kubernetes exécute. Mal, s'il est mal configuré. Et il est souvent mal configuré, car il est trop complexe pour être correctement configuré par des non-spécialistes.

Débogage : l'enfer sur Terre

Un exemple parmi tant d’autres : le débogage.

Avez-vous déjà essayé de dépanner un véritable cluster Kubernetes en production, avec dix pods en cours d'exécution, des journaux dispersés sur un millier de nœuds, des conteneurs redémarrant sans journaux, des métriques disparaissant et votre seul outil est un kubectl describe ou kubectl logs qui souvent ne donne rien en retour ?

Avez-vous déjà essayé de monter dans un conteneur écrasé, peut-être basé sur Alpine, sans bashsans vi, sans outils d'analyse, sans rien ?

Si vous ne l'avez pas fait, je vous envie . Si vous l'avez fait, vous savez exactement de quoi je parle.

Kubernetes n'est pas un environnement conçu pour le dépannage. C'est un système qui part du principe que tout se passera bien , que tout est idempotent et que les pods peuvent être arrêtés et reconstruits sans état. Mais la réalité est tout autre. Elle est faite d'exceptions, d'erreurs et de situations imprévues. Et dans ces moments-là, Kubernetes ne vous aide pas : il vous complique la tâche.

Et maintenant vient l'IA

Alors qu'il était autrefois possible de faire comme si de rien n'était (créer deux conteneurs, utiliser Kubernetes comme un faux orchestrateur de microservices et passer le reste du temps à corriger les problèmes), ce n'est plus possible.

L’intelligence artificielle a changé les règles du jeu.

Les applications d'IA modernes sont véritablement natives du cloud . Elles sont composées de dizaines d'API qui communiquent entre elles, souvent via du streaming, avec gestion du GPU, modèles chargés en mémoire, orchestration dynamique, journalisation intensive, audit, observabilité et mises à jour constantes.

L'improvisation n'est plus de mise. On ne peut plus se contenter de jeter quelques conteneurs sur un cluster et de croiser les doigts. Il vous faut une infrastructure robuste, conçue pour gérer la complexité du monde réel, mais avec des outils qui ne vous mettront pas à rude épreuve à chaque modification.

C’est pourquoi de plus en plus d’entreprises recherchent des alternatives . Elles veulent simplifier. Elles veulent revenir à un modèle logique, gérable par des équipes humaines sans avoir à devenir des experts Kubernetes. Elles veulent un environnement stable, prévisible et facile à maintenir.

L'avenir ? Moins d'orchestration, plus de standards

Le signal est clair : la bonne direction n’est pas d’ajouter des couches supplémentaires à Kubernetes (plateformes PaaS, maillages de services, outils de gestion YAML, interfaces graphiques… que de la poudre aux yeux), mais de réduire la complexité , en partant chaque fois que cela est possible d’une base plus simple, standardisée et sans serveur.

Il n'est pas nécessaire de tout orchestrer. Il suffit d'orchestrer efficacement ce dont vous avez réellement besoin , de manière reproductible et automatique, en permettant à la plupart des charges de travail de se comporter comme des services découplés et sans état, résilients par conception.

Conclusion : Il est temps de se réveiller

Kubernetes m'a permis de comprendre la complexité de l'orchestration à grande échelle. Mais ce n'est pas une solution universelle . Et surtout, ce n'est pas la seule solution possible . C'est un système conçu pour répondre aux besoins spécifiques des grandes entreprises, avec des équipes spécialisées et des processus internes extrêmement rigides.

La plupart des entreprises n'ont pas besoin de Kubernetes . Elles recherchent des environnements plus simples, plus humains et plus standardisés, où développeurs et administrateurs système peuvent collaborer sans le risque constant de créer des architectures ingérables.

C’est pourquoi aujourd’hui, quand vous dites à une équipe qu’elle peut créer une IA native du cloud privé sans avoir à subir les difficultés de Kubernetes, elle vous regarde avec émerveillement. Et puis, elle sabre le champagne.

Car enfin — après des années de battage médiatique, de complications, de YAML infernal et de pods fantômes — quelqu'un a eu le courage de dire la vérité : Kubernetes n'est pas l'avenir. Ce n'était qu'un incident passager.