Pourquoi APISIX Ingress Controller est-il meilleur que NGINX Ingress Controller ?

Ingress expose les services dans Kubernetes, où le routage du trafic est contrôlé par des règles configurées sur la ressource Ingress. Pour satisfaire un Ingress, vous devez également avoir un contrôleur Ingress.

Dans cet article, nous comparerons deux contrôleurs Ingress populaires pour donner aux lecteurs des insights sur la sélection des contrôleurs Ingress.

• Ingress-NGINX est un contrôleur Ingress implémenté par la communauté Kubernetes et est largement utilisé dans la communauté.
• APISIX Ingress controller utilise Apache APISIX, un projet open-source sous l'ASF (Apache Software Foundation), comme son plan de données.

Ingress NGINX vs. APISIX Ingress

Comparaison des fonctionnalités

Le tableau ci-dessous compare les fonctionnalités de base d'Ingress NGINX et d'APISIX Ingress, y compris les protocoles, les sondes/résiliences en amont, les stratégies de répartition de charge, l'authentification, l'intégration Kubernetes, etc. Le tableau est extrait de learnk8s.io.

Différences

Nous pouvons voir dans la figure ci-dessous qu'il y a plus de fonctions et de fonctionnalités intégrées dans APISIX Ingress que dans Ingress NGINX, y compris le support des protocoles, les vérifications de santé et les disjoncteurs, l'authentification, l'intégration Kubernetes, etc.

Découverte de service

Dans l'architecture des microservices, l'application est divisée en de nombreux microservices. Chaque fois qu'un microservice tombe en panne, ou qu'un service est mis à l'échelle, l'appelant doit être notifié dès que possible pour éviter les échecs d'appel. Par conséquent, le mécanisme d'enregistrement et de découverte de service est vital dans l'architecture des microservices, généralement maintenu par le registre de services.

Support des protocoles

Alors que les deux Ingress supportent le protocole HTTP/HTTPS, APISIX supporte plus de protocoles. Il supporte TLS pour chiffrer le trafic TCP. Il supporte également MQTT, Dubbo, et kafka pour le proxying.

Sondes/résilience en amont

Vérifications de santé

Lorsqu'un nœud tombe en panne ou migre, il est inévitable que le nœud soit indisponible. Si un grand nombre de requêtes accèdent à ces nœuds indisponibles, cela entraînera une perte de trafic et une interruption des activités. Par conséquent, il est nécessaire d'effectuer des vérifications de santé sur les nœuds en utilisant des sondes, et de diriger les requêtes vers les nœuds sains, réduisant ainsi la perte de trafic.

La fonctionnalité de vérification de santé n'est pas encore supportée dans Ingress NGINX, mais APISIX Ingress fournit cette fonctionnalité :

• Vérification active : Utilisez des sondes pour vous assurer que les Pods en arrière-plan sont sains. Lorsque N sondes consécutives envoyées à un nœud échouent, le nœud sera marqué comme malsain. Le répartiteur de charge ignorera les nœuds malsains afin qu'ils ne puissent pas recevoir de requêtes. Activer les vérifications de santé actives peut désactiver efficacement les Pods malsains pour éviter la perte de trafic.
• Vérification passive : La vérification de santé passive n'a pas besoin de lancer des sondes supplémentaires. Chaque requête envoyée au nœud agit comme une sonde. Si N requêtes consécutives à un nœud sain échouent, le nœud sera marqué comme malsain. Comme il ne peut pas détecter l'état du nœud à l'avance, il peut y avoir un certain nombre de requêtes échouées. Cette situation est relativement courante lors des mises à jour progressives, et nous pouvons utiliser des dégradations de service pour éviter le nombre de requêtes échouées.

Exemple de configuration des vérifications de santé pour le service httpbin dans APISIX Ingress :

apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin
spec:
  healthCheck:
    passive:
      unhealthy:
        httpCodes:
          - 500
        httpFailures: 3
    active:
      type: http
      httpPath: /healthz
      healthy:
        successes: 3
        interval: 2s
        httpCodes:
          - 200

Disjoncteur

La passerelle est un point d'entrée pour les requêtes ; elle initie des appels au service en arrière-plan. Lorsque le trafic atteint un pic et que la charge est lourde, le service en arrière-plan peut échouer à appeler en raison d'un délai d'attente ou d'une exception. Lorsque l'échec se produit, les requêtes ne peuvent pas s'empiler sur la passerelle. Elle doit retourner rapidement, ce qui nécessite une rupture sur la passerelle.

Similaire à la fonctionnalité de vérification de santé, la fonctionnalité de disjoncteur de service n'est pas supportée dans Ingress NGINX. Dans APISIX Ingress, le plugin api-breaker aide à implémenter cela.

