Comment APISIX Ingress prend-il en charge les plugins personnalisés

Ingress & Ingress Controller

Ingress est l'un des objets API de Kubernetes. Il gère l'accès externe aux services dans un cluster, généralement HTTP/HTTPS.

Les clients peuvent suivre les règles Ingress pour acheminer les requêtes client vers les services du cluster Kubernetes ou un Pod spécifique.

Voici un exemple de ressource Ingress :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: apisix-gateway
spec:
  rules:
    - host: apisix.apache.org
      http:
        paths:
          - backend:
              service:
                name: apisix-gateway
                port:
                  number: 80
            path: /
            pathType: Exact

L'exemple ci-dessus contient les éléments suivants :

metadata.name : nom de la ressource Ingress
spec.rules[].host : domaine utilisé pour l'accès externe
spec.rules[].http.paths[].backend : décrit les informations relatives aux services dans un cluster
spec.rules[].http.paths[].path : décrit les chemins utilisés par l'accès externe pour atteindre les services dans un cluster
spec.rules[].http.paths[].pathType : décrit le type de chemin pour gérer l'accès externe aux services dans le cluster

À partir de l'exemple ci-dessus, nous pouvons remarquer que la spécification de la ressource Ingress est relativement simple.

Ingress est une définition de ressource dans Kubernetes qui ne peut pas gérer le trafic par elle-même. Par conséquent, si nous voulons rendre les ressources Ingress efficaces, nous devons utiliser un contrôleur pour traiter ces ressources Ingress, connu sous le nom de Ingress controller.

Le Ingress controller surveille en permanence les changements de ressources dans le cluster Kubernetes et transforme les règles des ressources Ingress en règles de proxy de la couche de données afin que la couche de données puisse gérer le trafic.

Dans un environnement de production réel, il existe de nombreux types de requêtes client. Par exemple, les ressources Ingress ne peuvent pas directement décrire certaines des fonctionnalités les plus courantes comme l'authentification et la réécriture d'URI. Alors, comment pouvons-nous satisfaire ces exigences ?

Comment Ingress-NGINX prend-il en charge les extensions ?

Tout d'abord, nous utiliserons un exemple du contrôleur Ingress-NGINX dans l'écosystème Kubernetes pour démontrer comment utiliser les extensions.

Nous pouvons utiliser Annotation pour décrire les extensions nécessaires des ressources Ingress dans Ingress-NGINX. Par exemple :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: https://foo.com,https://bar.com
    nginx.ingress.kubernetes.io/cors-allow-headers: x-foo-1,x-foo-2
    nginx.ingress.kubernetes.io/cors-allow-methods: GET,POST,PUT
  name: nginx-ingress
spec:
  rules:
    - host: kubernetes.github.io
      http:
        paths:
          - path: /ingress
            pathType: Exact
            backend:
              service:
                name: nginx
                port:
                  number: 80

La configuration ci-dessus active le CORS.

Il est relativement simple d'ajouter des Annotations à la ressource Ingress ; cependant, nous devons noter que le contrôleur Ingress-NGINX doit prendre entièrement en charge ces Annotations ; sinon, la configuration ne prendra pas effet. Si nous avons besoin d'utiliser certaines autres fonctionnalités non développées du contrôleur Ingress-NGINX, nous devons effectuer des développements personnalisés.

Les sections suivantes décrivent comment utiliser le contrôleur Apache APISIX Ingress pour répondre à ces exigences.

Utilisation des plugins dans APISIX Ingress

Apache APISIX Ingress utilise des plugins pour satisfaire les diverses exigences des clients en matière de gestion du trafic et de scénarios spécifiques. Actuellement, il existe plus de 80 plugins prêts à l'emploi, et les utilisateurs peuvent développer des plugins personnalisés pour prendre en charge de nouvelles fonctionnalités.

Il existe plusieurs façons de développer des plugins personnalisés :

Les utilisateurs peuvent utiliser Lua pour développer des plugins, et ces plugins peuvent s'exécuter en interne dans APISIX
Les utilisateurs peuvent également utiliser d'autres langages de programmation pour développer des plugins ; ce mécanisme est appelé "plugin runner", et les plugins développés par ce mécanisme sont appelés "External Plugin"

Veuillez consulter la documentation officielle sur le développement de plugins :

Développement de plugins : https://apisix.apache.org/docs/apisix/plugin-develop/
Développement de plugins externes : https://apisix.apache.org/docs/apisix/external-plugin/

Nous présenterons trois façons de développer des plugins en utilisant Lua dans APISIX Ingress.

Mode CRD pur

