Interview : Alexis Moussine-Pouchkine (Google) explique Kubernetes


SFEIR a profité du JUG Summer Camp, la conférence Java de cette rentrée 2016 qui s’est tenue à La Rochelle, pour interviewer plusieurs personnalités. On commence tout de suite avec Alexis Moussine-Pouchkine, qui présente lui-même son rôle chez Google avec notre première question. Il nous parle de Kubernetes, de son usage et de son avenir sur un marché en constante évolution.

SFEIR : Pourrais-tu te présenter rapidement ?

Alexis : Je m’appelle Alexis, je travaille chez Google, dans l’équipe des relations développeurs et plus précisément sur l’entité Google Cloud Platform.

Rentrons tout de suite dans le vif du sujet : qu’est-ce que Kubernetes ?

Kubernetes est un projet open source, qui a eu beaucoup de succès depuis son démarrage il y a deux ans. C’est un projet qui exploite les 10 ans d’expérience de Google dans la gestion de conteneurs, pour optimiser le déploiement d’applications conteneurisées, les monitorer et les mettre à jour.

Où et comment est utilisé Kubernetes chez Google ?

Kubernetes est assez peu utilisé en direct chez Google. Kubernetes est fondé sur les leçons apprises avec un outil comme Borg, qui lui est la base de tout ce qui se fait chez Google. Les deux sont très similaires, mais Borg a des spécificités liées à son usage chez Google. Toutes les applications Google sont déployées sur Borg sous forme de conteneurs. Le système se charge ensuite de réconcilier la réalité avec ce qui a été demandé de manière déclarative. C’est utilisé absolument partout : tout est un conteneur et tout est géré par Borg, que ce soit Google Maps, Gmail, le search, etc. Kubernetes reprend ces principes.

Comment s’intègre Kubernetes avec toutes les offres du marché, que ce soit Docker, etcd, etc.

Commençons par le plus simple, etcd. Disons, pour simplifier, que quand on a un système distribué, on veut avoir à tout moment une configuration qui soit la même vue par tout le monde. On utilise etcd pour ça. La version 3.0, qui est assez récente, doit beaucoup de ses nouveautés à Kubernetes, qui pousse etcd assez loin dans ses retranchements et rajoute notamment des fonctionnalités de transaction. C’est un outil important, une brique dont nous avions l’équivalent en interne, mais maintenant il existe ce produit CoreOS qui est très bien, très utilisé et qui s’améliore à chaque version.

Concernant Docker maintenant… C’est une technologie formidable, qui a démocratisé les conteneurs tout en résolvant un certain nombre de problèmes pour permettre le transport des applications. Sauf que ce ne sont pas vraiment des applications complètes, chaque conteneur encapsulant plutôt une partie d’application. On ne va pas y mettre le serveur web, la base de données, le serveur d’applis, la totale… Donc on va avoir plusieurs conteneurs, et il va falloir gérer leurs dépendances, leur cycle de vie, leur monitoring, toutes ces choses-là. C’est là qu’intervient Kubernetes, pour “orchestrer” ces conteneurs sur une infrastructure qui peut énormément varier.

Comment expliques-tu le succès de Kubernetes actuellement ?

C’est toujours une combinaison de plusieurs choses. Certains produits comme Mesosphere, un projet Apache, étaient là avant mais si on doit essayer de les comparer, peut-être que Kubernetes est plus pragmatique. Ce produit a été perçu comme une valeur ajoutée à Docker, lui-même très populaire, sans chercher à réinventer quoi que ce soit. L’aspect communautaire, où je pense que Google a fait du bon boulot, a surement joué aussi. On n’a pas seulement balancé du code mais accompagné les développeurs. En prime, c’est écrit en Go, comme Docker et beaucoup de choses dans l’univers du cloud, ce qui attire un certain nombre de contributeurs.

Enfin, et c’est quand même fondamental, je pense que l’architecture est très réussie. On a bien séparé les responsabilités entre un master, des noeuds dans le cluster, chacun a vraiment son rôle et on est capable ensuite d’avoir des abstractions (pod, déploiement, service, etc.) qui sont, je pense, les bonnes. Elles parlent aux développeurs et aux Ops en prod.

Kubernetes est écrit en Go : l’usage de ce langage était une évidence dès le départ ?

Franchement, oui. Entre le fait que Docker est lui aussi écrit en Go, que le langage est efficient du fait de l’absence de toute machine virtuelle et que Google a une expertise toute naturelle en étant à l’origine du langage, il n’y a donc pas eu de longues discussions sur le sujet.

Que peut-on attendre de l’avenir de Kubernetes ?

Même si on a les bons concepts, je pense qu’il y a quand même des niveaux d’abstraction qui sont encore trop complexes, surtout quand on découvre le produit. Je pense qu’on peut encore simplifier la manière dont on package et déploie une application, sans forcément avoir à expliquer à tout le monde ce qu’est un déploiement, un service, un pod…

Kubernetes se trouve quelque part entre les machines virtuelles, le côté Iaas – on ouvre SSH et après “good luck”, il y a tout à faire (maintenir, déployer, etc.) – et le côté Platform as a Service (App Engine, Heroku, etc.). On est un peu entre ces deux mondes mais je pense que Kubernetes va évoluer vers le côté PaaS tout en offrant au développeur une grande liberté. On va avoir un package manager, on va être capable d’installer facilement une app ou une brique façon apt-get, et monter comme ça vers le côté “no-Ops”, vers un niveau d’abstraction le plus simple possible pour tout le monde.

Quelle est votre positon par rapport à l’arrivée de Swarm et les tensions que ça crée dans la communauté, qui n’approuve pas toujours les choix de Docker ?

Je constate que Kubernetes a beaucoup de succès avec Docker aujourd’hui et que les deux fonctionnent très bien ensemble. C’est vrai que Docker c’est beaucoup de choses maintenant : le nom d’une entreprise, un produit, qui en fait englobe lui-même plein de composants : Docker Engine, Docker Machine, Compose et maintenant Swarm. Et ce tout est indissociable. On ne peut pas prendre juste une partie de cette offre. Ça apporte une belle intégration, mais ceux qui n’ont pas besoin de la totalité vont trouver que c’est inutilement sur-équipé. C’était d’ailleurs l’argument principal de CoreOS lors du démarrage du projet Rocket (rkt), qui voulait un conteneur qui ne joue que le rôle de conteneur, qui le fasse bien, et de manière très sécurisée. À ce titre, Kubernetes commence aussi à supporter rkt. Avoir plus de choix en fonction des projets est toujours une bonne chose, y compris côté orchestrateurs. Il y a des gens qui préfèrent utiliser Mesos ou Swarm et ça ne pose évidemment aucun problème. Il y a une communauté qui s’appelle CNCF qui permet d’essayer de fédérer un peu tout ça, mais globalement, plus il y a de solutions et de contributeurs, mieux c’est !

Merci Alexis !

Vous aimerez aussi...