Le massacre des ressources par les sidecars Istio : eBPF est-il le seul salut ?

Tu débarques un peu. Le modèle sidecar est effectivement une aberration architecturale héritée de l'époque où on ne savait pas manipuler le stack réseau Linux proprement depuis Kubernetes. Envoy est un super proxy, mais le forcer dans chaque pod c'est une hérésie.

L'avantage d'eBPF avec Cilium, c'est que tu vires la latence du loopback. Les paquets ne remontent plus dans l'user-space pour rien. Par contre, accroche-toi pour la configuration de la politique L7 sans sidecar, c'est là que ça devient moins rigolo.

C'est beau de fantasmer sur eBPF, mais on en reparle quand vous aurez besoin de faire de l'inspection de trafic TLS profonde ou du retry logique complexe. Istio et ses sidecars, au moins, c'est prévisible. Tu peux `tcpdump` dans ton container et voir ce qui se passe.

Avec eBPF, ton trafic est intercepté au niveau du kernel. Si un truc foire, tu fais quoi ? Tu sors `bpftool` en prod à 3h du mat ? Personne dans vos équipes ne sait lire du bytecode BPF.

L'argument du debug est dépassé. Cilium propose Hubble qui donne une visibilité que tu n'auras jamais avec des logs Envoy tronqués. Et niveau performance, il n'y a même pas de débat.

Regardez comment on drop du trafic proprement au niveau kernel sans même que le CPU ne transpire :

cilium networkpolicy create policy.yaml

C'est bien plus propre que de laisser un proxy user-space bouffer des cycles CPU pour rejeter un paquet.

Le vrai problème d'Istio sans sidecar (Ambient Mesh), c'est qu'on se retrouve avec des ztunnel par node. On partage le destin du proxy entre plusieurs pods. Si le ztunnel tombe, c'est tout le node qui est aveugle.

Avec eBPF on évite ce SPOF partagé au niveau applicatif. On utilise les hooks du scheduler pour rediriger les sockets. C'est chirurgical.

SPOF partagé ? Et le kernel Linux alors ? Si ton programme eBPF est mal écrit et qu'il cause un kernel panic parce que tu as bypassé le verifier avec une version de noyau trop vieille, c'est tout ton node qui reboot.

Je préfère mille fois un sidecar qui crash et qui est redémarré par le kubelet qu'une corruption de stack réseau globale. On parle de stabilité de prod là, pas de benchmarks de laboratoire.

Le risque de kernel panic me semble exagéré si on reste sur des kernels récents. On tourne sur du 6.x partout. Ce qui m'inquiète plus, c'est la gestion du mTLS. Est-ce que Cilium gère l'identité aussi bien que les certificats injectés par Istio ?

Cilium utilise IPsec ou WireGuard pour le chiffrement node-to-node, ce qui est bien plus performant que de faire du TLS dans chaque tunnel applicatif. Pour l'identité, il se base sur les labels Kubernetes et des identités numériques internes.

Pour activer le chiffrement, c'est une ligne de commande :

cilium encryption enable --type wireguard

Attention quand même, IPsec ou WireGuard au niveau node ça ne répond pas à la conformité FIPS ou à certains besoins de chiffrement de bout en bout où le paquet doit être crypté même à l'intérieur de la mémoire du node.

Si tes audits SecOps exigent du TLS applicatif, eBPF seul ne suffira pas, tu devras quand même injecter de la logique dans le flux, et on retombe sur du proxying, qu'il soit transparent ou non.

Exactement. Et parlons de la complexité opérationnelle. Mettre à jour Istio, c'est chiant mais documenté. Mettre à jour un CNI comme Cilium qui gère tout ton routage, ton load-balancing et ta sécurité via eBPF, c'est une opération à cœur ouvert.

Si ton `cilium-agent` merde pendant l'upgrade, plus rien ne communique sur le cluster. C'est un pari risqué pour gagner quelques gigas de RAM.

Gagner quelques gigas ? Sur une infra à l'échelle, on parle de dizaines de milliers de dollars par mois d'économie de compute. C'est du FinOps pur.

Et niveau sécurité, eBPF permet de faire du runtime security avec Tetragon. Tu peux bloquer des appels système suspects en plus du réseau. Istio ne fera jamais ça.

Tetragon c'est puissant mais c'est encore une couche de complexité. On parle de charger des programmes C compilés dans le kernel.

struct event_t { 
    u32 pid;
    char comm[80];
};
BPF_PERF_OUTPUT(events);

C'est ça que vous voulez gérer au quotidien ? Des hooks sur `execve` ?

C'est précisément mon point. On transforme des ingénieurs DevOps en ingénieurs système kernel. La courbe d'apprentissage est monstrueuse par rapport à un simple fichier YAML de VirtualService Istio.

Je commence à voir le tableau. eBPF offre des perfs de dingue et une visibilité kernel, mais demande une expertise que l'équipe n'a pas forcément. Istio est lourd mais rassurant car bien connu.

Ne reste pas sur tes vieux acquis. Le monde bouge. Google, AWS et consorts migrent tous vers des solutions basées sur eBPF pour leurs propres réseaux. Le modèle sidecar est une impasse technique à long terme.

Si tu veux tester sans tout casser, essaie d'abord d'installer Cilium en mode CNI simple et garde Istio par-dessus. Puis migre doucement les politiques réseau. Ne fais pas un Big Bang.

Et surtout, vérifie la version de tes kernels sur tes nodes de prod avant. Si tu n'es pas au moins en 5.10, tu vas souffrir avec des fonctionnalités eBPF bridées ou buggées.

Vrai. Un petit `uname -a` avant de jouer aux apprentis sorciers ça évite bien des larmes. Mais honnêtement, une fois que tu as goûté à la vitesse de Cilium, tu ne reviens jamais en arrière.

Merci pour les retours. On va monter un lab avec Cilium sur un cluster de staging et comparer la latence L7 réelle avec nos sidecars actuels. Si le gain est aussi massif que prévu, je préparerai la migration. On va surveiller les kernels de près. Merci !