Kubernetes : Istio passe lui aussi au régime sans sidecar

Le projet Istio expérimente une option sans sidecar… qui coexistera jusqu’à nouvel ordre avec l’architecture actuelle.

Un maillage de services sans sidecars ? C’est à l’expérimentation sur Istio. À la baguette, Google et Solo.io, les deux principales forces en présence au comité technique du projet.

L’architecture actuelle d’Istio implémente toutes les fonctionnalités du plan dans des proxys Envoy déployés aux côtés des conteneurs, sous la forme de sidecars. Avec cette approche :

– Installer ou mettre à jour les sidecars exige de relancer les pods
– Un proxy étant dédié à une charge de travail, il faut provisionner les ressources (CPU/RAM) en fonction du pire scénario de consommation pour chaque pod
– La capture du trafic et le traitement HTTP sont gourmands en ressources
– Le coût d’exploitation est fixe : pas moyen de désagréger les fonctions du proxy

Les services de couche 7 déportés

Avec le mode dit « Ambient », Istio divise ces fonctions en deux couches. D’une part, un socle avec routage TCP, sécurité mTLS et observabilité (journalisation, métriques TCP). De l’autre, des services de couche 7 (routage et répartition de charge HTTP, contrôle d’accès plus fin, traces…).

On peut choisir d’utiliser uniquement le socle ou les deux. Ce au niveau des clusters ou des espaces des noms. Peu importe le mode sur lequel ils fonctionnent, les workloads peuvent communiquer.

Ambient repose sur des « tunnels zero trust » déployés sur chaque nœud. Tout le trafic y passe. Cette architecture permet d’agir sur le plan de données sans perturber les applications.

Le mode « complet » ajoute des proxys intermédiaires auxquels se connectent les tunnels. C’est là que se passe le traitement de couche 7.

Istio rejoint Cilium au « club sans sidecar »

Du point de vue de Kubernetes, ces proxys sont des pods. On peut donc les déployer et les mettre à l’échelle dynamiquement, en fonction du trafic. En outre, ils libèrent de la charge CPU, les fonctions L4 du socle étant moins consommatrices.

Sur le volet sécurité, Google et Solo.io avancent quelques arguments :

– En mode « classique », une faille dans une app peut contaminer un sidecar et vice versa ; en mode Ambient, les tunnels et les proxys peuvent appliquer des restrictions sur le trafic de l’app compromise
– Les tunnels sont des ressources partagées, mais leur surface d’attaque est limitée à la couche 4
– Les proxys sont aussi des ressources partagées, mais il ne servent qu’un compte de service

Quid des performances ? La position du proxy intermédiaire (il n’est pas forcément sur le même nœud que le workload qu’il sert) peut induire de la latence. Mais dans la plupart des cas, nous affirme-t-on, le déport du traitement L7 compense.

D’autres maillages de services proposent une option sans sidecar. Cilium en fait partie. Istio a toutefois pour signe distinctif de pouvoir faire coexister les deux modes (« classique » et Ambient) avec un même plan de contrôle. Avec, on le rappellera, les limites d’un produit encore expérimental. Certains composants ont par exemple encore trop de permissions. Quant aux requêtes directes sur les IP des pods, elles ne fonctionnent pas toujours, entre autres éléments à corriger.