Apache APISIX-Ingress无需ETCD结论方案

Apache APISIX-Ingress无需ETCD结论方案

Deng YongJie's blog 103 2024-08-25

无ETCD官方博客参考

https://apisix.apache.org/zh/blog/2023/10/18/ingress-apisix/

部署测试

#注意,这里只能使用1.7.0版本。经过测试,1.8.2最新版会启动失败,日志报错:无法使用单机模式,提示etcd端点检查失败,需要连接etcd。
git clone --depth 1 --branch 1.7.0 https://github.com/apache/apisix-ingress-controller.git ingress-apisix-1.7.0

cd ingress-apisix-1.7.0

kubectl apply -k samples/deploy/crd/v1/

#经过测试,修改yaml文件的kind为daemonset和hostnetwork是可行的。但修改http和https端口时,日志会出现报错:连接etcd端点拒绝。由于POD内有2个容器,一个是controller,另一个是apisix,尝试多次不同的端口组合,并不能成功修改默认的端口为80 443。
kubectl apply -f samples/deploy/composite.yaml

image-20240521174011088

部署应用进行测试连通性

1.自行创建一个nginx服务,过程忽略

2.创建apisix的路由,只能通过yaml文件创建。注意,这不是ingress,是路由规则

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: http-route
  namespace: jette-test
spec:
  http:
    - name: route-1
      match:
        hosts:
          - httpbin.org
        paths:
          - /*
      backends:
        - serviceName: nginx-test
          servicePort: 80


kubectl apply -f test-route.yaml

3.查看路由规则

kubectl get ApisixRoute -A

image-20240521175114139

4. 访问测试

curl http://127.0.0.1:9080 -H 'Host: httpbin.org'

image-20240521174253908

绑定host,浏览器访问

image-20240521174507921

结论

无etcd模式,仅适用纯粹的APISIX网关。目前暂不适合替换K8S集群nginx-ingress,因为需要手动通过yaml文件创建APISIX提供指定apiversion来配置路由规则,这并不是ingress,而且无etcd模式不能部署Dashboard可视化管理,因此管理和使用都会比较麻烦。

APISIX有三种部署模式:

  • 第一种是有etcd的替换nginx-ingress,可以在K8S集群创建ingress后,apisix-controller成功监听并自动配置路由规则。
  • 第二种是有etcd纯粹的POD服务,可以用为K8S集群内部apisix-gateway服务,POD之间的转发路由等,由于流量先进入nginx-ingress,再到apisix-gateway,所以此方法会多了一层转发,链路变长,访问延迟提升。
  • 第三种是VM部署,需要自行配置高可用VIP飘移。

部署模式优缺点对比

无etcd模式,纯粹的APISIX网关——不适用我们的场景

  • 优点:

    1. 轻量级高性能

    2. 以声明式配置作为配置的唯一来源,减少运维复杂性

  • 缺点:

    1. 没有可视化,没有ingress,只有配置路由规则,对于开发人员不友好,使用和配置域名不方便

    2. 不能自定义修改默认端口

    3. 目前测试版本为1.7.0,原地升级版本有兼容问题启动报错

有etcd模式,替换nginx-ingress

  • 优点:

    1. 基于K8S创建ingress或者Rancher创建ingress,apisix-controller自动监听ingress-class,自动配置路由规则,无需人工介入

    2. 有Dashboard可视化路由规则

    3. 高性能

    4. 多种插件集成,支持多种自定义配置

  • 缺点:

    1. 重量级,维护成本高,强依赖etcd集群
    2. Dashboard不能修改自动监听到的ingress的路由规则,否则二次修改ingress配置,可能会无法监听并更新路由
    3. K8S集群1.20以下,K8S创建ingress时,需要手动修改apiversion为networking/v1beta1,否则Rancher创建ingress的默认apiversion,APISIX无法监听并自动配置路由。因此建议使用K8S集群高于1.22以上版本,例如1.23、1.24 等较新的 LTS 版本
    4. 需要使用helm部署,由于官方版本发布较快,高版本修改的参数较多,并且有部分配置参数改名或废弃导致不兼容,因此后期更新版本的不确定因素变多,影响较大

有etcd模式,纯粹的POD服务

  • 优点:

    1. 高性能

    2. 多种插件集成,支持多种自定义配置

    3. Dashboard可视化配置路由规则

    4. 可随时修改路由配置热更新

  • 缺点:

    1. 重量级,维护成本高,强依赖etcd集群

    2. 需要使用helm部署,由于官方版本发布较快,高版本修改的参数较多,并且有部分配置参数改名或废弃导致不兼容,因此后期更新版本的不确定因素变多,影响较大

    3. 链路变长,延迟提高。流量先进入ingress,再到apisix-gateway

VM部署高可用模式

  • 优点:

    1. 高性能,在备用节点进行版本升级,影响较小,高可靠

    2. 多种插件集成,支持多种自定义配置

    3. Dashboard可视化配置路由规则

    4. 可随时修改路由配置热更新

  • 缺点:

    1. 重量级,维护成本高,强依赖etcd集群

    2. 如果选择传统链路,流量先进入VM-apisx,再进入ingress,此链路也会变长,延迟提高。

链路架构优缺点对比

有etcd模式,替换nginx-ingress

链路短,高性能,能获取真实HTTP头

image-20240522114807320

有etcd模式,纯粹的POD服务

链路长,可能引发协议不匹配错误,HTTP头处理错误从而拒绝服务

image-20240522114949274

VM部署高可用模式

链路短,高性能,能获取真实HTTP头。如果使用传统nginx-ingress,此模式的意义不大,链路反而更长。

但是后端POD暴露的NodePort端口会很多,后续的端口配置管理不友好,要对K8S熟悉度要求比较高

image-20240522114949274-1724830612968

image-20240522120535170