今天就跟大家聊聊有關(guān)TKE基于彈性網(wǎng)卡直連Pod的網(wǎng)絡(luò)負(fù)載均衡是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)于2013年開(kāi)始，是專(zhuān)業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元玉屏做網(wǎng)站,已為上家服務(wù),為玉屏各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:13518219792

前言

Kubernetes在集群接入層設(shè)計(jì)并提供了兩種原生資源Service和Ingress，分別負(fù)責(zé)四層和七層的網(wǎng)絡(luò)接入層配置。

傳統(tǒng)的做法是創(chuàng)建Ingress或LoadBalancer類(lèi)型的Service來(lái)綁定騰訊云的負(fù)載均衡將服務(wù)對(duì)外暴露。這種做法將用戶流量負(fù)載到用戶節(jié)點(diǎn)的NodePort上，通過(guò)KubeProxy組件轉(zhuǎn)發(fā)到容器網(wǎng)絡(luò)中，但這種方案在業(yè)務(wù)的性能和能力支持會(huì)有所局限。

為了解決這個(gè)問(wèn)題，TKE容器團(tuán)隊(duì)為在騰訊云上使用獨(dú)立或托管集群的用戶提供了一種新的網(wǎng)絡(luò)模式，利用彈性網(wǎng)卡直連Pod的方案很大的增強(qiáng)了性能和業(yè)務(wù)能力的支持。

本文將會(huì)從傳統(tǒng)的模式的問(wèn)題入手，比較新舊模式的區(qū)別，并在最后提供新直連模式的使用指引。

傳統(tǒng)模式面臨的問(wèn)題與挑戰(zhàn)

性能與特性

KubeProxy在集群中會(huì)將用戶NodePort的流量通過(guò)NAT的方式轉(zhuǎn)發(fā)到集群網(wǎng)絡(luò)中。這個(gè)NAT轉(zhuǎn)發(fā)帶來(lái)了以下一些問(wèn)題。

1. NAT轉(zhuǎn)發(fā)導(dǎo)致請(qǐng)求在性能上有一定的損失。

1. 進(jìn)行NAT操作本身會(huì)帶來(lái)性能上的損失。

2. NAT轉(zhuǎn)發(fā)的目的地址可能會(huì)使得流量在容器網(wǎng)絡(luò)內(nèi)跨節(jié)點(diǎn)轉(zhuǎn)發(fā)。

3. NAT轉(zhuǎn)發(fā)導(dǎo)致請(qǐng)求的來(lái)源IP被修改了，客戶端無(wú)法獲取來(lái)源IP。

4. 當(dāng)負(fù)載均衡的流量集中到幾個(gè)NodePort時(shí)。過(guò)于集中的流量會(huì)導(dǎo)致NodePort的SNAT轉(zhuǎn)發(fā)過(guò)多，使得源端口耗盡流量異常。還可能導(dǎo)致 conntrack 插入沖突導(dǎo)致丟包，影響性能。

5. KubeProxy的轉(zhuǎn)發(fā)具有隨機(jī)性，無(wú)法支持會(huì)話保持。

6. KubeProxy的每個(gè)NodePort其實(shí)也起到獨(dú)立的負(fù)載均衡作用，由于負(fù)載均衡無(wú)法收斂到一個(gè)地方，所以難以達(dá)到全局的負(fù)載均衡。

為了解決以上問(wèn)題，我們以前給用戶提供的技術(shù)建議主要是通過(guò)Local轉(zhuǎn)發(fā)的方式，避免KubeProxyNAT轉(zhuǎn)發(fā)帶來(lái)的問(wèn)題。但是因?yàn)檗D(zhuǎn)發(fā)的隨機(jī)性，一個(gè)節(jié)點(diǎn)上部署多個(gè)副本時(shí)會(huì)話保持依舊無(wú)法支持。而且Local轉(zhuǎn)發(fā)在滾動(dòng)更新時(shí)，容易出現(xiàn)服務(wù)的閃斷，對(duì)業(yè)務(wù)的滾動(dòng)更新策略以及優(yōu)雅停機(jī)提出了更高的要求。我們有理由去尋找更好的方案解決這個(gè)問(wèn)題。

業(yè)務(wù)可用性

