KubernetesIngress控制器的技術(shù)選型技巧有哪些-創(chuàng)新互聯(lián)

小編給大家分享一下Kubernetes Ingress控制器的技術(shù)選型技巧有哪些，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

創(chuàng)新互聯(lián)從2013年創(chuàng)立，先為烏蘭察布等服務(wù)建站，烏蘭察布等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為烏蘭察布企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。
名詞解釋
閱讀本文需要熟悉以下基本概念：

• 集群：是指容器運(yùn)行所需云資源的集合，包含了若干臺(tái)云服務(wù)器、負(fù)載均衡器等云資源。
• 實(shí)例（Pod）：由相關(guān)的一個(gè)或多個(gè)容器構(gòu)成一個(gè)實(shí)例，這些容器共享相同的存儲(chǔ)和網(wǎng)絡(luò)空間。
• 工作負(fù)載（Node）：Kubernetes 資源對(duì)象，用于管理 Pod 副本的創(chuàng)建、調(diào)度以及整個(gè)生命周期的自動(dòng)控制。
• 服務(wù)（Service）：由多個(gè)相同配置的實(shí)例（Pod）和訪問(wèn)這些實(shí)例（Pod）的規(guī)則組成的微服務(wù)。

• Ingress：Ingress 是用于將外部 HTTP（S）流量路由到服務(wù)（Service）的規(guī)則集合。

Kubernetes 訪問(wèn)現(xiàn)狀
 Kubernetes 的外部訪問(wèn)方式
在 Kubernetes 中，服務(wù)跟 Pod IP 主要供服務(wù)在集群內(nèi)訪問(wèn)使用，對(duì)于集群外的應(yīng)用是不可見(jiàn)的。怎么解決這個(gè)問(wèn)題呢？為了讓外部的應(yīng)用能夠訪問(wèn) Kubernetes 集群中的服務(wù)，通常解決辦法是 NodePort 和 LoadBalancer。
這兩種方案其實(shí)各自都存在一些缺點(diǎn)：

• NodePort 的缺點(diǎn)是一個(gè)端口只能掛載一個(gè) Service，而且為了更高的可用性，需要額外搭建一個(gè)負(fù)載均衡。

• LoadBalancer 的缺點(diǎn)則是每個(gè)服務(wù)都必須要有一個(gè)自己的 IP，不論是內(nèi)網(wǎng) IP 或者外網(wǎng) IP。更多情況下，為了保證 LoadBalancer 的能力，一般需要依賴于云服務(wù)商。

在Kubernetes的實(shí)踐、部署中，為了解決像 Pod 遷移、Node Pod 端口、域名動(dòng)態(tài)分配，或者是 Pod 后臺(tái)地址動(dòng)態(tài)更新這種問(wèn)題，就產(chǎn)生了 Ingress 解決方案
Nginx Ingress 的缺點(diǎn)
Ingress 是Kubernetes中非常重要的外網(wǎng)流量入口。在Kubernetes中所推薦的默認(rèn)值為Nginx Ingress，為了與后面Nginx 提供的商業(yè)版 Ingress 區(qū)分開(kāi)來(lái)，我就稱它為Kubernetes Ingress。
Kubernetes Ingress，顧名思義基于 Nginx 的平臺(tái)，Nginx 現(xiàn)在是世界上最流行的 Nginx HTTP Sever，相信大家都對(duì) Nginx 也比較熟悉，這是一個(gè)優(yōu)點(diǎn)。它還有一個(gè)優(yōu)點(diǎn)是 Nginx Ingress 接入 Kubernetes 集群所需的配置非常少，而且有很多文檔來(lái)指引你如何使用它。這對(duì)于大部分剛接觸 Kubernetes 的人或者創(chuàng)業(yè)公司來(lái)說(shuō)，Nginx Ingress 的確是一個(gè)非常好的選擇。
但是當(dāng) Nginx Ingress 在一些大環(huán)境上使用時(shí)，就會(huì)出現(xiàn)很多問(wèn)題：

