Virer Istio pour du full eBPF avec Cilium, c'est vraiment le futur ou une lubie de Hype-Driven-Development ?

C'est marrant cette fascination pour le dernier outil brillant dès qu'on ne sait pas tuner le précédent. Si tu as de la latence avec Istio, c'est probablement que ta configuration est aux fraises ou que tu as activé le mTLS sur des flux qui n'en ont pas besoin.

Istio offre une granularité L7 que tu ne retrouveras jamais proprement en eBPF pur sans finir par réinventer un proxy partagé. Le sidecar a un avantage : l'isolation. Si un proxy tombe, seul un pod est impacté. Si ton agent Cilium sur le node crash, c'est tout ton node qui devient aveugle.

L'argument de l'isolation est fallacieux. On parle de centaines de megas de RAM bouffés par node juste pour faire du routing basique. Multiplie ça par 500 pods et tu payes littéralement des instances pour faire tourner du vent.

Le bypass de la stack réseau classique via `sockops` en eBPF, c'est pas une lubie, c'est de la physique. On réduit drastiquement les context switches. Regardez comment on attache un programme de filtrage basique :

SEC("sockops")
int bpf_sockmap(struct bpf_sock_ops *skops) {
  __u32 family = skops->family;
  if (family == AF_INET) {
    bpf_sock_hash_update(skops, &sock_hash, &key, BPF_NOEXIST);
  }
  return 0;
}

On se calme sur le C. Le vrai sujet c'est la SecOps. Istio est certifié, audité, et tout le monde sait comment gérer des `PeerAuthentication`. Avec Cilium et Tetragon, on rentre dans une complexité de gestion des politiques au niveau syscall qui va rendre vos on-call insupportables.

Comment tu expliques à un dev pourquoi son paquet est drop par le kernel sans aucun log applicatif clair ? Bonne chance pour débugger ça à 4h du matin avec un `cilium monitor` qui défile à la vitesse de la lumière.

Exactement. Et parlons du mTLS. Cilium délègue souvent ça à IPsec ou WireGuard au niveau node. Super, donc tes données sont en clair dès qu'elles arrivent sur l'interface réseau du node avant d'atteindre le pod ? C'est un retour en arrière de 5 ans sur la sécurité Zero Trust.

Le sidecar garantit que le trafic est chiffré jusqu'au container, point final.

C'est faux, Cilium supporte maintenant le mTLS sans sidecar en s'appuyant sur un certificat node-local et une authentification via le control-plane. Et pour le debug, Hubble est dix fois plus puissant que Kiali.

Tu lances un `hubble observe --pod my-app -f` et tu vois les flows en temps réel sans avoir à injecter des headers de tracing manuellement partout. C'est l'observabilité dont on rêvait.

Le point sur les coûts m'intéresse vraiment. Actuellement sur nos clusters, Istio nous bouffe environ 15% de la capacité CPU totale uniquement pour le transit. Si je passe sur Cilium avec le mode `kube-proxy-replacement=strict`, je gagne vraiment en densité ?

Tu gagnes en CPU mais tu perds en flexibilité de routing. Dès que tu vas vouloir faire du header manipulation complexe ou du retry intelligent avec des backoffs custom, tu vas finir par déployer un Envoy partagé via le Gateway API de Cilium.

Au final, tu auras juste déplacé le proxy du pod vers le node. C'est le retour du Shared Proxy des années 2010. On tourne en rond.

Sauf que le Shared Proxy est optimisé et ne tourne pas 2000 fois inutilement. Pour le remplacement de kube-proxy, c'est le jour et la nuit. On vire des milliers de règles `iptables` qui ralentissent le kernel dès qu'on a beaucoup de services.

Un simple `cilium status` te montre la différence de santé du cluster. C'est propre, c'est net.

Attention au Kernel. Cilium demande un kernel récent, au moins 5.10+ pour profiter des features sérieuses. Si vous êtes sur des vieilles AMI ou du Debian stable un peu daté, vous allez souffrir.

Vérifiez vos versions de kernel avec `uname -r` avant de rêver. Et ne parlons pas de la complexité de l'upgrade de Cilium lui-même, c'est pas juste un `helm upgrade` sans douleur.

Merci de le rappeler. Les gens oublient que eBPF c'est charger du code dans le kernel. Un bug dans un programme BPF et c'est le kernel panic assuré ou des fuites mémoires que tes outils de monitoring classiques ne verront même pas.

Istio tourne dans l'espace utilisateur. Si ça crash, le kernel survit. C'est la base de la résilience système.

Le vérificateur BPF empêche les crashs et les boucles infinies. On n'est plus en 2014. C'est aujourd'hui la techno la plus sûre et la plus performante pour faire du networking sur Kubernetes.

D'ailleurs Cloudflare et Google l'utilisent massivement. Si c'était si instable, ça se saurait.

Bon, le débat sur la sécurité et le mTLS me fait réfléchir. On a des contraintes PCI-DSS assez strictes. Si je ne peux pas prouver le chiffrement jusqu'au container, l'audit ne passera jamais.

Mais la surcharge d'Istio nous tue. Est-ce qu'on peut mixer les deux ? Garder Cilium pour le CNI et Istio uniquement là où c'est critique ?

C'est le meilleur moyen de créer une usine à gaz impossible à maintenir. Tu vas devoir gérer les NetworkPolicy de Kubernetes, les CiliumNetworkPolicy et les AuthorizationPolicy d'Istio.

Choisissez un camp et tenez-vous y. La stack hybride c'est l'assurance d'avoir des ghosts dans le réseau que personne ne saura expliquer.

Exactement. Reste sur Istio, optimise ton `Sidecar` resource pour ne pas importer tous les services du cluster dans chaque proxy, et tu verras ta RAM fondre. C'est juste de la config.

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

C'est du sparadrap. On sait tous que la gestion des dépendances dans Istio devient ingérable dès que le nombre de namespaces explose. Cilium gère ça nativement sans configuration manuelle de visibilité.

Bref, restez au moyen-âge avec vos proxies si vous voulez, mais ne venez pas pleurer quand vos instances m5.xlarge seront saturées à rien foutre.

Merci pour ces échanges. Je vais commencer par optimiser nos ressources Istio via l'objet `Sidecar` comme suggéré pour voir si on calme la facture.

Mais on va quand même monter un lab avec Cilium et Tetragon sur un cluster de dev pour mesurer précisément le gap de performance et valider l'aspect sécurité avec les auditeurs. Le gain potentiel de CPU est trop gros pour être ignoré. Merci !