Sealos 公有云幾乎打爆了市面上所有主流的開源網關，本文可以給大家很好的避坑，在網關選型方面做一些參考。

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 一些意見：

• 能對 Gateway 的標準有更好的支持，目前雖然已經支持了 v1 版本，但還沒有完全兼容 ingress 上的能力。
• 能開放出一些大殺器的功能，比如安全和熔斷方面的能力。讓開源和商業結合的更緊密一些，我們倒是不排斥付費，但是隨著平臺發展，需要更強的一些功能。
• 周邊功能建議更多通過插件機制擴展，讓核心功能更內聚一些，簡單可依賴。

總結

網關對于云和應用而言是個非常非常核心的組件，隨著我們規模的不斷擴大也會出現很多新的挑戰，我們希望能和上下游社區建立緊密的合作，讓開源網關能得到更好的發展，讓更多開發者受益。

以上列舉的很多網關都很優秀，Sealos 沒用不代表項目不厲害，只是我們的場景苛刻且奇葩，真的在公網環境能支持多租戶的網關并不多，所以各位看官還是要從自己的場景出發，我們的選型僅作參考，同樣 Sealos 本身也會以一個開放心態來繼續跟進其他網關的發展。

最后非常感謝 Higress 開源社區的大力支持，感謝阿里云云原生團隊開源了這么優秀的項目，造福廣大社區用戶。

總結

以上是生活随笔為你收集整理的K8s 网关选型血泪史的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。