eBPF peut-il éliminer le besoin de Sidecar pour Service Mesh

Le maillage de services est un concept décrivant les exigences des applications cloud natives modernes en matière de communication, de visibilité et de sécurité. Les implémentations actuelles de ce concept impliquent l’exécution de proxies sidecar dans chaque charge de travail ou pod. C’est une façon assez inefficace de résoudre ces exigences. Dans cet article, nous examinerons une alternative au modèle de sidecar qui fournit un maillage de service transparent avec un rendement élevé à faible complexité, avec l’aide d’eBPF.

Qu’est-ce que Service Mesh

Un maillage de services est une couche d’infrastructure dédiée qui facilite la communication entre les microservices dans une application distribuée. Il fournit un moyen de gérer et de contrôler les interactions entre les services, offrant des fonctionnalités telles que la gestion du trafic, la découverte de services, l’équilibrage de charge, la sécurité, l’observabilité et la tolérance aux pannes.

Dans une architecture de maillage de services, chaque service est déployé avec un proxy sidecar, qui agit comme un conduit de communication et gère le trafic réseau entre les services. Le proxy sidecar intercepte toutes les demandes entrantes et sortantes, ce qui permet d’appliquer des fonctionnalités avancées sans modifier les services individuels.

Auparavant, la fonctionnalité de maillage de services était souvent implémentée en tant que bibliothèques, ce qui exigeait que chaque application du maillage soit liée à une bibliothèque écrite dans le framework de l’application. Des événements similaires se sont produits dans les premiers jours d’Internet : les applications utilisées pour expédier leur propre pile TCP / IP! Comme nous le verrons plus loin dans cet essai, le service mesh devient une responsabilité du noyau, tout comme la pile réseau.

Les maillages de service sont souvent développés aujourd’hui en utilisant une architecture connue sous le nom de modèle sidecar. Cette architecture encapsule le code implémentant les fonctions mentionnées ci-dessus dans un proxy de couche 4 et s’appuie ensuite sur le trafic de et vers les services étant détournés dans ce soi-disant proxy sidecar. Il est appelé un sidecar parce que chaque application a un proxy attaché à elle, semblable à la façon dont un sidecar s’attache à une moto.

Le coût de l’injection de side-car

Lorsque nous examinons de près le modèle de side-car, nous pouvons voir qu’il tente de reproduire ce concept. L’application continue à utiliser des sockets, et tout est poussé dans l’espace de noms réseau du noyau Linux. Cependant, il est plus compliqué qu’il n’y paraît; de nombreuses étapes supplémentaires sont nécessaires pour injecter le proxy sidecar de manière transparente.

Cette complexité accrue entraîne des coûts élevés en termes de délais et d’utilisation des ressources. Les premiers benchmarks montrent que cela peut augmenter la latence jusqu’à 3-4x, et qu’une grande quantité de RAM supplémentaire est nécessaire pour tous les proxies.

The Limitations of Sidecar Proxies in a Service Mesh

Les proxies Sidecar sont devenus un choix populaire pour la mise en œuvre d’architectures de maillage de services en raison de leur capacité à fournir des fonctionnalités avancées telles que la gestion du trafic, la sécurité et l’observabilité. Cependant, il est important de comprendre que les proxys sidecar ont également leurs limites.

L’une des principales limites des proxies sidecar est la complexité accrue qu’ils introduisent dans le système global. Chaque service ayant son propre proxy sidecar, le nombre de connexions réseau et l’utilisation des ressources peuvent rapidement augmenter, entraînant des problèmes de performance potentiels. En outre, la gestion et la configuration de plusieurs proxys sidecar peuvent devenir difficiles, en particulier dans les déploiements à grande échelle.

Une autre limitation des proxies sidecar est la latence supplémentaire qu’ils introduisent dans la communication entre les services. Étant donné que tout le trafic est acheminé via le proxy sidecar, il y a un surcoût inhérent qui peut affecter le temps de réponse global du système. Bien que cette latence puisse être acceptable pour certaines applications, elle peut être une préoccupation importante pour les cas d’utilisation sensibles à la latence.

