淺談 k8s ingress controller 選型

你們好，先簡單自我介紹下，我叫厲輝，來自騰訊雲。業餘時間比較喜歡開源，如今是Apache APISIX PPMC。今天我來簡單給你們介紹下 K8S Ingress 控制器的選型經驗，今天我講的這些內容須要你們對 K8S 有必定的瞭解，下面是個人分享。

名詞解釋

閱讀本文須要熟悉如下基本概念：

• 集羣：是指容器運行所需雲資源的集合，包含了若干臺雲服務器、負載均衡器等雲資源。
• 實例（Pod）：由相關的一個或多個容器構成一個實例，這些容器共享相同的存儲和網絡空間。
• 工做負載（Node）：Kubernetes 資源對象，用於管理 Pod 副本的建立、調度以及整個生命週期的自動控制。
• 服務（Service）：由多個相同配置的實例（Pod）和訪問這些實例（Pod）的規則組成的微服務。
• Ingress：Ingress 是用於將外部 HTTP（S）流量路由到服務（Service）的規則集合。

K8S 訪問現狀

在 K8S 中，服務跟 Pod IP 主要供服務在集羣內訪問使用，對於集羣外的應用是不可見的。怎麼解決這個問題呢？爲了讓外部的應用可以訪問 K8S 集羣中的服務，一般解決辦法是 NodePort 和 LoadBalancer。

這兩種方案其實有各自的缺點，NodePort 的缺點是一個端口只能掛載一個 Service，並且爲了更高的可用性，須要額外搭建一個負載均衡。LoadBalancer 的缺點則是每一個服務都必需要有一個本身的 IP，不管是內網 IP 或者外網 IP。更多狀況下，爲了保證 LoadBalancer 的能力，通常須要依賴於雲服務商。

在K8S的實踐、部署中，爲了解決像 Pod 遷移、Node Pod 端口、域名動態分配，或者是 Pod 後臺地址動態更新這種問題，就產生了 ingress 解決方案。

Ingress 選型

Nginx ingress 的缺點

Ingress 是 K8S 中很是重要的外網流量入口，前面又拍雲的總監也講到了 K8S 默認的 Nginx ingress。這個 ingress 是 K8S 所推薦的默認的 ingress。爲了跟後面的 Nginx 提供的商業版 ingress 做爲區分，我就叫它叫 K8S ingress。K8S ingress，顧名思義基於 Nginx 的平臺，Nginx 如今是世界上最流行的 Nginx HTTP Sever，相信在座各位都對 Nginx 比較熟悉，這是一個優勢。第二個優勢則是 Nginx ingress 接入 K8S 集羣所需配置很是少，並且有不少文檔來指引你如何使用這個 ingress。這對於大部分剛接觸 K8S 的人或者創業公司來講，Nginx ingress 確實是一個很是好的選擇。

可是當 Nginx ingress 在一些大環境上使用時，就會有很是多的問題。第一個，Nginx ingress它用了一些 OpenResty 的特性，但最終配置加載仍是依賴於原有的 Nginx config reload。當路由配置很是大的時候，Nginx reload 會耗時很是久，能夠達到幾秒甚至十幾秒，這種 reload 會很嚴重的影響業務，甚至形成業務中斷，這是第一個問題。

第二個問題是 Nginx ingress 的插件開發很是困難，若是你以爲 Nginx ingress 自己插件夠用，那仍是能夠用的。但若是想用一些定製化的插件，好比像阿里雲的IM鑑權，或者是騰訊雲的 KM 鑑權都須要進行額外的開發。Nginx ingress 開發插件很是痛苦，額外開發就很是麻煩，因此 Nginx ingress 的插件能力和可擴展性是比較差的。

Ingress 選型原則

既然發現了 Nginx ingress 有不少問題，那是否是考慮選擇開源的更好用的 ingress，市場上說比 K8S ingress 好用的起碼有十幾家。如何從這麼多 ingress 中選擇適合本身的，這讓人感到困擾。

