Actualites

Cloud Foundry : une communauté officiellement divisée par l’intégration de Kubernetes

Suse, IBM et SAP présentent deux projets dont l’ambition est de pousser plus loin l’intégration native de Kubernetes au Paas, quitte à ôter le propre orchestrateur de la plateforme. Une approche qui contraste avec celle de Pivotal, via BOSH.

Cyrille Chausson
par
Publié le: 15 oct. 2018

Kubernetes et Cloud Foundry : saison 2. Un an après avoir rapproché les deux socles technologiques open source et, par la même occasion, les deux communautés respectives, la communauté Cloud Foundry décide finalement d’apporter une autre vision de cette intégration. A la clé, la présentation d’Eirini et CF Containerization, deux projets portés notamment par Suse, IBM et SAP, et dont l’ambition est de placer l’orchestrateur de container très en vogue au cœur du Paas open source. Mais au-delà, ces deux projets viennent également cristalliser un désaccord dans la communauté quant à l’intégration de Kubernetes : BOSH ou pas BOSH, natif ou pas natif ?

Pour mémoire, lors de l’édition 2017 du Cloud Foundry Summit, la fondation, sous l’impulsion de Pivotal et Google, avait officiellement inscrit Kubernetes sur sa feuille de route en présentant Container Runtime. Ce projet vise tout simplement à proposer une offre de Caas (container-as-a-service) bâti sur Kubernetes en s’appuyant sur BOSH, un autre projet de la fondation, dont la vocation est de servir de tour de contrôle opérationnelle à des déploiements de clusters Kubernetes. Cette offre côtoie donc Application Runtime, qui représente le socle historique de la fondation, à savoir un Paas open source intégré au sein duquel on retrouve logiquement un orchestrateur de containers maison, nommé Diego.

 Cette vision du Caas, soutenue par BOSH, n’avait pas reçu le support de la communauté Cloud Foundry dans son ensemble. Seul Pivotal à ce jour en a fait une offre commerciale, sous le nom de PKS (Pivotal Container Service – le K étant pour marquer la présence de Kubernetes). Pivotal a décliné une plateforme cloud globale bâtie sur BOSH où l’on retrouve trois composants : PAS (Pivotal Application Service, motorisé par Application Runtime de Cloud Foundry) ; PKS (BOSH et Kubernetes) et une offre de services Serverless (PFS – Pivotal Function Service). « BOSH apporte l’efficacité opérationnelle et permet ainsi de décomplexifier l’administration de Kubernetes, une tâche généralement compliquée », soutient d’ailleurs Ian Andrews, vice-président en charge de la stratégie produits chez Pivotal – il est également un cadre influent de la communauté Cloud Foundry.

Mais ce n’était pas l’avis de Suse ou encore d’IBM et de SAP. Pour eux, Kubernetes doit faire partie intégrante de la pile Cloud Foundry, et non pas constituer un « à-côté », piloté par un autre composant. Kubernetes doit être plus natif, en somme. Suse mise davantage sur la containerisation de Cloud Foundry  en lui-même pour que le Paas gagne en souplesse, qu'il bénéficie de capacités d’administration avancées et soit plus facile à mettre à jour. « Suse vient de l’infrastructure, un secteur qui exploite déjà une galaxie d’outils comme BOSH. Ce dernier n’est pas utilisé par toutes les distributions Cloud Foundry et reste surtout un composant clé pour Pivotal. » Selon les informations de Pivotal, la société est responsable de presque 75 % du code de Cloud Foundry.

Faire de Kubernetes une expérience native

C’est ainsi que cette édition 2018 du Cloud Foundry a vu naître ces projets CF Containerization et Eirini, concrétisant les efforts techniques de l’autre partie de la communauté. Le  projet CF Containerization est le fruit des travaux de Suse remis à la fondation. « Le container est à la base de ce projet, et supporté notamment par IBM. On peut donc déployer directement Cloud Foundry  sur des clusters Kubernetes, y compris dans le cloud public », témoigne le responsable. L’idée est de faire passer l’Application Runtime de la fondation, de la VM aux containers. « Les manifestes BOSH sont convertis en Helm Charts pour déployer les containers (Docker) Cloud Foundry sur Kubernetes », détaille-t-il.

IBM a repris cette approche avec Cloud Foundry Enterprise Environment (annoncé lors de cette édition européenne du Cloud Foundry Summit) qui permet d’instancier Cloud Foundry dans un cluster Kubernetes sur le Cloud d’IBM – ou encore dans Private Cloud.

Remplacer Diego par Kubernetes ?

Toutefois cette approche comporte une difficulté technique, ajoute encore Thomas Di Giacomo : Cloud Foundry dispose déjà de son propre orchestrateur de containers (Diego). « On se retrouve donc à avoir des containers dans des containers. » Là intervient donc le projet  Eirini dans le dispositif de Suse : ce projet permet de choisir son orchestrateur, Diego ou Kubernetes, pour les workloads Cloud Foundry. Avec un postulat de base : Kubernetes s’inscrit dans un schéma qui n’est plus imbriqué. Là est donc l’expérience native. Si certes, l’utilisateur a le choix, indique Thomas Di Giacomo (qui est au board des deux fondations, Cloud Foundry et CNCF), Suse, tout comme IBM d’ailleurs, ne cachent pas leur ambition de retirer Diego de l’équation et de faire de Kubernetes l’orchestrateur par défaut.