通過(guò)NodePort接入服務(wù)時(shí)，NodePort的設(shè)計(jì)存在極大的容錯(cuò)性。負(fù)載均衡會(huì)綁定集群所有節(jié)點(diǎn)的NodePort作為后端。集群任意一個(gè)節(jié)點(diǎn)的訪問(wèn)服務(wù)時(shí)，流量將隨機(jī)分配到集群的工作負(fù)載中。這就意味著部分NodePort的不可用，或者是Pod的不可用都不會(huì)影響服務(wù)的流量接入。

和Local訪問(wèn)一樣，直接將負(fù)載均衡后端連接到用戶Pod的情況下，當(dāng)業(yè)務(wù)在滾動(dòng)更新時(shí)，如果負(fù)載均衡不能夠及時(shí)綁定上新的Pod，業(yè)務(wù)的快速滾動(dòng)可能導(dǎo)致業(yè)務(wù)入口的負(fù)載均衡后端數(shù)量嚴(yán)重不足甚至被清空。因此，業(yè)務(wù)滾動(dòng)更新的時(shí)候，接入層的負(fù)載均衡的狀態(tài)良好，方能保證滾動(dòng)更新的安全平穩(wěn)。

負(fù)載均衡的控制面性能

負(fù)載均衡的控制面接口。包括創(chuàng)建刪除修改四層、七層監(jiān)聽(tīng)器，創(chuàng)建刪除七層規(guī)則，綁定各個(gè)監(jiān)聽(tīng)器或者規(guī)則的后端。這些接口大部分是異步接口，需要輪詢請(qǐng)求結(jié)果，接口的調(diào)用時(shí)間相對(duì)較長(zhǎng)。當(dāng)用戶集群規(guī)模較大時(shí)，大量的接入層資源同步會(huì)導(dǎo)致組件存在很大的時(shí)延上的壓力。

新舊模式對(duì)比

性能對(duì)比

Pod直連模式已經(jīng)在騰訊TKE上線，是對(duì)負(fù)載均衡的控制面優(yōu)化。針對(duì)整個(gè)同步流程，重點(diǎn)優(yōu)化了批量調(diào)用和后端實(shí)例查詢兩個(gè)遠(yuǎn)程調(diào)用比較頻繁的地方。**優(yōu)化完成后，Ingress典型場(chǎng)景下的控制面性能較優(yōu)化前版本有了95%-97%左右的性能提升。**目前同步的耗時(shí)主要集中在異步接口的等待上。

后端節(jié)點(diǎn)突增 (應(yīng)對(duì)集群擴(kuò)容的場(chǎng)景)

七層規(guī)則突增（應(yīng)對(duì)業(yè)務(wù)第一次上線部署到集群的場(chǎng)景）

除去控制面性能優(yōu)化這樣的硬核優(yōu)化，負(fù)載均衡能夠直接訪問(wèn)容器網(wǎng)絡(luò)的Pod就是組件業(yè)務(wù)能力最重要的組成部分了，其不僅避免了NAT轉(zhuǎn)發(fā)性能上的損失，同時(shí)避免了NAT轉(zhuǎn)發(fā)帶來(lái)的各種對(duì)集群內(nèi)業(yè)務(wù)功能影響。但是在啟動(dòng)該項(xiàng)目時(shí)這一塊還沒(méi)有特別好的訪問(wèn)容器網(wǎng)絡(luò)的支持。所以一期考慮集群CNI網(wǎng)絡(luò)模式下Pod有彈性網(wǎng)卡入口，這個(gè)入口可以直接接入到負(fù)載均衡以達(dá)到直接訪問(wèn)的目的。負(fù)載均衡直接后端訪問(wèn)到容器網(wǎng)絡(luò)，目前已經(jīng)有通過(guò)云聯(lián)網(wǎng)解決的方案，后續(xù)也會(huì)繼續(xù)跟進(jìn)這種更貼近集群網(wǎng)絡(luò)的直連方案。