Ingress 最終是基於 HTTP 網關的，市面上 HTTP 網關主要有這麼幾種。好比 Nginx、Golang 原生的以及新崛起的 Envoy 這些網關。可是每一個開發人員所擅長的技術棧不一樣，例如我對 Nginx 比較熟悉，但有些人對 HAproxy 更加熟悉，或者有些人對新興的 Envoy 這個網關更加熟悉。由於每一個人熟悉的底層網關不同，因此適合的 ingress 也會不同。

那麼問題來了，咱們如何選擇一個更加好用的 ingress 呢？或者縮小點範圍，熟悉 Nginx 或 OpenResty 的開發人員，應該選擇哪個 ingress 呢？

下面來介紹一下我對 ingress 控制器選型的一些經驗。

基本特色

圖中的這些我以爲是基本功能，這些功能必需要有。若是連這些功能都沒有，那徹底能夠直接pass。

• 必須開源的，不開源的沒法使用
• K8S 中 Pod 變化很是頻繁，服務發現很是重要
• 如今 HTTPS 已經很普及了，TLS 或者 SSL 的能力也很是重要，好比證書管理的功能
• 支持 WebSocket 等常見協議，在某些狀況下，可能還須要支持 HTTP2 、QUIC 等

基礎軟件

前面有提到，每一個人擅長的技術平臺不同，因此選擇本身更加熟悉的 HTTP 網關也顯得相當重要。好比 Nginx、HAProxy、Envoy 或者是 Golang 原生網關。由於你熟悉它的原理，在使用中能夠更快落地。

在生產環境上，高性能是一個很重要的點，但比之更重要的是高可用。這意味着你選擇的網關，它的可用性、穩定性必定要很是強，只有這樣，服務才能穩定。

功能需求

拋開上述兩點，就是公司業務對網關的特殊需求。你選擇一個開源產品，最好確定是開箱能用的。好比你須要 GRPC 協議轉換的能力，那固然但願選的網關直接支持這個功能。而確定不但願去選擇還須要開發的網關。這裏簡單列一下影響選擇的點：

• 協議上是否支持 HTTP二、HTTP3；
• 負載均衡算法上，最基本的WRR，或者是一致性哈希這種負載均衡算法是否足夠，仍是須要更加複雜的相似EWMA負載均衡算法。

鑑權限流上，簡單的鑑權是否足夠，仍是說須要更進階的鑑權方式，或者要集成，或者很方便的能開發像阿里雲、騰訊雲的 IM 鑑權。前面咱們有提到K8S ingress主要有這麼些缺點，好比說 Nginx reload 的問題，插件擴展能力比較弱。其實它的後端節點調整權重的能力也不太好。

選擇 APISIX 做爲 Ingress controller

這裏就要推薦一下 APISIX，它有很是強大的路由能力，插件能力也很是靈活。雖然它在功能上比 Kong 會少不少，可是 APISIX 很好的路由能力、靈活的插件能力，以及自己的高性能，可以彌補在 ingress 選型上的一些缺點。若是大家是基於 Nginx 或 Openresty 的開發人員，又對如今的 ingress 不滿意，我推薦大家去使用 APISIX 做爲 ingress。

如何將 APISIX 做爲 ingress 呢？咱們先要作出一個區分，ingress 是 K8S 名稱的定義或者規則定義，ingress controller 是將 K8S 集羣狀態同步到網關的一個組件。但 APISIX 自己只是 API 網關，怎麼把 APISIX 實現成 ingress controller 呢？咱們先來簡要了解一下如何實現 ingress。

實現 ingress，本質上就是兩點。第一點，須要將 K8S 集羣中的配置，或者 K8S 集羣中的狀態同步到 APISIX 集羣。第二點，須要將 APISIX中 的一些概念，好比像服務、upstream 等概念定義爲 K8S 中的 CRD。實現了第二部分的話，經過 K8S ingress 的配置，很快的去產生 APISIX，經過 APISIX ingress controller 就會產生 APISIX 相關的配置。咱們當前爲了快速的將 APISIX 落地爲可以支持 K8S 的 ingress 。咱們建立了一個開源項目，叫 ingress controller。