En outre, les proxys sidecar peuvent également être un point de défaillance unique dans une architecture de maillage de services. Si un proxy sidecar échoue, il peut perturber la communication entre les services, entraînant potentiellement des pannes de service. Il est donc crucial de mettre en œuvre des mécanismes appropriés de surveillance et de tolérance aux pannes pour atténuer l’impact de ces défaillances.

Enfin, les proxys sidecar nécessitent souvent des ressources supplémentaires, telles que le processeur et la mémoire, pour fonctionner efficacement. Cela peut augmenter la consommation globale de ressources du système, ce qui pourrait être une préoccupation dans les environnements à ressources limitées.

En supposant 30 pods par nœud dans un cluster de 500 nœuds, une conception basée sur sidecar nécessitera l’utilisation de 15K proxies. Avec 70 Mo de mémoire utilisée par proxy (en supposant des tables de routage bien optimisées), la mémoire totale consommée par tous les sidecars du cluster est de 1,5 To. Les 500 proxies n’utiliseront pas plus de 34 Go de mémoire dans une approche par nœud avec la même empreinte mémoire prévue par proxy.

Qu’est-ce que eBPF ?

eBPF, ou Berkeley Packet Filter étendu, est une technologie passionnante qui a attiré beaucoup d’attention ces dernières années. C’est un framework puissant et flexible qui permet l’exécution dynamique du code dans le noyau Linux. Avec eBPF, les développeurs peuvent écrire et charger des programmes personnalisés qui s’exécutent directement dans le noyau, ce qui leur permet d’effectuer diverses tâches, telles que le filtrage, le suivi et la surveillance des paquets réseau.

eBPF et son rôle dans l’architecture Service Mesh

Dans le contexte de l’architecture de maillage de services, eBPF joue un rôle crucial dans l’amélioration de l’observabilité, de la sécurité et des performances. En exploitant eBPF, les plateformes de maillage de services peuvent obtenir une visibilité approfondie du trafic réseau, ce qui permet une surveillance et une analyse en temps réel. Cette visibilité permet aux opérateurs d’identifier et de résoudre les problèmes potentiels, en garantissant des performances et une fiabilité optimales.

De plus, eBPF fournit un mécanisme robuste pour mettre en œuvre des mesures de sécurité dans un maillage de service. En interceptant et en analysant le trafic réseau au niveau du noyau, les programmes eBPF peuvent appliquer des politiques de sécurité précises, telles que le contrôle d’accès et le cryptage. Cette capacité améliore la posture de sécurité globale du maillage de service, protégeant les données sensibles et atténuant les menaces potentielles.

Un autre avantage significatif de eBPF dans l’architecture de maillage de services est sa capacité à optimiser les performances du réseau. En déchargeant certaines tâches sur le noyau, les programmes eBPF peuvent réduire la latence et améliorer le débit. Par exemple, eBPF peut être utilisé pour implémenter des algorithmes d’équilibrage de charge, un routage intelligent, ou même accélérer les opérations de chiffrement et de déchiffrement. Ces optimisations contribuent à améliorer les performances globales et l’évolutivité du maillage de services.

Défis et limites

Bien que eBPF offre de nombreux avantages, il est important de reconnaître certains défis et limites :

1. Courbe d’apprentissage: Le développement et le débogage de programmes eBPF peuvent nécessiter une courbe d’apprentissage, car il implique l’écriture de programmes personnalisés dans un langage virtuel spécifique de type machine.

2. Compatibilité du noyau : Les programmes eBPF reposent sur des fonctionnalités spécifiques du noyau, donc la compatibilité entre les différentes versions du noyau doit être prise en compte.

3. Complexité des programmes eBPF : La rédaction de programmes eBPF peut être complexe, en particulier pour les fonctions complexes de maillage de services. Les capacités avancées peuvent nécessiter une compréhension plus approfondie des composants internes du noyau.

Conclusion

Bien que l’eBPF ait encore quelques défis, il est clair que cette technologie a le potentiel de transformer la façon dont nous concevons et implémentons les architectures de maillage de services. Comme eBPF continue d’évoluer et de gagner en popularité, nous pouvons nous attendre à plus d’innovations et d’améliorations dans le paysage de maillage de services.