Service Mesh avec sidecars ou la voie eBPF pour le réseau et la sécu K8s c'est quoi le deal ?

L'overhead des sidecars c'est un faux problème si tu dimensionnes correctement tes nœuds. Istio c'est une solution mature éprouvée pour le traffic management l'mTLS et les policies d'autorisation L7. Ce n'est pas une question de marketing mais de fonctionnalités robustes.

Les solutions eBPF sont prometteuses mais elles n'offrent pas le même niveau de contrôle granulaire sur le trafic applicatif. Tu veux faire du canary testing précis ou des injections de fault c'est Istio qu'il te faut pas un CNI qui fait du proxy.

Franchement les sidecars c'est un anti-pattern à la base. Tu dupliques une pile réseau par pod c'est un gaspillage de ressources pur et simple. Chaque sidecar ajoute de la latence de l'overhead mémoire et des points de défaillance.

eBPF comme Cilium ça tourne au niveau du kernel. Pas de proxy en userspace pour chaque pod. Ça te donne des performances réseau bien meilleures une observabilité native avec Hubble et ça gère l'mTLS au plus proche du réseau sans surcharger tes pods applicatifs. Moins de complexité opérationnelle au final.

C'est drôle vous parlez tous de complexité mais les deux sont un enfer à débugger à leur manière. Avec un sidecar tu peux aller voir les logs d'Envoy mais tu dois jongler avec le reste du pod.

Avec eBPF tu dois être un peu plus proche du kernel tu utilises `cilium monitor` `cilium-dbg` c'est pas toujours évident pour un développeur lambda. Ça dépend vraiment de tes équipes et de ce qu'elles sont prêtes à apprendre.

Le modèle de sécurité d'Istio avec les AuthorizationPolicies est ultra robuste. Tu peux définir des règles très fines basées sur l'identité du service le chemin HTTP la méthode etc. C'est audit-proof.

Et la gestion des certificats mTLS avec Citadel est transparente. Ça tourne et ça expire pas en pleine nuit sans que personne ne s'en aperçoive. Avec eBPF tu gères comment la rotation des certificats à grande échelle sans un contrôleur dédié ?

eBPF est plus sûr parce que le code est vérifié par le kernel verifier avant d'être chargé. Moins de bugs de user-space moins de CVEs potentielles qu'un proxy géant comme Envoy avec tous ses modules.

Pour l'mTLS Cilium intègre SPIFFE/SPIRE c'est le standard de facto pour l'identité de service. Et pas besoin d'injecter des sidecars partout le CNI gère ça. Tu penses vraiment que 1000 Envoy sont plus stables que quelques agents Cilium par nœud ?

L'mTLS Cilium est bon mais il nécessite souvent une intégration plus poussée avec ta PKI existante si elle est un peu custom. Istio a une CA intégrée qui simplifie l'onboarding pour des équipes qui n'ont pas d'infra PKI existante.

Faut regarder l'écosystème global pas juste la technologie de base.

Le traffic management d'Istio c'est un game changer pour les déploiements avancés. Les VirtualServices et Gateways te donnent un contrôle total sur le routage du trafic L7.

Imagine devoir faire un routage complexe basé sur des headers HTTP ou des pourcentages de trafic pour une feature flag. Avec Istio c'est super clair et déclaratif :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
  - my-app.example.com
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*chrome.*"
    route:
    - destination:
        host: my-app
        subset: canary
  - route:
    - destination:
        host: my-app
        subset: stable

Bonne chance pour faire ça proprement avec juste du eBPF pur sans Envoy ou une couche de proxy.

Cilium peut faire du L7 aussi avec l'intégration d'Envoy si tu en as vraiment besoin mais ce n'est pas la base de son fonctionnement. Pour des règles simples comme la limitation de taux ou le filtrage HTTP basique ça se fait au niveau kernel avec une efficacité redoutable.

Et encore une fois la différence c'est que tu n'as pas un Envoy par pod qui consomme 50-100MB de RAM et 0.1 vCPU juste pour forwarder du trafic. L'agent Cilium sur le nœud s'occupe de tout.

L'observabilité par contre est un point fort des deux. Istio te donne Kiali Prometheus et Grafana avec des métriques riches au niveau de l'application.

