Sergej Khackimullin - Fotolia

Actualites

Cloud Foundry et Kubernetes : une intégration qui fait encore débat

L’intégration entre Kubernetes et Cloud Foundry est un souhait pour les entreprises, mais l’écosystème débat encore sur la bonne méthode. De quoi semer la confusion chez les utilisateurs.

Beth Pariseau
par
Publié le: 30 avr. 2018

Les feuilles de route de Cloud Foundry et de Kubernetes sont certes entrelacées. Mais leurs communautés ne se sont pas encore mises d'accord sur le mode d’intégration entre le PaaS et les différentes déclinaisons l'orchestrateur de containers. C’est l’une des conclusions que l’on pouvait tirer de Cloud Foundry Summit qui s’est tenu à Boston à la mi-avril. Ce sujet était à l’ordre du jour de nombreuses sessions organisées pendant cet événement, avec, pour fil conducteur, l’éventuelle consolidation des deux approches en matière d’automatisation d’infrastructure.

Les entreprises qui ont fait le choix de Cloud Foundry montrent un intérêt marqué pour Kubernetes et voient comme positif le remplacement de Diego, l’orchestrateur de Cloud Foundry, par celui de la Cloud Native Computing Foundation (CNCF). Pour eux, cela se justifie par le fait que Kubernetes a dominé l'écosystème des outils de gestion des containers l'année dernière. Kubernetes est également considéré comme une plateforme d'orchestration généraliste, plus flexible et personnalisable, tandis que Diego est destiné à être utilisé uniquement dans les environnements Cloud Foundry. Ce dernier possède aussi un ensemble limité de fonctionnalités en matière de gestion de containers.

« Les supporters de Cloud Foundry ont annoncé leur soutien à Kubernetes pour les mêmes raisons que Docker (celui-ci a ajouté le support de Kubernetes aux côté de Swarm, NDLR) ;  parce qu'elles doivent le faire », explique Tom Petrocelli, analyste chez Amalgam Insights. « La communauté Cloud Foundry s’est rendu compte que Kubernetes a grignoté le monde des containers, et qu'il y a un véritable intérêt à l'utiliser, juste parce que tout le monde le fait ».

La popularité de Kubernetes crée sa propre dynamique : les fournisseurs ajustent leurs produits et leurs applications pour qu'ils prennent en charge l'outil d'orchestration de containers ; les utilisateurs en entreprise supportent la communauté, créant une base solide pour ceux qui envisageraient d’adopter la technologie.

« Une technologie n'a pas besoin d'être supérieure pour être plus populaire, ajoute  l’analyste. Il suffit qu'elle soit suffisamment bonne pour qu’une masse critique d’utilisateurs commence à l’adopter."

Les images de containers sont également devenues le standard pour distribuer des logiciels packagés. Kubernetes a la particularité d’exécuter plus facilement des images non modifiées que la le PaaS de Cloud Foundry.

« Les possibilités de stockage de Kubernetes peuvent aussi être plus flexibles pour certaines applications commerciales, en particulier les applications stateful qui nécessitent un accès au stockage », avance à son tour Kyle Campos, responsable DevOps et des opérations Cloud chez CSAA Insurance Group. « D'un point de vue opérationnel, nous aimerions qu’un tableau de bord unifié puisse gérer les applications commerciales sous Cloud Foundry. »

Le groupe n'a pas encore décidé s’il associerait ou non de combiner les deux solutions en production, mais en théorie, consolider la gestion des deux plateformes et des applications est un gain important, résume Kyle Campos. Cependant, certains points d'intégration entre les deux plateformes ne sont pas encore prêts pour la production – c’est le cas pour le partage des logs, la télémétrie et la gestion des identités.

Des désaccords sur les méthodes d'intégration dans l’écosystème

Si certains projets d'intégration ont bien démarré, les principaux éditeurs de solutions bâties sur Cloud Foundry et les contributeurs de code semblent de leur côté en désaccord sur la façon de combiner les deux plateformes.

Lors de cette édition du Cloud Foundry Summit, les représentants des principaux distributeurs du Paas Open Source (Pivotal, SUSE, Google, SAP, Microsoft et IBM) ont montré que les débats, et les questions,  sur les choix d'intégration étaient encore nombreux.

Cloud Foundry a déjà prouvé qu’il était capable de proposer une bonne expérience pour les développeurs, souligne Cornelia Davis, directrice de la technologie chez Pivotal. Que l'outil de gestion des containers soit Kubernetes ou Diego, cela ne change en rien l'expérience du développeur, ajoute-t-elle. D'une certaine manière, Kubernetes reprend simplement les principes d'infrastructure déclarative, d'abstraction et d'automatisation que Pivotal défend depuis des années.

Un point sur lequel un représentant de Microsoft est déjà en désaccord.  « Les abstractions et les délimitations proposées par le Paas sont excellentes. Mais si vous atteignez les limites, jusqu'où le développeus doit descendre dans l’infrastructure »,  répond ainsi Gabe Monroy, lead container program manager chez Microsoft Azure. « Un PaaS sur Kubernetes rend cela beaucoup plus acceptable, avec la découverte de services, leurs maillage et d'autres abstractions. »

Ne pas changer pas fondamentalement l'expérience du développeur en remplaçant Diego par Kubernetes est en fait un argument  commercial, ajoute à son tour Jeff Hobbs, directeur de l'ingénierie chez Suse. « Cela permet d'améliorer l'expérience de l'opérateur et l'utilisation des ressources sans perturber l'expérience du développeur. »

Ce débat perturbent les responsables IT

Les degrés d’intégration  de Cloud Foundry et de Kubernetes varie d'une distribution à l'autre. La gestion entièrement automatisée des containers nécessite généralement un scheduler pour chaque couche d'infrastructure, un pour les containers eux-mêmes et un pour les clusters de VM.

Dans Pivotal Cloud Foundry, l’intégration entre Cloud Foundry et Kubernetes réside dans l'outil d'automatisation de VM de Cloud Foundry, BOSH, et Cloud Provider Interface (CPI), pour ajouter l'automatisation de VM au scheduler de Kubernetes.

De son côté,  Suse a fait le choix de contourner BOSH. Les utilisateurs n'ont pas besoin d'apprendre à la fois BOSH et Kubernetes pour exécuter des applications Cloud Foundry dans des containers, ont déclaré les responsables de Suse lors ce même événement.

Pour les utilisateurs, tout dépend de la plateforme qu'ils ont découverte en premier. L'approche de Suse pourrait plaire aux utilisateurs qui n'utilisent pas déjà Cloud Foundry.  Mais sans CPI, les utilisateurs de Cloud Foundry perdent une couche d'abstraction qui leur est familière, commente un architecte de solutions dans une société de services informatiques.

« À première vue,[l'approche de SUSE] ressemble un peu à un projet scientifique, poursuit-il. La plupart des personnes que j'ai rencontrées ont déjà assez de difficultés à gérer un environnement de containers ou Cloud Foundry.  Ajouter cette complexité me fait dire que cela ne fonctionnera pas. »

Ces différentes approches crée un message confus sur la façon dont les deux plateformes vont se réunir, croit savoir Tom  Petrocelli d'Amalgam Insights. « Qu'est-ce qu'il y a de si dur ? », se demande-t-il. « Les containers Kubernetes ne sont pas pour  tout et tout le monde, et l'intégration est pertinente. Il n'y a aucune raison de ne pas envoyer le message aux responsables IT qu'il s'agit en définitive de technologies complémentaires. Ils sont déjà assez dans le brouillard. »

Pour approfondir sur Stockage de conteneurs