Ce que les entretiens d’embauche m’ont appris sur Kubernetes

• Kubernetes est adopté même dans les petites entreprises moins comme réponse à des besoins de scalabilité technique que comme standard pour uniformiser les modes de déploiement et résoudre des problèmes d’organisation
• Toutes les entreprises avec lesquelles j’ai échangé récemment pendant ma recherche d’emploi utilisaient Kubernetes, contrairement à la coexistence d’il y a cinq ans entre VM·serverless·K8s
• Les principales raisons citées par les CTO étaient de déployer tous les services de la même manière, de consigner le savoir opérationnel dans les YAML et les charts Helm, et de suivre l’historique des changements avec GitOps
• Les petites entreprises acceptent la complexité de Kubernetes moins pour ses fonctions avancées comme HPA, Pod Disruption Budget ou l’affinité de nœuds que pour ses avantages organisationnels
• Pour une entreprise en phase initiale, il vaut mieux souvent démarrer sans Kubernetes afin de rester concentré sur le produit, puis le besoin d’adoption augmente à partir du moment où le CTO n’assure plus seul toute l’ingénierie

---

Les changements observés dans ma récente recherche d’emploi

• En lisant des offres, en passant des entretiens et en parlant avec une douzaine d’équipes d’ingénierie, j’ai constaté que toutes les entreprises avec lesquelles j’ai échangé utilisaient Kubernetes
• Lors de ma recherche d’emploi il y a cinq ans, coexistaient encore un groupe qui utilisait rarement Kubernetes, un groupe fonctionnant avec systemd sur des VM/VPS/EC2, et un groupe serverless avec Lambda et Cloud Run
• Là où je travaille actuellement, les problèmes sont d’une échelle Big Tech, donc Kubernetes est clairement adapté, mais j’ai été surpris de voir des startups d’une dizaine de personnes avec seulement deux services l’utiliser aussi
• Les entreprises avec lesquelles j’ai parlé n’opéraient ni de véritables architectures microservices ni des environnements proches d’une très grande échelle, et elles ne montraient pas un grand intérêt pour les aspects techniques de Kubernetes

Pourquoi Kubernetes est adopté et selon quels critères

• Pourquoi utiliser Kubernetes

  • La première raison était l’uniformité : si tous les services sont déployés de la même manière, on évite qu’un service particulier reste coincé sur une vieille VM bare metal avec des scripts bash ou sur Docker Compose
  • La deuxième raison était un savoir partageable et recrutable : Kubernetes sert de langage commun, et il suffit souvent de regarder les charts Helm et la configuration Kube pour comprendre rapidement l’architecture
  • Si le savoir n’est pas seulement dans la tête des gens mais consigné dans le YAML, cela réduit les cas où un successeur doit passer des semaines à comprendre comment exécuter un système après le départ de quelqu’un
  • Dans mon entreprise actuelle, l’astreinte SRE peut maintenir même des services qu’elle ne connaît pas, parce que les patterns Kubernetes restent similaires d’une équipe à l’autre
  • Cet avantage ne tient toutefois que si la configuration n’est pas excessivement atypique
  • La troisième raison était la traçabilité : au lieu d’exécuter directement kubectl apply -f sur le cluster, on pousse les charts Helm dans git, puis on passe par l’approbation d’une MR et un déploiement via FluxCD ou ArgoCD, ce qui laisse un historique des changements
  • Ce flux aide presque sans coût supplémentaire à la conformité, car GitOps et Kubernetes s’articulent naturellement ensemble
  • Mon entreprise actuelle obtient de bons résultats aux certifications ISO avec cette approche

• Conclusion tirée

  • Les choix des CTO n’étaient pas absurdes : c’étaient des moyens de résoudre de vrais problèmes
  • Kubernetes me semblait être une solution technique à un problème technique, mais beaucoup de CTO s’intéressaient davantage que prévu à ses avantages non techniques
  • Les problèmes techniques des petites entreprises ne sont généralement pas au point de rendre Kubernetes indispensable, et il est probable que leurs manifestes n’incluent ni topologySpreadConstraints, ni HPA, ni Pod Disruption Budget, ni règles d’affinité de nœuds
  • Elles conservent à peu près le même nombre de nœuds qu’avec des VM, tout en acceptant le coût d’exploitation d’un logiciel complexe pour bénéficier de ses avantages organisationnels

• Pourquoi cette bascule s’est-elle produite récemment ?

  • Il y a cinq ans, VM + systemd, serverless et Kubernetes restaient tous des options, mais aujourd’hui la combinaison VM + systemd a presque disparu des offres d’emploi, le serverless est resté une niche, et Kubernetes a gagné
  • Les raisons exactes de ce basculement ne sont pas totalement certaines
  • Une explication possible est que les Kubernetes managés comme EKS, GKE et AKS ont mûri, et qu’il y a désormais suffisamment de personnes formées à Kubernetes pour que recruter sur d’autres approches soit devenu plus difficile
  • Helm a aussi rendu réaliste l’option consistant à reprendre tel quel un chart créé par d’autres

