Kubernetes, mise en réseau et découverte du VMware de Cloud Native

Thomas Graf est le co-fondateur et CTO de isovalent, et créateur d'une technologie de mise en réseau open source (et native du cloud) populaire appelée Cil. Cilium est construit sur une technologie Linux au niveau du noyau appelée eGMP.

Dans cette interview, Graf discute des rôles que jouent Cilium et eBPF dans l'écosystème croissant des réseaux natifs du cloud, ainsi que de certaines tendances plus larges concernant l'adoption et l'évolution de Kubernetes. Il explique qui utilise et achète Kubernetes au sein des grandes entreprises, où l'infrastructure cloud native doit encore s'améliorer et comment le désir de standardisation stimule l'innovation.

---

FUTUR : Comment devrions-nous penser eBPF et Cilium dans le contexte de l'informatique et des réseaux, en général, puis spécifiquement dans le contexte du écosystème cloud natif?

THOMAS GRAF : Dans l'ensemble, eBPF est la technologie, et c'est un niveau extrêmement bas. Il a été conçu pour les développeurs du noyau, et mon expérience est dans le développement du noyau. eBPF est au noyau, au système d'exploitation, ce que JavaScript est au navigateur. Il rend le système d'exploitation programmable tout comme JavaScript rend le navigateur programmable. Dans le passé, nous devions mettre à jour nos versions de navigateur pour utiliser réellement certains sites Web. Et puis JavaScript est arrivé, et tout d'un coup, les équipes d'applications et les développeurs ont pu créer des applications massives - au point où l'application de traitement de texte la plus populaire a été remplacée par une application intégrée au navigateur. Cela a conduit à une énorme vague d'innovation. 

La même chose se produit avec eBPF, bien qu'au niveau du système d'exploitation, car tout d'un coup, nous pouvons faire des choses au niveau du noyau ou du système d'exploitation où nous voyons tout et contrôlons tout - ce qui est très important pour la sécurité - sans avoir à changer de noyau. code source. Nous pouvons essentiellement charger des programmes dans le noyau pour étendre ses fonctionnalités et apporter de nouvelles capacités avec lui. Cela a également débloqué une vague massive d'innovation. Les hyperscalers comme Facebook, Google et Netflix l'utilisent eux-mêmes, directement, avec leurs propres équipes de noyau. 

Ce que Cilium apporte à la table, c'est qu'il utilise cette technologie eBPF de bas niveau pour fournir essentiellement une nouvelle vague d'infrastructure logicielle, en particulier pour la vague cloud native. Pensez à cela comme à la mise en réseau définie par logiciel et à ce que Nicira, qui est devenu VMware NSX, a fait pour l'industrie de la virtualisation. Nous faisons de même pour le cloud natif, où il s'agit d'un mélange de fournisseur de cloud ou d'infrastructure de cloud public, ainsi que d'infrastructure sur site. Et nous résolvons des cas d'utilisation de mise en réseau, de sécurité et d'observabilité avec cela au niveau de la couche d'infrastructure.

Et le Cilium Service Mesh, qui vient de sortir, est une évolution de ces capacités ?

Ce qui se passe actuellement, depuis environ un an, c'est que les deux espaces entrent en collision. Ce que Cilium a fait jusqu'à présent se concentre sur la mise en réseau, la mise en réseau virtualisée, puis la mise en réseau native dans le cloud, mais toujours la mise en réseau. Mais ensuite, en venant de haut en bas, les équipes d'application de Twitter et de Google faisaient maillage de service trucs - dans l'application d'abord, puis le modèle basé sur le side-car, le modèle basé sur le proxy, qui est ce que les projets aiment Istio livrer. Et maintenant ces deux couches se rapprochent parce que les entreprises traditionnelles arrivent dans le monde natif du cloud, et elles ont des exigences de mise en réseau d'entreprise, mais leurs équipes d'application veulent également un maillage de services. 

Gartner appelle cette nouvelle couche « connectivité de service » - nous verrons si ce terme fait son chemin - mais il s'agit essentiellement d'une couche qui comprend la partie réseau de l'entreprise et la partie maillage de services provenant des équipes d'application. Et parce que c'est ce que les clients exigent, nous avons ajouté ces fonctionnalités à Cilium lui-même. Donc, essentiellement, Cilium monte du côté des réseaux d'entreprise et les maillages de services descendent davantage du côté des réseaux.

Pourquoi l'accent est-il mis autant sur le réseau et le maillage de services de la pile Kubernetes ?

Parce qu'avec la volonté de fonctionner dans plusieurs clouds et de scinder les applications en conteneurs, la couche de connectivité est devenue centrale. Ce qui était peut-être autrefois la communication inter-processus et le middleware est maintenant le réseau, de sorte que le réseau devient absolument essentiel pour que les applications communiquent entre elles et que les données circulent. 

