eBPF ou Sidecars pour l'observabilité et le réseau dans K8s il faut choisir

Les sidecars c'est un gouffre énergétique et un bottleneck point barre. Chaque pod a son proxy c'est une hérésie à l'échelle.

eBPF c'est l'avenir pour ça. Tu tapes directement dans le kernel avec XDP pour le réseau tu fais du filtrage hyper rapide du load balancing. Pour l'observabilité kprobes uprobes c'est la killer feature. Tu traces tout sans impacter l'application. Fini le context switch user/kernel.

Faut arrêter de vendre eBPF comme la solution miracle. C'est hyper puissant oui mais hyper complexe aussi. Écrire des programmes eBPF c'est pas à la portée de tout le monde et débugger un truc qui tourne dans le kernel c'est une galère pas possible.

Et la compatibilité kernel c'est un enfer. Un simple patch peut te casser ton programme eBPF et là tu as le node qui est instable. C'est une surface d'attaque supplémentaire aussi le kernel.

Mais le gain de performance est juste indécent. Pas de context switch entre user et kernel c'est ça la clé. Le réseau avec Cilium par exemple c'est du XDP direct. Latence plus basse même pour des règles L7 complexes.

Et pour la sécurité Falco ou Tetragon utilisent eBPF. C'est du runtime security sans agent lourd dans l'userland. Le jeu en vaut la chandelle.

Exactement. Pour le mTLS on peut faire du transparent TLS avec eBPF sans sidecar. Le mode proxy des service mesh c'est un concept dépassé en termes de performance.

Avec eBPF tu traces les appels syscall tu vois tout le trafic réseau sans même modifier l'application. C'est non-intrusif.

Oui mais le sidecar tu peux le débugger. C'est un conteneur tu peux y aller en SSH tu vois les logs. Un programme eBPF si ça foire ça te plante le kernel ou ça fait des choses imprévisibles.

Et le débugging avec bpftool c'est pas pour tout le monde. Ça demande des skills kernel très spécifiques.

C'est une question de skill set à acquérir oui. Mais on parle de décharger le data plane du user-space. Quand tu as des centaines de services qui communiquent l'overhead des sidecars devient plus critique que la complexité eBPF.

Le trade-off est clair sur la performance pure.

Et l'Observabilité. Prometheus avec les exports de cAdvisor c'est très bien mais limité. Avec eBPF tu peux instrumenter absolument chaque syscall chaque paquet réseau chaque I/O.

La granularité est sans égale. Tu peux savoir exactement pourquoi une requête est lente. Pas juste que la CPU du conteneur est à 80%.

Cette granularité est aussi un problème. Tu génères des téraoctets de données. Comment tu stockes ça ? Comment tu requêtes ça ? T'as des outils comme Grafana ou Datadog qui sont faits pour Prometheus pas pour du eBPF brut.

Faut des pipelines de données énormes derrière.

Non mais c'est pas brut. Les frameworks comme Pixie ou Falco digèrent ça. Ils agrègent ils filtrent à la source. Le point c'est que tu *peux* avoir la granularité si tu en as besoin.

Avec un sidecar tu as juste ce que le proxy te donne comme métriques. C'est moins flexible.

Et le réseau. Les sidecars c'est pas du BGP anycast. C'est du proxy classique. Avec Cilium tu peux faire du L3/L4 policy du peering BGP avec les applications directement.

L'intégration avec le kernel network stack est native. C'est un game changer pour les performances réseau en K8s.

BGP directement dans K8s pour des petites infra ça complexifie beaucoup trop le déploiement. Pour les grosses boîtes avec leurs propres AS oui ça se justifie.

Mais 90% des utilisateurs K8s n'ont pas besoin de ce niveau d'intégration BGP.

C'est pas une question de taille d'infra c'est une question de performance et de résilience. Pourquoi s'encombrer d'un proxy user-space qui ajoute de la latence de la mémoire et des points de défaillance quand le kernel peut le faire 100 fois plus vite ?

C'est l'évolution logique de la stack réseau.

On n'a pas besoin d'injecter des images de sidecars de 100 Mo dans chaque pod. C'est un cauchemar pour la CVE et la supply chain security. eBPF c'est un agent léger sur le node. Moins de vulnérabilités potentielles.

Léger oui mais hyper privilégié. Root sur le node. Si un programme eBPF est vulnérable ou mal codé tout le node est vulnérable et potentiellement compromis.

Un sidecar c'est plus isolé. Si le proxy est pwned il ne compromet que son pod.

Il y a des mécanismes de vérification du bytecode eBPF par le kernel. C'est pas n'importe quel code qui tourne. Et la sandbox eBPF est robuste. Ce n'est pas un driver custom avec des privilèges illimités.

Le kernel refuse tout ce qui est dangereux ou non conforme.

Ok les gars. C'est un débat passionnant. La performance et l'isolation au niveau kernel d'eBPF sont vraiment séduisantes.

Mais la complexité opérationnelle et la courbe d'apprentissage abrupte pour le débugging sont des points à ne pas négliger.

On va regarder Cilium pour la partie réseau et quelques outils eBPF pour de l'observabilité ciblée. On garde les sidecars pour l'instant pour des politiques L7 complexes où eBPF est peut-être overkill ou trop tôt pour nous. Merci pour vos éclairages.