項目的架構大概是這樣。左邊是 K8S 的集羣，這裏能夠導入一些 yaml 文件，對 K8S 進行配置上的變動。右邊則是 APISIX 集羣，以及它的控制面和數據面。在這裏，APISIX Ingress 充當這兩個 K8S 集羣以及 APISIX 集羣之間的鏈接者。它主要是監聽 K8S 集羣中節點的變化，去將集羣中的狀態同步到 APISIX 集羣。另外，K8S 倡導全部組件都要高可用，因此 APISIX Ingress 設計之初，也考慮到它的高可用。咱們經過雙節點或多節點的模式，來實現 APISIX ingress controller 的高可用。

各類 Ingress 橫向對比

相對於市面上流行的 ingress 控制器，咱們簡單對比來看看 APISIX ingress 有什麼優缺點。上圖是外國開發人員針對 K8S ingress 選型作的一張表格。我在原來表格的基礎上，結合本身的理解，將 APISIX ingress 的功能加入了進來。咱們能夠看到，最左邊的是APISIX，後邊就是 K8S ingress 和 Kong Ingress，後面的 Traefik，就是基於 Golang 的 ingress。HAproxy 是比較常見的，過去是比較流行的負載均衡器。Istio 和 Ambassador 是國外很是流行的兩個ingress。

咱們能夠簡單聊一下這些 ingress。首先說下 APISIX ingress，APISIX ingress 的優勢前面也說到了，它有很是強大的路由能力，性能很是強，也有很是靈活的插件拓展能力。APISIX 剛開源沒幾個月，就已經有很是多的功能。可是它的缺點也很是明顯，APISIX 有很是多的功能，可是缺乏落地案例，沒有文章去教你們如何將這些功能都給用起來。

第二個就是我前面吐槽了不少的 K8S ingress，也是那個 K8S 推薦的 Nginx Ingress。它的主要優勢前面也說了，簡單、易接入。但缺點就很是明顯，Nginx reload根本就沒有解決，插件是不少的，但插件擴展能力是很是弱的。

咱們再說第三個，Nginx ingress主要優勢是在於它對 TCP 和 UDP 協議的徹底支持，可是其餘的，好比像鑑權方式，或者流量調度，這個功能都是很是缺失的。

Kong 自己是一個 API 網關，他也算是開創了先河，將 API 網關引入到 K8S 中當 ingress。另外對於邊緣網關，你們仍是有不少需求的，好比說像鑑權、限流、灰度部署等能力。Kong 在這些方面作的很是好。另外 Kong ingress 還有一個很是大的優勢，他提供了一些 API、服務的定義，去抽象成 K8S 的 CRD，因此能夠很方便地經過 K8S ingress 配置，去同步到 Kong 的集羣。雖然 Kong 有不少優勢，但 Kong 也有一個很是大的缺點，那就是部署特別困難，另外他的高可用，與 APISIX 相比也是相形見絀。

Traefik 是基於 Golang 的 ingress，它自己是一個微服務網關，可是在 ingress 的場景應用比較多。他的主要平臺是基於 Golang，自身支持的協議也很是多，整體來講是沒有什麼缺點。若是你們熟悉 Golang 的話，也推薦一用。

HAproxy，是一個久負盛名的負載均衡器。它主要優勢是有很是強大的負載均衡能力，其餘方面並不佔優點。

Istio ingress 和 Ambassador ingress 都是基於最近很是流行的 envoy。說實話，我以爲這兩個 ingress 沒有什麼缺點，可能惟一的缺點是他們基於 envoy 平臺，你們對這個平臺都不是很熟悉，上手門檻會比較高。

騰訊雲 CLB ingress

前面主要說了開源中的一些 ingress，如今再來講一下 ingress 在騰訊雲的落地狀況。前面提到的，像 K8S APISIX，或者是 ingress，他們都是開源的。K8S 跟 ingress，它們都是相互對應的。要聊騰訊雲中的 ingress，天然要先去了解騰訊雲中的 K8S 是什麼。因此我先簡要介紹一下騰訊雲的 TKE，也就是騰訊雲的 K8S 平臺，而後再是騰訊雲 ingress 的落地狀況，它是集成了 CLB 來完成了 ingress 的功能。