• Quand utiliser Kubernetes

  • Mon critère personnel, c’est le moment où le CTO n’est plus l’unique ingénieur
  • Dès qu’un deuxième ingénieur rejoint l’équipe, il faut qu’une personne qui n’a pas configuré les serveurs elle-même puisse déployer, et il devient nécessaire d’avoir un contrôle d’accès adapté plutôt que de distribuer des clés SSH pour tout
  • Au final, quelqu’un finit toujours par quitter l’entreprise, et le savoir opérationnel détenu par cette personne peut partir avec elle
  • À partir de là, le savoir doit rester dans le système plutôt que chez les personnes
  • Avant ce stade, le débogage d’un cluster est réellement difficile, et l’énergie qui devrait aller au produit peut partir dans l’infrastructure
  • Juste avant un appel avec un gros client, au lieu de passer deux heures à chercher pourquoi un pod est en CrashLoopBackOff, il peut être plus rapide et plus compréhensible en situation d’urgence de corriger à la hâte avec un git pull sur un VPS

[GN⁺]

Avis sur Lobste.rs

• En Europe, la raison est assez claire. Les CTO croient que si on le met sur K8s, on pourra changer de fournisseur de K8s managé en quelques semaines
  Ce n’est pas forcément vrai, mais c’est réellement ce qu’ils croient. Ils pensent aussi que les environnements de PR deviennent plus simples
  Mais le point central, c’est le changement de fournisseur. Ils s’attendent à ce qu’au cours des prochaines années, l’usage de fournisseurs liés aux États-Unis soit interdit, surtout dans le cadre du RGPD, des systèmes financiers, etc. Donc ils se sont préparés à ce risque

• Cela ressemble à une preuve que l’industrie tech a complètement perdu le nord, quelle que soit la taille de l’entreprise. La stack est devenue de plus en plus uniforme et complexe, et au final il devient plus difficile de trouver des produits et services qu’on peut utiliser sans serrer les dents

  • Les couches de bas niveau sont tellement pleines de bugs et compliquées que, pour survivre, on finit presque forcément par construire quelque chose comme Kubernetes. Si on veut empêcher la stack de monter encore plus haut, il faut améliorer les couches inférieures
    Il faut de bien meilleurs fondamentaux du système d’exploitation. Par exemple, les conteneurs ont longtemps été un assemblage bancal de plusieurs mécanismes d’isolation du noyau, sans conception cohérente, donc avec beaucoup de failles
    L’isolation des conteneurs s’est nettement améliorée aujourd’hui, mais ce n’était pas pensé dès le départ pour la sécurité et la robustesse : cela a surtout été corrigé au coup par coup. Tant que le noyau n’aura pas absorbé cette énorme dette technique, ou que quelqu’un n’aura pas créé un noyau vers lequel les gens auront envie de migrer, on continuera à empiler des choses par-dessus

• Tout outil de déploiement suffisamment complexe finit par inclure une demi-implémentation de Kubernetes, faite comme un pis-aller, définie de manière informelle, pleine de bugs et lente

  • Le mot « demi » est juste. C’est simplement que cette moitié est justement la moitié dont on a besoin
    Je pourrais parler longuement de la façon dont on organisait en 2009 une société SaaS e-commerce valorisée à un milliard de dollars, ou du fonctionnement des backends en ligne de très gros jeux AAA multijoueurs : c’était clairement plus proche de Kubernetes que d’un déploiement sur machine unique
    Mais c’était plus rapide, et l’approche était fortement opinionated exactement dans le sens dont l’organisation avait besoin, pas d’une manière qui entrait en conflit avec les exigences produit
    Le côté « plein de bugs » de Kubernetes vient souvent moins du système central lui-même que des nombreuses couches d’interface qu’on ajoute par-dessus pour le faire fonctionner comme on le souhaite
  • Ça s’applique à Erlang, pas à Kubernetes. Pour Kubernetes, ça n’a aucun sens

• Le problème, c’est que la plupart des organisations adoptent K8s à moitié, mettent en place une équipe DevOps pour le gérer, puis finissent quand même par faire porter aux ingénieurs logiciel tout ce qui touche à K8s : écriture, déploiement, débogage et exploitation
  Une bonne équipe DevOps devrait fournir en interne une expérience de type Heroku. On devrait définir les ressources nécessaires, fusionner dans main, et le déploiement devrait se faire, au lieu d’errer dans un tableau de bord GitOps/DevOps médiocre pour comprendre ce qui a cassé
  Heroku représentait, à mes yeux, le sommet de l’expérience développeur, et on a perdu cela après K8s

  • À part le fait de voir les Pods tourner sur des nœuds, je ne vois pas vraiment la grande différence entre l’expérience d’usage de Heroku et celle de Kubernetes
    Bien sûr, Heroku offre une expérience plus intégrée pour la base de données ou le déploiement par git push, mais construire une surcouche personnalisée au-dessus de Kubernetes me semble peu pertinent. On finit de toute façon par exposer tous les paramètres tels quels

