À quoi pourrait ressembler Kubernetes 2.0

• Kubernetes a mené l’innovation de l’orchestration de conteneurs au cours des dix dernières années
• Plusieurs limites et besoins d’amélioration ont été observés dans la configuration YAML, la dépendance à etcd et la gestion des paquets avec Helm, entre autres
• L’adoption de HCL, un stockage modulaire, un nouveau gestionnaire de paquets (KubePkg), IPv6 par défaut, etc. sont évoqués comme éléments de changement pour Kubernetes 2.0
• La structure ouverte actuelle reste importante, mais les valeurs par défaut et une orientation officielle claire ont un impact décisif sur l’innovation de l’écosystème
• Il apparaît nécessaire que Kubernetes devienne adapté à un plus large éventail d’utilisateurs et d’organisations grâce à une amélioration disruptive continue

---

Dix ans de Kubernetes : succès et limites

Débuts et croissance

• En 2012~2013, des rumeurs sur Borg, le système interne de conteneurs Linux de Google, ont commencé à circuler dans la communauté des sysadmins
• En 2014, Kubernetes a été rendu public, et même son nom était alors difficile à prononcer
• Microsoft, RedHat, IBM, Docker et d’autres grands acteurs l’ont rapidement rejoint, et Kubernetes a commencé à s’imposer comme standard de l’écosystème
• En 2015, la publication de la v1.0 et la création de la CNCF ont véritablement lancé un écosystème ouvert

Principales innovations

Gestion des conteneurs à grande échelle

• Kubernetes apporte la scalabilité du développement et du déploiement de logiciels basés sur des conteneurs
• Il permet des déploiements homogènes à grande échelle, depuis un simple environnement de développement jusqu’à des milliers de serveurs
• Les organisations ont ainsi pu amorcer leur transition d’architectures monolithiques vers des microservices distribués

Maintenance à faible coût et auto-réparation

• L’administration des serveurs est passée brutalement de l’ère "Simpsons" (chaque serveur a un surnom, exploitation manuelle) à l’ère "UUID" (remplacement complet, automatisation, absence d’état)
• Les notions de durée de vie des machines et de période de support de l’OS ont quasiment disparu, les pannes étant traitées par une recréation du nœud
• De nombreuses compétences Linux sont désormais passées du statut d’indispensables à celui d’atouts simplement appréciés

Traitements batch et gestion des Jobs

• Le batch processing, autrefois dépendant de "boîtes dédiées à cron", a été remplacé par des automatisations basées sur des files d’attente et des mécanismes de retry
• Le redémarrage automatique en cas d’échec et la flexibilité de traitement ont fortement amélioré l’efficacité opérationnelle et la satisfaction des développeurs

Service discovery et load balancing

• Au lieu du codage en dur des adresses IP, un système de nommage de services fondé sur le DNS interne a été introduit
• Les API, IP fixes et noms d’hôte simplifient les connexions entre services et permettent de traiter les services externes comme s’ils étaient internes

Kubernetes 2.0 : propositions d’amélioration clés

De YAML à HCL : changer de langage de configuration

Les limites de YAML

• YAML est agréable à lire et semble préférable à JSON ou XML, mais présente de sérieux problèmes : source d’erreurs, absence de typage, débogage difficile, etc.
• Exemples : le problème norvégien (NO interprété comme false), les erreurs d’indentation, la confusion entre chaînes et nombres, et bien d’autres causes d’incident

Alternative : adopter HCL

• HCL (HashiCorp Configuration Language), format standard de Terraform, offre d’excellentes fonctionnalités comme le typage fort, la validation, les fonctions et les branchements conditionnels
• Une part importante des clusters Kubernetes utilise déjà HCL avec Terraform
• HCL propose des capacités plus puissantes que YAML : sûreté de typage, réduction des duplications, configuration dynamique, itération, logique conditionnelle, excellent support des commentaires, modularité et validation
• Le sujet des licences open source (MPL 2.0 → compatibilité avec Apache 2.0) reste en suspens, mais l’intérêt en matière de qualité est jugé suffisant

Exemple : HCL vs YAML

