Les clusters Kubernetes nécessitent une passerelle d'entrée (Ingress) pour acheminer le trafic externe vers les services backend. Un mauvais choix de passerelle peut entraîner des goulots d'étranglement au niveau des performances, une charge opérationnelle accrue ou des failles de sécurité. Dans les clusters managés Container Service for Kubernetes (ACK), les clusters ACK Serverless et les clusters Container Compute Service (ACS), vous pouvez utiliser des passerelles Ingress NGINX ou des passerelles Ingress Microservices Engine (MSE). Cette comparaison couvre l'architecture, les performances, le routage, la sécurité, l'observabilité et d'autres aspects afin de vous aider à choisir la passerelle adaptée.
Guide de décision rapide
Choisissez Ingress NGINX si :
Votre volume de trafic est faible et vos exigences en matière de sécurité, de scalabilité et de stabilité sont modestes.
Vous avez besoin d'une passerelle hautement personnalisable que vous gérez vous-même.
Choisissez Ingress MSE si :
Votre volume de trafic est élevé et vous avez besoin de garanties solides en matière de sécurité, de scalabilité et de stabilité.
Vous souhaitez une exploitation entièrement managée sans contrainte de maintenance liée à la passerelle.
Vous avez besoin de plusieurs méthodes de découverte de services (Kubernetes, Nacos, Eureka, DNS, adresses IP fixes).
Vous avez besoin d'une protection Web Application Firewall (WAF) intégrée et d'une authentification avancée (JWT, OIDC, IDaaS, authentification personnalisée).
Vous avez besoin d'une observabilité de bout en bout avec des journaux d'accès, du tracing distribué, des métriques et des alertes.
Architecture
| Aspect | Ingress NGINX | Ingress MSE |
|---|---|---|
| Moteur | NGINX avec plug-in Lua | Istiod + Envoy |
| Multi-location | Composants autogérés | Instances dédiées par utilisateur |
| Gestion des ressources | Configuration manuelle du nombre de réplicas et des limites de ressources | Entièrement managée |
| Transfert de trafic | -- | Connecté directement aux adresses IP des pods pour le transfert des requêtes |
Performances
| Métrique | Ingress NGINX | Ingress MSE |
|---|---|---|
| Optimisation | Réglage manuel requis | Optimisé au niveau du système d'exploitation avec des améliorations internes |
| Accélération HTTPS | Non disponible | Amélioration des performances HTTPS d'environ 80 % grâce à l'accélération matérielle |
| Débit par rapport à NGINX open source | Référence | Environ 40 % supérieur grâce à l'optimisation du système d'exploitation et interne |
| TPS à 30–40 % d'utilisation du CPU | Référence | Environ 90 % supérieur à Ingress NGINX open source |
| Impact des plug-ins | L'utilisation intensive de scripts Lua dégrade considérablement les performances | -- |
Routage et équilibrage de charge
| Fonctionnalité | Ingress NGINX | Ingress MSE |
|---|---|---|
| Routage basé sur le contenu | Oui | Oui |
| Réécriture des en-têtes HTTP | Oui | Oui |
| Redirections et réécritures d'URL | Oui | Oui |
| Limitation du débit | Oui | Oui |
| Partage de ressources cross-origin (CORS) | -- | Oui |
| Délais d'attente et nouvelles tentatives | -- | Oui |
| Algorithmes d'équilibrage de charge | -- | Tourniquet (round-robin), aléatoire, moins de requêtes, hachage cohérent |
| Préchauffage du trafic (préchargement) | Non | Oui. Le trafic vers les nouveaux pods backend augmente progressivement sur une fenêtre de temps configurable. |
Mises à jour de configuration
| Comportement | Ingress NGINX | Ingress MSE |
|---|---|---|
| Modifications de configuration | Mises à jour progressives via le plug-in Lua (sauf pour les certificats) | Mises à jour progressives prises en charge |
| Mises à jour de certificats | Nécessite un rechargement, ce qui interrompt les connexions persistantes | Mises à jour progressives prises en charge |
| Mises à jour des plug-ins | Nécessite un rechargement | Mises à jour progressives pour les plug-ins WebAssembly |
| Mécanisme de mise à jour | Basé sur le rechargement | List-Watch pour une propagation de configuration quasi en temps réel |
Découverte de services et gouvernance
| Fonctionnalité | Ingress NGINX | Ingress MSE |
|---|---|---|
| Découverte de services | Kubernetes uniquement | Kubernetes, Nacos, Eureka, DNS, adresses IP fixes |
| Versions Canary | Oui | Oui |
| Routage basé sur les tags | Non | Oui |
| Distribution du trafic par pourcentage | Non | Oui (version canary, test A/B, déploiement bleu-vert) |
| Limitation du débit | Oui | Oui |
| Disjoncteur et dégradation | Non | Oui, intégré à Application High Availability Service (AHAS) |
| Simulation de service | Non | Oui |
Sécurité
| Fonctionnalité | Ingress NGINX | Ingress MSE |
|---|---|---|
| HTTPS | Oui | Oui, intégré à Certificate Management Service |
| Protection WAF | Non | Oui, intégré à Alibaba Cloud WAF |
| Contrôle d'accès basé sur l'IP (listes noires et listes d'autorisation) | Oui | Oui |
Authentification
| Méthode | Ingress NGINX | Ingress MSE |
|---|---|---|
| BasicAuth | Oui | Oui |
| OAuth | Oui | Oui |
| JWT | Non | Oui |
| OIDC | Non | Oui |
| IDaaS | Non | Oui |
| Authentification personnalisée | Non | Oui |
Opérations et maintenance
| Aspect | Ingress NGINX | Ingress MSE |
|---|---|---|
| Modèle de gestion | Autogéré | Entièrement managé |
| Mise à l'échelle | Horizontal Pod Autoscaler (HPA) | HPA (en cours de développement) |
| Ajustement des spécifications | Configuration manuelle requise | -- |
Protocoles et conversion
| Fonctionnalité | Ingress NGINX | Ingress MSE |
|---|---|---|
| HTTP | Oui | Oui |
| HTTPS | Oui | Oui |
| Conversion HTTP vers Dubbo | Non | Oui |
| Conversion HTTPS vers Dubbo | Non | Oui |
Intégration Ingress et cloud-native
| Fonctionnalité | Ingress NGINX | Ingress MSE |
|---|---|---|
| Ressources Kubernetes Ingress | Oui | Oui |
| Conversion des annotations Ingress NGINX | Sans objet | Conversion automatique prise en charge. Pour plus de détails, consultez Annotations prises en charge par les passerelles Ingress MSE. |
| Types de clusters pris en charge | Clusters managés ACK, clusters ACK Serverless, clusters ACS | Clusters managés ACK, clusters ACK Serverless, clusters ACS |
Extensibilité
| Approche | Ingress NGINX | Ingress MSE |
|---|---|---|
| Langage des plug-ins | Lua | WebAssembly (prend en charge plusieurs langages de programmation) |
| Plug-in Lua | Oui | En cours de développement |
Observabilité
| Fonctionnalité | Ingress NGINX | Ingress MSE |
|---|---|---|
| Journaux d'accès | Oui | Oui, intégré à Simple Log Service (SLS) et Application Real-Time Monitoring Service (ARMS) |
| Métriques et alertes | Prometheus | Intégré à ARMS et Managed Service for Prometheus |
| Tracing distribué | Non | Oui, intégré à Managed Service for OpenTelemetry |
Écosystème
| Intégration | Ingress NGINX | Ingress MSE |
|---|---|---|
| Service mesh | Nginx Service Mesh | Maillage de services Istio (standard de facto) |
Cas d'utilisation typiques
Les passerelles Ingress NGINX sont construites sur NGINX open source et servent de passerelle Ingress Kubernetes par défaut. Elles conviennent mieux aux situations suivantes :
Charges de travail nécessitant des configurations de passerelle hautement personnalisées.
Environnements à faible volume de trafic où une gestion autonome est acceptable.
Équipes disposant d'une expertise NGINX existante et souhaitant un contrôle direct sur la passerelle.
Applications cloud-native utilisant des versions canary ou des déploiements bleu-vert.
Les passerelles Ingress MSE sont construites sur des passerelles cloud-native de MSE et combinent les capacités de passerelle de trafic, de passerelle de microservices et de passerelle de sécurité dans une seule plateforme managée. Elles conviennent mieux aux situations suivantes :
Environnements de production à fort trafic nécessitant une sécurité, une scalabilité et une stabilité robustes.
Architectures utilisant plusieurs méthodes de découverte de services ou nécessitant une conversion de protocole (HTTP/HTTPS vers Dubbo).
Scénarios de trafic nord-sud avec découverte de services backend via Nacos, Kubernetes, DNS ou adresses IP fixes.
Scénarios de trafic est-ouest nécessitant une interopérabilité cloud hybride, multi-centres de données ou multi-domaines de services, avec une intégration transparente du maillage de services.