?

1、概述

我覺得只要大家知道kube-proxy是用來配置網(wǎng)絡(luò)規(guī)則的而不是轉(zhuǎn)發(fā)流量的，真正的流量由iptables/ipvs來轉(zhuǎn)發(fā)就可以了。

網(wǎng)絡(luò)是k8s的一個(gè)關(guān)鍵部分。理解k8s中網(wǎng)絡(luò)組件如何工作可以幫助更好的設(shè)計(jì)和配置我們的應(yīng)用。

kube-proxy就是K8s網(wǎng)絡(luò)的核心組件。它把我們應(yīng)用使用的service翻譯為網(wǎng)絡(luò)規(guī)則。

kube-proxy這個(gè)名氣會(huì)有讓人產(chǎn)生一點(diǎn)歧義，因?yàn)橛屑夹g(shù)背景的朋友們看到后不了解之前就會(huì)想到用戶的流量是先經(jīng)過kube-proxy，然后kube-proxy轉(zhuǎn)發(fā)到集群的，其實(shí)并不是這樣的。kube-proxy只負(fù)責(zé)網(wǎng)絡(luò)規(guī)則的創(chuàng)建，修改和刪除，真正的流量還是依賴于Linux/Windows來接受和轉(zhuǎn)發(fā)。如果從這個(gè)角度來理解，kube-proxy在Linux環(huán)境上主要控制和配置iptables或ipvs, 在windows則控制和配置kernelspec。 從這個(gè)角度來看kube-proxy像是一個(gè)控制平面，iptables/ipvs/kernelspec像是一個(gè)數(shù)據(jù)平面。

正因?yàn)閗ube-proxy不處理用戶流量，所以k8s的性能不會(huì)有什么問題，反觀Istio使用邊車模式(sidecar)，對(duì)流量進(jìn)行管理才會(huì)導(dǎo)致性能問題。

在開始說明kube-proxy之前，我們可以想一下kube-proxy主要想解決哪些問題。

2.kube-proxy需要解決哪些問題？

1. 服務(wù)發(fā)現(xiàn)，給Pod提供一個(gè)統(tǒng)一的入口來訪問服務(wù)
2. 負(fù)載均衡：這里主要是kube-proxy把Pod的路由信息寫到iptables或者ipvs，讓內(nèi)核對(duì)根據(jù)支持的負(fù)載均衡算法進(jìn)行流量轉(zhuǎn)發(fā)

另外，我想額外說明的是kube-proxy時(shí)刻都要監(jiān)聽Api Server（kube-proxy的老板）發(fā)送過來的Pod的CUD（創(chuàng)建，更新和刪除）信息，有變更就改規(guī)則。

3.什么是kube-proxy

k8s中的Pod是臨時(shí)的，因?yàn)镻od中運(yùn)行的是我們的應(yīng)用，我們的應(yīng)用可能隨時(shí)會(huì)崩潰，崩潰了以后k8s會(huì)為我們重新創(chuàng)建，我們不能用Pod的IP通信，因?yàn)镻od每次崩潰重啟IP會(huì)變更，而且Pod的數(shù)量也會(huì)改變。

?

所以K8s就增加了Service來提供Pod統(tǒng)一的入口。Service提供了連接一個(gè)或者多個(gè)的Pod靜態(tài)地址。我們可以這么理解：進(jìn)入k8s集群的流量先到達(dá)Service，然后流量被重定向到Pod，同時(shí)Service保證流量不轉(zhuǎn)發(fā)到不健康的Pod。這個(gè)保證會(huì)在一個(gè)短的時(shí)間無法保證，就是Pod從進(jìn)入不健康狀態(tài)到被檢測(cè)出不健康的這個(gè)時(shí)間區(qū)間。

但是在網(wǎng)絡(luò)層如何實(shí)現(xiàn)Service到Pod的映射？kube-proxy就是干這事的。

kube-proxy會(huì)被安裝在每個(gè)k8s的Node之上。它用來監(jiān)控Service和Endpoint的變化。然后他會(huì)將這些變化轉(zhuǎn)換為自己Node上的網(wǎng)絡(luò)規(guī)則。

kube-proxy是以DaemonSet的形式運(yùn)行在k8s集群中的。但是它也可以以進(jìn)程的方式安裝在Linux系統(tǒng)之中。安裝方式可以參考官網(wǎng)自己選擇。

1. kubeadmin安裝k8s，kube-proxy會(huì)被安裝位DaemonSet
2. 使用Linux tar方式安裝，kube-proxy會(huì)以Linux進(jìn)程方式運(yùn)行

4.kube-proxy工作原理

