Kubernetes : le grand bluff DevOps

Kubernetes 2 arrive bientôt. Et, comme prévu, nous dirons enfin adieu à YAML. Ce sera aussi l'occasion d'admettre, sans trop de subtilité, que Kubernetes était — et est toujours — un désordre ingérableNon pas une innovation, mais un enchevêtrement technique élevé au rang de norme, sans que personne n'ait jamais le courage de s'arrêter et de dire : « Attendez, est-ce que tout cela a vraiment du sens ? ».

La vérité est que Kubernetes n'a jamais été conçu pour les gens ordinaires, pour les développeurs ordinaires, pour ceux qui gèrent de vrais projets avec des budgets, des délais et des environnements de production à maintenir en activité 24h/7 et XNUMXj/XNUMX. Kubernetes a été conçu par une élite technique — principalement d'anciens ingénieurs de Google — qui a tenté de reproduire en dehors de Google certains concepts empruntés à Borg, le système d'orchestration interne de l'entreprise. Dommage que Borg est un système conçu pour une échelle que la plupart des entreprises n'atteindront jamais, même de loin. Et cela le reproduire mal en dehors de ce contexte, cela n’a conduit à aucune révolution, mais seulement à une plus grande complexité.

Docker et le mythe du mini-cloud DIY

Pour comprendre d'où vient la confusion, revenons un instant en arrière. Docker était logique à sa naissance : c'était un raccourci pour éviter le coût des machines virtuelles, gérer les environnements pseudo-isolés plus facilement. Bien. Mais ensuite est arrivée la grande illusion : la possibilité de construire un mini-cloud « à la manière des grands » en utilisant simplement du YAML et un peu de scripting.

Et c'est là que le château s'est effondré. Pourquoi créer et gérer un environnement conteneurisé, orchestré par Kubernetes ? ce n'est pas simple du tout, ni même automatique. Cela requiert des compétences que tout le monde ne possède pas. En effet, cela requiert une quantité impressionnante de connaissances interdisciplinaires:

• Sémantique de Kubernetes, ce qui est incroyablement complexe. La sémantique de Kubernetes 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 un univers complet 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 propres états, conditions et finaliseur. La complexité est amplifiée par 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 ramasse-miettes gère les dépendances propriétaire-référence. Le modèle déclaratif exige une approche complètement différente de la gestion impérative traditionnelle, où l'on décrit l'état souhaité plutôt que les étapes pour l'atteindre.

• Réseau TCP/IP À un niveau plus profond, avec des superpositions, des plugins, des maillages de services et un DNS interne. La mise en réseau dans Kubernetes repose sur plusieurs couches d'abstraction qui nécessitent une compréhension approfondie de la pile TCP/IP. Les réseaux superposés comme Flannel, Calico et Weave créent des réseaux virtuels qui s'étendent sur des nœuds physiques, grâce à des technologies comme 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 introduisent une complexité supplémentaire avec des proxys side-car qui interceptent tout le trafic, implémentant un équilibrage de charge avancé, des coupures de circuit, des politiques de nouvelle tentative et le protocole TLS mutuel. Le DNS interne (CoreDNS) doit résoudre la découverte dynamique de services, gérer le fractionnement de zones et se synchroniser avec les registres de services externes. Le dépannage requiert une expertise en capture de paquets, analyse des chaînes iptables, compréhension des hooks netfilter et débogage des tables de connexion.

• Systèmes Linux Avancé : débogage dans les conteneurs, traçage des processus zombies et dépannage des pods qui ne démarrent pas sans logique apparente. Sous AlmaLinux, la gestion du système Kubernetes nécessite une expertise Linux au niveau du noyau appliquée aux environnements conteneurisés. Le débogage dans les conteneurs implique l'isolation des espaces de noms (PID, NET, MNT, IPC, UTS, USER), les cgroups v1/v2 pour la limitation des ressources et les capacités de gestion des limites de sécurité. Les processus zombies dans les conteneurs nécessitent une compréhension des systèmes d'initialisation (souvent tini ou dumb-init), de la gestion des signaux et de la récupération des processus. Lorsque les pods ne démarrent pas sans logique apparente, vous devez analyser : les journaux kubelet, l'état d'exécution du conteneur (containerd/CRI-O), les profils seccomp, les politiques AppArmor/SELinux sous AlmaLinux, les quotas de ressources et les règles d'affinité/anti-affinité des nœuds. Les outils essentiels incluent nsenter pour la saisie d'espace de noms, crictl pour le débogage CRI, systemd-analyze pour les 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 ajoute une complexité supplémentaire.

• Stockage distribué, réplication de volumes et persistance des données volatiles dans des environnements éphémères. Le stockage distribué dans Kubernetes répond au défi fondamental de maintenir la persistance dans un environnement conçu pour l'éphémère. Les PersistentVolumes et les PersistentVolumeClaims créent une abstraction entre le stockage physique et la consommation des 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 comprend les snapshots et les sauvegardes incrémentielles, le redimensionnement dynamique des volumes et la migration des données en temps réel entre les nœuds. Les défis spécifiques incluent les scénarios de split-brain pour le partitionnement réseau, l'optimisation des performances pour les IOPS/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 montages et les spécificités du système de fichiers. Le dépannage nécessite de comprendre les périphériques de blocs, les composants internes du système de fichiers, l'impact de la latence du réseau sur le consensus distribué et la surveillance des mesures de stockage pour la planification de la capacité et l'optimisation des performances.