Le contrôleur APISIX Ingress prend en charge sa propre spécification CRD, et vous pouvez directement activer des plugins dans les règles de routage (qu'il s'agisse d'un plugin interne ou d'un plugin personnalisé). Par exemple :

apiVersion: apisix.apache.org/v2beta3
kind: ApisixRoute
metadata:
  name: httpbin-route
spec:
  http:
    - name: rule1
      match:
        hosts:
          - apisix.apache.org
        paths:
          - /apisix-ingress
      backends:
        - serviceName: apisix-gateway
          servicePort: 80
      plugins:
        - name: cors
          enable: true
          config:
            allow_origins: http://foo.bar.org
            allow_methods: "GET,POST"
            max_age: 3600
            expose_headers: x-foo,x-baz
            allow_headers: x-from-ingress
            allow_credential: true

Les utilisateurs peuvent utiliser la configuration ci-dessus pour créer des règles de routage, et le plugin cors sera activé dans cette route.

Cette méthode est la plus native dans APISIX Ingress, et elle s'intègre bien avec APISIX. De plus, lorsque les utilisateurs ajoutent de nouveaux plugins personnalisés, APISIX Ingress n'a pas besoin d'être redéveloppé, ce qui permet aux utilisateurs de l'utiliser directement.

Mode CRD + Annotations Ingress

Nous pouvons également utiliser CRD + Annotations Ingress pour étendre les fonctionnalités dans APISIX Ingress, par exemple :

apiVersion: apisix.apache.org/v2
kind: ApisixPluginConfig
metadata:
  name: cors-plugin
spec:
  plugins:
    - name: cors
      enable: true
      config:
        allow_origins: http://foo.bar.org
        allow_methods: "GET,POST"
        max_age: 3600
        expose_headers: x-foo,x-baz
        allow_headers: x-from-ingress
        allow_credential: true
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: apisix
    k8s.apisix.apache.org/plugin-config-name: cors-plugin
  name: apisix-ingress
spec:
  rules:
    - host: apisix.apache.org
      http:
        paths:
          - path: /apisix-ingress
            pathType: Exact
            backend:
              service:
                name: apisix-gateway
                port:
                  number: 80

En utilisant la configuration ci-dessus, nous pouvons créer indépendamment une configuration de plugin appelée cors-plugin et utiliser l'annotation k8s.apisix.apache.org/plugin-config-name: cors-plugin de la ressource Ingress pour y faire référence. L'effet réel est presque le même que la première configuration ; les deux activeront le plugin cors pour les routes correspondantes.

Dans ce mode, la configuration du plugin peut être considérée comme une ressource indépendante, et plusieurs ressources Ingress peuvent également les partager. De même, aucun développement personnalisé n'est nécessaire.

Mode Annotations Ingress

En raison de la sémantique limitée des ressources Ingress, nous utilisons généralement annotations pour ajouter des informations supplémentaires aux objets de ressource, ce qui est également la manière la plus courante d'étendre les capacités d'Ingress. Par exemple :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: apisix
    k8s.apisix.apache.org/enable-cors: "true"
    k8s.apisix.apache.org/cors-allow-origin: https://foo.com,https://bar.com
    k8s.apisix.apache.org/cors-allow-headers: x-foo-1,x-foo-2
    k8s.apisix.apache.org/cors-allow-methods: GET,POST,PUT
  name: apisix-ingress
spec:
  rules:
    - host: apisix.apache.org
      http:
        paths:
          - path: /apisix-ingress
            pathType: Exact
            backend:
              service:
                name: apisix-gateway
                port:
                  number: 80

La configuration ci-dessus ajoutera des informations supplémentaires liées au cors dans la ressource Ingress. Le contrôleur APISIX Ingress peut ensuite identifier ces informations et les transformer en configuration de la couche de données pour étendre les fonctionnalités de la ressource Ingress.

Cependant, dans ce mode, nous devons nous assurer que le contrôleur APISIX Ingress est déjà capable de traiter ces Annotations. Sinon, nous devons effectuer des développements personnalisés.

Si vous avez besoin de réaliser des développements personnalisés, veuillez consulter la documentation suivante :

Comment utiliser le contrôleur APISIX Ingress pour développer : https://apisix.apache.org/docs/ingress-controller/contribute/

Conclusion

Cet article présente principalement les spécifications liées aux ressources Ingress et comment étendre les fonctionnalités des ressources Ingress. Par exemple, dans Ingress-NGINX, nous ne pouvons généralement utiliser que des Annotations pour étendre les fonctionnalités. Cependant, dans Apache APISIX Ingress, nous avons trois modes de configuration pour répondre à des exigences avancées et à plus de scénarios. De plus, les utilisateurs n'ont pas besoin de développements personnalisés pour les plugins personnalisés dans la plupart des cas.