关于apisix:APISIX-Ingress-如何支持自定义插件

摘要：本篇次要介绍了 Ingress 资源相干的语义，以及如何对 Ingress 资源进行能力的扩大。

作者：张晋涛，API7.ai 云原生技术专家，Apache APISIX PMC 成员，Apache APISIX Ingress Controller 我的项目维护者。

Ingress 和 Ingress controller

Kubernetes 中的 Ingress 是一种资源对象，用于定义如何从 Kubernetes 集群外拜访到 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：定义了 Kubernetes 集群中服务的相干信息
• spec.rules[].http.paths[].path：定义了内部服务拜访 Kubernetes 集群中服务时应用的门路
• spec.rules[].http.paths[].pathType：定义了内部服务拜访 Kubernetes 集群中服务时门路的匹配规定
  从上述内容能够看到，Ingress 资源的语义是绝对比较简单的。

Ingress 仅仅是 Kubernetes 中的一种资源定义，它自身不具备任何流量解决能力。要让 Ingress 资源失效，则必须要有 controller 来解决这些 Ingress 资源，通常这样的 controller 咱们称之为 Ingress controller。

Ingress controller 会继续地监控或监听 Kubernetes 集群中 Ingress 资源的变动，并依据 Ingress 资源中定义的规定，转换为其数据面中的代理规定，并由数据面来理论的承载流量。

在理论的生产环境中，客户端拜访的需要是多种多样的。比方最常见的认证、路由重写等能力，通过 Ingress 资源是无奈间接进行形容的。那么这些需要要如何满足呢？

Ingress-NGINX 如何反对扩大性能

首先我以 Kubernetes 社区的 Ingress-NGINX controller 为例，介绍如何在其中应用扩大性能。

在 Ingress-NGINX 我的项目中，能够为 Ingress 资源减少一些 Annotation 来形容其须要应用的扩大能力。比方应用如下配置便可开启 cors 能力。

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

这种形式仅仅须要为 Ingress 资源增加 Annotations 的配置即可，绝对简略。但须要留神，应用这种模式须要 Ingress-NGINX controller 曾经实现了对该 Annotations 的残缺反对，否则该配置是有效的。

如果须要其余的一些 Ingress-NGINX controller 尚未实现的能力，则须要对其进行二次开发。

在 APISIX Ingress 中应用插件

相较于 Ingress-NGINX controller，APISIX Ingress 应用 APISIX 作为数据面，APISIX 是一个高性能的全动静 API 网关。所有的配置变更都是动静进行的，无需重启，所以对业务流量不会造成任何影响。

在 Apache APISIX Ingress 中能够通过应用插件，来满足用户各种流量解决的需要和具体场景。以后有 80+ 插件开箱即用，当然用户也能够开发自定义插件来进行能力的扩大。

目前，在 Apache APISIX 中反对多种形式进行自定义插件的开发：

• 应用 Lua 进行插件的开发，这类插件会在 APISIX 外部运行；
• 应用其余语言进行插件的开发，这种机制叫作 Plugin Runner，利用该机制开发的插件属于 external-plugin。
  对于 APISIX 插件的开发，可参考官网文档：
• 插件开发 https://apisix.apache.org/docs/apisix/plugin-develop/
• External Plugin 开发：https://apisix.apache.org/docs/apisix/external-plugin/
  理解了 APISIX 的插件开发模式后，接下来将介绍 3 种在 APISIX Ingress 中应用 Lua 语言开发插件的形式。

形式一：纯 CRD 模式

APISIX Ingress controller 反对本人设计的一套 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 也无需进行任何二次开发，可间接应用。

形式二：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

上述配置在 Ingress 资源中减少了 cors 相干的一些信息。APISIX Ingress controller 能够辨认这些信息，并将这些信息转换为数据面中 cors 的配置，进而实现对 Ingress 资源的扩大。

然而这种模式下，须要确保在 APISIX Ingress controller 中曾经实现了对这些 Annotations 的解决逻辑，如果尚未实现，则须要进行一些二次开发。

如果须要进行二次开发，可参考《如何进行 APISIX Ingress controller 的开发》。

形式三：CRD + Ingress Annotations 模式

除以上两种形式外，在 APISIX Ingress 中也能够通过 CRD + Ingress Annotations 的形式进行扩大，例如：

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 的插件配置，并通过 Ingress 资源的 k8s.apisix.apache.org/plugin-config-name: cors-plugin 对其进行援用。通过这种操作的实际效果与前两个形式根本相似，都会在对应的路由上开启 cors 插件。

在这种模式下，用户的插件配置能够作为独立资源，并且能够被多个 Ingress 资源共享。同时，也无需进行任何二次开发。

总结

本篇次要介绍了 Ingress 资源相干的语义，以及如何对 Ingress 资源进行能力的扩大。在 Ingress-NGINX 中能够通过 Annotations 的形式进行能力的扩大，但在 Apache APISIX Ingress 中能够通过三种模式进行配置。且其中两种对于用户本人开发的自定义插件而言，是无需进行任何二次开发的，进而满足用户更多的场景和需要。