乐趣区

关于云原生:云原生网关哪家强Sealos-网关血泪史

jiezi

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 社区的反对力度很大，很疾速的解决了，次要有几个：

  1. Ingress 失效速度慢，路由条目多时，2min 多新建路由能力失效，社区最初优化到了 3s 左右，这曾经到极致了，也没有再优化的必要了，因为曾经比容器 Ready 工夫还短了，Higress 应用了一种增量加载配置的机制，让海量路由条目时也能有夸大的性能。
  2. 控制器 OOM，在无动静加载时资源耗费比拟大，呈现过 OOM 的状况，目前三高问题都解决掉了。
  3. 超时问题，有一个进一步优化加载延时的参数配置 onDemandRDS 在咱们一个主集群会偶发申请超时，目前是把该配置敞开了，还在进一步查看起因，而在其它集群中未发现这个问题。

安全性方面，咱们很多时候的故障问题都是性能问题造成的，流量过大，打爆网关比拟常见，所以网关的性能变得至关重要，实测下来 Envoy 要彪悍很多，控制器写的好不好也生死攸关，这个方面 Higress 体现出众：

在咱们曾经海量路由，超高并发的状况下，须要的资源少的可怜。

Higress 还兼容 Nginx Ingress 语法，次要是一些 annotations，咱们之前的代码都是用的 Ingress，所以简直没有任何迁徙老本，间接几分钟的降级就能够搞定。

同样为了促成社区更好的倒退咱们也给 Higress 一些意见：

1. 能对 Gateway 的规范有更好的反对，目前尽管曾经反对了 v1 版本，但还没有齐全兼容 Ingress 上的能力。
2. 能凋谢出一些大杀器的性能，比方平安和熔断方面的能力。让开源和商业联合的更严密一些，咱们倒是不排挤付费，然而随着平台倒退，须要更强的一些性能。
3. 周边性能倡议更多通过插件机制扩大，让外围性能更内聚一些，简略可依赖。

总结

网关对于云和利用而言是个十分十分外围的组件，随着 Sealos 规模的不断扩大，也会呈现很多新的挑战，咱们心愿能和上下游社区建设严密的单干，让开源网关能失去更好的倒退，让更多开发者受害。

以上列举的很多网关都很优良，Sealos 没用不代表我的项目不厉害，只是咱们的场景刻薄且奇葩，真的在公网环境能反对多租户的网关并不多，所以各位看官还是要从本人的场景登程。咱们的选型仅作参考，同样 Sealos 自身也会以一个凋谢心态来持续跟进其余网关的倒退。

最初非常感谢 Higress 开源社区的大力支持，感激阿里云云原生团队开源了这么优良的我的项目，造福宽广社区用户。

作者：Sealos 创始人，环界云计算 CEO 方海涛

原文链接

本文为阿里云原创内容，未经容许不得转载。

退出移动版