Si Cloud Foundry et donc Diego sont déjà en place et que cela fonctionne, inutile de passer à Kubernetes, explique-t-il. Mais pour réaliser de nouvelles applications cloud-natives, Kubernetes peut en revanche s’imposer. « En théorie », les deux peuvent être conjugués en fonction des applications.

Pour Chip Childers, le CTO de la Cloud Foundry Foundation, Diego est un « composant important pour le cœur du projet Cloud Foundry ». Il ajoute que « seulement une partie des cas d’usage peut supporter Kubernetes ». Diego offre selon lui davantage de garantie en matière de multi-tenancy, est plus riche fonctionnellement et supporte mieux les environnements Windows.

Logiquement, de son côté, Pivotal croit peu en Eirini et CF Containerization. « Nous n’avons pas de développeurs sur ces projets. Il se peut que cela donne quelque chose d’intéressant. Avec CF Containerization, ils ont pris le contrôleur pour le mettre dans un container à la place d’une VM et l’ont déployé au-dessus de Kubernetes. Cela vous permet de provisionner un cluster plus rapidement. Mais le problème qui ne se résoud pas : comment mettre en place Kubernetes - ce que résout BOSH », commente Ian Andrews. « Cela implique donc d’avoir déjà un cluster Kubernetes opérationnel. La réalité est que les entreprises ont aussi leur propre datacenter, et pas uniquement un cluster dans un cloud public ». Et de lancer finalement : « il s’agit là d’une recherche intéressante de Suse, d’IBM et de SAP autour du runtime de Cloud Foundry, mais je ne pense pas que ce qu’ils ont sorti jusqu’alors, satisfasse les besoins des clients. ».

Pas de remplacement de Diego par Kubernetes, pense-t-il également. Cela provoquerait « un risque de conflit » chez les utilisateurs. « Il existe certes des overlaps d’un point de vue fonctionnel. Mais, je pense l’on ne va pas gagner en productivité côté développeur à remplacer Diego par Kubernetes. »

Repositionner Cloud Foundry et Kubernetes pour qu'ils soient complémentaires

Finalement, ce désaccord est né d’une approche différente : quelle est la place des deux technologies, leur rôle et celui des communautés respectives. Si aujourd’hui, il convient de créer des passerelles entre communautés, a souligné Chip Childers, il existe toutefois un espace que chacune doit s’accaparer et maintenir, afin d’éviter d’éventuels chevauchements.

« Cloud Foundry est très bien pour les développeurs, explique Thomas Di Giacomo (Suse), mais finalement assez peu pour les spécialistes de l’infrastructure, qui sont passés des serveurs physiques aux VM puis aux containers aujourd’hui ».

« Cloud Foundry apporte l’outillage nécessaire à la gestion que n’a justement pas Kubernetes, côté infrastructure. L’administration de ce dernier passe généralement par une série d’outils. Kubernetes, pour le cloud-natif, Cloud Foundry pour l’abstraction apportée aux développeurs », rapporte-t-il. 

Mais, pour cela, il faut revoir l’écosystème,  « car cela implique un changement de positionnement pour Cloud Foundry, en tant que plateforme intégrée (un positionnement historique du Paas, NDLR) ».

Suse, comme IBM et SAP, militent là pour une approche de Paas où la couche infrastructure suit les projets des entreprises. Aujourd’hui, c’est donc vers Kubernetes qu’il faut se tourner. Ils ont également concrétisé cela au sein du projet Stratos dont la vocation est de  développer une interface graphique unique pour gérer de multiples instances Cloud Foundry et Kubernetes.

Cloud Foundry pour les développeurs et Kubernetes pour l’exploitation

« J’aimerais qu’on évite de refaire un Cloud Foundry pour la communauté Kubernetes. Cloud Foundry doit conserver son positionnement auprès des développeurs et Kubernetes dans l’infrastructure. On va perdre du temps à faire des schedulers pour Cloud Foundry et Kubernetes a d’autres problèmes à régler que de se pencher sur les développeurs. Il ne s’agit pas de multiplier les overlaps, mais de jouer la carte de la complémentarité », illustre Thomas Di Giacomo.

 Un point de désaccord avec Pivotal, qui s’interroge par la voie de Cornelia Davis, directrice des technologies chez Pivotal, sur « le bon modèle ». « Avant de mixer Kubernetes et Cloud Foundry plus avant, il convient de connaître les niveaux de responsabilité », lance-t-elle à l’occasion d’une session pendant l’événement.  « Je souhaite que les communautés se concentrent sur les personas, ceux qui gèrent et administrent, et ceux qui développent les applications. Ne perdons pas cela en mélangeant Kubernetes et Cloud Foundry. »

Et un représentant de Microsoft de conclure : il s’agit aussi de « préserver l’élégance de Cloud Foundry tout en ajoutant la puissance de Kubernetes ».  Là est justement l’équilibre.

Pour approfondir sur PaaS