接下來(lái)能夠直接訪問(wèn)了，如何保證滾動(dòng)更新時(shí)的可用性保證呢？我們找到了官方提供的一個(gè)特性ReadinessGate。這個(gè)特性在1.12正式提供出來(lái)，主要是用來(lái)控制Pod的狀態(tài)。默認(rèn)情況下，Pod有以下Condition：PodScheduled、Initialized、ContainersReady，當(dāng)這幾個(gè)狀態(tài)都Ready的時(shí)候，Pod Ready的Condition就通過(guò)了。但是在云原生的場(chǎng)景下面，Pod的狀態(tài)是非常有可能需要參考其他狀態(tài)的。ReadinessGate提供了這樣一個(gè)機(jī)制，允許為Pod的狀態(tài)判斷添加一個(gè)柵欄，由第三方來(lái)進(jìn)行判斷與控制。這樣Pod的狀態(tài)就和第三方關(guān)聯(lián)起來(lái)了。

負(fù)載均衡流量對(duì)比

傳統(tǒng)NodePort模式

請(qǐng)求細(xì)節(jié)過(guò)程

1. 請(qǐng)求流量進(jìn)入負(fù)載均衡

2. 請(qǐng)求被負(fù)載均衡轉(zhuǎn)發(fā)到某一個(gè)節(jié)點(diǎn)的NodePort

3. KubeProxy將來(lái)自NodePort的流量進(jìn)行NAT轉(zhuǎn)發(fā)，目的地址是隨機(jī)的一個(gè)Pod。

4. 請(qǐng)求進(jìn)入容器網(wǎng)絡(luò)，并根據(jù)Pod地址轉(zhuǎn)發(fā)到對(duì)應(yīng)節(jié)點(diǎn)。

5. 請(qǐng)求來(lái)到Pod所屬節(jié)點(diǎn)，轉(zhuǎn)發(fā)到Pod。

新的Pod直連模式

請(qǐng)求細(xì)節(jié)過(guò)程

1. 請(qǐng)求流量進(jìn)入負(fù)載均衡

2. 請(qǐng)求被負(fù)載均衡轉(zhuǎn)發(fā)到某一個(gè)Pod的ENI彈性網(wǎng)卡

直連與Local訪問(wèn)的區(qū)別

看起來(lái)這兩種訪問(wèn)方式的效果是一樣的，但是在細(xì)節(jié)上還是存在一些差別。

1. 從性能上區(qū)別不大，開(kāi)啟Local訪問(wèn)時(shí)，流量不會(huì)進(jìn)行NAT操作也不會(huì)進(jìn)行跨節(jié)點(diǎn)轉(zhuǎn)發(fā)，所以僅僅多了一個(gè)到容器網(wǎng)絡(luò)的路由。

2. 沒(méi)有進(jìn)行NAT操作，來(lái)源IP就能夠正確獲取了。會(huì)話保持功能可能會(huì)有以下問(wèn)題，當(dāng)一個(gè)節(jié)點(diǎn)上存在多個(gè)Pod時(shí)，流量到哪一個(gè)Pod是隨機(jī)的，這個(gè)機(jī)制可能會(huì)使話保持出現(xiàn)問(wèn)題。

ReadinessGate的引入

前面有兩個(gè)細(xì)節(jié)，可以在這里得到解答。

1. 為什么要求集群版本高于 1.12

2. 為什么kubectl get pod -o wide的結(jié)果中READINESS GATES列有內(nèi)容。

這里涉及到一個(gè)滾動(dòng)更新相關(guān)的問(wèn)題當(dāng)用戶開(kāi)始為應(yīng)用做滾動(dòng)更新的時(shí)候，Kubernetes會(huì)根據(jù)更新策略進(jìn)行滾動(dòng)更新。但是其判斷一批Pod啟動(dòng)的標(biāo)識(shí)僅包括Pod自身的狀態(tài)，并不會(huì)考慮這個(gè)Pod在負(fù)載均衡上是否已經(jīng)進(jìn)行配置健康檢查是否通過(guò)。有的時(shí)候當(dāng)接入層組件高負(fù)載，不能及時(shí)對(duì)這些Pod進(jìn)行及時(shí)調(diào)度的話，這些滾動(dòng)更新成功的Pod可能并沒(méi)有正在對(duì)外提供服務(wù)，從而導(dǎo)致服務(wù)的中斷。為了將滾動(dòng)更新和負(fù)載均衡的后端狀態(tài)關(guān)聯(lián)起來(lái)，TKE接入層組件引入了Kubernetes 1.12中引入的新特性ReadinessGate。TKE接入層組件只有在確認(rèn)后端綁定成功并且健康檢查通過(guò)時(shí)，通過(guò)配置ReadinessGate的狀態(tài)來(lái)使Pod達(dá)到Ready的狀態(tài)，從而推動(dòng)整個(gè)工作負(fù)載的滾動(dòng)更新。

