云原生網(wǎng)關(guān)哪家強(qiáng)---Sealos 網(wǎng)關(guān)血淚史
Sealos 公有云（https://cloud.sealos.io）幾乎打爆了市面上所有主流的開源網(wǎng)關(guān)，本文可以給大家很好的避坑返劲，在網(wǎng)關(guān)選型方面做一些參考兵多。
Sealos Cloud 的復(fù)雜場(chǎng)景
Sealos 公有云上線以來，用戶呈爆發(fā)式增長(zhǎng)碘箍，目前總共注冊(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)定嗤锉。
- 長(zhǎng)鏈接不穩(wěn)定，也是因?yàn)樽兏嗝龋谟玫拈L(zhǎng)鏈接會(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)的邏輯很簡(jiǎ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ǎn)單可依賴咐旧。
總結(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ū)用戶霍殴。
sealos 以kubernetes為內(nèi)核的云操作系統(tǒng)發(fā)行版，讓云原生簡(jiǎn)單普及
laf 寫代碼像寫博客一樣簡(jiǎn)單系吩，什么docker kubernetes統(tǒng)統(tǒng)不關(guān)心来庭，我只關(guān)心寫業(yè)務(wù)！