• Grâce aux avantages de HCL en matière de types, variables, fonctions, conditions et boucles, il devient possible de prévenir les erreurs de configuration, d’améliorer la maintenabilité et de garantir la cohérence même dans des environnements complexes

Prise en charge d’alternatives à etcd

• etcd est puissant, mais sa consommation de ressources peut être excessive pour de petits clusters ou des environnements peu dotés
• La nécessité d’élargir la souplesse du stockage par défaut est soulevée via un support officiel de backends modulaires comme Kine
• Exemple : k8s-dqlite, qui fournit une couche de données légère et flexible avec SQLite distribué + Raft

Au-delà de Helm : un gestionnaire de paquets natif

Les limites de Helm

• Helm est un cas où une solution de contournement temporaire est devenue un standard, avec divers problèmes : complexité des templates, difficulté du débogage, conflits de dépendances et de versions, validation insuffisante, etc.
• En pratique, de nombreuses difficultés apparaissent : duplication de charts, incohérences de versions, installations compliquées entre namespaces, absence de recherche de charts et de métadonnées, non-respect du versioning sémantique, gestion peu sûre des CRD

Proposition d’un nouveau système de paquets : KubePkg

• Gestion complète des paquets, dépendances, versioning sémantique, sécurité, cycle de vie et métadonnées sous forme de ressources Kubernetes
• Ensemble complet incluant des hooks de cycle de vie avancés, des stratégies d’état et de sauvegarde/restauration, une configuration déclarative, un processus de signature vérifiable, des traces d’audit et des contrôles de politiques organisationnelles
• L’objectif est d’hériter des atouts des gestionnaires de paquets Linux afin d’apporter une fiabilité et une cohérence solides à la gestion réelle de l’infrastructure

Principales exigences

1. Structure de ressources entièrement native Kubernetes
2. Prise en charge intégrée des applications à état
3. Renforcement des processus de signature, validation et security scanning
4. Configuration déclarative structurée + validation par schéma
5. Contrôle complet du cycle de vie et prise en charge simple des upgrades/hooks
6. Résolution des dépendances/versions à la manière de Linux
7. Historique des changements et piste d’audit
8. Possibilité d’appliquer des politiques propres à l’organisation
9. UX familière des gestionnaires de paquets Linux

Passage à IPv6 par défaut

• IPv6 et le dual stack sont déjà pris en charge, mais la valeur par défaut reste IPv4
• Cela permettrait de résoudre les communications inter-clusters, les problèmes de NAT et la pénurie d’IP, tout en offrant une architecture réseau plus simple et des avantages comme IPSec intégré
• Dans les environnements ayant de gros besoins en IP (ex. : plage en /20, 40 nœuds, 30 pods par nœud), les limites d’IPv4 sont vite atteintes
• Les bénéfices pratiques sont clairs : exploitation simplifiée dans les environnements IPv6 publics, meilleure attractivité pour les utilisateurs cloud, réduction de la charge de gestion des espaces privés

Conclusion : la nécessité du changement et la force des valeurs par défaut

• Certains estiment que, puisqu’il s’agit d’une "plateforme ouverte", la communauté se débrouillera, mais ce sont bien les valeurs par défaut qui orientent les pratiques du secteur
• Kubernetes 2.0 est arrivé à un moment où il lui faut des convictions officielles, une excellente conception et des valeurs par défaut fortes
• Pour un standard de l’industrie devenu central dans l’exploitation des datacenters à l’échelle mondiale, le moment est important pour un nouvel élan ambitieux
• Dans le mobile, le web et d’autres domaines techniques, l’innovation de l’écosystème a déjà souvent émergé grâce à des changements audacieux
• Il est désormais temps pour Kubernetes de réfléchir à la prochaine étape à travers un 2.0 marquant

[kaydash]

Je pense qu’il y aura encore peu d’ingénieurs capables de configurer et d’exploiter une stack vanilla k8s assemblée à partir d’open source.
Comme il y avait très peu d’ingénieurs capables d’exploiter un écosystème Hadoop vanilla, sans l’acheter sous forme de plateforme intégrée comme Cloudera.

