Как APISIX Ingress поддерживает пользовательские плагины

Ingress и Ingress Controller

Ingress — это один из API-объектов Kubernetes. Он управляет внешним доступом к сервисам в кластере, обычно HTTP/HTTPS.

Клиенты могут следовать правилам Ingress для маршрутизации запросов к сервисам Kubernetes или к конкретному Pod.

Ниже приведен пример ресурса 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

В приведенном выше примере содержатся следующие элементы:

metadata.name: имя ресурса Ingress
spec.rules[].host: домен, используемый для внешнего доступа
spec.rules[].http.paths[].backend: описывает связанную информацию о сервисах в кластере
spec.rules[].http.paths[].path: описывает пути, используемые для внешнего доступа к сервисам в кластере
spec.rules[].http.paths[].pathType: описывает тип пути для управления внешним доступом к сервисам в кластере

На основе приведенного выше примера можно заметить, что спецификация ресурса Ingress относительно проста.

Ingress — это определение ресурса в Kubernetes, который сам по себе не может обрабатывать трафик. Поэтому, чтобы сделать ресурсы Ingress эффективными, необходимо использовать контроллер для обработки этих ресурсов, который называется Ingress controller.

Ingress controller будет отслеживать любые изменения ресурсов в кластере Kubernetes и преобразовывать правила ресурсов Ingress в правила прокси на уровне данных, чтобы уровень данных мог обрабатывать трафик.

В реальной производственной среде существует множество различных типов клиентских запросов. Например, ресурсы Ingress не могут напрямую описывать некоторые из наиболее распространенных функций, таких как аутентификация и перезапись URI. Как же удовлетворить эти требования?

Как Ingress-NGINX поддерживает расширения?

Сначала мы используем пример контроллера Ingress-NGINX в экосистеме Kubernetes, чтобы продемонстрировать, как использовать расширения.

Мы можем использовать Annotation для описания необходимых расширений ресурсов Ingress в Ingress-NGINX. Например:

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

Приведенная выше конфигурация включает поддержку CORS.

Добавление аннотаций к ресурсу Ingress относительно просто; однако необходимо учитывать, что контроллер Ingress-NGINX должен полностью поддерживать эти аннотации, иначе конфигурация не вступит в силу. Если нам нужно использовать некоторые другие неразработанные функции контроллера Ingress-NGINX, необходимо выполнить некоторые пользовательские разработки.

В следующих разделах описано, как использовать контроллер Apache APISIX Ingress для удовлетворения этих требований.

Использование плагинов в APISIX Ingress

Apache APISIX Ingress использует плагины для удовлетворения различных требований клиентов по обработке трафика и специфических сценариев. В настоящее время доступно более 80 готовых к использованию плагинов, и пользователи могут разрабатывать пользовательские плагины для поддержки новых функций.

Существует множество различных способов разработки пользовательских плагинов:

Пользователи могут использовать Lua для разработки плагинов, и эти плагины могут работать внутри APISIX.
Пользователи также могут использовать другие языки программирования для разработки плагинов; этот механизм называется "plugin runner", а плагины, разработанные с использованием этого механизма, называются "External Plugin".

Обратитесь к официальной документации по разработке плагинов:

Разработка плагинов: https://apisix.apache.org/docs/apisix/plugin-develop/
Разработка внешних плагинов: https://apisix.apache.org/docs/apisix/external-plugin/

Мы представим три способа разработки плагинов с использованием Lua в APISIX Ingress.

Режим Pure CRD

Контроллер APISIX Ingress поддерживает собственную спецификацию CRD, и вы можете напрямую включать плагины в правила маршрутизации (будь то внутренний плагин или пользовательский плагин). Например:

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

Пользователи могут использовать приведенную выше конфигурацию для создания правил маршрутизации, и плагин cors будет включен для этого маршрута.

Этот способ является наиболее нативным для APISIX Ingress и хорошо интегрируется с APISIX. Кроме того, когда пользователи добавляют новые пользовательские плагины, APISIX Ingress не требует переразработки, и пользователи могут использовать их напрямую.

Режим CRD + Ingress Annotations

Мы также можем использовать CRD + Ingress Annotations для расширения функций в APISIX Ingress, например:

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

Используя приведенную выше конфигурацию, мы можем независимо создать конфигурацию плагина под названием cors-plugin и использовать аннотацию k8s.apisix.apache.org/plugin-config-name: cors-plugin в ресурсе Ingress для ссылки на нее. Фактический эффект почти такой же, как и в первой конфигурации; они оба включают плагин cors для соответствующих маршрутов.

В этом режиме конфигурация плагина может рассматриваться как независимый ресурс, и несколько ресурсов Ingress также могут совместно использовать их. Аналогично, никаких пользовательских разработок не требуется.

Режим Ingress Annotations

Из-за ограниченной семантики ресурсов Ingress мы обычно используем annotations для добавления дополнительной информации к объектам ресурсов, что также является наиболее распространенным способом расширения возможностей Ingress. Например:

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

Приведенная выше конфигурация добавит некоторую дополнительную информацию, связанную с cors, в ресурс Ingress. Контроллер APISIX Ingress сможет затем идентифицировать эту информацию и преобразовать ее в конфигурацию уровня данных для расширения функций ресурса Ingress.

Однако в этом режиме мы должны убедиться, что контроллер APISIX Ingress уже способен обрабатывать эти аннотации. В противном случае необходимо выполнить некоторые пользовательские разработки.

Если вам нужно выполнить пользовательские разработки, обратитесь к следующей документации:

Как использовать контроллер APISIX Ingress для разработки: https://apisix.apache.org/docs/ingress-controller/contribute/

Заключение

Эта статья в основном знакомит с характеристиками, связанными с ресурсами Ingress, и с тем, как расширить функции для ресурсов Ingress. Например, в Ingress-NGINX мы обычно можем использовать только аннотации для расширения функций. Однако в Apache APISIX Ingress у нас есть три режима конфигурации для удовлетворения расширенных требований и большего количества сценариев. Кроме того, в большинстве случаев пользователям не требуется выполнять пользовательские разработки для пользовательских плагинов.