Joe Beda fait partie de la dream team (avec Craig McLukie et Brendan Burns) qui a mis au point l’orchestrateur de cluster de conteneurs Kubernetes chez Google (un portage en Go de l'orchestrateur maison Borg). Depuis l'équipe s'est dispersée : Joe Beda et Craig McLukie ont rejoint VMware suite au rachat de leur start-up Heptio par l'éditeur de Palo Alto, alors que Brendan Burns a été recruté par Microsoft pour assurer le portage de K8 sur Azure. Joe Beda est revenu sur les orientations et les objectifs pour le projet Kubernetes lors d'une récente session virtuelle « Ask-Me-Anything » avec BrightTalk. Il admet que l'outil d'orchestration de conteneurs reste difficile à maitriser et que la communauté devrait essayer de rendre la technologie aussi « banal » que le noyau Linux afin de stimuler la prochaine vague d'adoption par l'industrie. « Kubernetes sert désormais de point d'ancrage à un écosystème plus large et a changé la manière de penser les déploiements et la gestion d'applications », déclare-t-il. On est loin des débuts de Kubernetes. « Nous n'avions pas prévu cela », a-t-il reconnu.

Kubernetes, un incontournable comme Linux

Maintenant que la technologie est devenue essentielle pour les développeurs dans les entreprises, Joe Beda a fixé deux objectifs pour Kubernetes (K8). Le premier est de rendre l’outil d’orchestration aussi fondamental que le noyau Linux, afin d’en faire une plateforme stable et performante sur laquelle on peut compter. Le second objectif est d’utiliser cette base pour construire des fonctionnalités innovantes. « Les gens construisent des choses étonnantes sur K8. Les fonctionnalités que nous ajoutons permettront de faire des choses vraiment intéressantes, D’ailleurs, il existe déjà une multitude de projets qui s'appuient sur Kubernetes ou construit autour et pour Kubernetes », a-t-il ajouté. C’est en 2014 que Joe Beda, aujourd’hui ingénieur principal chez VMware, après 10 ans passés chez Google, a rédigé l'un des premiers commits pour K8.

Au cours de la conversation, il a abordé deux autres questions clés auxquelles est confronté le projet open source.

Pourquoi Istio est-il distinct de Kubernetes ?

La première question vraiment intéressante posée à Joe Beda concernait Istio. On lui a demandé pourquoi le service mesh open source Istio, communément associé à Kubernetes et principalement développé par les ingénieurs de Google, n'avait pas été intégré plus profondément dans K8. Google n'a pas voulu céder Istio ou y contribuer pleinement en open source avec la Cloud Native Computing Foundation, l'organisation à laquelle l’entreprise a confié Kubernetes quand elle a lancé la technologie open source. D’une part, Google a voulu garder « un plus grand contrôle sur Istio », a déclaré M. Beda. Ensuite, l’autre raison pour laquelle les deux projets restent distincts, selon lui, c’est qu'il existe des solutions autres que Istio, comme Linkerd et l'Open Service Mesh de Microsoft, pour mettre en œuvre des services mesh. Parfois, il n'est pas du tout nécessaire de déployer un maillage de services avec K8.

Kubernetes, trop difficile à apprendre ?

Quand ils se plaignent de la courbe d'apprentissage abrupte de K8, les développeurs mettent souvent et facilement en cause les fichiers de configuration YAML. Jo Beda a admis que « YAML servait de bouche-trou, le temps de trouver la bonne solution, sauf qu’il n’y a pas une seule bonne solution ». Ajoutant : « C'est comme demander quel est le bon langage de programmation ? Tout dépend de ce que vous voulez faire et de l'environnement dans lequel vous vous trouvez ». Cela dit, il serait possible de rendre YAML plus déclaratif et moins intimidant pour les nouveaux venus, avec des diagrammes de Helm par exemple, qui permettraient de combiner packaging et déploiement en une seule expérience intégrée, et CDK pour Kubernetes, le dernier framework de développement logiciel qui essaye aussi d'abstraire une partie de cette difficulté. M. Beda a également admis que c’était toujours un défi pour des développeurs assez courageux pour tenter l’expérience, d’exécuter K8 sur du bare metal. « C’est encore difficile de gérer Kubernetes sur du bare metal. Le plus simple est de disposer d’une infrastructure programmable, comme Terraform, Ansible ou Cluster API », a-t-il déclaré.

Ce choix d’une infrastructure as a code offre aux développeurs de gérer plusieurs clusters avec des builds plus automatisées et une plus grande malléabilité. « Grâce à l'automatisation et à cette agilité, vous rendez les choses plus fiables. Á la place d'un seul cluster modifié à la main, vous avez un ensemble de clusters autogérés et vous disposez de plus de fluidité pour déplacer les choses, les pousser et revenir en arrière plus rapidement », a expliqué M. Beda. Ce dernier a également contesté l'idée selon laquelle il fallait faciliter le fonctionnement de K8 en réduisant la complexité qui découle de son inhérente flexibilité. « La beauté de Kubernetes, c’est qu'il n'y a pas de gardiens, personne ne vous dit ce que vous ne pouvez pas faire ou comment l'utiliser. Cela fait partie de l'éthique de l'open source. Cette flexibilité est l'une de ses forces », a-t-il déclaré.