无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网关——不适用我们的场景
-
优点:
-
轻量级高性能
-
以声明式配置作为配置的唯一来源,减少运维复杂性
-
-
缺点:
-
没有可视化,没有ingress,只有配置路由规则,对于开发人员不友好,使用和配置域名不方便
-
不能自定义修改默认端口
-
目前测试版本为1.7.0,原地升级版本有兼容问题启动报错
-
有etcd模式,替换nginx-ingress
-
优点:
-
基于K8S创建ingress或者Rancher创建ingress,apisix-controller自动监听ingress-class,自动配置路由规则,无需人工介入
-
有Dashboard可视化路由规则
-
高性能
-
多种插件集成,支持多种自定义配置
-
-
缺点:
- 重量级,维护成本高,强依赖etcd集群
- Dashboard不能修改自动监听到的ingress的路由规则,否则二次修改ingress配置,可能会无法监听并更新路由
- K8S集群1.20以下,K8S创建ingress时,需要手动修改apiversion为networking/v1beta1,否则Rancher创建ingress的默认apiversion,APISIX无法监听并自动配置路由。因此建议使用K8S集群高于1.22以上版本,例如1.23、1.24 等较新的 LTS 版本
- 需要使用helm部署,由于官方版本发布较快,高版本修改的参数较多,并且有部分配置参数改名或废弃导致不兼容,因此后期更新版本的不确定因素变多,影响较大
有etcd模式,纯粹的POD服务
-
优点:
-
高性能
-
多种插件集成,支持多种自定义配置
-
Dashboard可视化配置路由规则
-
可随时修改路由配置热更新
-
-
缺点:
-
重量级,维护成本高,强依赖etcd集群
-
需要使用helm部署,由于官方版本发布较快,高版本修改的参数较多,并且有部分配置参数改名或废弃导致不兼容,因此后期更新版本的不确定因素变多,影响较大
-
链路变长,延迟提高。流量先进入ingress,再到apisix-gateway
-
VM部署高可用模式
-
优点:
-
高性能,在备用节点进行版本升级,影响较小,高可靠
-
多种插件集成,支持多种自定义配置
-
Dashboard可视化配置路由规则
-
可随时修改路由配置热更新
-
-
缺点:
-
重量级,维护成本高,强依赖etcd集群
-
如果选择传统链路,流量先进入VM-apisx,再进入ingress,此链路也会变长,延迟提高。
-
链路架构优缺点对比
有etcd模式,替换nginx-ingress
链路短,高性能,能获取真实HTTP头
有etcd模式,纯粹的POD服务
链路长,可能引发协议不匹配错误,HTTP头处理错误从而拒绝服务
VM部署高可用模式
链路短,高性能,能获取真实HTTP头。如果使用传统nginx-ingress,此模式的意义不大,链路反而更长。
但是后端POD暴露的NodePort端口会很多,后续的端口配置管理不友好,要对K8S熟悉度要求比较高