上圖是當前騰訊雲的 TKE 平臺的總體縱覽，主要由用戶接入層、核心功能，和整合產品三方面組成，整合產品將 Iaas 層和 PaaS 層進行了一些整合。

TKE 的全稱是 Tencent Kubernetes Engine，是⼀個⾼度可擴展的⾼性能容器管理服務。最核心的是 TKE 解決了多租戶的問題，K8S 自己是單租戶的，怎麼在騰訊雲上變成多租戶的場景呢？咱們花了很長的時間去改造它。其次，在 K8S 節點內，解決了其餘一些問題。咱們採用了騰訊雲的 VPC 的方案，解決了 Service 和 Pod 之間的通訊問題。另外，內部網絡集成了 vpc 的能力，對外網絡集成 CLB 的負載均衡能力，硬盤存儲上集成 CBS 的存儲能力等等，最終實現了騰訊雲 K8S 的公有云版。當前 TKE 在騰訊雲上差很少有 200 萬的狀態吧。

CLB 是怎麼樣的？上圖是騰訊雲 CLB ingress 的總體架構圖。由於我想從高性能、高可用的角度來說咱們的 ingress 集羣，因此把 K8S 這塊作了簡化，只留了用戶操做，API Server 以及控制器這些。

TKE 須要將 ingress 集成，只需將原有負載均衡的概念，去抽象成 K8S 中一些 CRD 的源語，而後就能夠進行映射。好比建立 ingress 或者節點進行調度的時候，咱們均可以經過調用 CLB 的接口去更新狀態，完成整個 ingress 鏈路。

接下來就聊一下騰訊雲 CLB 的高性能與高可用。由於後臺服務最關注的也是這兩點。

高性能

高性能網關主要說兩部分，一是數據面，二是控制面。咱們先說數據面，數據面這邊的話，咱們作的七層 CLB 主要是基於 Nginx。爲了保證高性能，第一步就是要對 Nginx 進行優化。第二步優化是負載均衡，負載均衡最重要的就是 HTTPS 的能力，HTTPS 實際上是很是消耗 CPU的。開源界裏，HTTPS 的的優化空間很是大。舉個例子，就好比開源 Nginx，我記不大清是八核仍是四核，能夠很輕鬆的達到10萬 KBS。可是一旦用了 HTTPS 後，可能連 1 萬 KBS 都達不到。因此 HTTPS 是有很大優化空間的。咱們在作七層高性能時，花了不少時間去優化這塊。怎麼優化呢？百度搜一下 Nginx 常見的優化，結果裏出現的，基本上都能優化，固然咱們還作了另一些細節上的優化。

第二部分是協議層上的優化，主要是對 HTTPS 協議自己的優化，這包含不少，包括加密協議、open ssl 庫等，咱們都作了一些優化。另外還有 HTTP2 協議的優化，HTTP2 是默認開啓 TLS 加密的，因此也繞不過 HTTPS 協議的優化。

第二方面，咱們作了不少控制面的的優化。前面已經提了不少次，只要用 Nginx，確定避免不了 Nginx reload 的問題。只有幾條路由時，可能沒有問題。可是當有幾千條、幾十萬條路由配置時，若是用 Nginx reload 至少要花十幾秒，這對業務中斷影響很是嚴重，徹底不能接受。那該怎麼辦呢？咱們做爲一個雲廠商，客戶不只僅在 upsteam這 塊，在後臺節點的變化也很是快，並且客戶是共享集羣，很是多的客戶可能都在操做規則，例如操做 Nginx Server。因此咱們又作了動態 Server 的優化。在完成 upstream 和動態 Server 這兩個優化後，對於 99.9% 的規則，基本上均可以經過 Nginx 動態 Server 以及 Nginx 動態 upstream 來解決配置加載、變動，而不須要再去經歷 Nginx reload，這是咱們控制面的優化。

高可用

高可用也分兩方面，一是控制集羣，也就是控制面的高可用，二是數據面的高可用。咱們先來講數據面的高可用。

