Pourquoi APISIX Ingress Controller est-il un meilleur choix qu'Emissary-ingress ?
Xin Rong
March 17, 2023
Informations de base
Kubernetes Ingress est un objet API utilisé pour définir des règles de routage du trafic externe vers les services internes d'un cluster. Un Ingress Controller est couramment utilisé pour implémenter la logique de la ressource Ingress et gérer ces règles de trafic de manière centralisée.
En pratique, les utilisateurs professionnels ont généralement besoin de fonctions de gestion du trafic telles que mTLS, les nouvelles tentatives, la limitation de débit et l'authentification, que la sémantique de la ressource Ingress ne peut pas satisfaire. Par conséquent, les implémentations d'Ingress Controller étendent généralement les fonctions en ajoutant des CRD supplémentaires. La suite de ce document fournira une comparaison détaillée des différences entre les implémentations d'APISIX Ingress Controller et d'Emissary-Ingress.
Qu'est-ce que Apache APISIX Ingress Controller
Apache APISIX Ingress Controller est un projet open source sous la ASF (Apache Software Foundation). Son plan de contrôle configure et délivre les ressources dans Kubernetes, tandis qu'APISIX gère le trafic commercial réel. Pour améliorer la sécurité, l'ensemble du processus de déploiement utilise une architecture complètement séparée entre le plan de données et le plan de contrôle, évitant ainsi efficacement le risque de fuite des permissions du cluster Kubernetes causée par des attaques sur le plan de données.
Qu'est-ce qu'Emissary-Ingress
Emissary-Ingress est un projet en incubation de la CNCF (Cloud Native Computing Foundation). En tant que plan de contrôle du proxy Envoy, il est responsable de l'analyse des ressources Kubernetes, et tout le trafic est directement traité par Envoy sur le plan de données. En emballant le plan de contrôle et le plan de données dans un seul conteneur, l'ensemble est plus facile à accéder et à déployer.
La différence entre APISIX Ingress Controller et Emissary-Ingress
En plus de prendre en charge les ressources Ingress, APISIX Ingress Controller et Emissary-Ingress peuvent tous deux prendre en charge la configuration via des CRD et l'API Gateway pour compléter les limitations de la sémantique Ingress.
Les sections suivantes analyseront les différences et les avantages entre les deux du point de vue des fonctionnalités de base, de la découverte de services et de l'extensibilité.
Fonctionnalités de base
| Fonctionnalité | APISIX Ingress | Emissary-ingress | |
| Protocoles | HTTP/HTTPS | ✓ | ✓ |
| gRPC | ✓ | ✓ | |
| TCP | ✓ | ✓ | |
| UDP | ✓ | ✕ | |
| Websockets | ✓ | ✓ | |
| Équilibrage de charge | Round Robin | ✓ | ✓ |
| Ring Hash | ✓ | ✓ | |
| Least Connections | ✓ | ✓ | |
| Maglev | ✕ | ✓ | |
| Authentification | External Auth | ✓ | ✓ |
| Basic | ✓ | ✓ | |
| JWT | ✓ | ✕ | |
| OAuth | ✓ | ✕ | |
| OpenID | ✓ | ✕ | |
| Gestion du trafic | Circuit Breaker | ✓ | ✓ |
| Limitation de débit | ✓ | ✓ | |
| Canary | ✓ | ✓ | |
| Injection de fautes | ✓ | ✕ | |
| Vérifications de santé | ✓ | ✓ | |
Les fonctions courantes des passerelles incluent la gestion du trafic, l'équilibrage de charge et l'authentification. Cependant, il convient de noter qu'Emissary-Ingress a un support relativement limité pour l'authentification, qui ne comprend que les capacités Basic Auth et External Auth.
Découverte de services
Dans l'architecture des microservices, les applications sont généralement décomposées en plusieurs microservices qui travaillent ensemble pour accomplir une logique métier spécifique. Comme le nombre d'instances de microservices change constamment, un mécanisme est nécessaire pour aider les services à se découvrir et à se localiser mutuellement.
La découverte de services fait référence à la manière dont les microservices sont localisés sur le réseau en obtenant des informations sur la découverte de services via le nom du service pour déterminer à quelle instance la demande est routée.
Pour les frameworks de microservices traditionnels, le choix d'un registre est souvent basé sur des besoins métier spécifiques. Cependant, migrer un composant existant d'enregistrement et de découverte de services vers un mécanisme de découverte de services basé sur DNS dans Kubernetes peut entraîner certains coûts en termes de modifications.
D'un autre côté, si la passerelle prend en charge les composants actuels d'enregistrement et de découverte de services, de telles modifications ne sont pas nécessaires, ce qui peut permettre un meilleur support des frameworks de microservices.
Voici les situations de support des deux pour les composants de découverte de services :
| Découverte de services | Apache APISIX Ingress Controller | Emissary-Ingress |
|---|---|---|
| Kubernetes | ✓ | ✓ |
| DNS | ✓ | ✓ |
| Nacos | ✓ | ✕ |
| Eureka | ✓ | ✕ |
| Consul | ✓ | ✓ |
En ce qui concerne l'écosystème de la découverte de services, APISIX Ingress Controller a un support plus fort, et les utilisateurs peuvent facilement l'intégrer dans leur framework de microservices existant via le contrôleur Ingress.
Extensibilité
Lorsque la fonctionnalité du contrôleur Kubernetes Ingress ne répond pas à des besoins spécifiques, les utilisateurs peuvent étendre sa fonctionnalité par un développement personnalisé. Des besoins plus personnalisés peuvent être satisfaits en développant des plugins personnalisés ou en modifiant le code existant. Les contrôleurs Ingress avec une extensibilité robuste peuvent rendre le développement et la personnalisation des fonctionnalités plus faciles, fournissant un meilleur support et des solutions pour des scénarios spécifiques.
Emissary-Ingress
L'extensibilité d'Emissary-Ingress est relativement faible, car elle ne prend pas en charge l'extension via le Envoy Filter personnalisé. Comme le plan de données et le plan de contrôle sont intégrés, il nécessite un développement personnalisé de l'ensemble du système. La complexité du développement personnalisé pour le plan de données Envoy est élevée et représente un fardeau important pour les développeurs.
De plus, si les utilisateurs ont besoin d'un Emissary-Ingress plus puissant, ils doivent le mettre à niveau vers le produit commercial d'Ambassador, Edge Stack. Certaines fonctionnalités propriétaires nécessitent des paiements pour obtenir un support.
APISIX Ingress Controller
Le plan de données d'APISIX étend principalement ses fonctionnalités via des plugins, qui fournissent plus de 80 plugins prêts à l'emploi. APISIX Ingress Controller prend en charge tous les plugins fournis par APISIX, ce qui peut satisfaire la plupart des cas d'utilisation quotidiens.
Si une personnalisation est nécessaire en fonction de scénarios métier spécifiques, APISIX offre plusieurs options d'extension pour que les utilisateurs puissent choisir et combiner librement selon leurs situations. Les méthodes d'extension actuellement supportées sont les suivantes :
- Développer des plugins en utilisant le langage Lua est relativement simple et presque sans perte de performance. De plus, vous pouvez utiliser le plugin serverless pour écrire du code Lua directement, ce qui peut rapidement répondre aux besoins métier.
- En plus du langage Lua natif, vous pouvez également utiliser
Plugin RunnerouWASMpour l'extension, ce qui permet de développer des plugins personnalisés dans des langages de programmation tels que Java, Python et Go. Cela permet aux utilisateurs d'utiliser leur logique métier existante et de sélectionner en fonction de la pile technologique ou des préférences de développement de leur entreprise sans nécessiter un nouveau langage.
APISIX Ingress Controller prend entièrement en charge les méthodes d'extension ci-dessus sans aucun développement supplémentaire.
Performance
En tant que composant proxy de trafic d'entrée Kubernetes, il gère tout le trafic entrant de la plateforme et gère de manière uniforme diverses règles de trafic, ce qui impose des exigences plus élevées sur la performance du proxy.
Dans cet article, nous effectuerons des tests de performance sur APISIX Ingress Controller (APISIX: 3.1.0) et Emissary-Ingress 3.4.0 sur la même instance (4C 8G).
QPS
QPS (Queries-per-second) représente le nombre de requêtes qu'un service peut traiter par seconde. Plus le nombre est élevé, meilleure est la performance.
- 5000 Ingress Resource QPS
Latence
Latence de réponse : le temps que prend le serveur pour répondre. Plus le délai est petit, meilleure est la performance.
Le graphique montre qu'APISIX Ingress Controller maintient une performance constante à différentes échelles de ressources, démontrant une performance bien équilibrée.
D'un autre côté, Emissary-Ingress a un impact significatif sur le QPS et la latence lors de la gestion de grandes échelles de ressources et de différents matchs de routage, avec une performance qui diminue à mesure que le nombre de ressources augmente. Par conséquent, à mesure que le volume métier augmente dans les environnements de production réels, la haute performance d'APISIX devient plus évidente.
Conclusion
Emissary-Ingress se caractérise par sa simplicité et sa facilité d'intégration, mais est plus difficile à développer de manière personnalisée. De plus, des besoins supplémentaires en fonctionnalités dépendent des composants associés de la plateforme pour un support.
En comparaison, APISIX Ingress Controller a des avantages en termes d'extensibilité et d'intégration de la découverte de services, avec une forte extensibilité et un développement simple. De plus, APISIX Ingress Controller performe exceptionnellement bien, en particulier dans les scénarios où l'échelle métier continue de croître, montrant des avantages significatifs.