Sealos 公有云幾乎打爆了市面上所有主流的開源網(wǎng)關(guān)，本文可以給大家很好的避坑，在網(wǎng)關(guān)選型方面做一些參考。
Sealos Cloud 的復(fù)雜場(chǎng)景
Sealos 公有云上線以來，用戶呈爆發(fā)式增長，目前總共注冊(cè)用戶 8.7w，每個(gè)用戶都去創(chuàng)建應(yīng)用，每個(gè)應(yīng)用都需要有自己的訪問入口，就導(dǎo)致整個(gè)集群路由條目非常巨大，需要有支撐數(shù)十萬條 ingress 的能力。
另外，在公網(wǎng)提供共享集群的服務(wù)，對(duì)多租戶要求極為苛刻，用戶之間的路由必須不能相互影響，需要非常好的隔離性，以及流量控制能力。
公有云的受攻擊面是很大的，黑客會(huì)攻擊云上跑的用戶應(yīng)用，也會(huì)直接攻擊平臺(tái)的出口網(wǎng)絡(luò)，安全性上也有非常大的挑戰(zhàn)。
對(duì)控制器的性能和穩(wěn)定要求都比較高，很多控制器路由條目一多時(shí)消耗資源會(huì)非常大，甚至 OOM 導(dǎo)致網(wǎng)關(guān)奔潰。
排除 Nginx Ingress
我們最早用的就是 Nginx Ingress, 最后發(fā)現(xiàn)有幾個(gè)核心問題無法解決：
- reload 問題，每次有 ingress 變更會(huì)導(dǎo)致斷連一小會(huì)，而一個(gè)集群用戶一多的時(shí)候，ingress 的創(chuàng)建變更會(huì)是個(gè)頻繁事件，就會(huì)導(dǎo)致網(wǎng)絡(luò)經(jīng)常不穩(wěn)定。
- 長鏈接不穩(wěn)定，也是因?yàn)樽兏?，在用的長鏈接會(huì)經(jīng)常斷。
- 性能不行，生效時(shí)間慢，消耗資源多。
所以幾乎排除掉了很多底層用 Nginx 實(shí)現(xiàn)的網(wǎng)關(guān)。我們實(shí)測(cè)下來基于 Envoy 實(shí)現(xiàn)的網(wǎng)關(guān)性能彪悍太多，幾乎控制面和數(shù)據(jù)面都不怎么消耗性能。
這是 Envoy 的：
這是 Nginx 的：
差距非常之大，所以我們就可以排除掉 Nginx 系列選項(xiàng)了。徹底擁抱 Envoy。
關(guān)于 APISIX
APISIX 本身是個(gè)優(yōu)秀項(xiàng)目，解決了 Nginx reload 的一些問題，所以我們 Laf 早期也用了 APISIX，但是很不幸 APISIX 的 Ingress Controller 并不是很穩(wěn)定，控制面奔潰給造成了我們好幾次大的故障，還出現(xiàn)過控制器 OOM 等問題，我們本來真的很想用，但是最終還是因?yàn)楣收蠁栴}被強(qiáng)制勸退，當(dāng)然 APISIX 社區(qū)也在一直跟進(jìn)這些問題，希望能越做越好。
總結(jié)一下就是: APISIX 本身穩(wěn)定性很好，但是控制器需要優(yōu)化的東西還很多，穩(wěn)定性也有待提高。社區(qū)支持力度也很大，無奈我們線上問題火燒眉毛沒法按照社區(qū)的節(jié)奏慢慢迭代，只能先切成別的網(wǎng)關(guān)了。
Cilium Gateway
Sealos 的 CNI 很早就切換成 Cilium 了，確實(shí)很強(qiáng)，所以我們想著網(wǎng)關(guān)也統(tǒng)一用 Cilium 得了，但是現(xiàn)實(shí)很骨感。
Cilium Gateway 只支持 LB 模式，這樣就強(qiáng)依賴云廠商的 LB，而我們也有一些私有化的場(chǎng)景，所以不希望耦合，穩(wěn)定性方面也遇到了路由非常多的時(shí)候 Ingress 生效特別慢的問題，需要分鐘級(jí)生效，這樣用戶的體驗(yàn)就很差了，我們能接受的是 5s 內(nèi)路由生效。所以結(jié)論就是只能再等等。
Envoy Gateway
K8s 標(biāo)準(zhǔn)的發(fā)展來看，會(huì)逐漸從 Ingress 遷移到 Gateway 的標(biāo)準(zhǔn)，而我們底層又更傾向使用 Envoy，那 Envoy Gateway 的實(shí)現(xiàn)似乎是一個(gè)很好的選擇，所以我們調(diào)研了 Envoy Gateway, 但是這個(gè)項(xiàng)目還是太過于早期，遇到了一些不穩(wěn)定的 bug，比如會(huì) OOM，pathpolicy 不生效，有些特性在 merge gateway 模式下不生效等問題，在持續(xù)解決中，我們也在不斷幫助上游社區(qū)提改進(jìn)意見和貢獻(xiàn)，希望未來可以能達(dá)到生產(chǎn)可用的狀態(tài)。
逼格很高但不那么實(shí)用的 Gateway 標(biāo)準(zhǔn)
Gateway 的處境很尬感，我的感覺是設(shè)計(jì)者并沒有真的實(shí)踐過多租戶場(chǎng)景，當(dāng)多租戶共享一個(gè)集群時(shí)，就要明確區(qū)分管理者和使用者的權(quán)限問題，Gateway 設(shè)計(jì)之初就沒完全考慮清楚，舉個(gè)例子：
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
這里監(jiān)聽端口這類的配置應(yīng)該是給集群管理員而不是普通用戶，而 TLS 證書的配置屬于某個(gè)應(yīng)用，管理員可以有權(quán)限配置，主要還是每個(gè)用戶去配置自己的，所以這里面權(quán)限就沒有分開。 那就只能讓用戶也有權(quán)限配置 Gateway，所以這里就又需要在控制器里實(shí)現(xiàn)很多的權(quán)限控制的細(xì)節(jié)問題，如端口號(hào)白名單，沖突檢測(cè)等。
個(gè)人覺得更優(yōu)雅的設(shè)計(jì)是把其中租戶級(jí)別的字段下沉到 HTTPRoute 中實(shí)現(xiàn)，或者一個(gè)單獨(dú)的 CRD,這樣用戶態(tài)和超級(jí)管理員就可以分開的更清楚。 現(xiàn)有的方式也能做，就是有點(diǎn)混雜。
最終 Higress 勝出
除了以上重點(diǎn)的項(xiàng)目我們還測(cè)試了很多其他項(xiàng)目，我這里就不一一列舉了。 Sealos 最終選了 Higress。
我們目前選擇網(wǎng)關(guān)的邏輯很簡單，主要就是在滿足我們功能的前提下足夠穩(wěn)定，最終選擇 Higress 幾乎是排除法得出來的。
穩(wěn)定性是排在第一位的，在我們的場(chǎng)景里面能夠達(dá)到生產(chǎn)可用的目前只有 Higress，不過實(shí)踐過程中也出現(xiàn)過一些問題，好在 Higress 社區(qū)的支持力度很大，很快速的解決了，主要有幾個(gè)：
- ingress 生效速度慢，路由條目多時(shí) 2min 多新建路由才能生效，社區(qū)最后優(yōu)化到了 3s 左右，這已經(jīng)到極致了，也沒有再優(yōu)化的必要了，因?yàn)橐呀?jīng)比容器 Ready 時(shí)間還短了, Higress 使用了一種增量加載配置的機(jī)制，讓海量路由條目時(shí)也能有夸張的性能。
- 控制器 OOM,在無動(dòng)態(tài)加載時(shí)資源消耗比較大，出現(xiàn)過 OOM 的情況，目前三高問題都解決掉了。
- 超時(shí)問題，有一個(gè)進(jìn)一步優(yōu)化加載延時(shí)的參數(shù)配置 onDemandRDS 在我們一個(gè)主集群會(huì)偶發(fā)請(qǐng)求超時(shí)，目前是把該配置關(guān)閉了，還在進(jìn)一步查看原因，而在其它集群中未發(fā)現(xiàn)這個(gè)問題。
安全性方面，我們很多時(shí)候的故障問題都是性能問題造成的，流量過大，打爆網(wǎng)關(guān)比較常見，所以網(wǎng)關(guān)的性能變得至關(guān)重要，實(shí)測(cè)下來 Envoy 要彪悍很多，控制器寫的好不好也生死攸關(guān)，這個(gè)方面 Higress 表現(xiàn)出眾：
在我們已經(jīng)海量路由，超高并發(fā)的情況下，需要的資源少的可憐。
Higress 還兼容 Nginx Ingress 語法，主要是一些 annotations，我們之前的代碼都是用的 Ingress，所以幾乎沒有任何遷移成本，直接幾分鐘的升級(jí)就可以搞定。
同樣為了促進(jìn)社區(qū)更好的發(fā)展我們也給 Higress 一些意見：
- 能對(duì) Gateway 的標(biāo)準(zhǔn)有更好的支持，目前雖然已經(jīng)支持了 v1 版本，但還沒有完全兼容 ingress 上的能力。
- 能開放出一些大殺器的功能，比如安全和熔斷方面的能力。讓開源和商業(yè)結(jié)合的更緊密一些，我們倒是不排斥付費(fèi)，但是隨著平臺(tái)發(fā)展，需要更強(qiáng)的一些功能。
- 周邊功能建議更多通過插件機(jī)制擴(kuò)展，讓核心功能更內(nèi)聚一些，簡單可依賴。
總結(jié)
網(wǎng)關(guān)對(duì)于云和應(yīng)用而言是個(gè)非常非常核心的組件，隨著我們規(guī)模的不斷擴(kuò)大也會(huì)出現(xiàn)很多新的挑戰(zhàn)，我們希望能和上下游社區(qū)建立緊密的合作，讓開源網(wǎng)關(guān)能得到更好的發(fā)展，讓更多開發(fā)者受益。
以上列舉的很多網(wǎng)關(guān)都很優(yōu)秀，Sealos 沒用不代表項(xiàng)目不厲害，只是我們的場(chǎng)景苛刻且奇葩，真的在公網(wǎng)環(huán)境能支持多租戶的網(wǎng)關(guān)并不多，所以各位看官還是要從自己的場(chǎng)景出發(fā)，我們的選型僅作參考，同樣 Sealos 本身也會(huì)以一個(gè)開放心態(tài)來繼續(xù)跟進(jìn)其他網(wǎng)關(guān)的發(fā)展。
最后非常感謝 Higress 開源社區(qū)的大力支持，感謝阿里云云原生團(tuán)隊(duì)開源了這么優(yōu)秀的項(xiàng)目，造福廣大社區(qū)用戶。