• 第一個(gè)問(wèn)題：Nginx Ingress用了一些 OpenResty 的特性，但最終配置加載還是依賴于原有的 Nginx config reload。當(dāng)路由配置非常大時(shí)，Nginx reload 會(huì)耗時(shí)很久，時(shí)間長(zhǎng)達(dá)幾秒甚至十幾秒，這樣就會(huì)嚴(yán)重影響業(yè)務(wù)，甚至造成業(yè)務(wù)中斷。

• 第二個(gè)問(wèn)題：Nginx Ingress 的插件開(kāi)發(fā)非常困難。如果你認(rèn)為 Nginx Ingress 本身插件不夠用，需要使用一些定制化插件，這個(gè)額外的開(kāi)發(fā)任務(wù)對(duì)程序員來(lái)說(shuō)是十分痛苦的。因?yàn)镹ginx Ingress自身的插件能力和可擴(kuò)展性非常差。

Ingress 選型原則
既然發(fā)現(xiàn)了 Nginx Ingress 有很多問(wèn)題，那是不是考慮選擇其他開(kāi)源的、更好用的 Ingress？市場(chǎng)上比 Kubernetes Ingress 好用的Ingress起碼有十幾家，那么如何從這么多 Ingress 中選擇適合自己的呢？
Ingress 自身是基于 HTTP 網(wǎng)關(guān)的，市面上 HTTP 網(wǎng)關(guān)主要有這么幾種：Nginx、Golang 原生的網(wǎng)關(guān)，以及新崛起的 Envoy 。但是每個(gè)開(kāi)發(fā)人員所擅長(zhǎng)的技術(shù)棧不同，所以適合的 Ingress 也會(huì)不一樣。
那么問(wèn)題來(lái)了，我們?nèi)绾芜x擇一個(gè)更加好用的 Ingress 呢？或者縮小點(diǎn)范圍，熟悉 Nginx 或 OpenResty 的開(kāi)發(fā)人員，應(yīng)該選擇哪一個(gè) Ingress 呢？
下面來(lái)介紹一下我對(duì) Ingress 控制器選型的一些經(jīng)驗(yàn)。

選型原則

1.基本特點(diǎn)

首先我認(rèn)為Ingress 控制器應(yīng)該具備以下基本功能，如果連這些功能都沒(méi)有，那完全可以直接pass。

• 必須開(kāi)源的，不開(kāi)源的無(wú)法使用。
• Kubernetes 中Pod 變化非常頻繁，服務(wù)發(fā)現(xiàn)非常重要。
• 現(xiàn)在 HTTPS 已經(jīng)很普及了，TLS 或者 SSL 的能力也非常重要，比如證書(shū)管理的功能。
• 支持 WebSocket 等常見(jiàn)協(xié)議，在某些情況下，可能還需要支持 HTTP2 、QUIC 等協(xié)議。

2.基礎(chǔ)軟件

前面有提到，每個(gè)人擅長(zhǎng)的技術(shù)平臺(tái)不一樣，所以選擇自己更加熟悉的 HTTP 網(wǎng)關(guān)也顯得至關(guān)重要。比如 Nginx、HAProxy、Envoy 或者是 Golang 原生網(wǎng)關(guān)。因?yàn)槟闶煜に脑?，在使用中可以?shí)現(xiàn)快速落地。在生產(chǎn)環(huán)境上，高性能是一個(gè)很重要的特性，但比之更重要的是高可用。這意味著你選擇的網(wǎng)關(guān)，它的可用性、穩(wěn)定性一定要非常強(qiáng)，只有這樣，服務(wù)才能穩(wěn)定。

3.功能需求

拋開(kāi)上述兩點(diǎn)，就是公司業(yè)務(wù)對(duì)網(wǎng)關(guān)的特殊需求。你選擇一個(gè)開(kāi)源產(chǎn)品，最好肯定是開(kāi)箱能用的。比如你需要 GRPC 協(xié)議轉(zhuǎn)換的能力，那當(dāng)然希望選的網(wǎng)關(guān)具備這樣的功能。這里簡(jiǎn)單列一下影響選擇的因素：