在集群中使用ReadinessGate的細(xì)節(jié)Kubernetes集群提供的是一個(gè)服務(wù)注冊(cè)的機(jī)制，你只需要將你的服務(wù)以MutatingWebhookConfigurations資源的形式注冊(cè)到集群中就可以了。集群會(huì)在Pod創(chuàng)建的時(shí)候按照你的配置的回調(diào)路徑通知你，這個(gè)時(shí)候就可以對(duì)Pod做一些創(chuàng)建前的操作，在這個(gè)Case里面就是給Pod加上ReadinessGate。唯一需要注意的就是這個(gè)回調(diào)過(guò)程必須是Https的，所以標(biāo)配需要在MutatingWebhookConfigurations中配置簽發(fā)請(qǐng)求的CA，并在服務(wù)端配置該CA簽發(fā)的證書(shū)。

ReadinessGate機(jī)制的災(zāi)難恢復(fù)用戶集群中的服務(wù)注冊(cè)或是證書(shū)有可能被用戶刪除，雖然這些系統(tǒng)組件資源不應(yīng)該被用戶修改或破壞。但在用戶對(duì)集群的探索或是誤操作下，這類(lèi)問(wèn)題會(huì)不可避免的出現(xiàn)。所以接入層組件在啟動(dòng)時(shí)會(huì)檢查以上資源的完整性，在完整性受到破壞時(shí)會(huì)重建以上資源，加強(qiáng)系統(tǒng)的魯棒性。

QPS和網(wǎng)絡(luò)時(shí)延對(duì)比

直連與NodePort是服務(wù)應(yīng)用的接入層方案，其實(shí)最終參與工作的還是用戶部署的工作負(fù)載，用戶工作負(fù)載的能力直接決定了業(yè)務(wù)的QPS等指標(biāo)。所以我們針對(duì)這兩種接入層方案，在工作負(fù)載壓力較低的情況下，重點(diǎn)針對(duì)網(wǎng)絡(luò)鏈路的時(shí)延進(jìn)行了一些對(duì)比測(cè)試。直連在接入層的網(wǎng)絡(luò)鏈路上能夠優(yōu)化10%左右的時(shí)間。同時(shí)測(cè)試中的監(jiān)控也發(fā)現(xiàn)，直連模式減少了大量VPC網(wǎng)絡(luò)內(nèi)的流量。測(cè)試場(chǎng)景，從20節(jié)點(diǎn)到80節(jié)點(diǎn)，逐步增大集群規(guī)模，通過(guò)wrk工具對(duì)集群進(jìn)行網(wǎng)絡(luò)延時(shí)的測(cè)試。針對(duì)QPS和網(wǎng)絡(luò)時(shí)延，下圖給出了直連場(chǎng)景與NodePort的對(duì)比測(cè)試。

KubeProxy的一些設(shè)計(jì)思考

KubeProxy的缺點(diǎn)也在前文中提到的一樣明顯。但是基于云上負(fù)載均衡、VPC網(wǎng)絡(luò)的各種特性，我們能給出各種其他更加本地化的接入層方案。但這并不意味著KubeProxy的設(shè)計(jì)不好或是作用不大。其對(duì)集群接入層的設(shè)計(jì)極具普適性、容錯(cuò)性，基本適用于所有業(yè)務(wù)場(chǎng)景下的集群，作為一個(gè)官方提供的組件這個(gè)設(shè)計(jì)是非常合適的。

新模式使用指引

前置要求

1. Kubernetes集群版本需要高于 1.12。

2. 集群網(wǎng)絡(luò)模式必須開(kāi)啟VPC-CNI彈性網(wǎng)卡模式。

3. 直連模式Service使用的工作負(fù)載需使用VPC-CNI彈性網(wǎng)卡模式。

