 Merci d'être venu. Aujourd'hui, je vais parler de BPF sur Kubernetes. La première question est, est-ce que vous avez essayé de BPF ? Peut-être de l'alphabet ? Si vous avez essayé de Kubernetes ? De l'alphabet aussi, je pense. Oui, c'est ma alphabet. Mon nom est Albon. J'ai fait une grande contribution à la roquette en temps. J'aime travailler sur les containers en Kubernetes, en SystemD, en Linux, en BPF, et ce genre de choses. Je suis le CTO de Kinfolk, en Berlin. Aujourd'hui, je vais vous concentrer sur la utilisation de BPF à l'intérieur des Kubernetes. Je ne vais pas faire une présentation technique de BPF. Il y a déjà un couple de parcs d'aujourd'hui. Je vais vous montrer un exemple de différents programmes en BPF et de comment ils peuvent être utilisés en Kubernetes. Je vais finir avec un couple de choses que nous avons faites de Kinfolk pour faire un test en utilisant Go. La première présentation de Kubernetes, je vais juste présenter ce qui est nécessaire pour le reste de mon talk. Kubernetes est une orchestration de containers. Cela signifie que c'est un système qui va décider de s'acheter les containers dans votre cluster. Quand vous déploiez les applications, vous ne décidez pas de passer à ces machines, mais Kubernetes va le faire pour vous. En Kubernetes, il y a un couple de concepts, un groupe qui est le plus petit unité de déployement. Un groupe peut contenir un ou plusieurs containers. Ils vont être déployés ensemble dans les mêmes nodes. Et ensuite, un service. C'est un concept important de Kubernetes. C'est fait pour adresser un service quand un pod veut parler à un autre pod. Normalement, nous n'avons pas besoin de connaître l'IP d'un autre pod. Nous avons utilisé le concept de service. Comme le front-end peut parler à la back-end, mais le pod ne décide quels containers il peut connecter. Il va connecter l'IP de le service. Et puis, Kubernetes va déployer cela pour vous, en utilisant le load balancing. Cela peut être fait en utilisant l'IP de table ou la destination de la destination. Ensuite, l'introduction à BPF. BPF est un code de base qui est exécuté dans l'AXNL. Nous pouvons dire que c'est une petite machine virtual dans l'AXNL qui est safe pour ne pas crusher l'AXNL. Cela peut être exécuté d'autres sub-systems dans l'AXNL. Il y a beaucoup d'autres. Je vais vous montrer. Pour l'introduction à BPF, je vais prendre, comme d'autres, l'exemple de TCP-Dump. Peut-être que vous avez déjà vu ce genre de schéma de networking stack. Cela shows l'incomping packet et l'inux qui peut être routé à une machine différente ou à un processus local. Dans cet exemple, j'ai Apache qui a un socket, un socket internet pour recevoir les packets par AT, pour exemple. Comment le TCP-Dump a-t-il été fabriqué ? Il a été fabriqué dans l'incomping packet très rapidement dans le networking stack. Cela peut faire une copie de toutes les packets avant qu'une décision soit routée. Comment le TCP-Dump va créer un socket type AFPacket et le Linux va faire une copie de toutes les packets. Le TCP-Dump a-t-il été fabriqué par AT ou vous pouvez avoir plus de filtres complexes. Vous ne pouvez pas faire tout mais vous pouvez stiller beaucoup de filtres compliqués. Dans cet exemple, vous pouvez même inspecter les packets pour voir si c'est HTTP GET ou quelque chose comme ça. Pour faire ça, le TCP-Dump ne va pas vérifier le packet mais il faut faire ce travail. Le but de ça c'est que le processus de TCP-Dump n'a pas besoin d'être fabriqué pour toutes les packets mais d'ailleurs le canal sera fabriqué par un filter BPF et c'est un petit programme qui va vérifier dans cet exemple si c'est pour AT ou pour 22 ou quelque chose comme ça. Et puis, seulement les packets vont être fabriqués pour TCP-Dump. Ok, c'était l'introduction sur BPF par TCP-Dump mais il y a maintenant beaucoup plus d'autres programmes BPF Dans ce slide, il y a 3 catégories. BPF programmes pour networking, pour sécurité ou pour tracé. Pour chaque catégorie, il y a différents programmes. Pour networking, il y a un programme BPF pour socket filtering sur le C-group player c'est quelque chose de nouveau dans canal 4.10 et Trafic control pour insérer packets très rapidement dans le sac de networking et sur le layer 2. Et d'autres programmes BPF sont pour sécurité que nous recevons avec l'on-lock. Il y a un truc à l'hôtel comme vous pouvez le voir sur fort-tracing. Donc si vous ne savez pas où les différents programmes BPF de type networking sont dans cette stack network si vous avez vu cette stack network netfilter le layer de contrôle trafic est très rapidement dans le stack c'est là-bas et Farigua Spaghetti est là-bas et socket filtering est très haut près du processus dans la stack network. Dans le reste de mon parler je vais parler de différents usages BPF dans différents projets de software donc je vais vous montrer différents programmes BPF nous commençons avec K-PROB ou Corel-PROB c'est fort-tracing K-PROB est quelque chose qui existe indépendamment de BPF qui existe avant c'est un moyen de mettre un hook et des instructions dans le kernel par exemple, chaque fois le kernel est exécuté je peux intercepter ça pour exécuter des codes pour exécuter des programmes BPF avec K-PROB et Corel-PROB je peux exécuter des codes à la fin de la fonction à la fin de la fonction je peux injecter l'arbitrary code dans le site WAVE avec BPF il y a aussi un traspoint qui est plus fort pour définir le traspoint statiquement dans le kernel je vais avoir deux exemples d'abord, le premier est avec le projet WIFSCOP si vous savez de WIFSCOP c'est peut-être 10% c'est un projet pour voir dans une façon graphique la liste des containers sur votre cluster de Kubernetes pour voir les connections de TCP dans ce screenshot vous pouvez voir les liens chaque lien représente le fait qu'il y a une connection de TCP entre deux containers vous pouvez voir comment ils communiquent et vous avez un un visage global de ce qui s'occupe pour faire ça ils ont besoin de savoir la liste de connection de TCP avant c'était par inspecter toute la liste de process de process dans Slashprock toute la liste de connection de TCP dans Slashprock c'est parfait, pas efficace et cette nouvelle façon de le faire c'est d'utiliser K-PROB sur eBPF ce que nous faisons c'est de mettre un PROB sur chaque TCP connect, TCP accept TCP close donc nous pouvons manager un view de toutes les connections sur le système un autre exemple d'utiliser K-PROB sur eBPF en Kubernetes cette fois en utilisant l'http statistique plugin donc nous avons sculpté comme un système de plugins pour avoir un additional view sur le cluster de Kubernetes et cet http statistique plugin va vous montrer combien de requests de HTTP il y a par seconde d'autres types de request de HTTP ou de supply par exemple GET, POST, Error Code 404 etc dans ce screenshot vous pouvez voir par exemple 115 requests par seconde et vous pouvez voir le graph pour faire ça, il va installer un couple de K-PROB sur une fonction cannelle chaque fois procéde un packet ou un packet cet eBPF programme sera triggered et il va regarder dans le packet pour voir si ça ressemble à un request de HTTP ou de supply je vais parler de K-PROB je vais parler d'un programme de different types de BPF pour les networks donc comment beaucoup de vous connaissent ce que l'on apprend sur le schedule de networks peut-être 30% sur Linux chaque interface de networks comme ETH0 il peut être attaché sur le schedule de networks ce que nous allons décider de quel packet à émettre quand il y a beaucoup de packets vous pouvez décider de l'ordre de délai ou quelque chose comme ça quand on fait la décision il y a une espèce spéciale que l'on peut exécuter un programme de BPF pour classifier le packet ou appliquer des règles je vais vous montrer deux exemples de l'utilisation de Kubernetes le premier exemple est toujours avec WeaveScope avec un autre plugin il s'appelle Trafic Control plugin ce qu'il fait c'est qu'il installe Q-Discipline sur chaque interface de networks pour tous les containers et appuyer des règles d'exemple, ajouter un limit de bandwidth ou un délai pour tester votre application pour voir ce qui s'occupe quand des containers sont slow des networks sont slow pour voir ce qui s'occupe de votre website de l'UI donc on a fait un travail sur ça vous pouvez vérifier le blog post pour avoir plus d'informations et comment on utilise BPF donc dans la branche dans la branche master de ce projet on n'utilise pas BPF on utilise des codes pour utiliser BPF pour filtrer les trafics d'exemple, tous les trafics on pour AT on va avoir des latencies tous les trafics on pour 22 avec des latencies différentes d'exemple, pour tester un autre projet dans Kubernetes qui utilise BPF pour network c'est cilium donc cilium utilise BPF d'extentif on peut décider à quel point il faut parler sur les autres codes pour appliquer des policiers de sécurité incluant la lait 7 donc ils peuvent regarder les packets voir ce que l'on utilise et décider basé sur le URL pour s'accepter BPF cilium utilise BPF pour filtrer donc on n'utilise pas pour filtrer les packets entre les networks c'est tout en utilisant BPF et si vous vous souvenez au début de mon parler je parle de services de Kubernetes et que l'on utilise NAT pour passer les packets pour services de Kubernetes traditionnellement c'est fait avec IP table ou netfilter mais cilium implemente la même chose seulement basé sur BPF ok un autre type de BPF programme c'est pour sécurité il y a un projet qui s'appelle LONLOK que vous avez probablement entendu à l'hôpital de LONLOK ce n'est pas quelque chose qui est déjà il n'y a pas de merge dans le Linux LNL c'est un projet envers combien d'entre vous avez entendu sur lsm ou Linux sécurité 60% d'entre vous peut-être donc peut-être que vous savez que les Linux LNL LONLOK est un autre base sur BPF l'idée c'est d'avoir une prévélation de sandbox donc vous n'avez pas besoin d'impliquer votre sandbox dans vos applications à ce moment il n'y a pas mais c'est l'idée c'est différent que les Linux LNL parce que vous n'aurez pas besoin de ça et c'est différent d'un second BPF je vais vous montrer le suivi pourquoi donc ici il y a un exemple d'application qui fait l'open system call donc avec un second BPF vous avez juste d'accès à la paramètre donc un pointeur sur la flèche et votre second il faut faire leur décision basé sur la météo LONLOK avec BPF c'est un peu différent parce qu'il peut voir quel genre d'objectif par exemple qui est structuré ou structuré et c'est tout basé sur BPF donc l'espace utilise un programme BPF dans le kernel et décide d'appliquer cette isolation pour un processus spécifique donc la question c'est pourquoi ça pourrait être utile j'ai un exemple ou une idée ce n'est pas quelque chose qui est implémenté mais combien de vous savez qu'il n'y a pas de cube ou des frameworks de serverless peut-être 3 % ok donc j'ai dit avant que dans Kubernetes le minimum unit de déploiement c'est le pod la idée dans serverless ou en cube less c'est de déployer les fonctions donc c'est un plus petit et par déployer les fonctions nous pouvons couper ces fonctions sur HTTP request ou couper cela dans Kafka ou ce genre de choses mais traditionnellement les containers isolent sur le level de containers pas dans la fonction spécifique dans un processus spécifique donc je voudrais voir dans le futur si il y avait une sorte d'intégration entre long log et cube less pour pouvoir isoler différentes fonctions de différentes fonctions dans le même processus et le dernier programme de Bpf que je parlerai d'aujourd'hui c'est pour des filtres de socket par C-group donc c'est une nouvelle feature dans Linux dans 4.10 c'est un peu similaire pour des filtres de socket comme pour TCP dump mais la idée c'est d'appliquer ça sur un C-group donc beaucoup différents processus dans le même C-group ne peuvent pas avoir le même Bpf programme qui va filtrer la trafique et puis vous pouvez filtrer la trafique ou appliquer des statistiques là-bas ce qu'on peut faire c'est pour chaque pakette d'incombre pakette ou d'outre-pakette trouver quelle socket c'est relativement et cette socket c'est pour un processus qui est dans un C-group et il vérifierait si ce C-group a un Bpf programme attaché à ça et ça pourrait être fait pour des statistiques j'aimerais être capable de gérer des statistiques spécialisées statistiques dans un cluster de Kubernetes et pour chaque conteneur ce qui se passe là donc combien de trafiques il y a pour 80 combien de trafiques de ce genre etc. donc je pense que c'est bien d'intégrer ça pour un premier TOS pour avoir un exporteur en profondation sur chaque node et pour les statistiques basées sur E-B-P-F pour poursuivre ce taux de preuve pour pouvoir inspecter ce qui se passe là il y a un prototype que on a fait sur github.com et sur com.com c'est pas vraiment complet mais c'est une idée pour celui de là Je suis terminé de donner un exemple d'exemple d'utilisation. Je vais juste mentionner un couple d'outils. Donc BCC est un set d'outils pour faire un programme de BPF de manière plus facile. Il y a une integration avec Python, donc vous pouvez faire un programme de Python et utiliser une BPF de là-bas. On a réveillé un autre projet de BPF de manière similaire dans Go. Donc de vos programmes de go-long, vous pouvez charger les programmes de BPF et les appliquer pour différents programmes de BPF. Finalement, nous avons fait un travail pour pouvoir tester ça. Donc, sur un projet d'open source, nous utilisons des outils comme Trevis, ou CircleCI, ou CMA4. Ce type de service est gratuit. Vous pouvez passer sur votre projet pour tester si chaque pull request, chaque commit n'a pas de problème. Pour un programme de BPF, c'est un peu difficile de faire ça parce que souvent nous avons besoin d'une dernière version de l'exemple de Linux. Parfois, des systèmes comme Trevis ou CMA4 utilisent toute la version. Donc, des cannelles 3.16, ou quelque chose comme ça. Donc, ce n'est pas vraiment disponible pour les tests BPF. Et beaucoup d'entre eux ne vous permettent pas de faire des choses en route, avec des privilèges, ou de faire des machines virtuelles. Mais en fait, il y a un service CI que nous avons trouvé, CMA4, qui vous permet d'aller dans les machines virtuelles et qui vous permet d'aller dans les machines virtuelles. Nous utilisons un roquet. Je l'ai dit avant que le roquet soit un container à temps, mais ce n'est pas seulement un container. Il y a ce qu'on appelle un stage 1, un roquet avec une machine virtuelle, avec KVM, et avec cela, nous utilisons un roquet pour lancer un environnement avec une nouvelle version de Linux. Par exemple, la dernière, la dernière, où il y a tous les features BPF. Et ensuite, nous avons rencontré CMA4. Donc, vous pouvez tester vos projects BPF directement là-bas. Donc, si vous êtes intéressés, vous pouvez regarder le blog poste là-bas. D'autres questions ? Oui ? La question est des performances. Qu'est-ce que l'impact de la performance quand on attache les programmes BPF à chaque place ? Je vais dire que il n'y a pas beaucoup d'impact sur les performances, parce que les programmes BPF compagnotent en première place un code BPF, mais ensuite, dans le kernel, il sera transmis à l'architecture native. Par exemple, armes, x86, ou quelque chose comme ça. Et ensuite, il sera exécuté par le code native. Donc, je pense que c'est la cause d'un code fonctionnel. Il n'y a pas de contexte switch à un processus différent entre l'utilisation de l'espace et le space de kernel. Donc, ce n'est pas trop. Je pense que si vous attachez les programmes BPF pour chaque système, ils pourraient encore avoir des impacts. Il n'y a encore moins de tools comme Strace. Si vous stracez sur votre processus, il y aura beaucoup plus d'impacts en utilisant BPF. Une autre question ?