[GN⁺]

Avis Hacker News

• À mon avis, le plus gros problème de Kubernetes, c’est que ce n’est pas un système qui « fonctionne tout simplement ». En pratique, seuls quelques ingénieurs sont capables d’exploiter un service en production sans difficulté, et construire puis maintenir soi-même un cluster Kubernetes sur des VM est encore plus compliqué. C’est aussi pour cela que les startups serverless qui montent attirent l’attention : Kubernetes est perçu comme (1) chronophage, (2) très sujet aux erreurs, et (3) fortement exposé à l’échec en production. Pour Kubernetes 2.0, je pense qu’il faut réfléchir à une direction où n’importe qui pourrait auto-héberger facilement une plateforme de déploiement et l’utiliser avec confiance, tout en conservant un cœur d’orchestrateur petit mais puissant. Je développe moi-même un orchestrateur et une plateforme de déploiement appelée Rivet, présentée comme la plateforme serverless open source Rivet, mais je me demande souvent : « à quoi ressemblerait Kubernetes 2.0 ? ». On voit aussi de plus en plus de cas où des gens adoptent Rivet pour des scénarios dépassant nos attentes initiales. Le plus grand point fort de Rivet, c’est qu’il permet de développer facilement des fonctionnalités du niveau d’un contrôleur Kubernetes, ce qui le rend exploitable pour des scénarios variés : serveurs de jeu, déploiements par tenant, orchestration avancée de workloads, multi-tenant, facturation par tenant, conception d’opérateurs puissants, etc.

  • Cette perspective me rebute franchement. Peut-être parce que je suis plus âgé et un peu cynique, mais c’est un schéma qu’on voit souvent. La techno X est trop lourde, alors quelqu’un dit : « moi je veux juste faire tourner ça simplement sur mon laptop » et crée la techno Y. Puis Y devient populaire, on veut la faire tourner ailleurs que sur un laptop, il faut de la montée en charge, on ajoute plein de fonctionnalités, et ça devient lourd. Alors quelqu’un d’autre dit : « maintenant Y est trop lourde aussi », et le cycle recommence. C’est comme une roue du temps : une histoire sans début ni fin qui se répète.

  • En réalité, k3s (un k8s léger) est vraiment facile à maintenir. Avec les mises à jour automatiques de k3s et des règles d’eviction adaptées, il y a très peu à faire, et si un stockage comme Ceph paraît trop complexe, on peut choisir des alternatives « zéro gestion » comme Lemon ou Longhorn. Il existe des milliers de charts Helm, donc même une base de données complexe peut être déployée en une minute. Déployer des services est aussi très simple si on utilise les templates Helm les plus courants. Helm n’est pas parfait, mais si on configure comme il faut, on peut profiter d’outils comme l’autocomplétion des valeurs. La barrière d’entrée est un peu plus haute qu’avec le serverless, mais apprendre ça en une semaine pour économiser des dizaines de milliers d’euros en production, ça vaut largement le coup.

  • Le problème que Kubernetes résout, c’est « comment déployer ça ? ». En regardant la doc de Rivet, je ne vois que conteneur unique, Docker Compose et déploiement manuel (commandes Docker). Je doute qu’on puisse réellement déployer une infrastructure serverless à l’échelle de cette façon. Ma première question est : « à ce stade, pourquoi ne pas faire tourner Rivet sur Kubernetes (conteneurs, kube-virt, etc.) ? ». Je ne vois pas en quoi Docker Compose pourrait être plus robuste ou plus scalable que Kubernetes. Et si l’idée est de vendre un service cloud, alors ça ne colle pas non plus au concept de Kubernetes 2.0. Si j’auto-hébergeais Rivet, je modifierais probablement la documentation pour permettre de le faire tourner sur Kubernetes.

  • Si l’on utilise du « k8s as a service » en externalisant la maintenance du cluster au cloud provider, je me demande ce qui paraît si compliqué. Le champ des configurations est large, mais pour déployer un service réel en production, il suffit de connaître un petit nombre de paramètres. Un niveau de configuration à peine plus complexe que Docker Compose suffit largement pour déployer sur k8s. Mais pour la plupart des applications, même ce « petit plus » peut être inutile. En fait, c’est exactement au besoin grand public auquel Docker Compose devait répondre, et c’est dommage qu’il n’ait pas bénéficié d’un intérêt soutenu.

  • D’après mon expérience, en exploitation d’infrastructure, le « ça marche tout seul » n’existe pas. Même Heroku a des problèmes à l’échelle. Si on veut une plateforme de déploiement que tout le monde puisse adopter facilement, il est plus réaliste de considérer Kubernetes comme une primitive de base pour un PaaS donné. Rivet est intéressant, assez original, et on y voit aussi quelques idées de l’écosystème BEAM. Personnellement, je m’intéresse davantage à la robustesse et au local-first qu’aux déploiements massifs.