• 協(xié)議：是否支持 HTTP2、HTTP3；
• 負(fù)載均衡算法：最基本的WRR、一致性哈希負(fù)載均衡算法是否能夠滿足需求，還是需要更加復(fù)雜的類似EWMA負(fù)載均衡算法。
• 鑒權(quán)限流：僅需要簡(jiǎn)單的鑒權(quán)，或更進(jìn)階的鑒權(quán)方式。又或者需要集成，能夠快速的開(kāi)發(fā)出像騰訊云 IM 的鑒權(quán)功能。Kubernetes Ingress除了前面我們提到的存在Nginx reload 耗時(shí)長(zhǎng)、插件擴(kuò)展能力差的問(wèn)題，另外它還存在后端節(jié)點(diǎn)調(diào)整權(quán)重的能力不夠靈活的問(wèn)題。

選擇 APISIX
相比Kubernetes Ingress，我個(gè)人更推薦 APISIX 作為Ingress  controller。雖然它在功能上比 Kong 會(huì)少很多，但是 APISIX 很好的路由能力、靈活的插件能力，以及本身的高性能，能夠彌補(bǔ)在 Ingress 選型上的一些缺點(diǎn)。對(duì)于基于 Nginx 或 Openresty 開(kāi)發(fā)的程序員，如果對(duì)現(xiàn)在的 Ingress 不滿意，我推薦你們?nèi)ナ褂?APISIX 作為 Ingress。
如何將 APISIX 作為 Ingress 呢？我們首先要做出一個(gè)區(qū)分，Ingress 是 Kubernetes 名稱的定義或者規(guī)則定義，Ingress controller 是將 Kubernetes 集群狀態(tài)同步到網(wǎng)關(guān)的一個(gè)組件。但 APISIX 本身只是 API 網(wǎng)關(guān)，怎么把 APISIX 實(shí)現(xiàn)成 Ingress controller 呢？我們先來(lái)簡(jiǎn)要了解一下如何實(shí)現(xiàn) Ingress。實(shí)現(xiàn) Ingress，本質(zhì)上就只有兩部分內(nèi)容：

• 第一部分：需要將 Kubernetes 集群中的配置、或 Kubernetes 集群中的狀態(tài)同步到 APISIX 集群。
• 第二部分：需要將 APISIX中 的一些概念，比如像服務(wù)、upstream 等概念定義為 Kubernetes 中的 CRD。

如果實(shí)現(xiàn)了第二部分，通過(guò) Kubernetes Ingress 的配置，便可以很快的產(chǎn)生 APISIX。通過(guò) APISIX Ingress controller 就可以產(chǎn)生 APISIX 相關(guān)的配置。當(dāng)前為了快速的將 APISIX 落地為能夠支持 Kubernetes 的 Ingress ，我們創(chuàng)建了一個(gè)開(kāi)源項(xiàng)目，叫 Ingress Controller。ingress controller 架構(gòu)圖上圖為Ingress controller 項(xiàng)目的整體架構(gòu)圖。左邊部分為 Kubernetes 集群，這里可以導(dǎo)入一些 yaml 文件，對(duì) Kubernetes 的配置進(jìn)行變更。右邊部分則是 APISIX 集群，以及它的控制面和數(shù)據(jù)面。從架構(gòu)圖中可以看出，APISIX Ingress 充當(dāng)了 Kubernetes 集群以及 APISIX 集群之間的連接者。它主要負(fù)責(zé)監(jiān)聽(tīng) Kubernetes 集群中節(jié)點(diǎn)的變化，將集群中的狀態(tài)同步到 APISIX 集群。另外，由于Kubernetes 倡導(dǎo)所有組件都要具備高可用的特性，所以在 APISIX Ingress 設(shè)計(jì)之初，我們通過(guò)雙節(jié)點(diǎn)或多節(jié)點(diǎn)的模式來(lái)保證 APISIX  Ingress Controller 的保障高可用。
總結(jié)    各類 Ingress 橫向?qū)Ρ?br/>
相對(duì)于市面上流行的 Ingress 控制器，我們簡(jiǎn)單對(duì)比來(lái)看看 APISIX ingress 有什么優(yōu)缺點(diǎn)。上圖是外國(guó)開(kāi)發(fā)人員針對(duì) Kubernetes Ingress 選型做的一張表格。我在原來(lái)表格的基礎(chǔ)上，結(jié)合自己的理解，將 APISIX Ingress 的功能加入了進(jìn)來(lái)。我們可以看到，最左邊的是APISIX，后邊就是 Kubernetes Ingress 和 Kong Ingress，后面的 Traefik，就是基于 Golang 的 Ingress。HAproxy 是比較常見(jiàn)的，過(guò)去是比較流行的負(fù)載均衡器。Istio 和 Ambassador 是國(guó)外非常流行的兩個(gè)Ingress。接下來(lái)我們總結(jié)下這些 Ingress各自的優(yōu)缺點(diǎn)：

