 Ok, donc, on commence. Je pense qu'on va avoir quelques slides au début. Donc, même si les gens sont un petit peu tard, ils vont être en temps pour le workshop. Alors, bonjour, tout le monde. Mon nom est Denis Jeannot. Je suis le directeur de la équipe d'engineering solution dans EMEA à solo.io. Je vais présenter le workshop avec Christian. Tu veux vous interpréter ? Oui, bonjour tout le monde. Mon nom est Christian Fakata. Je travaille dans le team Denis. Dans l'équipe d'engineering solution de l'Europe. Et oui, on va faire ce workshop-là ensemble. Lene est en approchage. Elle n'est pas capable de joindre. Mais elle a travaillé avec nous pour préparer le workshop. Je veux vous dire merci à elle. Ce que nous allons faire, comme je l'ai dit, pour les gens qui sont déjà là, nous allons aller à quelques slides pour introduire les concepts de la main de l'EBPF. Et puis nous allons utiliser l'instruct plateforme pour faire le workshop. Donc vous allez tous avoir accès à ce workshop. Nous allons encore partager le lien dans quelques minutes. Peut-être qu'on peut le faire maintenant, si j'en parle, oui. Et s'il vous plait, ne cliquez pas sur le start. Parce que si vous cliquez sur le start, vous allez profiter tout. Et puis, si vous ne l'utilisez pas pour quelque temps, ça se termine. Et quand nous allons être prêts à commencer, vous devez le faire de nouveau. Donc le start devrait être assez rapide. Comme je l'ai mentionné, pour les gens qui ne sont pas là à ce moment, nous vous donnons beaucoup d'options. Vous pouvez juste regarder à nous faire ça. Ou vous pouvez le faire en même temps que nous le faisons. Ou vous pouvez utiliser ce lien jusqu'à la fin de la nuit, si vous voulez le faire plus tard. Donc c'est assez flexible. Donc je pense que nous pouvons juste commencer. Et aussi, nous voulons essayer de le faire interactif. Nous avons 90 minutes, ce qui est assez d'un bon nombre de temps pour pouvoir prendre notre temps. Et si vous avez une question, vous pouvez juste, vous savez, aller par ces microphones qu'il y a une année. Et je pense qu'ils vont avoir une là-bas aussi. Donc si vous avez une question, vous pouvez vraiment ressentir vos mains et aller à ces microphones. Parce que nous allons essayer de faire des breaks à un moment juste pour vous donner du temps à poser des questions, comme peut-être à l'end of the slides, pour exemple. Mais oui, nous allons essayer de le faire interactif, même si c'est compliqué avec so many people in the room. Mais oui, nous voulons vraiment essayer de répondre à ces questions que vous pouvez avoir. Donc Christian, la flore est yours. All right. Donc, comme Donny m'a mentionné, nous avons quelques slides introduits et le début de la vidéo. Juste pour vous donner un peu de l'aéroport sur ce que l'EVPF est, ce que vous pouvez faire avec ce qu'il y a d'autres cas de utilisation. Et juste pour comprendre la implementation technologique, et après ça, on va utiliser un projet d'open source pour vous rendre plus facile. Parce que l'EVPF peut encore être un peu spécifique pour des gens. Donc, peut-être que vous savez ce qu'est l'EVPF, de l'audience, peut-être que je vois des mains, si vous savez ce qu'est l'EVPF. Ah, ok, donc peut-être que ce sera une session d'introduction, donc c'est comme un niveau débutant, mais il y aura encore une manière assez intéressante de développer, de faire des shoots et de déployer les programmes de l'EVPF. Donc, ce qu'est l'EVPF, beaucoup de vous connaissent déjà ce qu'est l'EVPF et basé sur les mains que je vois, mais l'EVPF c'est en fait une façon flexible pour injecter un certain logiciel dans le kernel. Il y a beaucoup de cas de utilisation, pourquoi ça pourrait être une bonne idée et les approches précédentes n'étaient pas les plus grandes pour externer les capacités du kernel. Parce que l'une des cas de utilisation pour l'EVPF, c'est de l'observité. C'est bien, vous pouvez faire des choses customaires dans le kernel, mais si vous êtes... Avant l'EVPF, c'était assez difficile de mettre le logiciel customaire, de rébuilder votre kernel, d'utiliser le kernel, pour exemple, et ce n'était pas quelque chose que vous pouvez faire facilement dans la production. Votre sécurité et les autres plateformes, avant l'EVPF, vous n'avez probablement pas mal à ajouter un kernel customaire pour les machines de production, parce que n'est-ce pas bien. L'EVPF est ici pour aider. Comme je l'ai mentionné, vous pouvez faire des programmes de performance que vous pouvez juste injecter dans le kernel et évoquer ce logiciel que vous avez injecté. C'est aussi un safe way d'injecter un certain logiciel dans le kernel, parce qu'il y a un feu, donc... Il y a un processus qui doit être... Le premier step est de utiliser le logiciel au vérifier, et si le vérifier a des choses que ce code peut cacher votre kernel, il ne va pas le charger, ce qui est une bonne chose à faire, parce que sinon, votre machine de production peut juste mourir dans le spot. Et c'est aussi une bonne performance. Et... l'EVPF est utilisé par l'EVPF comme l'analyse de la technologie, originalement, c'est la même technologie que l'on utilise pour la TCP, par exemple. Mais l'EVPF est, à dire, plus moderne façon de faire des choses similaires. Comme je l'ai mentionné, il y a des outils de utilisation. Vous pouvez voir les quatre principales catégories ici. La sécurité. Pourquoi la sécurité est importante? Si vous avez... Si vous avez une façon d'observer ce qui se passe dans le kernel, la team de sécurité serait vraiment heureuse d'avoir ces capacités, et de pouvoir faire des outils d'addition sur les méthodes précédentes qui sont disponibles. Vous pouvez aussi faire des traces en profilant. Vous pouvez extraire des informations par rapport à l'application. Vous pouvez correler cette information avec d'autres données qui sont assurées par le kernel. Il y a des outils de utilisation. Par exemple, Syllium utilise l'EVPF à un moment pour résoudre des outils de utilisation. Et comme je l'ai mentionné, il y a des outils de utilisation qui sont aussi assez intéressants parce que vous pouvez facilement extraire ces informations par rapport à l'application de l'EVPF. Durant ce workshop, nous serons plus focussés sur l'utilisation de l'observité. Si quelqu'un n'a pas pas... Si quelqu'un n'a pas la vraie picture de comment l'EVPF peut travailler, je pense que c'est la meilleure picture que vous pouvez utiliser pour comprendre ce qui se passe et ce sont les compétences si nous parlons de l'EVPF. Comme vous pouvez le voir, il y a un programme d'utilisation à la gauche et il y a un kernel à l'arrière de la droite. Vous avez besoin de les deux parce que vous avez besoin d'avoir un moyen d'injecter cette logique dans le kernel. Le kernel sur la droite est la partie de l'EVPF qui est la plus intéressante parce que c'est où l'EVPF magie arrive. C'est le endroit où vous pouvez spécifier votre logique custom que vous voulez injecter dans le kernel. Le programme d'utilisation, la partie de l'espoir d'utilisation est plus comme une chose que vous devez faire pour pouvoir visualiser l'information, par exemple, qui est à l'arrière de la kernel, mais ce n'est pas excitant. Vous devez décoller pour visualiser ce qui se passe. Vous devez contrôler l'input d'utilisation. C'est quelque chose que vous devez faire mais ce n'est pas important. Et c'est pourquoi ce talk est assez excitant parce que après le talk, vous devez avoir une bonne et facile façon de faire attention à la partie de l'espoir de l'EVPF qui est le plus excitant, comme je l'ai mentionné, et on va basically utiliser les pro-meteuse pour prendre soin de la partie de l'espoir d'utilisation, si vous voulez. Alors, nous allons parler un peu de ce qui se passe ici. Donc, vous devez trouver ce custom pour prendre la partie de l'espoir. C'est celle-ci que vous avez acheté à l'égrement de l'espoir. Après ceci, le carnet fait de vérifier le programcle actuale de l'espoir et si il est vérifié et il n'y a pas d'issu ensuite, vous pouvez le prendre sur l'espoir de l'espoir d'espoir de l'EVPF. Le rectangle d'espoir est le custom logique que vous avez évoqué. Le EVPF est landlords et affaires. Ça veut dire qu'on obliged On dirait quels sont les options que vous avez dans le kernel. Ce sont des proches K, kernel, proches U, proches Therese. Ce sont des points différents dans le kernel. Et quand le kernel atteint ces proches, cela exécutera la logique custom que vous voulez injecter. C'est pourquoi j'ai dit que c'est comme une approche d'architecture. Après que votre logique custom soit exécuté, l'output de la logique que vous avez injecté va être installé dans les maps. Ces maps sont la façon d'attendre les données du kernel et d'attendre la surface sur le site de l'usage. Vous mettez tous ces événements et des données que vous avez injectées dans le kernel et que vous êtes basé sur la map de l'usage. Après cela, la logique est visualisée. Bumblebee est un projet d'architecture que nous serons utilisés à l'avenir. Mais avant cela, nous ferons aussi la façon traditionnelle d'interromper avec les programmes d'EBPS. Ce sont les programmes qui ont été créés par Brandon Gregg pendant que c'était sur Netflix. Ce sont des programmes standard d'EBPS que la plupart des programmes d'EBPS sont utilisés à l'avenir. Ce qu'on va faire, c'est qu'on regarde l'ecosystème existant qui est à l'extérieur de Github. Nous serons utilisés à Bumblebee pour l'architecture. C'est une image OCI, c'est comme une image docker, si vous voulez. Vous pouvez mettre cela dans des repos locales ou de nouvelles repositions. C'est une façon assez belle et cloud native pour consommer ces programmes d'EBPS. Comme je l'ai mentionné, vous ne devez même pas penser à l'espèce d'utilisation, de la responsabilité et de ces tests parce qu'avec Bumblebee, vous pouvez auto-générer des magasins primitives d'une certaine façon, qui est assez belle, car dans la cloud native l'infrastructure vous êtes probablement déjà sur les primitives. Je pense que c'était l'introduction que nous avons. C'est un lien que vous pouvez utiliser pour accéder à la plateforme de l'instruct que nous serons utilisés. Pour la première partie, je vais l'aider à Danny. Je vais attendre quelques secondes pour que vous puissiez ajouter l'environnement, si nécessaire. Si vous pouvez maintenant tous aller à ce lien, je vais juste le garder un peu plus de secondes et je vais switcher à l'interface de l'instruct. Maintenant, vous pouvez cliquer sur le bouton de jouer pour commencer le workshop. Donc, ce qui va arriver à l'arrivée, c'est qu'il va provisioner une machine virtuelle pour tous de vous. Et dans cette machine virtuelle, nous allons jouer avec l'EBPF et nous allons déployer le cluster de cubains. On va construire un très simple tool de observabilité de scratch pour visualiser le trafic dans votre cluster de cubains. Donc, vous avez un exemple pratique. Et puis, Christian va aussi aller faire quelques plus d'advences de l'utilisation, qui vous permet d'utiliser l'EBPF pour les utilisations de l'utilisation de networking, mais aussi pour l'opération de trafic, ou tout ce qu'on veut d'intercepter dans votre kernel. Donc, je vais maintenant exécuter ceci et aller à l'instruct lab ici. Et après que vous cliquez sur le bouton de jouer, il devrait prendre deux minutes, peut-être, pas plus, parce que c'est juste la provision de l'EBPF. Évidemment, nous sommes beaucoup de gens, mais l'instruct est assez robuste. Nous avons déjà fait un workshop pour 500 personnes ou plus. Ça devrait être bien, mais qui le sait, quand nous essayons de faire 500 provision de l'EBPF, ça peut être un peu difficile. Je vais juste attendre 4 minutes. En 1 minute, je vais vous asker si vous avez tout prêt. Donc, nous avons une idée, mais si tout semble works well. Et puis, nous allons commencer. Vous pouvez voir le crème, d'ailleurs, ou peut-être essayer de le faire un peu plus grand? Ça ressemble bien, surtout sur le côté gauche, peut-être un peu plus petit. Je vais essayer de le faire plus grand. Il y a un texte sur la droite, mais c'est plutôt comme pour vous, quand vous le faites sur votre propre. Si vous êtes dans la salle et vous êtes en train de nous entendre, vous n'aurez pas besoin de lire le tout. Vous pouvez juste focusser sur le terminale à la gauche. Ça ressemble bien. Cool, merci. Donc, nous allons voir où nous sommes maintenant. Est-ce que vous pouvez tous raise votre main si c'est prêt sur votre côté? Ça ressemble bien. Nous sommes probablement prêts à aller. Parfait. Donc, pour les gens qui connaissent probablement dans cette salle, comme Kelsy, quand il a fait cette cuberture, c'est le HardWay. Nous essayons de faire le HardWay et puis nous allons vous montrer comment le faire un peu plus simple. Et nous allons commencer avec un peu d'histoire. Donc, vous pouvez lire ce texte plus tard, mais c'est basiquement un summary de ce que Christian a dit avant. Donc, si vous n'oubliez pas ce que Christian a dit et que vous voulez faire le lab dans le week-end, vous pouvez lire ce paragraph et obtenir la même explication. Ce que nous allons faire ici, c'est que nous allons vous montrer comment faire compiler eBPF programme sans Bumblebee. Nous allons vous montrer comment les gens ont fait ça au début avec quelque chose qui s'appelle BCC. Et puis, nous allons vous donner comment les gens le font aujourd'hui, avec LeapBPF. Et nous allons vous montrer comment le faire avec Bumblebee. Donc, le premier approche qui était disponible était d'utiliser BCC qui était quelque chose qui était utilisé par Python. Donc, c'était vraiment une bonne idée parce que Python n'est pas trop compliquée d'utiliser et beaucoup de gens sont confortables d'utiliser. Le challenge est que si vous vous souvenez de ce que Christian explique, vous avez ce programme user space et vous avez le programme kernel et basiquement, le programme space contains le programme kernel et si vous regardez le programme BCC dans Python, vous verrez que vous avez un string dans le milieu qui représente le programme kernel que j'ai voulu dans C. Vous avez un programme Python mais vous devez mettre un string dans votre C programme dans le milieu et c'est là où vous avez le plus important logiciel. Donc, avoir le reste dans Python n'a pas aidé beaucoup et c'était aussi un peu confusant de faire ça de cette façon d'être capable de vérifier si le code est valide et imaginer si vous voulez utiliser un code VS et tout ça, c'est pas idéal. Et le autre problème est que quand vous lavez dans ce programme vous avez une dépendance dans votre kernel et vous avez besoin d'avoir le Linux kernel headers ce n'est pas quelque chose que vous voulez que ce soit le package que vous voulez mettre dans votre cluster de production c'était une bonne approche pour expérimenter avec ça et jouer avec ça mais pas pour avoir une binary portable que vous pouvez déployer. Nous allons commencer dans le programme et vous voyez que chaque fois que vous avez un commande qui utilise cette direction de data vous pouvez aussi aller au file ici et dans la direction de data vous pouvez voir que nous avons utilisé le BCC ici donc c'est un peu plus beau pour voir ce que le programme fait de cette façon pour être exécuté chaque fois qu'il y a ce TCP connect et ça fait différentes choses et puis ce que nous avons vu ici c'est que le logic de le programme Python c'est que je veux loader ce programme et puis je veux continuer de lire des messages sur cette map donc vous vous souvenez que Christian a parlé sur cette map qui est dans le kernel que le programme d'utilisation peut lire en fait dans les cas de utilisation on va vous montrer même quand vous faites à la fin Christian vous n'aurez pas le droit à la map, c'est juste de lire dans les cas où nous faisons oui, dans l'utilisation de l'utilisation c'est plus de temps que de lire de cette information parce que vous êtes intéressés en quoi vous pouvez sortir un logic custom à l'intérieur de ça ce n'est pas quelque chose qui est assez commun pour l'utilisation de l'authenticité exactement, pour cet utilisation ce n'est pas commun mais c'est un moyen pour qui vous pouvez faire un changement de comportement vous avez votre programme kernel vous pouvez lire quelque chose dans la map d'un programme d'utilisation pour que le logic kernel read ce que vous avez dans la map et dire que le programme d'utilisation me dit que maintenant je dois donc c'est aussi un moyen c'est une 2-way interaction si vous voulez et puis il juste print ce qu'il y a donc c'est assez basique donc si je vais ici vous avez ce généralement speaking, vous avez ce play button ici quelque chose qu'ils ont ajouté après, nous avons construit le workshop initialement, donc on a essayé de le mettre partout mais il y a des instructions mais vous verrez la plupart du temps vous avez juste un play button c'est beaucoup plus convaincu donc ici, c'est tout ce que je disais et chaque fois qu'il y a une communication network ce tcp connect s'occupe c'est juste de l'adresse source et destination c'est un exemple assez basique donc maintenant on parle de la 2e et dans la communauté d'open source vous savez généralement, vous avez plusieurs projets qui compitent entre l'un et l'autre mais c'est assez intéressant quand vous commencez à apprendre de l'EBPF et vous commencez à regarder BCC et LibBPF et tout c'est la première fois que j'ai vu que ces 2 très différentes options elles sont dans le même repos donc dans le même repository vous avez le BCC original approche et le LibBPF approche est basiquement en utilisant seulement C donc vous avez le programme user en C et le programme kernel en C et la autre différence c'est que c'est plus portable donc vous n'avez pas besoin d'avoir ces kernel headers déployés dans la machine dans l'opérating system donc ça le fait très portable vous pouvez compiler et puis vous pouvez copier la binary dans un VM ou un server et puis vous pouvez commencer à l'utiliser et vous le voyez aussi dans Bumblebee que nous avons travaillé sur cette portabilité et en faisant ça un petit peu plus facile que juste en faisant un copier ou SSH donc, encore une fois vous pouvez aller dans cette file tab et vous pouvez voir les différents files et vous pouvez voir deux mains vous avez l'un qui s'appelle BPF.C qui est basiquement votre programme kernel et ensuite vous avez l'un qui s'appelle CERE qui est votre programme user donc vous voyez que le programme user c'est vraiment j'ai envie de loader mon programme kernel et j'ai des erreurs en ligne si je ne peux pas loader et puis, dès que c'est loadé je vais toujours exécuter cette fonction print et cette fonction basiquement est, encore une fois, reculter la data du map dans le kernel pour déployer cette information et ce que ça fait est d'avoir cette attachement à deux différents procs donc ça dit que je veux attaquer à cette TCP avant connect je veux attaquer cette inter TCP connect fonction et vous pouvez voir cette fonction qui est un petit peu ici vous avez des informations et des updates sur le map cette fameuse map qui peut être reculée par le programme user et vous voyez ici que nous défendons ces maps par exemple, ici dans ce cas spécifique nous avons cette map qui est de type hash et nous allons aller dans tous les détails de ça mais dans le texte ici vous verrez plus d'informations et l'autre qui est un map hash selon votre utilisation vous choisissez l'un ou l'autre et ici, ce que nous faisons c'est que nous avons cette clé sur cette map et la valeur et la valeur est juste un numéro mais la clé est la structure qui est cette structure ici donc ce qui veut dire c'est que je vais contacter mon source et le IP address et ma valeur va être un counter et si je retourne ici et si je exécute ce command here, vous voyez juste un binary comme je vous dis, c'est très portable dès que vous avez compilé vous pouvez juste couper ce binary dans une autre machine vous pouvez juste couper c'est juste un binary parce que ce binary est le programme source qui contente le programme kernel qu'il a besoin d'un load donc je rentre ici je ne suis pas dans le droit je pense que je l'ai compilé mais nous allons le faire maintenant donc nous avons juste copié les files vous voyez le playbutton, c'est un peu mieux et nous faisons ce make TCP connect ce n'est pas ce qui va compilé ce programme pour que nous recevons ce single binary et après ça on va pouvoir le rouler une autre différence entre le traditionnel BCC et l'EBPF implementation c'est la performance nous ne pourrions pas faire ça maintenant mais quand vous faites le même lab à la maison ce que vous pouvez faire c'est que vous avez deux terminaux ici donc vous pouvez commencer le programme BCC en même temps, quand vous commencez le code de TCP que nous sommes construits ici et si vous comparez l'utilisation de CPU entre les deux processus vous verrez que l'une de l'ancienne l'une de l'ancienne BCC consomme beaucoup plus de CPU parce que c'est pas l'exécution de runtime il faut compilé tout à l'heure et surtout quand vous commencez vous verrez un maximum de CPU et c'est une autre raison pourquoi l'EBPF-Based Tooling c'est mieux parce que sur le service de production vous ne pourriez pas compilé quelque chose qui consomme beaucoup de CPU parce que vous avez des applications d'application c'est très intéressant d'y ajouter pourquoi personne n'est utilisé en production donc vous voyez l'output est ce que nous espérons la seule différence de l'autre programme qu'on avait avant c'est que vous voyez un counter plutôt que de dédié le source et le target tout le temps nous nous indiquons beaucoup d'occurrences qu'on a de ça donc c'est la fin de cette section qui est l'EBPF Hardware qui n'est pas si difficile il y a des technologies qui sont plus difficiles ce qui est très difficile c'est d'écrire ce code C c'est comme si je me demande combien de gens peuvent écrire un programme en Python combien de gens maintenant peuvent écrire un programme en C plus ou moins mais je dois admettre plus que ce que j'ai généralement c'est très intéressant donc nous allons faire le même avec Bumblebee et peut-être une chose que je n'ai pas montré très clairement c'est que aussi le programme en self le programme C correspond à le kernel dans BCC et LibPF il n'y a rien à faire il n'y a pas de syntaxe c'était pas le même code le code de BCC que celui de LibPF je pense que je peux encore le voir ici si je regarde la logique de BCC le programme C ici vous pouvez voir la façon dont la map est définie est complètement différente et la façon dont c'est en LibPF tout ce logic ici est complètement différent il utilise des autres libraries pour le faire la façon dont ça fonctionne avec LibPF où vous avez ces multilèges pour décrire les maps tout le code est complètement différent donc l'idée de Bumblebee n'est pas de venir avec une troisième option n'est pas de venir avec une troisième façon de développer ça c'est vraiment de simplifier la façon dont vous faites avec l'approche de LibPF donc on ne va pas toucher le code beaucoup on va utiliser des conventions pour légèrement ajuster le code que nous avons utilisé mais vraiment légèrement mais l'idée c'est de vraiment vous aider à commencer très rapidement sans avoir de risques de la dépendance d'autres outils pour pouvoir compiler le code C et aussi pour vous aider à contrôler le cycle de vie donc vous pouvez déployer Bumblebee de cette façon oh je dois aller vers le terminale ici c'est mieux et c'est un projet d'open source que l'on a avancé il y a un moment et le but était vraiment de faire ça plus simple pour commencer de jouer avec LibPF et d'adopter ça mais notre but est vraiment d'avoir as many people as possible interested to make this project like a living project with many updates and so on right now it has been really just us and a few other companies but we will be happy to have a lot more contribution in the project so when you do this B in it that's the first thing we do if it's your really first eBPF program instead of starting with like blank page you can just run this B in it's command and it's going to ask you a few questions like is it like for the network use case or is it like a file system use case if it's a network use case then what type of map do you want to use so as I say you have this ring buffer and hash map and I don't know do you want to speak about like the difference quickly right? I think we can do that at a later stage because in the last lab I will have I will go through an actual example of what kind of changes you have to make to take an existing code and port that into bumblebee and I think that's a better way to perfect, I don't want to confuse people at that stage as well so here we choose a hash map and then you can decide do you want to just like print the value as they come or you want to have a type of counter or goge and you will see why as well because we are going to show you some nice output that we can get from the program and then you can decide how you want to call the program so here we just like call it like prop.c and that's a fully functional program that looks like this here and it doesn't do much but the goal is just to allow you to get started right so that you have like already an example to start with we are not going to compile this one it doesn't really make so much chance it's just to show you that we have this like init command to get some skeleton ready for you what we are going to do instead we are going to go back to this tcp connect example that was the program we have used in the previous lab with libbpf and we are going to do a small I said the goal of the project is not to give a third option the goal of the project is really to make it simpler to use libbpf if you wish right so what we want we don't want to modify the code we want to do like the modification as small as possible and the only thing we need to do in that case is basically to add a naming convention to the map so you see if I do a diff between the program that we have used just before the problem we are going to use now the only difference is that we have added here this dot counter as a suffix of the dot maps and that's enough for Bumblebee to know that oh this map I want it to act as a counter and you will see that we are going to emit some matrix and these matrix will be emitted with the right type because of this additional information we have added but the program, everything else stay exactly the same so if I copy this file here and I want to build it the idea was really to take the docker experience right like nothing is better than this like docker build docker run all these things like docker push that's why people love docker it's like this user experience so the goal was kind of trying to do the same so here we do not a docker build but we do a B build and the first thing that is nice with this command is that you don't need any dependency in your machine because it is going to get a docker image behind the scene that has all the prerequisites to compile the program so the first time you do it it takes like perhaps 30 seconds to compile the image but the second time you do it is very quick because the docker image that is used with all these dependencies to compile the code is already in your laptop so the second time you run this command it takes like 3 seconds perhaps like 4 seconds and the other thing that is interesting is that we when we build it we are generating an output which is in a directory I think it's even like a hidden directory so you can get the binary if you want to just execute it but what we do is also we are created as an OCI image so that we can use the portability of the OCI images I'm pretty sure everyone knows OCI image but that's kind of the same format that is used by docker writes so it's a way for us to again not only help compiling but also help distributing the program that has been built so because I have this OCI image now I can do a docker push to this local 5000 I do look at my docker engineer I can see that this is a registry and basically this is just a standard open source docker registry because I have an OCI image I can just push it to any OCI compliant registry basically so I do I have built it then I have pushed it now obviously I want to assign it so that's the last option that you generally use when you do something with docker so same idea I do a B run and I give the image name and you have a UI kind of UI not a UI but like you know what I mean you have like an output that is a little bit nicer but I can just update the value instead of always adding the new line again and again but that's obviously the goal is not to launch a program and to watch this interface some use cases why not you want to create a debugging tool you may be happy to see the output here but what we believe is a lot more powerful le programme est pour émettre des métriques pour que vous puissiez obtenir cette information ici, à l'aide des métriques de Prometheus. Donc si je vais au second tab et j'ai rendu ce commentaire, vous pouvez voir ici que je l'ai à l'envers je pense, vous voyez ici que je l'ai à l'aide des métriques qui basiquement montrent l'adresse source et l'adresse destination et le nombre d'occurrences basicalement. Donc la même chose que je vois ici, je le vois comme des métriques et parce qu'ils sont des métriques de Prometheus, ça peut évoquer beaucoup de cas de utilisation, parce que je peux évoquer ces métriques, store-t-elles en Prometheus, peut construire la graphe et la dashboard au-dessus de ça, donc dans l'observabilité du côté, ça ouvre beaucoup de différents cas de utilisation. Donc c'est tout pour l'overview de Bumblebee et nous allons maintenant déployer l'occurrence des métriques et essayer de vous montrer comment nous pouvons utiliser un programme comme ça pour vous montrer ce que sont les différentes communications qui se passent dans votre métriques. Peut-être que avant de faire ça, il y a une question, c'est bon, n'hésitez pas, si vous avez une question, raise vos mains et on va faire un petit break dans la présentation pour essayer de répondre à ça. Oh, il y a peut-être une question là. Oui, vous avez un microphone juste ici. Oui, merci, nous avons toujours besoin d'un breaker de l'oeil, le premier qui a demandé une question. Oh, on ne peut pas vous entendre, je vais le faire mieux. C'est tout le monde. Merci. Merci beaucoup pour le workshop. J'ai une question comme ce générateur, c'est le C-Sharp code. Est-ce possible d'avoir un autre générateur pour Golan, pour exemple, ou est-ce que c'est seulement pour le C, quand on parle d'EBPF et ce genre de choses ? Oui, c'est vraiment seulement pour le C, mais vous voyez, on l'a construit quand, à la première fois, quand vous faites l'EBPF, on vous demandait quelle langue, donc on a fait ça en gardant en compte qu'il y a peut-être d'autres options, mais Bumblebee est vraiment juste en faisant ça avec le C. Mais c'est pour l'EBPF, c'est traditionnel, l'actual code kernel que vous avez écrit pour l'EBPF, c'est either C ou Rust. Le C-Sharp code est plus comme une langue d'usage, il n'est pas performant et assez sécurité pour le kernel, c'est la raison pour laquelle la plupart des fois c'est C ou Rust. Mais la support Rust serait bien, si nous avons des développeurs Rust, et vous êtes intéressés en faisant ce générateur pour ajouter un nouveau futur, tous les contributaires sont plus que bienvenus. Il y a combien de développeurs Rust qu'il y a dans la salle ? C'est drôle, c'est un EBPF et nous n'avons pas un seul développeur Rust. Nous avons un, ici. Oui, c'est bien. Je suis sûr que si nous avons la même question dans deux ou trois ans, ce sera un numéro différent. Donc ici, ce qu'on va faire, c'est qu'on va déployer, il y a un cluster, je l'ai oublié, je pense que l'on a déjà fait, en fait, au début, quand vous faites... Je ne me souviens pas d'où nous déployons, mais de toute façon, vous pouvez juste créer cet espace-là et ce que nous déployons ici c'est l'application de l'info, donc pour les gens qui jouent parfois avec Istio, vous êtes peut-être déjà aware de cette application, c'est juste une application qui a plusieurs microservices parce que, comme je l'ai dit, notre goal est d'être capable de déployer à quel service, à quel service dans le cluster, donc nous devons avoir quelques interactions, donc nous avons juste déployé ce programme ici et nous avons juste attendu pour tous les postes pour être en train, ça devrait être assez rapide. C'est déjà là, parfait. Et puis, nous allons aussi déployer les promotives parce que vous vous souvenez, j'ai dit que nous pouvons émettre quelques métriques, donc ce que nous voulons faire ici c'est de collectir ces métriques et les installer dans les promotives, donc nous allons juste créer cet espace-là et nous installons les promotives et puis ce que nous allons faire, c'est parce que nous avons une image OCI, c'est très facile de déployer ce programme donc nous allons juste faire ça, mais nous ne allons pas déployer l'image OCI que j'ai construite avant. Mais, ce que nous faisons c'est que nous déployons un image docker qui contente le BCLI, parce que ce que nous voulons c'est un programme qui est capable de déployer ce programme qu'on a construit dans le kernel. Je sais que cette partie peut être un peu confusée, parce que c'est une image OCI que nous avons construite, mais ce n'est pas une image OCI que vous pouvez déployer sur le docker. C'est une image OCI qui est juste comme le programme d'EBPF que nous avons construite. Ce que nous avons besoin de déployer dans les Kubernetes c'est une image docker qui contente le BCLI qui contente le programme dans le kernel. Ce que vous voyez ici dans le set démon c'est que nous disons que nous voulons utiliser cette image docker qui a le BCLI et ce sont les arguments. Les arguments sont bi-run insecure, parce que nous allons obtenir ça par la registre qui est juste comme un plan HTTP-1 et nous donnons le nom de cette image qu'on a construite avant. En ce cas, ce n'est pas appelé localhost 5000 comme avant, c'est appelé master parce que master est le nom de mon VM et le cluster de Kubernetes est aussi en train d'utiliser ce VM, donc il sait comment atteindre cette registre. Donc quand nous déployons ce set démon ce qui va arriver est qu'à chaque node de mon cluster de Kubernetes je vais obtenir basiquement cette Bumblebee image déployée et cette image est allée charger le programme que nous avons construit avant. Donc la même chose que nous avons fait avant. Pas de modification, c'est juste que on le run de cette façon. Donc si je fais un code pour obtenir un code qui est passée dans la numérant des noms, et avant nous déployons l'application dans les noms différents ici. Mais maintenant, et c'est ce que j'ai probablement oublié de vous montrer, c'est que je pense que je vais vous montrer un peu plus tard. Mais nous avons plusieurs nodes, parce que la idée c'est aussi de vous montrer comment nous pouvons l'utiliser pour cacher parce que nous avons ces matrices des métriques qui sont émitées par le programme. Nous allons coller les programmes dans les différents nodes de la cluster et installer cela dans les promoteurs communs. Donc, c'est maintenant en cours. Je dois maintenant créer ce code monitor pour coller les métriques sur le set démon. Si vous êtes familial avec les promoteurs, vous avez différentes manières à faire ça. Vous pouvez utiliser les annotations ou vous pouvez utiliser un code monitor. Alors, cela dit que maintenant je veux coller tous ces métriques et les installer dans les promoteurs. Et ensuite, vous pouvez générer un peu de trafic. Juste générer un peu de trafic pour que maintenant ma application soit utilisée. Donc, ces communications sont arrivées. Alors, où sommes-nous? Nous avons notre programme ABPF qui est vraiment un programme basique qui a un adresse source, un adresse destination, un nombre de communications. Nous avons cela pour chaque node. Et vous savez que les codes ont ces codes IP. Et les services ont ces services IP. Donc, ce que nous avons maintenant dans les promoteurs en réalité, c'est que nous avons ces métriques qui disent que le code IP parle de service IP. Le code IP parle de service IP. Le code IP parle de service IP. Ce qui est assez bien déjà, mais vous voulez quelque chose de mieux. Vous voulez pouvoir connaître le code name pour le service name. Le code name pour le service name. C'est beaucoup mieux. Donc, pour cela, nous avons un programme qui est juste un programme démo qui s'appelle KBPF. Et ce que ce programme va faire est qu'on va déployer ici. C'est un programme qui va... Et peut-être que ceci peut le faire plus grand. Donc, ce que ça va faire, c'est qu'on va aller à la promoteuse, faire des enquêtes pour obtenir toutes ces informations. Donc, ça va avoir toutes ces informations que je vais avoir comme source IP, code IP, service IP, code IP, service IP. Et ce que ça fait, c'est aussi que l'appli de la service IP pour savoir ce que le code name correspond à ce code IP ou ce que le service IP correspond à ce code IP. Alors que, en lieu de déployer l'appli de la service IP à tous les adresses, nous pouvons déployer quelque chose qui fait du sens. Et ça fait ça. Et ensuite, c'est tout simplement déployé dans un UI pour que vous puissiez voir ce qui se passe. Donc, je l'ai déployé ici. Et maintenant, si tout va bien, vous pouvez aller là-bas, vous pouvez refresh it. Et vous pouvez voir ici, vous pouvez voir que j'ai beaucoup de communications qui se passent. J'ai l'appli de la service product page qui parle du service review. Le code qui parle du service review. Le service review correspond à ces deux codes, v2 et v3 ici. Ils sont aussi appelés à un autre service qui s'appelle Rating. Mais vous pouvez aussi voir que les components de la promotation sont en train de parler de la service IP API. Vous voyez, et vous ne voyez pas KBPF ici, parce que c'est la première fois que je l'ai déployé. Je l'ai déployé tout de suite. Il a eu le data, mais il n'existe pas dans cette picture parce que ce n'était pas encore dans la métro. Mais ce qui est intéressant, c'est que si nous essayons de recharger ici, nous allons aussi commencer à voir ce nouveau component qui est la programmation de KBPF. Parce que maintenant, ce qu'on voit, c'est que nous avons ce service KBPF qui correspond à les codes, et les codes parlent à la promotation et parlent à l'application de la service IP API. Comme nous l'avons vu dans la picture avant. Donc, encore une fois, le but n'est pas de vous dire qu'on va faire ça en production. Le but était juste de vous montrer qu'au final, avec un très petit programme de KBPF et une coopération avec ce que l'application de KBPF peut nous donner, nous pouvons déployer une information assez intéressante sur ce qui se passe dans notre cluster de KBPF. C'est ça pour moi, et Christian va passer un peu plus d'exemples et un peu plus d'exemples. Merci. C'est un demo qui a été créé beaucoup de temps avant, mais si quelqu'un est prudent avec la prumise et l'écosystème graphonique, vous pouvez aussi savoir qu'il y a un service graphonique, une source de data, ou un type de polynée pour le graphonique. Vous pouvez obtenir de la même information comme ce qu'est le podname sous le pod IP. Il y a des mesures de coberture que vous pouvez obtenir dans la box, si vous êtes en charge de l'application de KBPF, si vous faites des mesures de coberture pour l'écosystème graphonique, vous pouvez visualiser tout ceci dans le graphonique. Vous n'avez pas besoin d'un autre projet pour cela, et c'est aussi très bien. Vous avez des questions ? Oui, si j'en ai. Merci pour cette workshop, j'aimerais vous rapprocher un peu plus sur le cycle de l'écosystème graphonique de l'application de KBPF. Alors, on va dire que l'écosystème graphonique est terminé, ça veut dire que tout ce que nous installons dans l'écosystème graphonique dans l'écosystème graphonique, c'est aussi bien évité. Et ce qui se passe, si j'aimerais retirer tout ce que j'ai, de mon cluster de coberture, est-ce que c'est suffisant de retirer le démon, ou quelles sont les actions que j'ai à prendre ? Oui, comme vous l'avez dit, si vous retirez le démon, tout va être nettoyé. C'est comme si vous avez l'interaction avec l'écosystème graphonique, c'est ce qui est en charge de l'écosystème graphonique. Si vous n'avez pas le pot, si vous avez le compte, c'est point quand tout va être retiré amaque ou le bilan. Si vous avez le compte, vous n'avez pas le pot. Vous n'avez pas le pot. Vous n'avez pas le pot. Si vous avez le compte, vous n'avez pas le pot. Vous ne pouvez pas vous démon. Vous n'avez pas la paix de l'écosystème graphonique. C'est un point de production, vous n'avez pas le pot. Vous n'avez pas le pot. C'est un point d'appartement, c'est des saisons. future or not but the idea was also like potentially to have like a way to manage a life cycle of several programs to one big comment for example you know so you could enhance that but basically when you when you run a user program this program is loading the kernel program if you stop this user program it stops the kernel program. Ok so it is enforced by I don't know not because of some hooks or callbacks that's just executed when the user space program got killed but essentially when the user space program terminates that immediately terminates the kernel part. Yes that's the logic sorry something is wrong with my voice so that's that's something that's taking care by Wumblebee for you that's like the actual go user space code that is there as a proper run the primitive version but behind the scene it also cleans up the kernel program that is loading into the kernel you don't even need to think about that because it will be just care of you and as Danny mentioned we also have a branch so if you go to the github repository solo dash IO on github you will find the Wumblebee repository there's a branch called operator or something like that that's an experimental branch that is aiming to do the same thing that that Danny just mentioned that's like having an operator like user experience for Wumblebee you just deploy in that case when you are deploying the operator from that particular branch you are not actually deploying the whole CNI itself you are just deploying the loader you have the loader part of Wumblebee running as a demon set and you can create let's say I think it's called probe probe is the is the CRD and what the probe CRD is defining is the actual OCI image of the kernel program that you want to load into the kernel so the user experience in that case is that you create you apply a probe that's the actual CRD as I mentioned and that will instruct your Bumblebee demon set the loader that is running as a demon set still to load the actual program that you are specifying in the probe CRD which is quite nice so you can just deploy another probe custom resource into the cluster and the demons that will load the other program as well do we have any more questions it looks like at the moment no so let's go to the next lab we didn't spend too much time to explain well maybe we have a question yeah we have a question ok we can wait we have 30 minutes left and we have two small apps so let's take the question can you yeah you can hear me my question is about these two which you installed lastly I think it's key bbf key bbf yes yeah so it's just used to visualize in a graph manner or what is the interconnection between the components right yeah that's just a visualization layer and one more thing is it you I think it's an open source tools that you can use it freely maybe yeah it's it's something that I built some time ago I don't think I have published that in any repo because it's a very basic program but you can ping me and I'm happy to give you the code it's just that it was like a dirty experiment and you know I'm not a big fan of sharing code that is not really nicely written so I'm a little bit shy with this but if you want the code I give it to you no problem it's really basic it's just like you know querying promoters getting data and for each entry querying Cubans API server to get the IP and and nothing nothing really fancy ok thank you but as I mentioned the diplomat use node graph or service graph actually that's a graph on a panel type that's that that might be a more productionally way to to visualize all this you just need to do some relabeling which we probably also won't be perfect code it will be a bit ugly but it's nicer to have all this information in in graphana because most probably are already using graphana as well do we have more questions yeah we have all more hello I have a question regarding the is there some statistic regarding the ingénie de C program into the kernel for example in term of performance yeah that's a good question so the traditionnelly and generally the BPF part is really performant most of the price in terms of resource usage usage is that you have to pay for the actual go bumblebee demo set itself so yeah you can you can for example take a look at the the graph on dashboards the default one that you can get out of the box with the cube promettive stack and you can take a look at the resource constitution of the bumblebee pots itself usually it's like maybe 100 megabytes it's a demon set if you have a simple program loaded into the kernel it won't be too much higher than that but there's also there are also ways to inject to compose multiple ebpf programs into a single large ebpf program and load that into into bumblebee and you can see that if you even if you include the multiple one the resource usage usage won't be won't be that much higher because the S I mentioned the kernel part is pretty performant obviously we are in the kernel you have access to lots of things and it's very easy to get to a state when you have coordinate the problems on the matrix so in that case the actual matrix will be the will be a biggest program in terms of resource consumption okay thank you and also just to note that the size of a bpf program is limited so you cannot really write a program that would be having a very complex logic also for that reason that the goal is not to impact you know the performance rates but obviously you know you have a lot of power with it so you also have to be careful and I think right now I have never seen use case of usage of ebpf that is not provided by a vendor right so I have not seen really adoption of ebpf like people do their own and all the things it's probably exist it's just that I didn't see it yet right but if you have this such a use case then obviously in the company you have to have a lot of mechanisms in place to have proper testing and you know validate what what is the impact of your program not only on performance but only on it can drop packets it can redirecting it can do a lot of magical things that are very difficult to debug right so but easiest and most flexible ways just really to write a small purpose build I don't know maybe in this case it will be like it's not even 50 lines of code and you can get this information out of the cluster and you can visualize from the from the kernel and you can visualize that as primitive metrics so if you know what you are doing it's it's a bit bumble bit it's very easy to to write develop test and deploy it as an image you can the verifier is still in the loop so you you can actually crash your kernel with with a code like that it bumblebee won't even build the problem the the program for you if there's if it wouldn't pass the verifier itself we haven't spent too much time on actually explaining what's happening here so this lab is called bumblebee from scratch we use the template generator that created the template the boilerplate for you to get started but in this lab I will be going through all the lines that we have here because we only have I don't know 40 40 40 something lines of code here and after that we I also have another lab where I will be focusing on an even smaller use case just so that you can understand how the the kernel space code works so as Danny mentioned at the very top of the file we have a few headers vml users h for example and all the bpf helpers I think we haven't mentioned this but if you're using libpf then you can get access to these bpf helpers as well and these can make your life really easy for example there are lots of helpers little functions in this library that can get you for example the name of the processes that are running or the process ID if you are doing ebpf with the earliest possible way like with the traditional original bcc tooling you would need to do all that work for yourself to be able to find what's the what's the name of the other process that is running if you are using libpf you can just import this bpf helpers header and it will be so much easier so after the headers we have this struct and that struct is basically how you want to describe your events that you want to extract from the kernel here in this case we are interested in the process parent ID thread ID process ID these are the informations that are that will describe what kind of process processes are affected by the events that we are tracking with our ebpf code and as I mentioned this last part here is the actual name of the process because process ID is nice but you most probably are more interested in seeing the actual name of the process so you have a struct like this and that will describe all of your kernel events that's all the information that you need to know we also hasn't been focusing on explaining where the labels are coming from when you are consuming these with primitives but you can see that these actual fields in this struct will be the labels so this is the place where you have to make sure that you are not introducing a cognitive issue when you are exporting everything to true primitives after that we have another struct and this struct is basically the map we were talking about the map previously the map is basically the way to exchange information between kernel space and user space as we mentioned in the in the observatory use case we are mostly just reading from that so you can see that the type of this map is ring buff ring buffer if you are using ebpf the modern way of developing ebpf programs then most of the time ring buffer is the is the best and most performant choice it has lots of benefits over traditional other map types for example the perf buffer bumblebee itself cannot even support it doesn't even support per buffer this is why we are also pushing everyone to to use ring buffers it's it's more memory safe it's it easier to use it has really nice apis through these helpers and libraries and basically if you are taking an existing example from the libipf tools github repository most of the time the only thing that you need to do if that actual existing example is using per buffer you have to migrate that from per buffer to ring buffer the next lab that I will be doing right after this will be going through a migration procedure like that it's not that it's not that complex as it may sound like so we specified the type of the map we specified how many entries we want to store and then we specify that all the entries that we want to store in the map will be using the type that we specified here so it's quite simple this exits is the name of the map that we are using and this is important because if you remember but we will take a closer look at this in a bit when you are exporting or exposing the kernel event as primitive matrix the actual suffix of the matrix will be coming from from this value so this is why it's important to give a meaningful name to your map so that if you are for example composing multiple libipf programmes together if you only if you always call this for example events which is something that in the upstream basis repository is the case most of the time you won't be able to differentiate the various maps that you are using across your different problems programs so this is why this was called exits because with this 50 lines of code we will be checking the exits is called in your system after that we have this map section here this is something that's coming from the the upstream implementation and in bumblebee we have this dot print suffix and what it does is that it will tell bumblebee that okay you don't need to expose all these kernels all these events as primitive matrix I just want to print those out if you have print here then you can use the bumblebee CLI 2 to visualise those if I would want to expose these as primitive matrix all I have to do is to change this print to counter after that we have the actual logic kernel logic that we are injecting in and this is a very good example this line this function of the various helpers that are out there and you can use with libipf so as I mentioned you can just use this BPF get current pit thread group ID and the output of this function helper will be the actual process ID it also includes the thread group ID so you might need to do some very minor bit operations to strip the data to have this the kind of data that you are interested in like as I mentioned this includes both of them so we have to strip 32 units so that you can get the actual process ID part but if you're using these it's so much easier than then then without these after that we are initialising our events you can also use another helper function to get the actual running tasks that is running on your kernel here we are what we are doing in this section is that we are populating these fields that we specified up here so these are the actual fields that we need to populate in our map because in our map we are having events and after that this is where we are populating the actual values so it's quite simple we are using another helper to load the actual tasks that we initialised above and we can use another helper to get the actual name of the process again this is something that you would need to do yourself if you are using BCC in a raw format after that we have the ring buffer specific part as I mentioned ring buffer we are using ring buffer because that's currently a requirement for you to move existing tooling or tools into into Bumblebee itself we are just reserving the place the some place in memory and copying the data into the ring buffer and from the ring buffer we can do something like BPF ring buff submit that will push all the contents of the ring buff to the map and from the map Bumblebee will just read it and expose it in a format that we specified and that's it after we have this code what I can do is that I can copy this here so that I can build it into an image I will call this exit snoop it's a simplified version of the upstream exit snoop there were some additional logic that I removed to to make it simpler then I can push it to the registry by the way we also have a option like like this B list and that will list all the various images also images that you previously appeared all right after that I can do a B run and just up to the box we will have some exit scores happening in the system and these will be visualized with Bumblebee on this format because I only specified maps.print so I'm not exposing these as metrics all right then we reached the last part of the workshop do we have any questions in the meantime in the last part I will be talking a bit more about the migration between Perth buffer and ring buffer and the actual use case will be building a boom kill exporter because catching out of memory exceptions in a Kubernetes cluster can be challenging but if you have access to the kernel you can actually take a look at the kernel props in the kernel that will be most certainly passed during execution when an out of memory event happens without this there are some metrics there are some other approaches to get out of memory exceptions but you might not be able to to catch all of them all right so when you are doing this on your own you can read here about what's happening in a lunar in the Linux kernel when we are talking about out of memory exceptions there's a scoring system and basically based on the core based on the scores that are assigned to each process in the kernel the kernel will decide which program to kill when it's running out of memory if you are running on Kubernetes and you have a Linux kernel behind the nodes you can use CPU memory limits and memory request values to to affect the scores basically but the underlying technology and and the scoring system is the same you are still running Linux kernels after all so we can take a look at the code for boom kill I hope it's big enough that's that's that's all the code that is needed to catch an out of memory exception again it's very simple there's a header included I will talk about the header later but basically in this header traditionally the ebpf developers put all the that that was where they specified destruct that are describing the events that you want to that you want to expose in some way so that's what we have in the header that's destruct for the actual events as I mentioned usually these are called events in the absolute repository so when you are moving this code to bumblebee it makes sense to use a different name for example oom kills or out of memory exceptions or something like that we have these dot maps we don't have anything bumblebee specific here as I mentioned it's using per buffer that's the old map type that that bumblebee doesn't support that's the moxquee size and we are putting and we are specifying the size of for all the events the actual logic is here so when an out of memory exception is happening in in a Linux system you will get you will get this kernel probe executed it's called oom kill process so you can see that based on the name there's no real way of going around this and having out of memory exception happening in your system without passing this probe what you are doing here is that the same thing that we did before we are getting we are using the recent helpers to get the actual process ID we can we can even reach the memory pages that the process was reading so that you can get some sense about ok how much memory the extra process wanted to read into the memory right right before it died here we are populating the name the comb of the of the process that is getting out of memory killed and we can also this fpid is the other process that was running at the same time when our other process got oom killed why is this important this is this can be important or interesting because most probably if you have another process running at the same time that's the process that most likely killed your actual other process so we can get some additional information on what's happening in your in your system when you're having a situation like this ok as you can see it's like I don't know 20 lines of code it's not too much it's not too complex if you take a look at the user space code it's a it's a lot bigger it has all the tedious stuff that we discussed handling the lifecycle of the of the kernel program loading it into the verifier handling user input and output as well visualizing the data but traditionally if you are creating and building both the user space and the kernel space programs for your ebpf use case as it still is as is you can still get access to some additional data so for example here you can in the user space you can just run a you can read from the proc file system and you can check what was the CPU load at the time when the oom killed happened which is nice context this is a good reason to write your own user space programs as well but checking the load average is something that you only need if you are working in a constraint environment and you don't have access to other metrics because if you if you are exposing this information as primitives metrics you already have access to the load average the memory usage and all the other information as well all right what I'm doing now is that I'm downloading the original code oomkill.bpf.c and we can take a look at how that how is that different from what we have for bumblebee these are the differences so as I mentioned the header includes the description of the events that we are putting into the map the two process ID the one that is getting oomkilled and the one that is running at the time of the incident the memory pages and both names of the of the processes that are that are we are talking about this is what's in the oomkill.header file after that we have destruct in the original example as I already mentioned we have the pair buffer on the right we have the ring buffer this is the new structure that we want to use we just specify the number of max entries that we want to have in this map and we make sure that all the events are described in the format that we specified above nothing really changed up to this point oh yeah of course we have these maps.counter here because we want to expose these as primitive metrics because we are building an oomkiller and an oomkill exporter okay after this in the actual code section we are attaching this custom logic to the very same kernel problem that we had before we just need to handle the data a bit differently what we are doing is that we are using the API provided by by ring buffer itself it's coming from the BPF core read.header and it's also leveraging the BPF headers here we can leverage the reserve commit API so what we are doing is that we are reserving the space for our events and this is one of the benefits of ring buffer itself if this operation here was successful so if successful it could resolve the place in memory for our event that means that it will be able to inject that and surface that on the user space so if this is successful then we can just go ahead populate all the data as you can see we are doing the very same things we are just populating it differently but at the very end if this was successful all we need to do is to do is to call BPF ring buffer submit and our event that was successfully reserved will be committed to the buffer after that we don't need to think about that it will be bumblebee we'll be able to generate prometeuse metrics from that so let's build this into a yeah we have five minutes let's build this into an image again push it to the registry we can run it this is like a good local test if I would have a failure here then it makes no sense to deploy into a Kubernetes cluster because it wouldn't be wouldn't be working now let's deploy bumblebee itself as a demon set and if you are running this traditional CLI version of bumblebee in the cluster then you can see that you can disable the UI the console UI that I just showed you which is nice because it's consuming less memory in this case all right I'm referencing the umkeel image that I just build and I want to expose the metrics as well so now I should have running the bumblebee ports with the new configuration let's deploy prometeuse itself we will deploy a pod monitor so that we are scraping bumblebee right after this one is finished and after that since we are in a Kubernetes cluster I will be deploying a pod that will get an out of memory exception I'm using this particular image AV solutions slash memleak the owner and the creator of this image is at the conference he visited our booth recently yeah the guy sitting right in the in the back so if you need a very good and reliable image docker image that is leaking memory you should talk to him because it's a it's a great great docker image we will be taking a look at how that would work now prometeuse is installed yeah I need the prod monitor now we are scraping prometeuse if I go to prometeuse here I should have the UI coming up if you go to status targets we should see that we are scraping it might not appear right away so we have to wait a bit you don't necessarily need to refresh it maybe I skipped something I should unchanged three more minutes and the configuration doesn't seem to be working ok they are coming up good we will have the data soon so after this let's deploy the memory leak application from Arnold it's already 1.0 and if you check the pots cubes it'll get pots we will see that the memory leakers in crash loop back if you are watching this right after the crash loop back you should see that it's getting goon killed it's an actual event or status in en Kubernetes itself I might not be able to yeah goon killed if you go to the UI I should have all the pots in a healthy state all right and you can search for the metrics ebpf oom kills as you can see the name is coming from the from the map you can execute it and you can see some additional information these are all the labels that we populated that we specified when we created our ebpf program you can see the name of the command that is allocating too much memory it's called stress you can see the process ID you can see how much memory it wanted to locate it's basically up to you what kind of information you are extracting from the from the kernel all right that was it I think we still have one more slide on possible improvements on bumblebee itself you can use bumblebee sv version to get familiar with dbpf you only need to focus on the actual kernel space problem problems that you want to solve what you could see that was missing is a really tight Kubernetes integration so you could only see for example the names did the process names but not the names of the pod that we're getting out of memory that was that was getting goon killed we are also collaborating with inspector gadget from the king fork forms they are now working with Microsoft and they are also they are using our OCI loading layer so that you can deploy custom ebpf logic with the inspector gadget tooling using an OCI packaging layer which is which is quite nice if you want to contribute to bumblebee or bcc you can take a look at academy dot solo dot IO we have multiple ebpf labs there's the beginner one that was most represented here but there's also an advanced one the oom kill example is coming from there but there you can have more details on the actual migration passes and some advanced scenarios like putting multiple ebpf programmes together if you're interested in that it's it's quite nice thank you for attending this this workshop and please reach out if you have any questions after the talk yeah thank you thanks everyone I think we have a question for we have time for one question if you want to speak more about it you know you can come to our booth and we will be there for the next hour but yeah yeah so I was just wondering if you could elaborate more about the contents of the image you're creating and if if you also have some experience with images being on public registrées and and how how you handle these or are these even supported thanks yeah so I mean the content of this OCI image is mainly the binary basically the same one that you would just like create without it but yeah I don't think if you have like more information but like what it would come in exactly if you would also we also include the headers so you also don't need to ship those to another machine when you where you actually deploy the dipod you can also use when we originally created bumblebee there wasn't that many public repositories that supported this particular OCI format but now if you try to push these images to to the docker hub or github registry that should work out of the box because they have support otherwise you can just self host your own repository or use the one that is used by your company and it should just work the support for the OCI repository is quite nice now yeah all those thanks for the workshop by the way thanks for attendee thanks everyone and wish you like a good end of cubecon with low energy probably but we're almost there thanks everyone safe traverse