共计 3190 个字符，预计需要花费 8 分钟才能阅读完成。
Sealos 私有云（https://cloud.sealos.io）简直打爆了市面上所有支流的开源网关，本文能够给大家很好的避坑，在网关选型方面做一些参考。
Sealos Cloud 的简单场景
Sealos 私有云上线以来，用户呈爆发式增长，目前总共注册用户 8.7w，每个用户都去创立利用，每个利用都须要有本人的拜访入口，就导致整个集群路由条目十分微小，须要有撑持数十万条 Ingress 的能力。
另外，在公网提供共享集群的服务，对多租户要求极为刻薄，用户之间的路由必须不能相互影响，须要十分好的隔离性，以及流量控制能力。
私有云的受攻击面是很大的，黑客会攻打云上跑的用户利用，也会间接攻打平台的进口网络，安全性上也有十分大的挑战。
对控制器的性能和稳固要求都比拟高，很多控制器路由条目一多时耗费资源会十分大，甚至 OOM 导致网关奔溃。
排除 Nginx Ingress
咱们最早用的就是 Nginx Ingress，最初发现有几个外围问题无奈解决：
- reload 问题，每次有 ingress 变更会导致断连一小会，而一个集群用户一多的时候，ingress 的创立变更会是个频繁事件，就会导致网络常常不稳固。
- 长链接不稳固，也是因为变更，在用的长链接会常常断。
- 性能不行，失效工夫慢，耗费资源多。
所以简直排除掉了很多底层用 Nginx 实现的网关。咱们实测下来基于 Envoy 实现的网关性能彪悍太多，简直管制面和数据面都不怎么耗费性能。
这是 Envoy 的：
这是 Nginx 的：
差距十分之大，所以咱们就能够排除掉 Nginx 系列选项了，彻底拥抱 Envoy。
对于 APISIX
APISIX 自身是个优良我的项目，解决了 Nginx reload 的一些问题，所以咱们 Laf 晚期也用了 APISIX，然而很可怜 APISIX 的 Ingress Controller 并不是很稳固，管制面解体给造成了咱们好几次大的故障，还呈现过控制器 OOM 等问题，咱们原本真的很想用，然而最终还是因为故障问题被强制劝退，当然 APISIX 社区也在始终跟进这些问题，心愿能越做越好。
总结一下就是：APISIX 自身稳定性很好，然而控制器须要优化的货色还很多，稳定性也有待进步。社区反对力度也很大，无奈咱们线上问题迫在眉睫没法依照社区的节奏缓缓迭代，只能先切成别的网关了。
Cilium Gateway
Sealos 的 CNI 很早就切换成 Cilium 了，的确很强，所以咱们想着网关也对立用 Cilium 得了，然而事实很骨感。
Cilium Gateway 只反对 LB 模式，这样就强依赖云厂商的 LB，而咱们也有一些私有化的场景，所以不心愿耦合，稳定性方面也遇到了路由十分多的时候，Ingress 失效特地慢的问题，须要分钟级失效，这样用户的体验就很差了，咱们能承受的是 5s 内路由失效。所以论断就是只能再等等。
Envoy Gateway
从 K8s 规范的倒退来看，会逐步从 Ingress 迁徙到 Gateway 的规范，而咱们底层又更偏向应用 Envoy，那 Envoy Gateway 的实现仿佛是一个很好的抉择，所以咱们调研了 Envoy Gateway，然而这个我的项目还是太过于晚期，遇到了一些不稳固的 bug，比方会 OOM，pathpolicy 不失效，有些个性在 merge gateway 模式下不失效等问题，在继续解决中，咱们也在一直帮忙上游社区提改良意见和奉献，心愿将来能够能达到生产可用的状态。
逼格很高但不那么实用的 Gateway 规范
Gateway 的处境很尬感，我的感觉是设计者并没有真的实际过多租户场景，当多租户共享一个集群时，就要明确辨别管理者和使用者的权限问题，Gateway 设计之初就没齐全思考分明，举个例子：
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: eg
spec:
gatewayClassName: eg
listeners:
- name: http
port: 80
protocol: HTTP
# hostname: "*.example.com"
- name: https
port: 443
protocol: HTTPS
# hostname: "*.example.com"
tls:
mode: Terminate
certificateRefs:
- kind: Secret
name: example-com这里监听端口这类的配置应该是给集群管理员而不是普通用户，而 TLS 证书的配置属于某个利用，管理员能够有权限配置，次要还是每个用户去配置本人的，所以这外面权限就没有离开。那就只能让用户也有权限配置 Gateway，所以这里就又须要在控制器里实现很多的权限管制的细节问题，如端口号白名单，冲突检测等。
集体感觉更优雅的设计是把其中租户级别的字段下沉到 HTTPRoute 中实现，或者一个独自的 CRD，这样用户态和超级管理员就能够离开的更分明。现有的形式也能做，就是有点混淆。
最终 Higress 胜出
除了以上重点的我的项目，咱们还测试了很多其余我的项目，我这里就不一一列举了。Sealos 最终选了 Higress。
咱们目前抉择网关的逻辑很简略，次要就是在满足性能的前提下足够稳固，最终抉择 Higress 简直是排除法得进去的。
稳定性是排在第一位的，在咱们的场景外面可能达到生产可用的目前只有 Higress。不过实际过程中也呈现过一些问题，好在 Higress 社区的反对力度很大，很疾速的解决了，次要有几个：
- Ingress 失效速度慢，路由条目多时，2min 多新建路由能力失效，社区最初优化到了 3s 左右，这曾经到极致了，也没有再优化的必要了，因为曾经比容器 Ready 工夫还短了，Higress 应用了一种增量加载配置的机制，让海量路由条目时也能有夸大的性能。
- 控制器 OOM，在无动静加载时资源耗费比拟大，呈现过 OOM 的状况，目前三高问题都解决掉了。
- 超时问题，有一个进一步优化加载延时的参数配置 onDemandRDS 在咱们一个主集群会偶发申请超时，目前是把该配置敞开了，还在进一步查看起因，而在其它集群中未发现这个问题。
安全性方面，咱们很多时候的故障问题都是性能问题造成的，流量过大，打爆网关比拟常见，所以网关的性能变得至关重要，实测下来 Envoy 要彪悍很多，控制器写的好不好也生死攸关，这个方面 Higress 体现出众：
在咱们曾经海量路由，超高并发的状况下，须要的资源少的可怜。
Higress 还兼容 Nginx Ingress 语法，次要是一些 annotations，咱们之前的代码都是用的 Ingress，所以简直没有任何迁徙老本，间接几分钟的降级就能够搞定。
同样为了促成社区更好的倒退咱们也给 Higress 一些意见：
1. 能对 Gateway 的规范有更好的反对，目前尽管曾经反对了 v1 版本，但还没有齐全兼容 Ingress 上的能力。
2. 能凋谢出一些大杀器的性能，比方平安和熔断方面的能力。让开源和商业联合的更严密一些，咱们倒是不排挤付费，然而随着平台倒退，须要更强的一些性能。
3. 周边性能倡议更多通过插件机制扩大，让外围性能更内聚一些，简略可依赖。
总结
网关对于云和利用而言是个十分十分外围的组件，随着 Sealos 规模的不断扩大，也会呈现很多新的挑战，咱们心愿能和上下游社区建设严密的单干，让开源网关能失去更好的倒退，让更多开发者受害。
以上列举的很多网关都很优良，Sealos 没用不代表我的项目不厉害，只是咱们的场景刻薄且奇葩，真的在公网环境能反对多租户的网关并不多，所以各位看官还是要从本人的场景登程。咱们的选型仅作参考，同样 Sealos 自身也会以一个凋谢心态来持续跟进其余网关的倒退。
最初非常感谢 Higress 开源社区的大力支持，感激阿里云云原生团队开源了这么优良的我的项目，造福宽广社区用户。
作者：Sealos 创始人，环界云计算 CEO 方海涛
原文链接
本文为阿里云原创内容，未经容许不得转载。