數據面的高可用，主要是如上圖的鏈路。四層網關與七層網關，七層網關與後端節點之間，其實他們都有專門的心跳探測，有熔斷機制、超時能力等來保證高可用。好比發現某些節點有問題時，我會去剔除該節點。但也會去定時的撥測，一旦該節點恢復狀態以後，會再將節點去加回來，這是第一方面，數據面的高可能主要經過心跳探測。

第二方面的話，也就是網關的跨可用區容災。咱們也作了一個 7 層網關與 4 層網關的跨可用區容災好比當某一個機房的網關徹底掛掉以後，咱們依然能夠提供一個高可用、高性能的服務。控制面的話這個主要是經過 master agent 集羣化的模式來保證高可用。

騰訊雲將來的 Ingress——APISIX

說了 CLB ingress 的架構，看起來確實挺美好的，高可用，性能也很是好，那麼它的缺點呢？其實它也是有一些缺點的。

第一，雖然前面說經過動態 upstream 和動態 Server 能夠解決掉 99.9% 的配置變動問題，而不須要走 Nginx reload。可是本質上沒有解決配置變動的一些問題，尤爲是在一些突發或者後端節點比較多的狀況下出現問題。由於過去的後端節點最多也就幾十個，可是當 Docker 化時，後端節點很容易達到上千個甚至上萬個。這時很容易觸發動態 upstream 的域值，讓原本應該走動態 upsteam 的，最終去走了 Nginx reload，這會產生很是嚴重的性能問題。

第二，CLB ingress 全部的邏輯、附加功能都是基於 Nginx，好比像 ACL 限流等都是經過 Nginx 模塊來開發的。這樣的話，首先開發門檻會很是高，其次開發效率也比較低。

咱們對負載均衡的要求並不高。好比對負載均衡的主要要求，一是七層網關性能必定要好，二是 HTTPS 協議的支持能力必定要好，三是支持更多協議。可是對於 K8S ingress 的要求就不知足了，由於 K8S 有不少節點，我更但願有一個很好用的灰度能力。如今的 CLB，是知足不了定製化的灰度發佈需求。因此，經過 TKE 集成了 CLB 負載均衡的能力，看成一個 ingress，只是到了能用的級別，但並無徹底的去貼合 K8S 平臺的須要。

當前 CLB ingress 主要存在的問題就是這些。灰度能力比較弱，也很容易觸發 Nginx reload，從而影響業務，除了這兩點，還有就是隔離性很是差。CLB 的這種部署方式，依然仍是不少客戶共用一組 ingress。客戶與客戶之間，實際上是會互相影響的。而 K8S 的設計理念是但願客戶可以獨佔 ingress，不但願客戶與客戶之間的 ingress 會互相影響。咱們想要解決上述的問題，恰巧碰見了 APISIX 這個項目。

APISIX 的優點是性能好，這裏就不贅述了。另外 APISIX 插件能力靈活，能夠支持在更多位置去插入插件。而且，APISIX 是從雲原生角度去設計的，這意味着 APISIX 很是適合在容器中部署，不像過去的 CLB 在物理機上部署還好，可是在容器上部署，控制面架構就很是不適合。而 APISIX 的控制架構，咱們能夠很是輕鬆地選擇是讓客戶去共用一組 ingress，仍是每一個客戶有本身獨佔的 ingress。APISIX 在這三個方面都作的很是好，最終咱們打算去落地 APISIX ingress 去替代 TKE 平臺中的 ingress。

最後總結一下，雖然主要是聊 ingress 選型。前面其實就講到了 ingress 的定位，如何去選擇 ingress，選型要考慮哪些問題。後面將 APISIX ingress 與當前開源的一些 ingress 作了橫向對比，讓你們瞭解各個 ingress 的優劣勢，方便後續選型時可以快速選擇適合本身的 ingress。最後簡要介紹了咱們騰訊雲的 CLB ingress，以及它當前存在的問題和下一步計劃。

推薦閱讀

3 分鐘帶你深刻了解 Cookie、Session、Token

又拍雲邵海楊：基於 OpenResty 的動態服務路由方案