Et dans le cloud natif, en particulier, le multi-cloud devient incontournable. Tous les fournisseurs de cloud ont leurs propres couches de mise en réseau, mais, bien sûr, adaptées à leurs propres clouds. Ils ont des offres sur site, mais ils ne sont pas vraiment multi-cloud. Cilium et eBPF apportent à la table cette couche agnostique multi-cloud. Il se comporte exactement de la même manière sur site que dans le cloud public. Plusieurs fournisseurs de cloud public utilisent Cilium sous le capot pour leurs offres Kubernetes gérées, et les opérateurs de télécommunications l'utilisent pour l'infrastructure 5G sur site. Il s'agit de parler les deux langues et de connecter ces mondes ensemble.

C'est pourquoi l'accent est mis sur ce point : parce que l'un des moyens les plus simples pour les fournisseurs de cloud de verrouiller les clients est de posséder cette couche de connectivité. Je pense que du point de vue de l'infrastructure stratégique, tout comme la couche de virtualisation était essentielle, la connectivité et la couche réseau sont désormais absolument essentielles.

La source de l'innovation [future] sera l'open source, et les clients et les utilisateurs à l'origine de la demande seront des entreprises situées à un niveau inférieur aux hyperscalers - des entreprises déjà importantes qui sont encore très perturbatrices.

Kubernetes est assez largement accepté et adopté à ce stade, mais on parle encore dans certains cercles d'être exagéré. D'après vous, à qui s'adresse Kubernetes et l'écosystème cloud natif dans son ensemble ?

C'est pour les équipes d'application modernes. Je pense que l'on s'est rendu compte que si vous voulez attirer des équipes d'applications modernes et être en mesure d'avoir des délais de mise sur le marché rapides, vous devez leur fournir une infrastructure cloud native. Nous voyons souvent le prototypage - initial, pré-MVP, voire prouver le concept ou vendre en interne - sur sans serveur, quelque chose comme Lambda. Et puis sur Kubernetes, car les équipes d'application peuvent être directement propriétaires de l'infrastructure. Et puis, à mesure qu'il passe en production, ils passent aux distributions Kubernetes d'entreprise sur site. Mais c'est en fait une partie relativement petite de l'ensemble de l'infrastructure, peut-être un pourcentage à un ou deux chiffres. 

Ce sera clairement la nouvelle norme, cependant. Tout comme l'adoption de la virtualisation a été très lente au départ et les gens ont dit que c'était exagéré - mais avec le temps, bien sûr, cela a commencé à remplacer la majorité des choses - nous verrons la même chose ici. Ou tout comme avec les langues modernes. Les gens disaient que Java était exagéré, et c'est probablement encore le cas pour de nombreuses applications, mais il fut un temps où il devenait très difficile de développer des applications en dehors de Java car c'est ce que la majorité des développeurs d'applications pouvaient écrire. être vrai pour les équipes d'application modernes : elles s'attendront à avoir Kubernetes pour se développer de manière plus agile et mettre rapidement le produit sur le marché.

Du côté de l'infrastructure, c'est peut-être un peu exagéré, mais si l'alternative est de réécrire une application sans serveur vers une application sur site, c'est une tâche énorme. Kubernetes est donc le juste milieu, ce qui est très attrayant. 

Qu'en est-il de l'idée que Kubernetes a encore besoin d'une meilleure expérience de développement ?

Si nous regardons l'OpenShift d'origine, avant qu'il ne soit rebasé sur Kubernetes, c'était ça. C'était encore plus proche de l'équipe d'application et c'était une expérience encore meilleure pour les développeurs d'applications. Vous pouvez pousser vers Git et il se déploiera automatiquement. Heroku a également essayé cela, mais en mode SaaS. 

Kubernetes a fait un pas en arrière et a déclaré: «Nous devons conserver certains aspects opérationnels et le rendre un peu plus proche de ce à quoi un administrateur système s'attendrait également. Nous ne pouvons pas être uniquement adaptés aux applications. C'est le juste milieu : il doit être suffisamment attrayant pour les équipes d'application, mais il doit toujours être possible d'exécuter cette application en dehors d'un environnement spécifique et de la faire gérer par des personnes autres que les développeurs d'applications.

Je dirais que le plus grand pas entre Docker et Kubernetes était que Docker était axé sur l'expérience des développeurs. Il a résolu cette partie, mais n'a pas résolu la partie de l'écosystème de cloud public.

Comment en sommes-nous arrivés là ? Était-ce l'évolution naturelle de la plate-forme en tant que service (PaaS) et des conteneurs d'applications ?

