无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

部署应用进行测试连通性

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

4. 访问测试

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

绑定host，浏览器访问

结论

无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头

有etcd模式，纯粹的POD服务

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

VM部署高可用模式

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

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

image-20240522114949274-1724830612968

Apache APISIX-Ingress无需ETCD结论方案