• APISIX Ingress：APISIX Ingress 的優(yōu)點(diǎn)前面也提到了，它具有非常強(qiáng)大的路由能力、靈活的插件拓展能力，在性能上表現(xiàn)也非常優(yōu)秀。同時(shí)，它的缺點(diǎn)也非常明顯，盡管APISIX開(kāi)源后有非常多的功能，但是缺少落地案例，沒(méi)有相關(guān)的文檔指引大家如何使用這些功能。

• Kubernetes Ingress：即 Kubernetes 推薦默認(rèn)使用的 Nginx Ingress。它的主要優(yōu)點(diǎn)為簡(jiǎn)單、易接入。缺點(diǎn)是Nginx reload耗時(shí)長(zhǎng)的問(wèn)題根本無(wú)法解決。另外，雖然可用插件很多，但插件擴(kuò)展能力非常弱。

• Nginx Ingress：主要優(yōu)點(diǎn)是在于它完全支持 TCP 和 UDP 協(xié)議，但是缺失了鑒權(quán)方式、流量調(diào)度等其他功能。

• Kong：其本身就是一個(gè) API 網(wǎng)關(guān)，它也算是開(kāi)創(chuàng)了先河，將 API 網(wǎng)關(guān)引入到 Kubernetes 中當(dāng) Ingress。另外相對(duì)邊緣網(wǎng)關(guān)，Kong 在鑒權(quán)、限流、灰度部署等方面做得非常好。Kong Ingress 還有一個(gè)很大的優(yōu)點(diǎn)：提供了一些 API、服務(wù)的定義，可以抽象成 Kubernetes 的 CRD，通過(guò)K8S Ingress 配置便可完成同步狀態(tài)至 Kong 集群。缺點(diǎn)就是部署特別困難，另外在高可用方面，與 APISIX 相比也是相形見(jiàn)絀。

• Traefik ：基于 Golang 的 Ingress，它本身是一個(gè)微服務(wù)網(wǎng)關(guān)，在 Ingress 的場(chǎng)景應(yīng)用比較多。他的主要平臺(tái)基于 Golang，自身支持的協(xié)議也非常多，總體來(lái)說(shuō)是沒(méi)有什么缺點(diǎn)。如果大家熟悉 Golang 的話，也推薦一用。

• HAproxy：是一個(gè)久負(fù)盛名的負(fù)載均衡器。它主要優(yōu)點(diǎn)是具有非常強(qiáng)大的負(fù)載均衡能力，其他方面并不占優(yōu)勢(shì)。

• Istio Ingress 和 Ambassador Ingress 都是基于非常流行的 Envoy。說(shuō)實(shí)話，我認(rèn)為這兩個(gè) Ingress 沒(méi)有什么缺點(diǎn)，可能唯一的缺點(diǎn)是他們基于 Envoy 平臺(tái)，大家對(duì)這個(gè)平臺(tái)都不是很熟悉，上手門(mén)檻會(huì)比較高。

看完了這篇文章，相信你對(duì)“Kubernetes Ingress控制器的技術(shù)選型技巧有哪些”有了一定的了解，如果想了解更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，感謝各位的閱讀！

新聞標(biāo)題：KubernetesIngress控制器的技術(shù)選型技巧有哪些-創(chuàng)新互聯(lián)
文章位置：http://www.bm7419.com/article16/cdjpgg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、品牌網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、域名注冊(cè)、虛擬主機(jī)、服務(wù)器托管

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)