在kube-proxy安裝完成后，它會(huì)與API Server完成認(rèn)證。
當(dāng)新的Service或者EndPoint被添加或者移除，那么API Server會(huì)將這些變更通知給kube-proxy。

kube-proxy在收到通知后會(huì)將這些變化應(yīng)用于Node的NAT規(guī)則中。這些NAT規(guī)則就是簡(jiǎn)單的件Service IP映射到Pod IP。

當(dāng)有流量發(fā)送給Service時(shí)，Service會(huì)基于NAT的這些規(guī)則將流量轉(zhuǎn)發(fā)給Pod。

我們來看幾個(gè)例子。
假設(shè)我們有一個(gè)Service，這個(gè)Service名字為SVC01，類型為ClusterIP。當(dāng)這個(gè)Service創(chuàng)建完成后，API Server會(huì)檢查需要關(guān)聯(lián)到這個(gè)Service的Pod。我們一般是通過在Service中配置Pod的標(biāo)簽來選擇一組Pod,所以API Server會(huì)查找與Service中標(biāo)簽匹配的Pod。

假設(shè)API Server查找到的Pod為Pod01和Pod02，其中Pod1在Node1，Pod2在Node2。API Server會(huì)創(chuàng)建一個(gè)抽象的Endpoint。每個(gè)EndPoint。每個(gè)EndPoint代表了一個(gè)Pod的IP地址。SVC01可以綁定到這兩個(gè)Pod對(duì)應(yīng)的Endpoint。假設(shè)這兩個(gè)EndPoint為EP01和EP02。

?

這些配置在Control Plane完成后，k8s還在將這些Mapping關(guān)系體現(xiàn)在Node上。一旦這些配置在Node上配置完成后，SVC01 Servvice的流量就會(huì)被轉(zhuǎn)發(fā)到EP01和EP02,如下圖所示：

在這種情況下，如果有流量進(jìn)入SVC01，則流量轉(zhuǎn)發(fā)如下圖：

Service和EndPoint映射說明：

1. Service和EndPoint是IP和端口的映射而不只是IP的映射
2. DNAT轉(zhuǎn)換發(fā)生在源Node。因?yàn)镾ervice類型是ClusterIP，只能從集群內(nèi)部進(jìn)行訪問
3. 如果Service類型是其他方式，比如：NodePort，這些規(guī)則會(huì)被應(yīng)用到Linux。
4. NAT規(guī)則會(huì)隨機(jī)選擇其中一個(gè)Pod進(jìn)行流量轉(zhuǎn)發(fā)，但是這個(gè)會(huì)根據(jù)kube-proxy的模式而改變

下面我們來看下kube-proxy的模式。

5.kube-proxy模式

kube-proxy支持不同的網(wǎng)絡(luò)轉(zhuǎn)發(fā)模式。每種模式用來描述Kube-proxy如何來實(shí)現(xiàn)NAT規(guī)則。想要知道每種模式的好壞，我們需要理解每種模式的工作原理。

5.1.IPtables 模式

IPTables是最通用和最常用的模式。在這個(gè)種模式下，kube-proxy依賴于Linux的IPTables的功能特性。Iptable用來處理數(shù)據(jù)和過濾數(shù)據(jù)包。它會(huì)檢查Linux機(jī)器上的入站和出站流量，然后IPtable可以根據(jù)規(guī)則來匹配數(shù)據(jù)包并將其轉(zhuǎn)發(fā)。
當(dāng)k8s使用這種模式時(shí)，kube-proxy會(huì)將Service到Pod的NAT規(guī)則寫入到IPTables中。IPTables根據(jù)kube-proxy寫入到這些規(guī)則將流量重定向到對(duì)應(yīng)的Pod。

5.1.1.IPTables劣勢(shì)

IPTables劣勢(shì)就是在大規(guī)模集群下性能低。
使用IPTables模式的不好之處就是它的規(guī)則是鏈?zhǔn)降?#xff0c;因?yàn)镮PTables的設(shè)計(jì)目的是為了數(shù)據(jù)包的過濾組件。那么IPTables在處理大量規(guī)則時(shí)性能就會(huì)很低，因?yàn)殒準(zhǔn)讲檎宜俣嚷Ｋ赃x擇這種模式時(shí)你需要考慮你的k8s集群Service和Pod的數(shù)量，如果數(shù)量太大的話就考慮選擇其他模式了。

另外，IPTables不支持一些特定的負(fù)載均衡算法，只支持簡(jiǎn)單輪詢方式來實(shí)現(xiàn)負(fù)載均衡。

5.2.IPVS 模式