Il s'agissait des images Docker et de l'aspect packaging de Docker. La vieille école était de savoir comment se déployer dans des machines virtuelles, et il y avait toutes sortes d'automatisation autour de cela. Et puis il y avait ce que Facebook faisait avec Tupperware – très personnalisé et à très grande échelle. Et puis Docker est arrivé et a essentiellement fourni cette image de conteneur et tout le monde pouvait la traiter comme une machine virtuelle miniature. Je peux maintenant distribuer mon application et au lieu d'une image virtuelle de 600 Mo, c'est maintenant un conteneur de 10 Mo. Mais vous pouvez le traiter de la même manière, il a tout ce dont il a besoin. 

Cela a débloqué la possibilité d'intégrer un orchestrateur comme Kubernetes qui vous permet toujours de traiter les applications comme des mini-VM, mais aussi d'aller plus loin et de les traiter comme des microservices. Il vous permet de faire les deux.

Je dirais que le plus grand pas entre Docker et Kubernetes était que Docker était axé sur l'expérience des développeurs. Il a résolu cette partie, mais n'a pas résolu la partie de l'écosystème de cloud public. Il n'avait pas, ou ne voulait pas nécessairement, une intégration étroite avec les fournisseurs de cloud. Kubernetes a résolu cela. 

Selon vous, qui dirige Kubernetes au sein des entreprises ? S'agit-il d'équipes d'application individuelles ?

Il y a un changement intéressant qui s'est produit avec le cloud natif, c'est-à-dire que nous avons la montée de «l'équipe de la plate-forme», je l'appellerai. Ce ne sont pas des ingénieurs d'application. Ils ont un peu de connaissance des opérations réseau et ils ont pas mal de connaissances en matière de sécurité. Ils ont des connaissances SRE et ils savent comment faire de l'automatisation du cloud. Ils fournissent la plate-forme aux équipes d'application et traitent ces équipes d'application comme leurs clients.

Les équipes de plate-forme sont celles qui achètent Kubernetes et les technologies associées, qu'elles utilisent car elles sont chargées de fournir cette infrastructure de nouvelle génération pour rendre les équipes d'applications modernes heureuses.

Je pense qu'il y a définitivement un espace pour le sans serveur, en particulier pour le développement d'applications très rapide. Mais dans les entreprises, nous considérons le cloud natif comme la nouvelle couche au-dessus de la virtualisation

S'agit-il d'un nouvel acheteur ou d'une nouvelle équipe ? Ou les équipes de plate-forme ressemblent-elles à quelque chose qui existe dans des endroits comme Google ou Facebook et qui se généralisent maintenant ?

C'est surtout une nouvelle équipe. Je pense qu'ils sont, dans une certaine mesure, comme les équipes SRE de Google et Facebook. Cependant, les équipes d'application possèdent probablement une plus grande part du déploiement des applications dans les entreprises, car les entreprises n'ont pas cette distinction très claire entre les ingénieurs logiciels et les SRE comme Google et Facebook. Je dirais que cette évolution est très similaire à la façon dont vous aviez des équipes de virtualisation, puis de nombreuses opérations réseau migrées - ou évoluées ou avancées - étant sur le réseau matériel être sur le réseau virtualisation. Et ces équipes, par exemple, ont commencé à exploiter VMware NSX. La même chose se passe ici. 

Bien que ce ne soit pas nécessairement un nouveau budget. Nous voyons les budgets passer de la sécurité et de la mise en réseau à cette équipe de plate-forme, par exemple, à mesure que les dépenses liées au cloud augmentent et que moins sont dépensées pour le matériel réseau. Ils fonctionnent souvent avec l'équipe de sécurité et avec l'équipe d'exploitation du réseau pour obtenir l'adhésion, mais ils possèdent en fait une part assez importante du budget.

Comment voyez-vous le Fondation Cloud Native Computing en constante évolution, et Kubernetes sera-t-il toujours au centre de celui-ci - ou du mouvement cloud natif en général ?

Kubernetes est ce qui a déclenché la CNCF, et au cours des deux premières années, tout était centré sur Kubernetes et le cloud public. Ce que nous avons vu depuis environ un an, c'est qu'il ne s'agit plus seulement de Kubernetes, mais plutôt de cloud natif principes. Cela signifie en fait que ce n'est plus nécessairement un cloud non plus, pas même un cloud privé. Il s'agit souvent même de réseaux d'entreprise traditionnels, d'infrastructures sur site ennuyeuses, de serveurs bare metal, etc., mais avec les principes natifs du cloud intégrés. 

La nouvelle norme est désormais hybride et comprend plusieurs fournisseurs de cloud public, ainsi qu'une infrastructure sur site. Les entreprises veulent fournir la même agilité aux développeurs d'applications, ou fournir une observabilité avec des outils natifs du cloud modernes, ou assurer la sécurité avec des outils natifs du cloud modernes - par exemple, l'authentification, au lieu d'une simple segmentation ou d'une application basée sur l'identité - tous ces nouveaux concepts natifs du cloud sur infrastructures existantes. 