• « Low maintenance »... J’utilise beaucoup EKS (k8s managé), et je n’ai pas besoin de surveiller l’état du cluster lui-même en direct — sauf si je trouve une façon inventive de casser mes nœuds. Kubernetes fait vraiment semblant d’être « aussi low maintenance que possible », alors qu’en réalité c’est un énorme bloc de maintenance pure. Le fait de pouvoir déployer un logiciel dans le monde entier juste en fournissant du YAML est extraordinaire. Mais le prix à payer, c’est justement une maintenance complexe. Le setup du cluster, l’initialisation d’ArgoCD, l’enregistrement d’autres clusters dans un modèle hub-and-spoke, tout cela relève déjà du numéro de cirque. Ensuite il faut encore installer des opérateurs utiles depuis le CNCF Landscape tooling, plus tout un ensemble d’outils annexes — pas primaires au sens strict, mais indispensables — et on en fait facilement tourner une trentaine. Configurer values.yaml, ce n’est pas une affaire d’une ou deux heures, et la plupart du temps on passe son temps sur ArgoCD et le templating. Secrets Manager -> External Secrets -> ArgoCD ApplicationSet -> Another values.yaml : on se retrouve souvent à perdre du temps juste pour faire passer un booléen. Le rythme des mises à jour de clusters et d’opérateurs est rapide, donc les problèmes de maintenance sont permanents. Et quand on autoscale avec Karpenter, le remplacement des nœuds et le zéro interruption deviennent un autre spectacle d’acrobatie à part entière — avec des applis stateful sur k8s, c’est encore deux fois plus drôle. En résumé : le vrai « low maintenance » est une expression ironique.

  • « Low maintenance » reste toujours une notion relative, définie par rapport aux alternatives. D’après mon expérience, avec k8s, la charge de maintenance pour obtenir le même niveau de qualité de service était bien plus faible sur l’ensemble : montée en charge, bascule en cas de panne, rollback, reprise après sinistre, DevOps, création de clusters indépendants, etc. Ça peut dépendre des cas, mais c’est ce que j’ai vécu.

  • J’utilise k3s sur Hetzner depuis deux ans et j’ai eu 100 % de disponibilité. La charge de maintenance est si faible qu’il m’est même arrivé de perdre la clé SSH du nœud maître, et reprovisionner tout le cluster n’a pris que 90 minutes, mise à jour de la documentation comprise. Si ça avait été vraiment urgent, 15 minutes auraient suffi. J’exploite un cluster k8s à 20 euros par mois, avec 3 nœuds ARM et 1 maître, un peu de stockage, et du DNS automatique relié à Cloudflare.

  • Mais en réalité, ce que tu administres, ce n’est pas Kubernetes en soi, c’est tout le système annexe : CI/CD, gestion des secrets, automatisation d’exploitation des bases de données, etc. Avant, on aurait fait ça avec des cronjobs, ansible, systemd, des scripts bash, au lieu de YAML.

  • On dirait que tu as construit toi-même ton propre chapiteau de cirque. Il ne faut pas installer autant de choses. Chaque ajout amène de la dette technique et des coûts de maintenance, même si l’outil est gratuit. Si l’autoscaling coûte plus cher en dette et en maintenance que ce qu’il permet d’économiser, il vaut mieux simplement le désactiver.

  • Si tu avais assemblé et exploité individuellement un ensemble de services équivalent, la charge de maintenance aurait été bien pire. Mais Kubernetes est assez simple à gérer pour qu’on puisse quasiment le laisser tourner une fois allumé. À condition toutefois de savoir ce qu’on fait, pour ne pas céder à la tentation d’installer des « outils qui ont l’air cool ».

