APISIX Ingress 如何支持自定义插件-低调大师

APISIX Ingress 如何支持自定义插件

2022-12-15 319

摘要：本篇主要介绍了 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 中可以通过三种模式进行配置。且其中两种对于用户自己开发的自定义插件而言，是无需进行任何二次开发的，进而满足用户更多的场景和需求。

微信关注我们

原文链接：https://my.oschina.net/ApacheAPISIX/blog/5609845

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

基于 KubeSphere 的运管系统落地实践

作者：任建伟，某知名互联网公司云原生工程师，容器技术信徒，云原生领域的实践者。背景介绍在接触容器化之前，我们团队内部的应用一直都是基于虚拟机运管，由开发人员自行维护。由于面向多开发部门服务，而开发人员运维能力参差不齐，所以每次部署新的环境时往往都要耗费大量时间。针对部署难的问题，我们将部分组件、服务容器化，采用 Docker 发布管理解决了部分问题，但仍未降低对开发人员的运维技能要求。下面是我们基于虚拟机管理开发环境的流程：从上图中我们也能发现当前架构存在的问题：下发虚机由各部开发人员管理，虚机安全问题难以维护、保障；基于 shell 运维，专业性过强；基于手动打包、发布，耗时耗力且不可靠。选型说明针对上述提到的痛点，我们决定对运维架构进行改造。新建运管平台，技术选型整体基于云原生，优先选取 CNCF 项目。 Kubernetes 成为了我们平台底座的不二选择，但 Kubernetes 原生的 Dashboard 不太满足实际使用需求。而从头开发一套 workbench 又耗时耗力，由此我们目光转向了开源社区。此时，一个集颜值 + 强大功能于一身的开源项目进...

2022-12-15

466

作者：王有卓，StarRocks Contributor 随着开源数据湖技术的快速发展以及湖仓一体全新架构的提出，传统数据湖在事务处理、流式计算以及数据科学场景的限制逐渐得以优化解决。为了满足用户对数据湖探索分析的需求，StarRocks 在 2.5 版本开始发布了诸多数据湖相关的重磅特性，为用户提供更加开箱即用的极速湖分析体验。本文为您揭秘如何利用 StarRocks 特性开启数据湖的极速分析体验，同时展示用户真实场景中的落地案例以及性能测试结果，最后对 StarRocks DLA (Data Lake Analytics)未来的产品规划做一些分享。站在Warehouse的当下，思考Lakehouse的未来整个大数据架构逐步经历了这么几个典型的发展阶段： Schema-on-Write 架构：通过严格的建模范式约束，来支撑 BI 场景下的查询负载，但在以存算一体为主流系统架构的历史背景下，数据量膨胀带给用户高昂维护成本，同时对异构数据缺乏维护能力。 Scheme-on-Read 架构：以 HDFS 为统一存储层，并提供基础的文件 API 来与查询层进行交互。这种架构模式虽然...

2022-12-15

379

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。