Nous constatons une très forte demande pour toujours se connecter à l'ancien monde et parler MPLS, VLAN, sFlow et NetFlow - l'ensemble des exigences existantes de l'entreprise. Aucun d'entre eux n'est parti.

Après environ une décennie, l'espace cloud natif ne semble pas être une mode. Quelle marge de manœuvre lui reste-t-il pour continuer à évoluer ?

Il fut certainement un temps où c'était comme, "Oh, Kubernetes est probablement de courte durée, et sans serveur va être la couche suivante." Ou, "Kubernetes est similaire à OpenStack. Ou, "Cela va disparaître et ce sera un détail de mise en œuvre." Et cela ne s'est pas produit. 

Je pense qu'il y a définitivement un espace pour le sans serveur, en particulier pour le développement d'applications très rapide. Mais dans les entreprises, nous considérons le cloud natif comme la nouvelle couche au-dessus de la virtualisation, et nous pensons qu'il a une durée de vie similaire à celle de la virtualisation. Ce qui signifie que nous sommes au tout début de la migration cloud native.

Quels grands problèmes doivent encore être résolus au niveau de l'infrastructure ?

Nous voyons des entreprises dans une situation où, tout d'un coup, qu'elles le veuillent ou non, elles ont besoin d'une stratégie multi-cloud. Parce qu'ils disposent également d'une infrastructure sur site, ils ont désormais besoin d'une stratégie de cloud hybride en plus de cela. Et ils doivent comprendre comment assurer la sécurité et d'autres fonctions de manière universelle sur cette infrastructure sans s'enfermer dans un cloud public particulier. 

Voici donc le prochain grand défi : qui sera cette couche agnostique pour le multicloud et le cloud natif, comme ce que VMware est devenu ? Qui sera le natif de VMware pour le cloud ?

Je pense que l'on s'est rendu compte que si vous voulez attirer des équipes d'applications modernes et être en mesure d'avoir des délais de mise sur le marché rapides, vous devez leur fournir une infrastructure cloud native.

Et bien que l'adoption native du cloud ait pu être relativement facile pour les entreprises Web modernes qui ont été les premiers à l'adopter, le défi, de votre point de vue, est de créer de nouvelles technologies qui comblent le fossé entre ce monde moderne et les outils et systèmes d'entreprise existants ?

Le plus difficile est que les équipes d'applications modernes ont l'habitude de voir la couche d'infrastructure évoluer aussi rapidement qu'elles. Et cela a forcé la couche d'infrastructure à être encore plus programmable, plus ajustable. C'est pourquoi nous voyons en fait une couche réseau et une couche de sécurité au-dessus de la couche réseau cloud. Mais maintenant, nous avons des entreprises qui arrivent, et nous constatons une très forte demande pour continuer à se connecter à l'ancien monde et parler MPLS, VLAN, sFlow et NetFlow - l'ensemble des exigences existantes de l'entreprise. Aucun d'entre eux n'a disparu, toutes les règles de conformité sont toujours les mêmes. Et même certaines des entreprises SaaS modernes sont désormais confrontées à ces défis à mesure qu'elles grandissent et qu'elles se soucient de la conformité etc. 

D'un point de vue technologique, il s'agit de connecter ce nouveau monde cloud natif aux exigences existantes de l'entreprise. Parce que beaucoup de ces problèmes étaient cachés par les fournisseurs de cloud public. Les fournisseurs de cloud public ont résolu les problèmes de conformité, mais ils n'ont ouvert aucune source ni publié quoi que ce soit ; ils ont résolu ça tout seuls. Cela fait partie de la valeur du nuage. Les entreprises doivent maintenant reconstruire et acheter cela si elles ne veulent pas s'enfermer dans les offres de cloud public.

D'où voyez-vous venir la prochaine vague d'innovation cloud native ? Est-ce que cela vient toujours d'une entreprise comme Google, ou y a-t-il un nouveau type d'entreprise qui mène la charge ?

C'est très intéressant. Je dirais que cela ne vient probablement pas des Google et des Facebook. La source d'innovation sera l'open source, et les clients et les utilisateurs à l'origine de la demande seront des entreprises situées à un niveau inférieur aux hyperscalers - des entreprises déjà importantes qui sont encore très perturbatrices, comme Adobe, Shopify ou GitHub. Mais aussi les entreprises risquant d'être perturbées par la technologie, comme les services financiers, les assureurs et les opérateurs de télécommunications. Ces entreprises ont toutes un intérêt commun à standardiser l'infrastructure avec des modèles de développement et d'infrastructure reproductibles.

Publié le 26 juillet 2022