IPVS (IP Virtual Server)是一種高效的Layer-4交換機(jī)，實(shí)現(xiàn)了運(yùn)行在LVS下的提供負(fù)載平衡功能的技術(shù)。IPVS基本上是一種高效的Layer-4交換機(jī)，它提供負(fù)載平衡的功能。這個(gè)是k8s kube-proxy的一個(gè)較好的選擇。在IPVS模式下，kube-proxy將轉(zhuǎn)發(fā)規(guī)則寫入到IPVS中。

由于IPVS是一個(gè)專門用于交換的模塊，所以它的查找算法最小可以在O(1)時(shí)間復(fù)雜度完成，所以它在大規(guī)模集群下能夠表現(xiàn)出很好且很穩(wěn)定的性能。

IPVS模式也支持很多負(fù)載均衡算法，比如：輪詢，最小連接和其他哈希算法。

5.2.1.劣勢(shì)

IPVS模塊不一定默認(rèn)安裝在Linux系統(tǒng)中，你可能需要手動(dòng)安裝或啟用它。并且如果不是大規(guī)模集群，IPTables就可以滿足你的場(chǎng)景。

IPVS和Iptable對(duì)比

tigera公司提供的數(shù)據(jù)，就是開源Colico網(wǎng)絡(luò)組件的那個(gè)公司。

1. 服務(wù)數(shù)量與平均響應(yīng)時(shí)間

   

2. 服務(wù)數(shù)量與CPU占用

   

如何iptables和ipvs如何選擇？

上面的兩個(gè)圖表表示：在1000個(gè)Pod時(shí)ipvs和iptables性能沒有什么差別，超過1000個(gè)ipvs模式性能更高。

另外，如果你不確定使用哪個(gè)，你就選擇ipvs吧。

5.3.KernelSpace 模式

這個(gè)模式時(shí)Windows節(jié)點(diǎn)專用的。在這個(gè)模式下，kube-proxy會(huì)將包過濾規(guī)則寫入到windows的VFP(Windows Virtual Filtering Platform)。Windows上的VFP的工作原理和Linux的IPTables一樣，這就意味著VFP會(huì)將數(shù)據(jù)包中的目的IP地址替換為Pod的IP地址。

如果你不熟悉Windows平臺(tái)的虛擬機(jī)，那么你可以認(rèn)為VFP是Hyper-V的一個(gè)擴(kuò)展，這個(gè)擴(kuò)展專門用于虛擬機(jī)網(wǎng)絡(luò)。

5.4.如果檢查kube-proxy的模式？

你可以通過接口查詢kube-proxy的模式，kube-proxy默認(rèn)端口為10249.

你可以使用/proxyMode?來查詢kube-proxy模式，

curl -v localhost:10249/proxyMode

COPY

?

上圖展示了這個(gè)kube-proxy使用了ipvs模式。

5.5.IPVS規(guī)則查看

IPVS可以通過ipvsadm命令進(jìn)行查看，可能需要先安裝

sudo apt install ipvsadm
sudo ipvsadm -L

COPY

?

5.6.IPTables規(guī)則查看

使用iptables命令查看nat規(guī)則列表

iptables -t nat -n -L

COPY

?

6.FAQ

6.1.k8s Service是一個(gè)代理嗎 ?

k8s service使用起來像是一個(gè)代理，它為客戶端提供了一個(gè)靜態(tài)接入點(diǎn)。

6.2.kube-proxy會(huì)進(jìn)行負(fù)載均衡嗎 ?

這個(gè)視情況而定。
如果你說的是的kube-proxy這個(gè)k8s的網(wǎng)絡(luò)agent，那么kube-proxy不會(huì)進(jìn)行負(fù)載均衡。因?yàn)閗ube-proxy并不接收流量進(jìn)行轉(zhuǎn)發(fā)，而是依賴于OS提供的能力。

如果你說的是kube-proxy創(chuàng)建的規(guī)則，那么會(huì)。因?yàn)閗ube-proxy會(huì)創(chuàng)建對(duì)多個(gè)Pod創(chuàng)建具有負(fù)載均衡能力的Service，這個(gè)依賴于iptables/ipvs/kernelspec。

7.總結(jié)

kube-proxy是k8s的網(wǎng)絡(luò)代理，它主要將Service的定義轉(zhuǎn)換為網(wǎng)絡(luò)規(guī)則。它在集群中的每個(gè)Node上運(yùn)行，并與API Server通信以接收Service的更新，然后將這些更新同步到自己的Node中。

kube-proxy并不會(huì)直接接收流量并將其轉(zhuǎn)發(fā)，而是依賴于OS提供的相關(guān)能力來完成。

8.參考

k8s kube-proxy – FOF編程網(wǎng)

?

?