Sans oublier toute la charge mentale liée à la gestion des mises à jourà problèmes de sécurité, La gestion des secretsà déploiements automatisésà conteneurs de registre privés et plus vous le mettez.

YAML, ce langage non-langage

La folie de 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, alambiqués, truffés de propriétés obligatoires et de sémantique implicite. Changer une virgule peut signifier la chute d'un cluster entier.

Et surtout, chaque fichier YAML dépend étroitement du comportement de l'image Docker sous-jacente. Cette image, à son tour, repose sur une ou plusieurs couches de système de fichiers dérivées d'on ne sait quelle distribution Linux, avec des configurations souvent opaques. Le résultat ? Un délire d'abstractions, où il est très difficile de prédire exactement ce qui se passera lorsque vous lancerez votre déploiement.

Un microservice, mille problèmes

Ceux qui pensaient que Kubernetes était la solution miracle pour gérer les architectures de microservices devraient réfléchir. 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, sa propre politique réseau.

Chaque conteneur devient potentiellement un nouvelle bombe à retardementEt qui le déclenche ? Le développeur.

Car ce sont les développeurs qui préparent les images, pas les administrateurs système. Mais dans la plupart des cas… les développeurs n'ont pas les compétences système nécessaires Pour assurer la sécurité, la stabilité et la maintenabilité du travail, ils ne savent pas comment isoler correctement les processus, gérer les variables sensibles ni mettre en œuvre des mécanismes de journalisation ou de surveillance persistants.

Et ainsi, petit à petit, toute l’architecture se remplit de points faibles. Ce n'est pas une question de si, mais de quand quelque chose va exploser.

L'illusion du cloud natif

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

Tout le monde rêve d'être cloud-native. Mais peu savent ce que cela signifie réellement. Être cloud-native ne signifie pas mettre Laravel dans un conteneur et l'appeler un microservice. Cela signifie repenser complètement la façon dont vous créez des 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.

Tout cela vous n'obtenez pas cela en mettant un monolithe dans un conteneur et l'alimenter avec Kubernetes. Pourtant, c'est exactement ce que font beaucoup. Car on a l'illusion que Kubernetes « s'occupera de tout ». Mais Kubernetes ne pense pas. Kubernetes exécute. Mal, s'il est mal configuré. Et il est souvent mal configuré, car Il est trop complexe pour être configuré correctement 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 déjà fait, Je t'envie. Si vous l'avez fait, tu sais 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 ira bien, que tout est idempotent, que les pods peuvent être détruits et reconstruits sans état. Mais la réalité est différente. Elle est faite d'exceptions, d'erreurs, de conditions imprévues. Et à ce moment-là, Kubernetes ne vous aide pas : il vous gêne..

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 modernes de l’IA sont cloud-native pour de vraiIls sont constitués de dizaines d'API qui communiquent entre elles, souvent en streaming, avec gestion du GPU, modèles à charger en mémoire, orchestration dynamique, journalisation intensive, audit, observabilité et mise à jour constante.

On ne peut pas improviser. Il ne suffit plus de placer quelques conteneurs sur un cluster et de croiser les doigts. Il vous faut une infrastructure solide, conçue pour gérer la complexité du monde réel, mais dotée d'outils qui ne vous ruineront pas à chaque modification.

Et c'est pourquoi de plus en plus d'entreprises recherchent des alternativesIls veulent simplifier. Ils veulent revenir à un modèle cohérent, gérable par des équipes humaines sans avoir à devenir des ninjas de Kubernetes. Ils veulent un environnement stable, prévisible et maintenable.

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

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

Il n’est pas nécessaire de tout orchestrer. bien orchestrer ce qui est vraiment nécessaire, de manière répétable et automatique, 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 difficulté d'une orchestration à grande échelle. ce n'est pas une solution pour tout le monde. Et particulièrement, ce n'est pas la seule solution possibleC'est un système né des besoins spécifiques des grandes entreprises, avec des équipes spécialisées et des processus internes extrêmement rigides.

La plupart des entreprises n'a pas besoin de KubernetesIl faut des environnements plus simples, plus humains et plus standardisés, où développeurs et ingénieurs système peuvent collaborer sans risque constant de créer des architectures ingérables.

Pour cela, aujourd'hui, Quand vous dites à une équipe qu'elle peut créer une IA native du cloud privé sans passer par l'enfer de Kubernetes, elle vous regarde avec stupeur. Et puis, elle ouvre le champagne.

Parce que finalement — après des années de battage médiatique, de complications, de YAML infernaux et de pods fantômes — quelqu'un a eu le courage de dire la véritéKubernetes n'est pas l'avenir. C'était un contretemps.