Alibaba Cloud Service Mesh (ASM) prend en charge deux modes de plan de données : le mode Sidecar et le mode Ambient. Ces deux modes offrent l'intégralité des fonctionnalités Istio pour la gestion du trafic, la sécurité et l'observabilité, mais diffèrent par leur architecture, leur consommation de ressources et leur modèle opérationnel.
Mode Sidecar
En mode Sidecar, un proxy Envoy est injecté en tant que sidecar dans chaque pod et intercepte tout le trafic entrant et sortant.
ASM prend en charge le mode Sidecar depuis sa première version. Après plusieurs itérations et une utilisation intensive en production, il s'agit de l'option la plus mature et la plus stable.
Cheminement du trafic
La figure suivante illustre un cheminement de trafic typique en mode Sidecar.
Mode Ambient
La communauté Istio a introduit le mode Ambient en 2022 pour pallier les limites inhérentes au mode Sidecar. Au lieu d'injecter un proxy dans chaque pod, le mode Ambient sépare le traitement des couches 4 (L4) et 7 (L7) en deux composants indépendants :
ztunnel : un proxy L3/L4 basé sur Rust, déployé sous forme de DaemonSet. Les pods d'un même nœud partagent une seule instance ztunnel. Ce composant gère le chiffrement mTLS, la vérification d'identité, l'autorisation L4 et l'observabilité L4 pour tout le trafic entrant et sortant de ces pods.
Waypoint proxy : un proxy L7 basé sur Envoy, déployé sous forme de Deployment et totalement indépendant des pods applicatifs. La mise à niveau ou l'installation d'un Waypoint proxy ne nécessite aucune modification des pods applicatifs.
À partir d'ASM 1,25, le mode Ambient est prêt pour la production dans les scénarios monoclustre.
Prise en main du mode Ambient
Ajoutez un libellé activant le mode ambient à un namespace pour bénéficier immédiatement du mTLS et de l'observabilité L4, sans injection de sidecar ni redémarrage des pods.
Pour les fonctionnalités L7 telles que le routage basé sur HTTP, l'autorisation L7 ou le traçage distribué, déployez un Waypoint proxy pour des services, des pods ou l'ensemble du namespace ciblé.
Plusieurs services ou pods peuvent partager le même Waypoint proxy. Toutes les requêtes adressées à ces services transitent par le Waypoint avant d'atteindre l'application.
Cheminement du trafic
La figure suivante présente le cheminement du trafic en mode Ambient.
Comparaison des fonctionnalités
|
Fonctionnalité |
Mode Sidecar |
Mode Ambient |
|
Gestion du trafic |
Intégralité des fonctionnalités Istio |
Intégralité des fonctionnalités Istio (nécessite Waypoint) |
|
Sécurité |
Intégralité des fonctionnalités Istio |
Intégralité des fonctionnalités Istio : mTLS et sécurité L4 activés par défaut ; l'autorisation L7 nécessite Waypoint |
|
Observabilité |
Intégralité des fonctionnalités Istio |
Intégralité des fonctionnalités Istio : observabilité L4 activée par défaut ; l'observabilité L7 nécessite Waypoint |
|
Intégration initiale |
Ajoutez un libellé d'injection automatique au namespace et redémarrez tous les pods |
Ajoutez un libellé au namespace ; aucun redémarrage de pod n'est nécessaire |
|
Mises à niveau |
Mise à niveau sur place et canari ; nécessite le redémarrage de tous les pods pour injecter la nouvelle version du sidecar |
Mise à niveau sur place ; les composants du plan de données sont mis à niveau avec le plan de contrôle ; aucun redémarrage de pod n'est nécessaire |
|
Gestion du cycle de vie |
Les développeurs d'applications gèrent le proxy |
Les administrateurs de plateforme gèrent le proxy ; transparent pour les développeurs d'applications |
|
Utilisation des ressources |
Chaque pod exécute un proxy L7, ce qui rend difficile une utilisation optimale |
Les proxies Waypoint montent en charge de manière indépendante ; un namespace entier ou un cluster peut partager un seul Waypoint |
|
Coût moyen en ressources |
Élevé |
Faible |
|
Latence moyenne (données de la communauté Istio) |
0,63 ms – 0,88 ms |
Sans Waypoint : 0,16 ms – 0,20 ms ; avec Waypoint : 0,40 ms – 0,50 ms |
|
Analyse L7 |
Deux fois (sidecar client + sidecar serveur) |
Sans Waypoint : 0 ; avec Waypoint : 1 |
|
Prise en charge à grande échelle |
Nécessite un ajustement fin du périmètre de configuration de chaque sidecar pour réduire le volume de configuration |
Aucun ajustement nécessaire ; seules les configurations nécessaires sont livrées par défaut |
|
Prise en charge des protocoles server-first |
Nécessite une configuration explicite |
Pris en charge par défaut |
|
Prise en charge des Kubernetes Job |
Complexe, car le sidecar est lié au cycle de vie du pod |
Prise en charge transparente |
|
Modèle de sécurité |
Le plus robuste : chaque charge de travail détient sa propre clé |
Robuste : chaque ztunnel détient les clés uniquement pour les charges de travail présentes sur son nœud |
|
Les pods compromis peuvent-ils accéder aux clés du mesh ? |
Oui |
Non |
La séparation L4/L7 du mode Ambient vous permet d'éviter entièrement la surcharge liée au traitement L7 lorsque ces fonctionnalités ne sont pas nécessaires.
L'utilisation conjointe du mode Sidecar et du mode Ambient au sein d'un même mesh n'est pas prête pour la production. Les pods fonctionnant dans des modes différents ne peuvent pas communiquer entre eux.
Le mode Ambient ne prend pas actuellement en charge la gestion multicluster.
Fonctionnalités L4 et L7 du mode Ambient
Le traitement du trafic L7 engendre une surcharge significativement plus élevée que le traitement L4. Si un service n'a besoin que de fonctionnalités L4, omettez le Waypoint proxy pour ce service afin de réduire la consommation de ressources et d'améliorer les performances.
|
Dimension |
Fonctionnalités L4 (ztunnel) |
Fonctionnalités L7 (Waypoint) |
|
Sécurité |
Chiffrement mTLS, autorisation basée sur ServiceAccount, autorisation basée sur IP |
Autorisation basée sur les métadonnées HTTP (méthode, chemin), authentification JWT, autorisation basée sur JWT, autorisation basée sur OPA |
|
Observabilité |
IP et port source/destination, octets envoyés/reçus |
Tracing Analysis, enregistrement complet des requêtes HTTP (méthode, chemin, hôte, code d'état) |
|
Routage |
Équilibrage de charge au niveau de la connexion TCP, disjoncteur, limitation de débit, délai d'expiration, nouvelle tentative |
Équilibrage de charge au niveau de la requête HTTP, disjoncteur, limitation de débit, délai d'expiration, nouvelle tentative, injection de fautes, mirroring du trafic |
|
Extensibilité |
S.O. |
WasmPlugin |