FRnOG 39 - Paul Chaignon : Cilium - Le meilleur de Linux pour vos réseaux Kubernetes
Category
🤖
TechnologieTranscription
00:00 Aujourd'hui je vais présenter Cilium, qui est un plugin réseau pour Kubernetes.
00:05 L'approche que je vais prendre c'est d'essayer de vous convaincre que Cilium utilise le meilleur de Linux
00:09 pour implémenter toutes les fonctionnalités dont on a besoin au niveau réseau Kubernetes.
00:13 Cilium c'est un projet open source qui a été créé à l'origine par Ease of Allent
00:18 et qui a été donné à la CNCF, la fondation open source autour de Kubernetes et du cloud native.
00:23 C'est un projet qui implémente toute la partie réseau dont vous avez besoin pour Kubernetes,
00:29 donc toute la connectivité, et qui va ensuite par dessus ajouter toute la partie sécurité,
00:34 donc le chiffrement, les politiques d'accès réseau, la partie observabilité pour voir ce qui se passe sur le réseau
00:39 et pouvoir débuguer des problèmes éventuels, et puis des fonctionnalités plus avancées,
00:43 plus haut niveau, au niveau applicatif sur le service mesh.
00:48 Cilium se base sur une technologie de Linux qui s'appelle IBPF, ça va être le point principal de cette présentation.
00:56 Et c'est la technologie sur laquelle je travaille essentiellement.
00:59 Je m'appelle Paul Chénion, je suis ingénieur logiciel à Ease of Allent.
01:03 Je travaille en particulier dans l'équipe datapath IBPF de Cilium.
01:07 C'est l'équipe qui va vraiment aller faire les implémentations pour faire tous les traitements sur les paquets,
01:11 donc assez bas niveau en C en général.
01:15 Ease of Allent c'est une startup qui est full remote, si on le dit à l'américaine.
01:20 Ça veut dire que la plupart de mes collègues sont un petit peu partout dans le monde,
01:24 des gens à la fois en France, au Japon, en Ukraine et aux Etats-Unis.
01:28 Et très récemment, il y a exactement deux semaines, Ease of Allent a été acquis par Cisco.
01:35 Aujourd'hui l'approche qu'on va prendre c'est de commencer par donner un petit peu de contexte sur IBPF,
01:41 expliquer ce qu'est IBPF et comment ça nous permet d'implémenter toutes ces fonctionnalités là.
01:46 Ensuite on va passer sur différents éléments qui me paraissent importants dans les réseaux Kubernetes,
01:50 donc à la fois la connectivité, le load balancing, la segmentation du réseau.
01:55 Et je vais ouvrir à la fin avant la conclusion sur ce que Cilium permet de faire
01:59 pour connecter le cloud native, le Kubernetes à ce qui existe déjà
02:03 et ce qu'on peut déjà avoir dans nos réseaux.
02:06 On va commencer avec IBPF.
02:09 Donc IBPF c'est un moyen de programmer son noyau.
02:11 Pour nous c'est un moyen d'implémenter beaucoup de choses qui potentiellement existent déjà dans le noyau,
02:14 mais peut-être de les faire de manière soit plus optimale, soit plus adaptée à Kubernetes.
02:19 Pour comprendre pourquoi est-ce qu'on a ce besoin de programmer le noyau,
02:22 il faut comprendre comment le développement actuellement fonctionne dans Linux.
02:26 Il manque les insultes de Linux, je veux bien.
02:38 Mais bon, ce qu'il faut retenir surtout c'est que, comme on le voit dans le slide là,
02:42 c'est assez long comme processus.
02:44 On va implémenter des fonctionnalités,
02:46 il faut convaincre les mainteneurs que ça a un intérêt,
02:49 il faut éventuellement faire plusieurs allers-retours avec eux
02:51 pour corriger les éventuels problèmes ou s'adapter à ce qu'ils veulent.
02:54 Et ensuite une fois que ça, ça a été émergé dans le noyau,
02:57 il faut qu'il soit release, il faut qu'il soit utilisé dans les distributions.
03:00 En fonction des distributions, ça peut déjà prendre pas mal de temps.
03:03 Et ensuite ces distributions là, il faut les mettre à jour dans la production,
03:06 chez les utilisateurs finaux.
03:08 Donc tout ce processus là, il peut prendre potentiellement
03:10 assez souvent au moins une année et des fois plusieurs années.
03:13 Donc c'est extrêmement long.
03:16 Maintenant l'approche IBPF va changer ça de manière assez importante,
03:19 comme on le voit ici.
03:21 Ce qu'on voit ici c'est que l'approche IBPF est radicalement différente.
03:37 On va aller implémenter les fonctionnalités pour notre noyau,
03:40 les changements qu'on veut faire, on va les charger dans le noyau
03:43 sans avoir besoin de recompiler, sans avoir besoin de redémarrer le système.
03:46 Et ils seront disponibles du coup beaucoup plus rapidement.
03:49 Alors bon sur le slide, le personnage en violet qui a l'air un petit peu trop sûr de lui,
03:54 qui pense que ce sera fini en quelques jours, c'est un petit peu optimiste quand même.
03:57 Ça prend plusieurs semaines pour implémenter quelque chose, le tester, le valider, tout ça.
04:01 Un peu plus concrètement, IBPF en fait c'est des programmes qu'on va écrire en C,
04:07 qu'on va aller compiler, donc c'est typiquement en C, ça peut être en Rust aussi,
04:11 qu'on va compiler ensuite vers du bytecode et qu'on va aller charger dans le noyau.
04:14 C'est un system call qu'on va faire pour aller charger ce bytecode-là dans le noyau.
04:18 Ça, ça va être vérifié statiquement pour s'assurer qu'on ne va pas avoir des crashes au niveau du noyau,
04:23 donc on ne va pas pouvoir fail de manière complètement obvieuse.
04:26 Et ensuite ce programme-là va être attaché à des événements dans le noyau.
04:29 Alors les événements ça peut être vraiment beaucoup beaucoup de choses différentes dans le noyau Linux.
04:33 Aujourd'hui ce qui va nous intéresser évidemment c'est la partie plus réseau.
04:36 Donc en particulier on va pouvoir s'attacher à des réceptions de paquets,
04:39 on va pouvoir faire ceci au niveau de différents endroits de la stack Linux.
04:43 Ça peut être de très bas niveau, au niveau des drivers,
04:45 ça pourrait être au niveau des sockets et un petit peu partout au milieu.
04:48 Et ensuite quand les événements vont avoir lieu, donc quand les paquets vont être reçus par exemple,
04:53 le programme va être exécuté, il va pouvoir agir sur ces paquets,
04:56 les modifier, les dropper, les rediriger, ou même des fois rien faire du tout
05:00 et juste récupérer des informations de manière plus optimale qu'autrement.
05:06 Ok, maintenant qu'on a vu un petit peu IBPF de manière très rapide,
05:09 c'est pas le but de la présentation d'expliquer tout IBPF,
05:12 on va le garder un petit peu en tête, je vais partir sur différents aspects de Kubernetes
05:17 et je vais revenir sur cet aspect IBPF à chaque fois pour expliquer en quoi nous ça nous permet
05:21 de faire les choses de manière un petit peu plus optimale.
05:23 Donc le premier aspect c'est tout ce qui est connecter les conteneurs entre eux dans votre réseau Kubernetes.
05:29 Dans le cas du modèle Kubernetes, les choses fonctionnent parfois de manière un petit peu différente
05:33 de ce dont on a l'habitude, donc déjà on a un ensemble de conteneurs
05:36 qui sont dans un même namespace réseau, donc dans un même pod dans le jargon Kubernetes.
05:41 Chacun de ces pods a une adresse IP et surtout tous les pods du cluster normalement
05:47 peuvent communiquer entre eux directement sans passer par du NAT,
05:51 sans être sur des VLANs différents, donc ils sont tous vraiment sur le même L3.
05:55 Avec Cilium du coup on va implémenter ça, on va utiliser des interfaces virtuelles,
06:01 donc c'est assez classique pour connecter les pods au namespace du hôte.
06:04 Ensuite pour connecter les pods entre eux, soit votre réseau physique permet de router les adresses IP des pods,
06:09 dans ce cas il n'y a pas vraiment besoin de faire un overlay,
06:11 autrement on fait un overlay par dessus du VXLAN ou du GeneEve
06:14 et on va pouvoir du coup avoir tous les pods qui communiquent entre eux.
06:17 Jusque là il n'y a rien de très extraordinaire.
06:20 Là où les choses deviennent un petit peu plus intéressantes, c'est avec IPPF.
06:23 Déjà ce qu'il faut comprendre c'est que la stack réseau Linux qui nous permet de faire tout ça
06:27 est très générale, donc elle nous permet de faire toutes ces fonctionnalités là et beaucoup plus.
06:32 Ça veut aussi dire qu'elle est assez lourde,
06:34 et dans le cas des containers, cette stack Linux est traversée plusieurs fois.
06:37 Donc on va la traverser une première fois au niveau du hôte, dans le namespace hôte,
06:41 et une deuxième fois dans le namespace du container.
06:43 Donc ça ça a un coût assez important.
06:46 Ce qu'on va chercher à faire avec IPPF, c'est que comme dans Cilium,
06:49 il y a beaucoup d'éléments de la stack du hôte qu'on ne va pas utiliser,
06:53 parce qu'on les a déjà implémentés avec IPPF directement dans Cilium,
06:57 finalement on n'a pas besoin de repasser par tous ces éléments là.
06:59 Donc on va les bypasser avec différents mécanismes d'IPPF
07:03 pour permettre d'optimiser les performances.
07:05 Donc ce qu'on voit sur la gauche du dessin ici,
07:08 enfin là-bas et là-bas,
07:09 c'est que tout ce qui est entouré en rouge sont des éléments qu'on va pouvoir bypasser.
07:13 Donc c'est essentiellement du netfilter qui nous rajoute quand même un overhead assez important,
07:16 dans beaucoup de cas.
07:18 Et quand on a besoin d'informations type les tables de routage Linux,
07:21 on va pouvoir aller chercher cette information là avec des mécanismes IPPF à nouveau,
07:24 pour l'utiliser directement dans le programme et faire la redirection là où on a besoin.
07:28 Ce bypass là, il nous permet d'optimiser les performances de manière assez importante.
07:34 Donc là ce qu'on voit c'est un benchmark qui a été fait en interne.
07:37 Sur la partie tout à droite, en jaune-orange, c'est la baseline.
07:42 En fait c'est deux nœuds qui vont communiquer entre eux sans utiliser de conteneur du tout.
07:46 En cyan-bleu, donc de l'autre côté, ce qu'on voit c'est la communication classique
07:51 avec des interfaces virtuelles et internet, les VS.
07:54 Et entre les deux c'est l'optimisation qu'on a en faisant ce bypassing d'une grande partie de la stack du hot.
08:00 Le petit gap qui nous reste, c'est quelque chose qu'on va chercher à adresser dans les prochaines versions,
08:05 mais là il va falloir qu'on remplace les interfaces virtuelles et qu'on utilise quelque chose d'autre,
08:09 qu'on a contribué dans Linux upstream, qu'on va pouvoir utiliser maintenant.
08:13 Donc une fois qu'on a connecté ces conteneurs entre eux,
08:17 on a pu voir qu'on arrive à faire les choses de manière un petit peu plus rapide avec Xilium,
08:21 avec eBPF en particulier.
08:23 Maintenant ce qui est intéressant, ce serait d'amener du trafic vers ces conteneurs.
08:26 Donc on veut pouvoir exposer ces conteneurs sur le réseau externe ou même entre eux.
08:31 Donc utiliser les services Kubernetes pour faire du load balancing entre nos pods.
08:36 Donc là le modèle Kubernetes à nouveau, il est un petit peu différent de son temps d'habitude potentiellement.
08:42 Les fonctions de load balancing sont incluses dans tout ce qui est Kubernetes.
08:45 Donc vous n'avez pas besoin d'avoir un boîtier en plus devant qui va aller faire le load balancing.
08:49 Non pas que vous ne puissiez pas le faire, mais c'est juste que c'est déjà intégré dans votre cluster.
08:53 Et en particulier la manière dont ça fonctionne,
08:55 c'est que l'ensemble de vos nœuds vont être capables d'agir comme des load balancer.
08:59 Donc ils vont tous être capables de rediriger le trafic vers une autre destination ou vers leur propre pod.
09:04 Avec Xilium on va comme d'habitude implémenter les standards,
09:08 donc le cluster IP, node port et tous les autres types de services Kubernetes qu'on pourrait avoir.
09:13 Et on va aussi supporter l'approche traditionnelle qui est plus du load balancer en stand alone,
09:18 donc en front du cluster pour aller rebalancer sur le cluster.
09:22 À nouveau là où ça devient un peu plus intéressant, c'est avec IBPF.
09:27 On va pouvoir changer un petit peu la manière dont on fait les choses.
09:29 Et en particulier, nous notre approche ça va être de faire cette redirection du load balancer
09:34 toujours au plus tôt possible.
09:36 Donc ce que ça veut dire concrètement, c'est que si votre trafic il vient de l'extérieur,
09:39 de internet ou je ne sais où, et qu'il arrive dans votre cluster,
09:43 au plus tôt possible, ça veut dire, pour du software en tout cas,
09:46 ça veut dire au niveau du driver.
09:47 Donc on va exécuter des programmes IBPF au niveau du driver
09:50 pour faire la redirection potentiellement ailleurs,
09:53 donc ça va peut-être repartir directement sur le câble,
09:56 et donc être beaucoup plus rapide dans le traitement.
10:00 On ne va pas avoir besoin de remonter sur toute la stack pour faire ce load balancing,
10:03 pour ensuite repartir ailleurs.
10:04 Et on a le même mécanisme dans l'autre sens.
10:06 Si on est sur du load balancing qui va se faire entre différents pods
10:09 dans l'intérieur du même cluster,
10:11 ce qu'on va faire cette fois-ci, c'est qu'on va faire le load balancing au niveau du socket.
10:14 Donc c'est à dire que dès que vous vous connectez sur votre socket,
10:16 on va faire le dynat une fois pour toutes,
10:18 et ensuite on va pouvoir envoyer sur vos back-ends.
10:21 Donc cette fois-ci, on a des utilisateurs qui ont mesuré ce gain de performance là,
10:28 donc en l'occurrence c'est des benchmarks,
10:30 des mesures en prod qui ont été faites par 16names.cz,
10:35 je ne sais pas si vous êtes familier,
10:36 mais c'est une sorte de Google de la République tchèque.
10:39 Ils ont quasiment tout dans leurs applications, c'est impressionnant.
10:42 Donc ce qu'ils ont fait, c'est qu'ils ont switché à nouveau vers IPVS qu'ils utilisaient avant,
10:46 juste pour pouvoir mesurer la différence.
10:48 Donc là ce qu'on voit c'est le throughput.
10:50 On n'est pas sur un throughput qui est énorme,
10:52 on monte à peut-être un million de paquets par seconde max avec la solution de Cilium.
10:57 Ils étaient un peu moins avec IPVS.
10:59 Là où ça devient plus intéressant, c'est sur l'impact que ça a sur le CPU.
11:03 Et l'impact qu'on a sur le CPU pour traiter un million de paquets par seconde
11:06 avec l'approche où on exécute au niveau du driver, c'est quasiment rien.
11:09 Donc on va pouvoir éviter d'utiliser du CPU,
11:12 qui est au niveau de nos noeuds Kubernetes,
11:14 qui servent à autre chose normalement,
11:16 pour faire ce balancing là, et à la place les utiliser pour autre chose.
11:20 Le dernier élément à voir aujourd'hui, c'est la partie segmentation réseau.
11:29 C'est généralement ce qui arrive après,
11:30 une fois qu'on a un petit peu la connectivité en place,
11:33 nos services en place et compagnie.
11:35 Et donc là, le modèle Kubernetes est à nouveau peut-être un petit peu différent
11:39 de ce qu'on peut avoir ailleurs.
11:40 J'ai pas mal notamment de telcos qui viennent me voir en me demandant
11:43 si on peut avoir des VLAN ou des choses comme ça
11:46 pour isoler les différents tenants à l'intérieur d'un même cluster.
11:49 Sauf que ça, habituellement, c'est en contradiction avec ce dont j'ai parlé au début,
11:53 qui est que tous les pods peuvent communiquer entre eux directement.
11:57 Donc ça clashe avec l'approche Kubernetes classique.
12:00 Ça veut pas dire qu'on peut pas le faire,
12:01 mais c'est juste que c'est pas ce qu'on a l'habitude.
12:03 Donc l'approche Kubernetes, en l'occurrence,
12:05 c'est d'utiliser des politiques d'accès réseau, niveau L3, L4,
12:08 pour définir de manière plus ou moins fine les accès entre vos applications.
12:12 Dans Tilium, on va supporter ça.
12:15 On va supporter en plus de pouvoir le faire sur du HTTP,
12:18 de pouvoir le faire sur du ICMP.
12:20 On va pouvoir aussi matcher sur des noms de domaine.
12:22 Alors sur les noms de domaine, c'est un petit peu particulier,
12:24 je vais pas rentrer en détail,
12:25 mais on est capable de le faire sans avoir besoin
12:27 de résoudre les noms de domaine en permanence.
12:29 Donc contrairement à beaucoup de solutions qui existent sur le marché aujourd'hui,
12:32 on va pas aller résoudre nous-mêmes les noms de domaine.
12:34 En fait, on a une autre manière que je pourrais prendre en question.
12:37 Tout ça, c'est fait avec des labels dans Kubernetes.
12:40 C'est l'approche assez classique.
12:42 Donc les différentes politiques de sécurité sont écrites avec des labels
12:46 qui correspondent souvent au rôle ou au type d'application qu'on peut avoir.
12:50 Et en fonction de si ça matche ou pas, on va pouvoir du coup avoir l'accès.
12:53 Donc tout ça est traduit ensuite dans des identifiants côté BPF
12:56 pour le faire côté réseau.
12:58 Et à nouveau, eBPF nous donne un léger avantage là-dessus.
13:03 Donc l'approche classique pour faire toute cette
13:08 tambouille au niveau des règles d'accès réseau,
13:11 c'est d'utiliser du IPT-Buzz ou du Netfilter.
13:14 Dans les pires cas, ça a tendance à être vraiment vraiment mauvais.
13:18 Donc c'est du look-up en "haut de laine" parce qu'en fait c'est une liste de règles.
13:21 Quand vos paquets arrivent, on va aller matcher contre chacune de ces règles là.
13:24 Quand vous voulez mettre à jour votre table,
13:26 en fait il faut recharger toutes les règles.
13:28 Donc on a des utilisateurs qui signalent des fois des heures
13:31 pour juste changer, rajouter une politique de sécurité sur la cluster.
13:34 C'est catastrophique.
13:36 Il y a des approches un petit peu meilleures pour faire ça aujourd'hui
13:38 et qui s'approchent de ce que peut faire eBPF.
13:40 Mais bon, vu que nous l'approche c'est eBPF,
13:42 on a quand même été sur essayer d'optimiser les choses autant qu'on peut.
13:45 Donc en l'occurrence avec eBPF,
13:47 on va pouvoir aller faire des vrais paquets de classifier.
13:50 Donc au sens de la littérature,
13:52 on peut aller regarder quelles sont les meilleures approches de faire ça.
13:54 Sur les lookups, on va être sur du "aud" de "log n".
13:57 En fait c'est principalement à cause du match sur les préfixes IP.
14:01 Et ensuite pour les mises à jour,
14:03 on va pouvoir faire ça typiquement au "aud 1".
14:06 C'est vraiment, on met juste à jour la règle au niveau d'une "hTable"
14:09 et puis du coup c'est beaucoup plus rapide.
14:11 Donc aujourd'hui, ce dont j'ai parlé,
14:16 c'est beaucoup d'éléments assez basiques de Kubernetes.
14:19 Donc à la fois la connectivité, les services, les politiques de sécurité.
14:23 Sur chacun de ces éléments là,
14:25 on a pu voir qu'on utilise, dans ces cas-ci en tout cas eBPF,
14:29 pour principalement optimiser les performances.
14:31 Donc pour ré-implémenter les choses.
14:33 Soit pour spécialiser "hashtag", "bypasser" des éléments,
14:36 spécialiser les algorithmes qu'on utilise.
14:39 Donc on est capable à chaque fois de faire un petit gain comme ça.
14:42 Après dans Cilium, il y a énormément plus de fonctionnalités.
14:44 Et notamment ce qui revient beaucoup plus récemment,
14:46 c'est toutes les fonctionnalités pour aller se connecter à de l'existant.
14:49 Les utilisateurs qu'on voit aujourd'hui arriver sur du Kubernetes,
14:51 c'est beaucoup d'utilisateurs qui ont déjà énormément d'existant.
14:54 C'est typiquement les telcos,
14:56 mais on a aussi beaucoup d'autres utilisateurs
14:58 qui sont déjà avec énormément de choses
15:00 et qui veulent passer progressivement sur du Kubernetes.
15:03 Donc là je vais aller assez rapidement sur quelques exemples
15:06 de fonctionnalités qui adressent ces besoins là.
15:08 La plus ancienne c'est Cilium Igress Gateway.
15:11 Donc là le besoin c'est prendre du trafic qui est sortant de notre cluster.
15:15 Donc tout ce qui va aller vers Internet ou vers des applications en interne.
15:19 Et être capable de le rediriger vers un certain nombre de noeuds.
15:22 Donc le faire sortir seulement de certains noeuds Kubernetes.
15:25 Et de le faire sortir seulement avec certaines adresses IP.
15:28 Source en fait, donc qui va être masqueradées.
15:31 Là où c'est intéressant, c'est pour tout ce qui va être
15:34 typiquement les pare-feux qu'on peut avoir déjà en existant.
15:37 Que ce soit des boîtiers ou autre.
15:40 Où on va configurer les choses avec des adresses IP.
15:42 Donc on va inscrire les adresses IP qui sont autorisées pour faire les accès
15:45 par exemple ici à la LegaCDB.
15:48 Quand on fait ça, si les adresses IP changent toutes les deux secondes
15:51 parce que c'est des conteneurs, ça clairement va pas très bien marcher.
15:54 Ça va être très coûteux.
15:55 Donc à la place ce qu'on peut faire c'est avoir ce Igress Gateway
15:58 qui va nous traduire tout, ou en tout cas la manière dont on veut,
16:01 sur des labels, en certaines adresses IP.
16:03 On va sortir, donc le trafic va sortir avec certaines adresses IP
16:06 qu'on va pouvoir matcher au niveau du pare-feu.
16:08 Et on aura pas besoin de changer en permanence avec les adresses IP d'Ethpad.
16:11 Quelque chose d'un petit peu plus récent, c'est surtout ce qui est L3 VPN.
16:16 Donc là on est parti sur du SRV6 en fonction de ce que nous donnaient les utilisateurs.
16:20 Ce qu'ils nous disaient qu'ils utilisaient déjà dans leur cas.
16:23 Donc un gros utilisateur de ça, d'Ancillum, c'est Bell Canada.
16:26 On est vraiment sur du SRV6 très basique.
16:29 On n'implémente pas toutes les fonctionnalités SRV6, c'est énorme.
16:32 Donc on est sur du L3 VPN avec quelques limitations en plus.
16:37 Donc on implémente juste ce dont on a besoin pour ça.
16:39 On va pouvoir avec SRV6 se connecter à soit des sites distants,
16:43 des trucs qui étaient déjà sur SRV6, qui comprennent ça et qui sont capables de recevoir ça.
16:48 Soit connecter différents clusters Cilium entre eux,
16:50 donc même s'ils sont sur des clouds différents par exemple,
16:52 on va pouvoir connecter un cluster on-premise avec un cluster sur IKLS
16:56 via cette approche là, à condition que IPv6 soit supporté sur le réseau.
17:01 Et beaucoup plus récemment, une dernière fonctionnalité qui nous permet
17:06 d'étendre un peu au-delà de Kubernetes, et qui change un peu par rapport aux autres
17:10 parce que cette fonctionnalité là va nous permettre vraiment d'étendre
17:12 les fonctionnalités de Cilium au-delà de Kubernetes.
17:16 Jusqu'à présent, ce que j'ai montré, c'était des manières de se connecter finalement à l'extérieur.
17:20 Ce qu'on fait déjà, mais pouvoir le faire avec certaines politiques, etc.
17:23 Là on va vraiment pouvoir étendre les fonctionnalités,
17:26 donc le chiffrement, les politiques de sécurité, le load balancing, au-delà de Kubernetes.
17:30 Donc la manière dont on fait ça, évidemment il n'y a pas de magie,
17:32 il nous faut une sorte d'agent ou quelque chose pour aller faire ce lien là.
17:36 Dans le cas de Cilium Mesh, ça va être des Transit Gateways,
17:39 qu'on va aller placer soit dans des VM, soit en amont de différents serveurs,
17:44 et qui vont en fait faire la traduction entre ces entités là,
17:48 et les concepts Kubernetes qu'on a dans Cilium,
17:51 et vont permettre d'utiliser du coup du chiffrement jusqu'à cette Transit Gateway,
17:55 ou jusqu'à un VPC qu'on pourra avoir ailleurs et qui n'est pas sur Kubernetes.
18:00 Pour conclure, Cilium c'est un plugin réseau pour Kubernetes,
18:09 ça implémente énormément de fonctionnalités,
18:11 ça a tendance à devenir le plugin réseau pour Kubernetes,
18:14 pour au moins une raison, qui est qu'on est le seul plugin réseau pour Kubernetes
18:17 qui est graduated à la CNCF.
18:19 On implémente énormément de fonctionnalités pour essayer de couvrir ce dont les utilisateurs ont besoin.
18:23 On s'appuie à chaque fois sur les dernières innovations du noyau,
18:26 l'exemple que j'ai donné, puisque c'est le principal, c'est IBPF.
18:30 Ça ne veut pas dire que c'est seulement IBPF,
18:32 on a aussi des exemples où ça va être les VS que je mentionnais tout à l'heure,
18:36 qu'on va aller remplacer avec des Meta-Devices.
18:39 Ce n'est pas tellement lié à IBPF, c'est quelque chose qu'on a contribué,
18:42 qu'on va utiliser dès qu'on pourra.
18:44 On a aussi fait des améliorations sur tout ce qui était ARP dans le noyau Linux,
18:47 c'est des choses comme ça qu'on va aller à chaque fois essayer d'utiliser,
18:50 dès que c'est disponible.
18:52 Et tout ça, ça nous permet principalement des gains en efficacité,
18:55 mais pas forcément que.
18:56 Ça nous permet aussi par exemple d'avoir SRV6 qui fonctionne, dans notre cas,
19:00 sur des noyaux qui sont très anciens.
19:02 Là, on a droppé le support pour du 4.9 assez récemment,
19:05 mais jusqu'à présent, on pouvait exécuter du SRV6 sur du 4.9,
19:08 tandis que sur Linux, si je me rappelle bien, c'est 5.11,
19:12 il me semble, pour avoir du N.24.
19:14 Donc il y a un assez gros gap qu'on peut couvrir.
19:16 Et enfin, j'ai montré quelques fonctionnalités qui permettent d'aller au-delà de
19:21 juste votre cluster Kubernetes, détend les choses un petit peu
19:24 à ce qui existe déjà dans vos réseaux,
19:27 et qui couvre différents aspects de Cilium.
19:31 Merci beaucoup pour vos attentions,
19:33 et si vous avez des questions, je serais ravi d'y répondre.
19:36 Est-ce qu'il y a des questions ?
19:45 Ouais.
19:46 Hop là.
19:47 Bonjour, merci beaucoup pour la presse.
19:53 J'ai une question stupide.
19:55 J'ai besoin, enfin on a souvent besoin de monter plusieurs interfaces réseau sur les pods.
19:59 Pour ça, il y a Multus qui fonctionne super bien, d'Intel.
20:02 Est-ce que Cilium est compatible avec Multus ?
20:05 Et surtout, est-ce qu'il supporte correctement les netpols ?
20:08 Parce que monter des netpols avec Multus, c'est un cauchemar.
20:11 Pour le montage.
20:12 Oui, Cilium est compatible avec Multus.
20:16 Pour nous, ce ne sera pas possible de supporter les networks policies
20:19 si on utilise Multus sur l'interface secondaire.
20:22 On n'a pas la main dessus, en fait.
20:24 Et du coup, notre approche, c'est d'aller faire ce support-là
20:27 pour plusieurs interfaces sur les pods, nous-mêmes.
20:29 Et du coup, à partir de ce moment-là, on pourra avoir
20:31 toutes les fonctionnalités de Cilium sur les différentes interfaces.
20:34 Ça s'appelle multi-homing dans Cilium.
20:36 C'est en cours de développement.
20:38 Il y a une grosse partie qui a déjà été émergée dans Cilium
20:41 dans la dernière release.
20:42 C'est la fonctionnalité sur laquelle on va aller pour tous ces besoins-là.
20:45 Ça revient assez souvent.
20:47 Est-ce qu'il y a une autre question ?
20:52 Eh bien, merci.
20:57 Merci.
20:58 (Applaudissements)