为什么 APISIX Ingress 是比 Ingress NGINX 更好的选择？

作者容鑫，API7.ai 云原生技术工程师，Apache APISIX Committer。

Ingress NGINX ^[1] 是 Kubernetes 社区实现的 Ingress Controller，在社区中被广泛使用。Apache APISIX Ingress ^[2] 则是 Apache 软件基金会下的开源项目，使用 APISIX 作为数据面的 Kubernetes Ingress Controller。

两者都对 HTTP/HTTPS 协议提供完整支持，APISIX Ingress 在协议支持上更丰富一些，能够的使用 TLS 来加密 TCP 流量，还支持 MQTT ^[4] ，Dubbo ^[5] 、Kafka ^[6] 等协议进行代理。

健康检查

• 主动健康检查 ：确保后端服务中的 Pod 处于可用的状态。在应用服务进行滚动更新时，会牵扯大量的节点进行更新，不健康的节点将会被负载均衡器忽略，开启健康检查能够有效的挑选出可用的 Pod，避免流量损失。
• 被动健康检查 ：被动的方式无需发起额外的探针，每个请求就是探针，若一个健康节点连续 N 个请求都被判定为失败（取决于如何配置），则该节点将被标记为不健康。由于无法提前感知节点的状态，可能会有一定量的失败请求，在滚动更新时这种情况会相对常见，可以通过服务降级来避免失败的请求量。

apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin
spec:
  healthCheck:
    passive:
      unhealthy:
        httpCodes:
          - 500
        httpFailures: 3
    active:
      type: http
      httpPath: /healthz
      healthy:
        successes: 3
        interval: 2s
        httpCodes:
          -




    
 200

服务熔断

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /status/*
   backends:
   - serviceName: httpbin
     servicePort: 80
   plugins:
   - name: api-breaker
     enable: true
     config:
       break_response_code: 502
       unhealthy:
         http_statuses:
         - 505
         failures: 2
       healthy:
         http_statuses:
         - 200
         successes: 2

apiVersion: apisix.apache.org/v2
kind: ApisixConsumer
metadata:
  name: hmac-value
spec:
  authParameter:
    hmacAuth:
      value:
        access_key: papa
        secret_key: fatpa
        algorithm: "hmac-sha256"
        clock_skew: 0

---

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /ip
   backends:
   - serviceName: httpbin
     servicePort: 80
   authentication:
     enable: true
     type: hmacAuth

1. 编写 Lua 程序 example-plugin
2. 将插件安装到 ingress-nginx pod 中的 /etc/nginx/lua/plugins/<your plugin name> → /etc/nginx/lua/plugins/example-plugin
3. 在 ConfigMap 中启用 example-plugin 插件，需要在安装 Ingress NGINX 时引用此 ConfigMap 对象

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  plugins: "example-plugin"

• 通过 Lua 进行插件开发 ^[12] ：这种方式相对简单，并且几乎没有性能损耗；
• 通过 plugin-runner 开发：这种模式下支持 Java/Python/Go 等语言进行开发，这可以方便用户利用一些现有的业务逻辑，并且无需学习新语言；
• 通过 Wasm 进行插件插件：这种模式下，可以使用任何支持构建出 Wasm 的语言进行插件开发。

• 更契合数据面的设计语义，更加简单易用；
• 一些重要配置能够被复用，而不会存在冗余庞大的单个配置；
• 功能性和可扩展能力有了巨大提升；
• 数据面 APISIX 有着活跃的社区，更新和发布版本快，CRD 的方式能够轻易支持数据面的更多能力。

• 创建新的 Inresss 资源；
• 将 TLS 部分添加到现有 Ingress；
• Ingress Annotations 的变化可能影响上游配置（例如 load-balance 注释不需要重新加载）；
• 在 Ingress 中添加或删除 path；
• Ingress、Service、Secret 资源被删除；
• Secret 发生更新。

• 面向角色：Gateway 是由一组 API 资源组成的。不同的 API 资源代表了使用与配置 Kubernetes 网络资源的不同角色；
• 表现力强：Gateway API 的核心功能就包含诸如基于头的匹配、流量加权以及其他在 Ingress 中只能通过各实现者自定义的非标准化 Annotations 等方式实现的功能；
• 可扩展：Gateway API 允许不同资源在不同层级一同使用。这使得能够对 API 结构进行更精细化的控制。