Wie unterstützt APISIX Ingress benutzerdefinierte Plugins?

Ingress & Ingress Controller

Ingress ist eines der API-Objekte von Kubernetes. Es verwaltet den externen Zugriff auf die Dienste in einem Cluster, typischerweise HTTP/HTTPS.

Clients können den Ingress-Regeln folgen, um Client-Anfragen an die Kubernetes-Cluster-Dienste oder einen bestimmten Pod weiterzuleiten.

Das Folgende ist ein Beispiel für eine Ingress-Ressource:

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

Das obige Beispiel enthält die folgenden Inhalte:

metadata.name: Name der Ingress-Ressource
spec.rules[].host: Domain, die für den externen Zugriff verwendet wird
spec.rules[].http.paths[].backend: Beschreibt die relevanten Informationen der Dienste in einem Cluster
spec.rules[].http.paths[].path: Beschreibt die Pfade, die für den externen Zugriff auf die Dienste in einem Cluster verwendet werden
spec.rules[].http.paths[].pathType: Beschreibt den Pfadtyp, um den externen Zugriff auf die Dienste im Cluster zu verwalten

Basierend auf dem obigen Beispiel können wir feststellen, dass die Spezifikation der Ingress-Ressource relativ einfach ist.

Ingress ist eine Ressourcendefinition in Kubernetes, die selbst keinen Datenverkehr verarbeiten kann. Wenn wir also Ingress-Ressourcen effektiv nutzen möchten, müssen wir einen Controller verwenden, um diese Ingress-Ressourcen zu verarbeiten, der als Ingress-Controller bekannt ist.

Der Ingress-Controller überwacht kontinuierlich alle Ressourcenänderungen im Kubernetes-Cluster und wandelt die Ingress-Ressourcenregeln in die Proxy-Regeln der Datenebene um, sodass die Datenebene den Datenverkehr verarbeiten kann.

In der tatsächlichen Produktionsumgebung gibt es viele verschiedene Arten von Client-Anfragen. Beispielsweise können Ingress-Ressourcen einige der häufigsten Funktionen wie Authentifizierung und URI-Rewriting nicht direkt beschreiben. Wie können wir also diese Anforderungen erfüllen?

Wie unterstützt Ingress-NGINX Erweiterungen?

Zunächst werden wir ein Beispiel des Ingress-NGINX-Controllers im Kubernetes-Ökosystem verwenden, um zu demonstrieren, wie Erweiterungen genutzt werden können.

Wir können Annotation verwenden, um die benötigten Erweiterungen der Ingress-Ressourcen in Ingress-NGINX zu beschreiben. Zum Beispiel:

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

Die obige Konfiguration aktiviert CORS.

Es ist relativ einfach, Annotations zur Ingress-Ressource hinzuzufügen; jedoch müssen wir beachten, dass der Ingress-NGINX-Controller diese Annotations vollständig unterstützen muss; andernfalls wird die Konfiguration nicht wirksam. Wenn wir einige andere, noch nicht entwickelte Funktionen des Ingress-NGINX-Controllers nutzen möchten, müssen wir einige benutzerdefinierte Entwicklungen durchführen.

Die folgenden Abschnitte beschreiben, wie der Apache APISIX Ingress-Controller verwendet werden kann, um diese Anforderungen zu erfüllen.

Verwendung von Plugins in APISIX Ingress

Apache APISIX Ingress nutzt Plugins, um die verschiedenen Anforderungen der Kunden an die Handhabung des Datenverkehrs und spezifische Szenarien zu erfüllen. Derzeit gibt es mehr als 80 einsatzbereite Plugins, und Benutzer können benutzerdefinierte Plugins entwickeln, um neue Funktionen zu unterstützen.

Es gibt viele verschiedene Möglichkeiten, benutzerdefinierte Plugins zu entwickeln:

Benutzer können Lua verwenden, um Plugins zu entwickeln, und diese Plugins können intern in APISIX ausgeführt werden
Benutzer können auch andere Programmiersprachen verwenden, um Plugins zu entwickeln; dieser Mechanismus wird als "Plugin Runner" bezeichnet, und die auf diese Weise entwickelten Plugins werden als "External Plugin" bezeichnet

