Getty Images/iStockphoto
Observabilité : une fondation tente d’organiser la ruée vers eBPF
Facebook, Google, Isovalent, Netflix et Microsoft veulent canaliser les efforts autour de la technologie eBPF en instituant une fondation rattachée à la Linux Foundation. L’objectif ? Sortir cette technologie de supervision de réseau, de sécurité et d’observabilité de la jungle des expérimentations.
La semaine dernière, la Linux Foundation a annoncé la création d’une nouvelle filiale : la fondation eBPF. À sa tête, l’on retrouve des employés de Facebook, Google, Isovalent, Netflix et Microsoft. Cette structure est classiquement composée de deux parties. Un comité de gouvernance géré par les entreprises elles-mêmes doit se charger de trouver les financements, former les partenariats et administrer l’organisation au quotidien. Le comité de pilotage doit, lui, apporter des orientations techniques et s’exprimer au nom de la communauté. Reste à savoir pourquoi ces grands groupes se réunissent.
Tout commence avec trois lettres : BPF. Nés en 1992, les Berkeley Packet Filter (BPF - littéralement les filtres de paquets Berkeley, aussi connus sous l’appellation BSD Packet Filter) sont des filtres contenus dans une VM au sein du kernel Linux, développés pour UNIX afin de regrouper, de copier et d’envoyer des paquets réseau.
Du sigle à la technologie
Cela n’est plus forcément vrai aujourd’hui, selon Brendan Gregg, Senior Performance Engineer chez Netflix, et accessoirement créateur de la méthode USE. « BPF est le nom d’une technologie, non plus d’un sigle. BPF est un bytecode et un environnement d’exécution au sein au sein du kernel Linux utilisé pour la mise en place de cas d’usage de supervision réseau, de sécurité et d’observabilité », déclare-t-il lors de son intervention pendant l’eBPF Summit 2021 se déroulant du 18 au 19 août 2021.
En 2013, BPF connaît une évolution majeure avec la naissance du projet eBPF (pour extended Berkeley Packet Filter) mené par Alexei Starovoitov, ingénieur logiciel chargé du kernel Linux chez Facebook depuis 2015. Il a étendu les possibilités associées à cette machine virtuelle – renommée eBPF – en rendant possible le chargement de programmes légers comme des sondes à côté du kernel Linux, sans modifier le code du noyau lui-même. Rattachés à des ancres, ces scripts permettent de collecter des données sur le comportement des systèmes et de les contextualiser en quasi temps réel.
Auparavant, si un développeur d’une application réclamait un ajustement du kernel pour obtenir une fonction de supervision, cela prenait des années selon Thomas Graf, CTO et cofondateur d’Isovalent, cocréateur de Cilium, un outil d’analyse réseau et d’observabilité basé sur eBPF. Il fallait convaincre un développeur du kernel, puis toute la communauté, avant de voir la capacité poussée dans le noyau et « cinq années de plus avant de la voir apparaître dans les distributions commerciales ». « EBPF rend le kernel Linux programmable », affirme-t-il.
« Traditionnellement, Linux bénéficie d’une grande quantité d’outils de diagnostic. Cependant, cet écosystème provoque deux difficultés majeures. Une application réside sur tellement de couches et les données de diagnostic en provenance de ces couches n’ont pas forcément un haut niveau de granularité. Il est donc complexe de comprendre les effets d’un service ou d’une requête sur les sous-systèmes du kernel Linux », considère de son côté Jaana Dogan, ingénieure principale chez AWS.
« Deuxième point, cette profusion d’instruments, d’API et de commandes est difficile à gérer. C’est pour cela qu’est né eBPF », assure-t-elle. Seulement, cette technologie a généré un « intérêt explosif » d’après Thomas Graf.
« Brendan Gregg a participé à la création de nombreux outils disponibles dans une librairie nommée BCC (BPF Compiler Collection). Ils sont tous conçus pour répondre à un cas d’usage précis, sur la base d’une philosophie UNIX », déclarait Alexei Starovoitov en 2019, lors d’une conférence développeur de Facebook.
Ordonner la jungle de projets eBPF
Ce n’est que l’arbre qui cache la forêt. Tout un écosystème sauvage a pris forme.
Celui-ci serait constitué de quatre strates, selon Thomas Graf. La partie immergée de l’iceberg représente les cas d’usage liés à l’administration réseau, la sécurité et l’observabilité en entreprise.
« La couche juste en dessous correspond à celle des projets eBPF qui résolvent un ou plusieurs de ces cas d’usage et soumettent des solutions aux utilisateurs finaux. Cela inclut des projets comme BCC, Cilium, Falco, Katran, Hubble ou encore bpftrace. Il y a beaucoup d’autres », déclare le CTO d’Isovalent. Par exemple, New Relic a racheté Pixie Labs, et Splunk a repris Flowmill, tous deux proposant des produits open source basés sur eBPF, Pixie et Flowmill.
À un cran inférieur, l’on trouve les librairies employées par les projets nommés plus haut. Ces librairies sont généralement consacrées à un langage de programmation en particulier comme Go, C, C++, Rust et Python.
« Au plus bas niveau, réside le runtime eBPF, le vérificateur et le compilateur JIT associé au système d’exploitation Linux ».
EBPF est utilisé dans une large variété de cas d’usage. Facebook est le porteur du projet open source Katran, qu’il emploie en interne pour le load balancing et la mitigation DoS. Netflix s’appuie sur la librairie BCC et d’autres outils pour le profiling et les traces distribuées dans les applications. Google Cloud Platform s’est approprié l’outil Cilium, entre autres, pour monitorer le réseau, la sécurité réseau, l’observabilité et la répartition de charges dans les instances GKE et Anthos. Apple recourt au moteur de détection de menaces Falco, lui-même propulsé par eBPF, un projet créé par Sysdig. De son côté, AWS utilise plusieurs outils et implémentations d’eBPF pour superviser ses microservices dans des environnements Kubernetes et multitenant.
En raison de sa nature programmable, les doublons basés sur cette technologie prolifèrent, « Cilium et Hubble sont davantage portés sur les diagnostics réseau, la construction de cartographie de services, d’ajouts de contextes aux données. Pixie propose quelque chose de similaire et joint une partie profiling, tandis que Flowmill est axé sur les diagnostics réseau et la réduction de l’overhead », énumère Jaana Dogan.
Brendan GreggSenior Performance Engineer, Netflix
De son côté, Brendan Gregg recommande aux utilisateurs finaux d’installer et d’employer les librairies disponibles avant de développer de nouvelles fonctions. « Il faut penser comme un administrateur système, moins comme un programmeur », déclare le même individu qui a largement contribué à cette prolifération.
C’est ce qui a motivé la création de la fondation eBPF. « Quand nous parlons d’eBPF aujourd’hui, en particulier dans le contexte de la fondation, nous nous référons à la totalité de la stack », précise Thomas Graf. Dans les bouches de Brendan Gregg et d’Alexei Starovoitov, le sigle ne désigne que la couche technique agissant comme une extension du kernel Linux. « Nous voulons favoriser une meilleure collaboration entre les différents projets et nous assurer qu’eBPF lui-même est extensible à d’autres plateformes. Par exemple, nous souhaitons le rendre compatible avec le kernel Windows », ajoute-t-il.
Une technologie complexe à prendre en main
Le comité de pilotage a clairement du pain sur la planche. L’on y retrouve les deux ingénieurs de Facebook et Netflix évoqués plus haut, deux collaborateurs d’Isovalent, un autre membre des équipes Facebook et deux responsables de projets maintenus chez Google (eBPF LSM) et Microsoft (eBPF for Microsoft).
Les membres de ce comité ont soit participé à la création du framework, soit à son développement ces deux dernières années. « La fondation eBPF souhaite que son comité de pilotage reflète sa politique basée sur les contributions », vante Thomas Graf.
En l’état, la nouvelle structure ne rassemble pas tous les efforts en la matière. La technologie Pixie a été confiée à la CNCF par New Relic et Splunk a donné le collecteur Flowmill au projet OpenTelemetry, également supporté par la filiale de la Linux Foundation.
Techniquement, selon Jaana Dogan, il manquerait à eBPF un langage plus haut niveau pour programmer les sondes, il faut également rendre les agents plus largement disponibles, que davantage de systèmes d’exploitation et plateformes supportent la technologie et il faut rendre les traitements d’événements plus standards afin de faciliter la réutilisation des pipelines et l’agrégation de données.
Sylvain HellegouarchCofondateur et CTO, Reliably
Sylvain Hellegouarch, cofondateur et CTO de Reliably, l’éditeur d’un kit d’outils dédié au chaos engineering, témoignait de ses débuts avec les technologies racines d’eBPF en partant de son expérience de SRE. « La courbe d’apprentissage d’eBPF est sinueuse. La documentation part un peu dans tous les sens et l’UX est rudimentaire », déclare-t-il. « Mais cela peut se comprendre, ce n’est pas un projet dont le développement est dirigé par des intérêts commerciaux. C’est un outil accessible depuis l’interface du kernel Linux. Cela veut aussi dire qu’il faut vraiment se pencher dessus pour réellement comprendre ce qu’il se passe quand vous l’utilisez ».
Par exemple, il est difficile d’estimer le nombre maximum de sondes eBPF possiblement déployables avant que cela affecte les performances de votre système.
En outre, les composants ne sont pas packagés comme la plupart des outils open source disponibles actuellement, selon le CTO. « Tout n’est pas accessible aujourd’hui, mais je recommande aux SRE de tester cette technologie déjà très puissante, peut être en commençant par des produits plus haut niveau tel Hubble, Falco ou bien ply ».
« Nous sommes au début de l’ère BPF et il y a encore beaucoup de choses à explorer », écrit Brendan Gregg dans un billet de blog. Cela n’empêche pas Thomas Graf de promouvoir la technologie comme le futur du maillage de services et de l’observabilité.