• Dans l’industrie, l’adoption technologique suit toujours le principe du « on recrute du prêt-à-porter, et on licencie ce qui ne sert pas ». Ce n’en est qu’un exemple de plus

• La phrase « la connaissance doit être dans le système, pas dans les personnes » exprime très bien quelque chose que j’avais en tête de manière diffuse
  Ce genre de formalisation n’est possible que lorsque la variabilité du processus diminue. On commence par le faire à la main, puis on documente le processus, on l’écrit en script, puis on l’automatise
  Dans les workflows courants des outils ou écosystèmes populaires, on obtient presque gratuitement la plupart de ces étapes

• Je ne fais pas énormément de DevOps, et aujourd’hui le système tourne très bien avec systemd et quelques conteneurs podman utilisés de temps en temps. Je travaille dans l’IoT/AgTech
  Il y a dans ce texte un type d’« affirmation » que j’entends souvent de la part de dirigeants non techniques. En gros : « eux aussi font du LoRa, non ? Donc c’est bon ? On peut lancer demain, alors ? »
  Il y a cette croyance selon laquelle l’hétérogénéité est le seul obstacle au succès. Si deux systèmes utilisent Fiber, Modbus, ou « ont une API », alors on pourrait les brancher ensemble immédiatement pour créer cette belle expérience où « 1 + 1 fait plus que la somme »
  Mais le simple fait que deux logiciels s’accordent sur des standards d’interopérabilité de bas niveau ne fait pas disparaître le vrai travail qui consiste à décider comment interpréter et utiliser utilement des données faciles à parser
  Ce n’est pas parce que deux personnes parlent la même langue qu’il n’y a plus de travail à faire. Le fait d’utiliser une langue commune n’efface pas non plus les décisions prises par une partie de l’équipe avec cet outil dans les conditions qu’elle connaissait à ce moment-là
  Aux débuts, dans les milieux scientifiques et de l’ingénierie, Fortran était une langue commune, mais cela n’a pas empêché qu’on soit complètement déconcerté par le travail des collègues ou qu’on doive le réécrire
  Je n’ai rien contre la valeur de K8s ni contre son statut actuel de « standard ». Mais j’ai du mal à accepter l’idée que cela fasse disparaître certains types de problèmes de programmation. La loi de conservation de la laideur est toujours là

• Kubernetes est une plateforme de déploiement correcte

• Le mode de distribution est aussi une autre raison. Je travaille sur des nœuds Canton, et le logiciel Canton amont ainsi que les applications associées sont fournis sous forme de charts Helm
  Que Kubernetes soit ou non adapté à notre travail — et je pense que non — le logiciel est distribué et supporté comme ça. Si on sort de cette voie, cela représente encore plus de travail que de simplement gérer Kubernetes

• Je ne sais pas si je suis le seul, mais ce texte donne vraiment l’impression d’avoir été écrit par une IA
  Cela dit, je suis d’accord avec l’idée générale. Je suis en train de migrer des configurations de homelab/self-hosting qui reposaient sur des réglages systemd personnalisés, des commandes shell dont je ne me souviens plus, et des « bon sang, dans quel fichier Markdown j’avais noté cette procédure de configuration ? », et c’est vraiment rafraîchissant
  Je n’utilise pas encore un vrai système de déploiement continu, mais le fait d’avoir juste un petit script shell apply et un ensemble de fichiers YAML me donne la sensation qu’en cas de catastrophe, je pourrais récupérer 90 % de l’ensemble, et c’est appréciable
  systemd est conceptuellement simple, mais la reproductibilité y est compliquée, alors que Kubernetes, c’est l’inverse. On paie un coût conceptuel plus élevé, mais la reproductibilité et la compréhension qui l’accompagne sont bien plus solides. En tout cas, c’est ainsi que je le vois pour l’instant
  Je suis encore en phase d’apprentissage de Kubernetes, mais récemment je m’amuse plutôt bien avec

  • Il y a 10 ans, j’aurais été d’accord, mais aujourd’hui, avec les diverses options de namespace et l’intégration d’utilisateurs dynamiques, systemd me donne aussi l’impression d’être « un autre monstre »
    Ce type d’intégration verticale avec des définitions de premier ordre ressemble à une mauvaise direction
  • Le fait que ce soit écrit par une IA n’a pas beaucoup d’importance. Ce qui compte, c’est si c’est bien écrit ou non