Bitte konsultieren Sie die offizielle Dokumentation zur Plugin-Entwicklung:

Plugin-Entwicklung: https://apisix.apache.org/docs/apisix/plugin-develop/
Entwicklung externer Plugins: https://apisix.apache.org/docs/apisix/external-plugin/

Wir werden drei Möglichkeiten vorstellen, wie Plugins mit Lua in APISIX Ingress entwickelt werden können.

Reiner CRD-Modus

Der APISIX Ingress-Controller unterstützt seine selbst entwickelte CRD-Spezifikation, und Sie können direkt Plugins in den Routing-Regeln aktivieren (ob ein internes Plugin oder ein benutzerdefiniertes Plugin). Zum Beispiel:

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

Benutzer können die obige Konfiguration verwenden, um Routing-Regeln zu erstellen, und das cors-Plugin wird in dieser Route aktiviert.

Diese Methode ist die nativste Unterstützung in APISIX Ingress und passt gut zu APISIX. Außerdem müssen Benutzer, wenn sie neue benutzerdefinierte Plugins hinzufügen, APISIX Ingress nicht neu entwickeln, sodass sie es direkt verwenden können.

CRD + Ingress Annotations Modus

Wir können auch CRD + Ingress Annotations verwenden, um die Funktionen in APISIX Ingress zu erweitern, zum Beispiel:

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

Mit der obigen Konfiguration können wir unabhängig eine Plugin-Konfiguration namens cors-plugin erstellen und die k8s.apisix.apache.org/plugin-config-name: cors-plugin der Ingress-Ressource verwenden, um darauf zu verweisen. Der tatsächliche Effekt ist fast der gleiche wie bei der ersten Konfiguration; beide würden das cors-Plugin für die entsprechenden Routen aktivieren.

In diesem Modus kann die Plugin-Konfiguration als unabhängige Ressource betrachtet werden, und mehrere Ingress-Ressourcen können sie ebenfalls teilen. Ebenso sind keine benutzerdefinierten Entwicklungen erforderlich.

Ingress Annotations Modus

Aufgrund der begrenzten Semantik von Ingress-Ressourcen verwenden wir normalerweise annotations, um einige zusätzliche Informationen für die Ressourcenobjekte hinzuzufügen, was auch die häufigste Methode zur Erweiterung der Ingress-Fähigkeiten ist. Zum Beispiel:

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

Die obige Konfiguration fügt einige zusätzliche Informationen im Zusammenhang mit CORS in die Ingress-Ressource ein. Der APISIX Ingress-Controller kann diese Informationen dann identifizieren und in die Konfiguration der Datenebene umwandeln, um die Funktionen der Ingress-Ressource zu erweitern.

In diesem Modus müssen wir jedoch sicherstellen, dass der APISIX Ingress-Controller bereits in der Lage ist, diese Annotations zu verarbeiten. Andernfalls müssen wir einige benutzerdefinierte Entwicklungen durchführen.

Wenn Sie benutzerdefinierte Entwicklungen durchführen müssen, konsultieren Sie bitte die folgende Dokumentation:

Wie man den APISIX Ingress-Controller entwickelt: https://apisix.apache.org/docs/ingress-controller/contribute/

Fazit

Dieser Artikel führt hauptsächlich in die Spezifikationen im Zusammenhang mit Ingress-Ressourcen ein und wie Funktionen für Ingress-Ressourcen erweitert werden können. Zum Beispiel können wir in Ingress-NGINX normalerweise nur Annotations verwenden, um Funktionen zu erweitern. Im Apache APISIX Ingress haben wir jedoch drei Konfigurationsmodi, um erweiterte Anforderungen und mehr Szenarien zu erfüllen. Darüber hinaus benötigen Benutzer in den meisten Fällen keine benutzerdefinierten Entwicklungen für benutzerdefinierte Plugins.