Cilium avec Hubble c'est incroyable pour le troubleshooting réseau bas niveau. Tu vois les flows en temps réel tu peux débugger les NetworkPolicies c'est super puissant. Quand t'as un problème de connexion obscure c'est Hubble qui va te sauver.

cilium monitor -t l3 l4 --from-label app=my-service

Chacun a sa force.

Pour les architectures multi-cluster et hybrides Istio est beaucoup plus mature. Tu peux fédérer des clusters déployés sur différentes régions cloud ou on-prem avec un plan de contrôle unifié.

C'est une brique fondamentale pour des entreprises avec une présence globale pas juste un petit cluster de dev.

Cilium Cluster Mesh existe et fonctionne très bien pour l'identité et la connectivité multi-cluster. L'avantage c'est que tu n'as pas besoin de propager un plan de contrôle complet sur chaque cluster ce qui réduit la complexité.

L'identité de service est gérée au niveau de la CNI pas par un sidecar qui injecte des certificats. C'est plus léger et plus rapide.

On ne peut pas ignorer l'impact sur la densité des pods. Les sidecars réduisent drastiquement le nombre de pods que tu peux faire tourner sur un nœud. Pour chaque pod tu as un conteneur Envoy en plus qui bouffe ses ressources.

Quand tu as des centaines voire des milliers de microservices ça se sent directement sur la facture cloud et la complexité du capacity planning. Ça c'est un argument FinOps important.

C'est un compromis. La valeur ajoutée d'Istio en termes de sécurité d'observabilité et de traffic management compense largement le coût des ressources supplémentaires.

Si tes équipes passent moins de temps à débugger des problèmes de réseau ou à gérer des failles de sécurité c'est un gain énorme qui dépasse le coût de quelques CPU en plus.

Le problème c'est que la plupart des applications n'ont pas besoin de la complexité d'un service mesh complet. Elles ont juste besoin de communiquer de manière sécurisée et rapide.

eBPF te donne cette base solide sans le bloatware. Tu ajoutes les fonctionnalités manquantes seulement si tu en as vraiment besoin pas par défaut sur chaque pod.

L'expérience développeur est aussi à prendre en compte. Avec Istio il faut comprendre les CRDs VirtualService Gateway etc. Ça ajoute une courbe d'apprentissage.

Avec une solution eBPF bien configurée les développeurs n'ont presque rien à savoir. Le réseau est abstrait. C'est juste là ça marche. C'est aussi un argument fort pour l'adoption.

C'est faux. L'abstraction eBPF c'est bien tant que ça marche. Dès que t'as un souci réseau tes devs sont complètement perdus parce qu'ils ne comprennent pas la couche magique qui gère le trafic.

Avec Istio les abstractions sont explicites. On sait qu'Envoy gère le trafic on sait que la règle X ou Y est appliquée. C'est plus facile à raisonner.

On est censé faire du SRE pas des experts en sidecars Envoy. Le but est de simplifier l'infra pas d'ajouter des couches de complexité superflues pour des scénarios de edge cases.

La simplicité opérationnelle et la réduction des coûts c'est le nerf de la guerre. Les sidecars c'est pas ça.

Le choix c'est souvent entre la flexibilité des sidecars pour des scénarios avancés et la performance brute des solutions eBPF pour le trafic réseau de base.

Pour un cluster à très haute densité où chaque milliseconde et chaque octet compte eBPF a un avantage clair. Pour des équipes qui veulent déléguer des décisions de routage complexes aux développeurs Istio peut être plus adapté.

Et on parle des capacités de Policy Enforcement d'Istio ? Tu peux bloquer des appels entre services ou vers des ressources externes avec une granularité incroyable. Essaye ça avec une NetworkPolicy classique.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all-egress-to-external
spec:
  selector:
    matchLabels:
      app: my-service
  action: DENY
  rules:
  - to:
    - operation:
        hosts:
        - "*.external-api.com"

CiliumNetworkPolicy peut faire des choses similaires avec des règles L3/L4 et même L7 basiques. Et c'est appliqué directement au niveau kernel c'est beaucoup plus performant et moins contournable qu'un proxy en userspace.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-to-kube-dns
spec:
  endpointSelector:
    matchLabels:
      app: my-app
  egress:
  - toEndpoints:
    - matchLabels:
        k8s:kube-dns

C'est une question de philosophie pas de capacités fondamentales.