控制臺(tái)操作指引

1. 登錄 容器服務(wù)控制臺(tái)。

2. 參考控制臺(tái) 創(chuàng)建 Service 步驟，進(jìn)入 “新建Service” 頁(yè)面，根據(jù)實(shí)際需求設(shè)置 Service 參數(shù)。

   其中，部分關(guān)鍵參數(shù)信息需進(jìn)行如下設(shè)置，如下圖所示：

   

• 服務(wù)訪問(wèn)方式：選擇為【提供公網(wǎng)訪問(wèn)】或【VPC內(nèi)網(wǎng)訪問(wèn)】。

• 網(wǎng)絡(luò)模式：勾選【采用負(fù)載均衡直連Pod模式】。

• Workload綁定：選擇【引用Worklocad】，并在彈出窗口中選擇 VPC-CNI 模式的后端工作負(fù)載。

3. 單擊【創(chuàng)建服務(wù)】，完成創(chuàng)建。

Kubectl操作指引

• Workload示例：nginx-deployment-eni.yaml

  注意spec.template.metadata.annotations中聲明了tke.cloud.tencent.com/networks: tke-route-eni，在工作負(fù)載使用VPC-CNI彈性網(wǎng)卡模式。

apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-deployment-eni spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: annotations: tke.cloud.tencent.com/networks: tke-route-eni labels: app: nginx spec: containers: - image: nginx:1.7.9 name: nginx ports: - containerPort: 80 protocol: TCP

- Service示例：nginx-service-eni.yaml

> 注意：`metadata.annotations`中聲明了`service.cloud.tencent.com/direct-access: "true"`，Service在同步負(fù)載均衡時(shí)將采用直連的方式配置訪問(wèn)后端。

 ```yaml
apiVersion: v1
kind: Service
metadata:
annotations:
 service.cloud.tencent.com/direct-access: "true"
labels:
 app: nginx
name: nginx-service-eni
spec:
externalTrafficPolicy: Cluster
ports:
 - name: 80-80-no
   port: 80
   protocol: TCP
   targetPort: 80
selector:
 app: nginx
sessionAffinity: None
type: LoadBalancer
 ```

- 部署以上內(nèi)容到集群

> 注意：在你的環(huán)境你首先需要連接到集群（沒(méi)有集群的需要先創(chuàng)建集群），可以參考文章尾部的幫助文檔配置kubectl連接集群。

 ```shell
?  ~ kubectl apply -f nginx-deployment-eni.yaml
deployment.apps/nginx-deployment-eni created

?  ~ kubectl apply -f nginx-service-eni.yaml
service/nginx-service-eni configured

?  ~ kubectl get pod -o wide
NAME                                   READY   STATUS    RESTARTS   AGE   IP               NODE          NOMINATED NODE   READINESS GATES
nginx-deployment-eni-bb7544db8-6ljkm   1/1     Running   0          24s   172.17.160.191   172.17.0.3    <none>           1/1
nginx-deployment-eni-bb7544db8-xqqtv   1/1     Running   0          24s   172.17.160.190   172.17.0.46   <none>           1/1
nginx-deployment-eni-bb7544db8-zk2cx   1/1     Running   0          24s   172.17.160.189   172.17.0.9    <none>           1/1
?  ~ kubectl get service -o wide
NAME                TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE    SELECTOR
kubernetes          ClusterIP      10.187.252.1    <none>           443/TCP        6d4h   <none>
nginx-service-eni   LoadBalancer   10.187.254.62   150.158.221.31   80:32693/TCP   6d1h   app=nginx
 ```

看完上述內(nèi)容，你們對(duì)TKE基于彈性網(wǎng)卡直連Pod的網(wǎng)絡(luò)負(fù)載均衡是怎樣的有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

名稱(chēng)欄目：TKE基于彈性網(wǎng)卡直連Pod的網(wǎng)絡(luò)負(fù)載均衡是怎樣的
文章出自：http://aaarwkj.com/article22/ihhjcc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、微信小程序、品牌網(wǎng)站制作、外貿(mào)網(wǎng)站建設(shè)、全網(wǎng)營(yíng)銷(xiāo)推廣、服務(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)