• K8S n’impose pas non plus YAML. C’est idiomatique, certes, mais pas obligatoire. kubectl apply a toujours supporté JSON dès le départ, et les endpoints sont en JSON et gRPC. On peut aussi générer la configuration depuis différents langages comme Jsonnet. Deuxièmement, je me demande pourquoi les dépendances et leur ordre dans les charts Helm sont présentés comme un problème. L’idiome principal de Kubernetes, c’est la boucle : si une dépendance n’est pas là, l’application considère ça comme une erreur récupérable et réessaie jusqu’à ce que ça fonctionne. Sinon elle crash, et le contrôleur ReplicaSet la redémarre automatiquement. Si le chart n’intègre pas de dépendance, il n’y a pas non plus de conflit de dépendances. Et si l’application dépend réellement d’un autre service, alors il est logique d’inclure ce service ou cette app dépendante directement dans le chart Helm.

  • (Citation d’un commentaire principal) > Dire que le contrôleur ReplicaSet redémarre l’application en cas de crash, ce n’est pas suffisant. Par exemple, si Keycloak met une minute à démarrer, le service qui en dépend va crasher immédiatement en son absence, puis réessayer jusqu’à être throttlé, et même après le démarrage de Keycloak il attendra encore 5 à 10 minutes pour rien. Si la dépendance est claire, il est plus approprié de vérifier le service dépendant avec un init container avant de passer au conteneur principal. J’aimerais bien qu’il y ait dans Kubernetes une déclaration explicite des dépendances de démarrage. Crasher, réessayer quelques fois, puis se faire throttler, ce n’est pas une bonne réponse. Les dépendances sont simplement une réalité.

  • Je pense que les échecs de dépendance doivent impérativement être récupérables. J’ai déjà vécu un incident provoqué par un comportement fail-closed sur une dépendance qui n’était même pas réellement utilisée. Les dépendances entre serveurs sont presque toujours des soft dependencies. Si la dépendance downstream ne fonctionne pas, il suffit de renvoyer une 500, et le load balancer évitera les serveurs unhealthy.

  • On dit souvent que c’est comme ça que les choses sont « censées » fonctionner, mais ça ne convient bien qu’aux stacks logicielles construites en interne. Beaucoup de logiciels anciens, déjà existants, supportaient Docker avant d’être adaptés à Kubernetes. Quand les développeurs créent des outils selon leur propre philosophie, les gens les utilisent malgré tout comme ils veulent, et le résultat devient parfois chaotique. Au final, il faut offrir diverses fonctionnalités et laisser le marché en faire l’usage qu’il souhaite.

  • « La caractéristique architecturale principale de Kubernetes, c’est la boucle de réconciliation » : je suis totalement d’accord. On observe l’état actuel, on fait le diff avec l’état désiré, puis on applique ce diff. Et on recommence sans fin. Il ne s’agit pas de succès ou d’échec, mais seulement de résoudre de façon itérative l’écart entre l’état présent et l’état attendu. Je vois ce pattern comme très proche des technologies « assez bonnes » des systèmes de contrôle mécanique, comme le contrôle PID.

  • Critiquer cet argument en disant « on peut utiliser JSON au lieu de YAML », ce n’est pas le sujet. Ce n’est pas ce qui intéresse vraiment les gens. Ça ressemble à un pinaillage inutile.