Exemple de configuration du disjoncteur dans APISIX Ingress :

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /status/*
   backends:
   - serviceName: httpbin
     servicePort: 80
   plugins:
   - name: api-breaker
     enable: true
     config:
       break_response_code: 502
       unhealthy:
         http_statuses:
         - 505
         failures: 2
       healthy:
         http_statuses:
         - 200
         successes: 2

Support de plus de plugins et de méthodes d'authentification

Ingress NGINX utilise principalement Annotations et ConfigMap pour la configuration, et les plugins supportés sont relativement limités. Si vous souhaitez utiliser JWT, HAMC, ou d'autres méthodes d'authentification, vous devez les intégrer vous-même.

APISIX Ingress supporte 80+ plugins dans APISIX nativement, qui supporte plusieurs méthodes d'authentification telles que JWT, HAMC, wolf-rbac, etc. Ces plugins fournissent une grande variété de fonctionnalités qui couvrent la plupart des scénarios d'utilisation.

Exemple d'authentification HMAC sur une route APISIX :

apiVersion: apisix.apache.org/v2
kind: ApisixConsumer
metadata:
  name: hmac-value
spec:
  authParameter:
    hmacAuth:
      value:
        access_key: papa
        secret_key: fatpa
        algorithm: "hmac-sha256"
        clock_skew: 0
---

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /ip
   backends:
   - serviceName: httpbin
     servicePort: 80
   authentication:
     enable: true
     type: hmacAuth

Extensibilité d'Ingress NGINX et d'APISIX Ingress

Lorsque les fonctionnalités de base du contrôleur Ingress ne peuvent pas répondre aux besoins des utilisateurs d'entreprise, il ne peut être personnalisé que par extension. Ensuite, nous expliquerons comment Ingress NGINX et APISIX Ingress étendent leurs fonctionnalités.

Comment Ingress NGINX étend ses fonctionnalités

Ingress NGINX ne peut être étendu qu'en intégrant des programmes Lua.

Exemple de développement de plugin Ingress NGINX :

1. Écrivez un programme Lua example-plugin
2. Installez le plugin dans /etc/nginx/lua/plugins/<votre nom de plugin> $\rightarrow$ /etc/nginx/lua/plugins/example-plugin dans le pod ingress-nginx
3. Activez le example-plugin dans ConfigMap, et référencez cet objet ConfigMap lors de l'installation d'Ingress NGINX

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  plugins: "example-plugin"

Comment APISIX Ingress étend ses fonctionnalités

APISIX Ingress fournit une variété de méthodes pour étendre les fonctionnalités, et les utilisateurs d'entreprise peuvent librement choisir la méthode selon leurs besoins. APISIX supporte :

• Le développement de plugins via Lua : simple et avec presque aucune perte de performance
• Le développement via plugin-runner : les langages de programmation tels que JAVA/Python/Go sont supportés pour le développement, permettant aux utilisateurs de personnaliser leurs plugins sans apprendre de nouveaux langages
• Les plugins via WASM : tout langage supportant la construction de WASM peut être utilisé pour le développement de plugins

De plus, vous pouvez directement écrire du code Lua via le plugin serverless pour répondre rapidement aux besoins métier.

Pourquoi APISIX Ingress supporte-t-il CustomResourceDefinition (CRD) ?

Actuellement, APISIX Ingress supporte trois configurations déclaratives : Ingress, CRD, et Gateway API. Nous comparerons principalement Ingress et CRD ici. Et nous expliquerons Gateway API après.

Ingress est plus adapté aux utilisateurs d'entreprise migrant d'Ingress NGINX pour son faible coût de migration. Ses inconvénients sont également apparents, tels que des capacités sémantiques faibles, aucune spécification standard, etc. Et Ingress ne peut être étendu que via des annotations, mais les annotations ne peuvent pas supporter des scénarios complexes. En comparaison, CRD présente les avantages suivants :

• Plus facile à utiliser car il est plus conforme à la sémantique de conception du plan de données
• Réutilisabilité des configurations pour réduire la redondance
• Amélioration des fonctionnalités et de l'extensibilité
• Le plan de données d'APISIX a une communauté active, avec des mises à jour et des versions rapides, et CRD peut facilement supporter plus de capacités du plan de données

Point douloureux d'Ingress NGINX : Rechargement à chaud non supporté

Problèmes causés par la configuration statique

Ingress NGINX est principalement implémenté sur la base des fichiers de configuration NGINX. Bien que NGINX et Lua soient utilisés pour réaliser des extensions de fonctionnalités, cela ne résout que partiellement le problème des fichiers de configuration statiques. Il montre des insuffisances dans ses capacités de routage et de rechargement. Par exemple, la configuration NGINX doit être rechargée lors de l'ajout ou de la modification d'une règle. Avec de plus en plus de règles de routage et de certificats, l'opération de rechargement prendra plus de temps, de quelques secondes à plus de dix secondes. Chaque rechargement de NGINX réinitialise l'état de la répartition de charge, impactant négativement le trafic en ligne, provoquant de courtes interruptions, augmentant la latence de réponse, et réduisant la qualité de la répartition de charge.

Situations qui déclenchent un rechargement NGINX

• Création d'une nouvelle ressource Ingress
• Ajout d'une section TLS à un Ingress existant
• Modification des annotations Ingress peut également affecter la configuration en amont (par exemple, les annotations de répartition de charge n'ont pas besoin d'être rechargées)
• Ajout ou suppression d'un chemin dans Ingress
• Suppression de ressources Ingress, Service ou Secret
• Mise à jour de Secret

Les situations listées ci-dessus couvrent la plupart des scénarios d'utilisation du contrôleur Ingress. Dans un environnement de cluster avec des applications fréquemment déployées, les opérations (création, mise à jour, suppression, etc.) de ressources telles qu'Ingress et Secret seront continuellement déclenchées. Cela entraînera une augmentation significative du nombre de rechargements NGINX, impactant considérablement l'environnement de production.

L'architecture d'Ingress NGINX détermine qu'elle doit d'abord générer la configuration NGINX et recharger pour compléter la mise à jour de la configuration. Le problème de rechargement ne peut pas être résolu sans ajuster l'architecture. Pour résoudre ce problème, APISIX Ingress ne dépend plus de la configuration NGINX dans son implémentation de routage et est passé à une architecture purement mémoire. Le routage dynamique est réalisé via le rechargement à chaud, et NGINX n'a plus besoin d'être redémarré.

Gateway API

Avantages de Kubernetes Gateway API

Kubernetes Gateway API est plus fonctionnel qu'Ingress et est conçu pour faire évoluer le réseau de services Kubernetes à travers une interface expressive, extensible et orientée rôle implémentée par de nombreux fournisseurs et avec un large support de l'industrie. Gateway API a les caractéristiques suivantes :

• Orienté rôle : Gateway est composé de ressources API. Différentes ressources API représentent différents rôles pour l'utilisation et la configuration des ressources réseau Kubernetes

• Forte expressivité : Gateway API supporte les fonctionnalités de base, y compris la correspondance basée sur les en-têtes, la pondération du trafic, et d'autres capacités qui n'étaient possibles dans Ingress qu'à travers des annotations personnalisées non standard

• Extensible : Gateway API permet à différentes ressources d'être liées à différents niveaux d'API. Cela permet une personnalisation granulaire au sein de la structure de l'API

Statut de support de Gateway API

Kubernetes Gateway API est une norme pour étendre le maillage de services Kubernetes. Sa ressource Gateway peut être utilisée comme une API Kubernetes pour gérer le cycle de vie de la passerelle, ce qui est très puissant. De nombreux contrôleurs Ingress le supportent activement, y compris Istio, Kong, Traefik, etc. Malheureusement, Ingress NGXIN ne prévoit pas encore de supporter Gateway API (Statut d'implémentation de Gateway API), alors qu'APISIX Ingress supporte déjà la plupart des fonctionnalités de Gateway API : y compris HTTPRoute, TCPRoute, TLSRoute, UDPRoute, etc.

Résumé

Après une comparaison approfondie d'APISIX Ingress et d'Ingress NGINX, nous pouvons conclure que les deux logiciels open-source sont excellents et que les fonctions essentielles des deux sont similaires. Dans l'architecture des microservices, cependant, APISIX Ingress montre plus d'avantages en supportant la gouvernance des services et la découverte de service en fournissant des vérifications de santé et des disjoncteurs.

Ingress NGINX est caractérisé par sa simplicité et sa facilité d'utilisation, avec quelques inconvénients évidents, tels que des difficultés dans les extensions de fonctionnalités. APISIX Ingress, arrivé plus tard, a résolu le point douloureux du rechargement à chaud de NGINX et a fourni de meilleures extensibilités et fonctionnalités. Par exemple, le support de Gateway API et de CRD enrichit les capacités du contrôleur Ingress en termes de développement de projet.

En bref, si vous souhaitez sélectionner un contrôleur Ingress avec des fonctionnalités plus riches et de meilleures extensibilités, APISIX Ingress est fortement recommandé. Si vous êtes nouveau dans le contrôleur Ingress et que vous n'avez pas beaucoup d'exigences fonctionnelles, Ingress NGINX est également un bon choix pour sa simplicité.