• Je suis fortement opposé à l’idée de remplacer YAML par HCL. HCL est difficile à lire pour les développeurs et pénible à parcourir. J’ai beaucoup de griefs en termes d’usabilité : support des imports ou non, difficulté du débogage, etc. Je ne comprends pas pourquoi ils n’ont pas mis au centre un langage de définition d’interface comme protobuf, puis laissé chacun transformer la forme selon ses préférences.

  • HCL, c’est le pire. Le YAML de k8s m’a toujours suffi. Si la configuration devient vraiment trop complexe, le problème relève probablement davantage de la conception de l’application que des ConfigMaps.

  • En réalité, que ce soit HCL, JSON ou YAML, il suffit de sérialiser/désérialiser côté client. Donc ce n’est pas un problème propre à Kubernetes, juste une couche de transformation externe.

  • Les définitions d’interface de Kubernetes sont déjà basées sur protobuf, sauf pour les CRD.

  • Mon principal reproche à HCL, c’est la syntaxe des boucles for. Elle est vraiment atroce.

  • Quand on dit que « HCL est difficile pour les développeurs, et que le linting ou le débogage sont compliqués », ça ressemble surtout à une réaction de gens qui ne veulent pas apprendre quelque chose de nouveau. J’ai l’impression que le problème vient plus de la complexité du domaine qu’on confond avec l’apprentissage de HCL.

• Je développe un projet nebulous dans un esprit « Kubernetes 2.0 » (encore en pré-alpha). L’objectif : distribution mondiale et allégée, exécution en binaire unique sur un laptop, et montée jusqu’à des milliers de nœuds dans le cloud, avec réseau Tailnet, stockage BitTorrent, multi-tenant, live migration, etc. La plupart des besoins viennent de l’exploitation ML, en particulier de la pénurie de GPU, et si le ML devient banal demain, ça pourrait peut-être devenir la norme.

  • La live migration est intéressante. Nous utilisons déjà une stratégie de prix fondée sur l’autoscaling entre plusieurs clusters et clouds, mais la live migration représente un niveau de défi totalement différent.

  • Ce n’est pas Kubernetes, c’est un système distinct spécialisé dans l’exploitation des GPU.

  • La « distribution mondiale » est peut-être au contraire une non-exigence. Si on utilise Tailnet comme réseau par défaut, c’est même une fonctionnalité que j’aurais envie de retirer immédiatement. L’hypothèse d’une interface réseau unique dans Kubernetes est un héritage frustrant du cloud (je suis content de voir plusieurs CNI et récemment des projets comme Multus ; voir le blog Red Hat). Je me demande aussi en quoi la conception multi-tenant diffère concrètement de k8s. Et si le stockage repose sur BitTorrent, partager même les images de conteneurs publiques risque d’exploser les coûts de trafic sortant.

  • En regardant GitHub, je vois un Chart.yaml, et même des templates comme provider_aws.yaml, ce qui correspond exactement au genre de pattern de code que j’aimerais éviter.

• Kubernetes me semble encore aujourd’hui vraiment complexe. On le ressent moins uniquement parce qu’il s’est démocratisé. Dans un Kubernetes 2.0, j’aimerais que l’expérience utilisateur soit simplifiée, surtout pour les opérations fréquentes comme le déploiement d’applications, l’exposition de services, ou les changements de comptes de service et d’images. Mais comme la mode actuelle est aux LLM, le développement de la suite semble peu probable.

  • Kubernetes accumule trop de couches d’abstraction. Les pods sont un concept central élégant, mais avec l’ajout des deployments, ReplicaSets, namespaces, etc., je me dis parfois que j’aimerais quelque chose d’aussi simple que Docker Swarm. Terraform aussi a une couche unique et était plus facile à apprendre. Je ressens vraiment à quel point la courbe d’apprentissage de k8s est raide.

  • C’est un sujet qui fait penser que « les distinctions de type dans les programmes informatiques sont le produit de la perception humaine ». Les opérateurs et contrôleurs sont trop abstraits, un peu comme COM/CORBA autrefois — à la fois un avantage et un inconvénient. Pour des implémentations simples, un k8s-lite plus limité pourrait être plus adapté. À l’inverse, dans des environnements complexes, même les abstractions actuelles de k8s sont souvent insuffisantes. Je doute qu’un seul système — qu’il s’appelle Kubernetes 2.0 ou autre — puisse réellement encapsuler tous les problèmes du monde réel d’une manière encore maniable pour des développeurs ou des architectes humains.

• Je veux un système avec des « sane defaults », c’est-à-dire un état par défaut suffisamment correct sans avoir à tout choisir explicitement : réseau, stockage, load balancer, etc. Je n’aime ni YAML ni HCL. Il faut une meilleure façon de configurer les choses, et changer seulement de langage ne résoudra pas le problème. Pour moi, IPv6 est indispensable. Docker, les conteneurs et Kubernetes auraient dû être conçus en IPv6-only en interne, avec IPv4 traité comme une exception au niveau de l’ingress controller.

  • Il y a un conflit fondamental entre les « sane defaults » et la conversion des clients vers des services managés. Plus j’observe k8s depuis longtemps, plus j’ai l’impression que la philosophie « batteries not included » s’étend au stockage, au réseau, etc., et que tout cela est ensuite revendu par AWS/GCP sous forme de services d’intégration coûteux. En pratique, le k8s du monde réel ne ressemble même plus tout à fait à de l’open source : il sert aussi d’outil pour vendre des solutions qui comblent les manques du cloud.

  • (Expérience personnelle) L’avantage de Terraform/HCL sur YAML, c’est que l’absence de dépendance à des caractères invisibles le rend plus lisible.

  • À cause de ces « sane defaults », j’aime beaucoup plus k3s.

• Je trouve que c’est une wishlist plutôt modeste pour une version 2.0. Autour de moi, tout le monde se plaint de la complexité de k8s en production. Le vrai point clé, c’est de savoir comment concilier rétrocompatibilité et simplicité. En général, la rétrocompatibilité fait exploser la complexité, parce qu’un nouveau système finit par devoir supporter à la fois l’ancien et le nouveau.

  • Au fond, toute la question est de savoir où et jusqu’où on peut retirer de la complexité. Parmi les abstractions k8s que j’ai vues jusqu’ici, certaines ne couvrent qu’un cas très restreint (wrappers façon Heroku), et d’autres finissent par créer leur propre DSL, ce qui augmente encore la courbe d’apprentissage — puisqu’il faut alors réapprendre à la fois k8s complexe et un DSL supplémentaire.

• J’ai l’impression de vivre déjà dans un monde « Kubernetes 2.0 » en gérant mon cluster et mes applications avec Terraform.

  • on peut utiliser directement HCL, le typage, les dépendances entre ressources et la manipulation de données
  • avec un seul tf apply, on configure d’un coup le cluster, les nœuds, les intégrations cloud (S3, etc.) et les services dans le cluster
  • les modules Terraform permettent la réutilisation du code et l’intégration d’infrastructures non-k8s. Par exemple, avec un module Cloudflare ZeroTrust, on peut exposer un endpoint SSO public en 5 lignes de code. (déploiement de cloudflared dans le cluster + config du tunnel via l’API Cloudflare)
  • les grands fournisseurs d’infrastructure publient de bons modules Terraform, et le lockfile provider facilite aussi la gestion des dépendances de modules et de providers
  • avec le provider Helm pour Terraform, on peut aussi gérer librement les charts Helm. En particulier, pour les charts qui ne font que « créer un namespace + déployer un operator + créer une custom resource », on installe seulement l’operator et on gère directement les CRD avec Terraform
  • l’inconvénient, c’est que l’orchestration du processus apply est un peu pénible (comme avec YAML, d’ailleurs), mais nous avons résolu ce point avec Spacelift
  • En réalité, gérer deux fois l’état du système, une fois dans le state k8s et une fois dans le state Terraform, est inefficace. Si les ressources sont modifiées par des mutating webhooks, il faut aussi gérer les computed fields. Donc j’évite Terraform pour l’administration au niveau applicatif. En revanche, gérer le cluster lui-même avec Terraform me semble tout à fait raisonnable.

• En venant du front-end, j’ai trouvé Kubernetes remarquablement intuitif. Avant, j’écrivais des interfaces réactives à partir de données en entrée ; maintenant, j’ai l’impression d’écrire du code qui aligne des ressources et de la configuration dans un plan de contrôle.