以我的經(jīng)驗來講，理解Kubernetes集群服務(wù)的概念，是比較不容易的一件事情。尤其是當我們基于似是而非的理解，去排查服務(wù)相關(guān)問題的時候，會非常不順利。

這體現(xiàn)在，對于新手來說，ping不通服務(wù)的IP地址這樣基礎(chǔ)的問題，都很難理解;而就算對經(jīng)驗很豐富的工程師來說，看懂服務(wù)相關(guān)的iptables配置，也是有相當?shù)奶魬?zhàn)的。

今天這篇文章，我來深入解釋一下Kubernetes集群服務(wù)的原理與實現(xiàn)，便于大家理解。

Kubernetes集群服務(wù)的本質(zhì)是什么

概念上來講，Kubernetes集群的服務(wù)，其實就是負載均衡、或反向代理。這跟阿里云的負載均衡產(chǎn)品，有很多類似的地方。和負載均衡一樣，服務(wù)有它的IP地址以及前端端口;服務(wù)后邊會掛載多個容器組Pod作為其“后端服務(wù)器”，這些“后端服務(wù)器”有自己的IP以及監(jiān)聽端口。

當這樣的負載均衡和后端的架構(gòu)，與Kubernetes集群結(jié)合的時候，我們可以想到的最直觀的實現(xiàn)方式，就是集群中某一個節(jié)點專門做負載均衡(類似LVS)的角色，而其他節(jié)點則用來負載后端容器組。

這樣的實現(xiàn)方法，有一個巨大的缺陷，就是單點問題。Kubernetes集群是Google多年來自動化運維實踐的結(jié)晶，這樣的實現(xiàn)顯然與其智能運維的哲學相背離的。

自帶通信員

邊車模式(Sidecar)是微服務(wù)領(lǐng)域的核心概念。邊車模式，換一句通俗一點的說法，就是自帶通信員。熟悉服務(wù)網(wǎng)格的同學肯定對這個很熟悉了。但是可能比較少人注意到，其實Kubernetes集群原始服務(wù)的實現(xiàn)，也是基于Sidecar模式的。

在Kubernetes集群中，服務(wù)的實現(xiàn)，實際上是為每一個集群節(jié)點上，部署了一個反向代理Sidecar。而所有對集群服務(wù)的訪問，都會被節(jié)點上的反向代理轉(zhuǎn)換成對服務(wù)后端容器組的訪問?；旧蟻碚f，節(jié)點和這些Sidecar的關(guān)系如下圖所示。

把服務(wù)照進現(xiàn)實

前邊兩節(jié)，我們看到了，Kubernetes集群的服務(wù)，本質(zhì)上是負載均衡，即反向代理;同時我們知道了，在實際實現(xiàn)中，這個反向代理，并不是部署在集群某一個節(jié)點上，而是作為集群節(jié)點的邊車，部署在每個節(jié)點上的。

在這里把服務(wù)照進反向代理這個現(xiàn)實的，是Kubernetes集群的一個控制器，即kube-proxy。關(guān)于Kubernetes集群控制器的原理，請參考我另外一篇關(guān)于控制器的文章。簡單來說，kube-proxy作為部署在集群節(jié)點上的控制器，它們通過集群API Server監(jiān)聽著集群狀態(tài)變化。當有新的服務(wù)被創(chuàng)建的時候，kube-proxy則會把集群服務(wù)的狀態(tài)、屬性，翻譯成反向代理的配置。

那剩下的問題，就是反向代理，即上圖中Proxy的實現(xiàn)。

一種實現(xiàn)

Kubernetes集群節(jié)點實現(xiàn)服務(wù)反向代理的方法，目前主要有三種，即userspace、iptables以及IPVS。今天我們只深入分析iptables的方式，底層網(wǎng)絡(luò)基于阿里云Flannel集群網(wǎng)絡(luò)。

過濾器框架

現(xiàn)在，我們來設(shè)想一種場景。我們有一個屋子。這個屋子有一個入水管和出水管。從入水管進入的水，是不能直接飲用的，因為有雜質(zhì)。而我們期望，從出水管流出的水，可以直接飲用。為了達到目的，我們切開水管，在中間加一個雜質(zhì)過濾器。

過了幾天，我們的需求變了，我們不止要求從屋子里流出來的水可以直接飲用，我們還希望水是熱水。所以我們不得不再在水管上增加一個切口，然后增加一個加熱器。

很明顯，這種切開水管，增加新功能的方式是很丑陋的。因為需求可能隨時會變，我們甚至很難保證，在經(jīng)過一年半載之后，這跟水管還能找得到可以被切開的地方。

所以我們需要重新設(shè)計。首先我們不能隨

便切開水管，所以我們要把水管的切口固定下來。以上邊的場景為例，我們確保水管只能有一個切口位置。其次，我們抽象出對水的兩種處理方式：物理變化和化學變化。

基于以上的設(shè)計，如果我們需要過濾雜質(zhì)，就可以在化學變化這個功能模塊里增加一條過濾雜質(zhì)的規(guī)則;如果我們需要增加溫度的話，就可以在物理變化這個功能模塊里增加一條加熱的規(guī)則。

以上的過濾器框架，顯然比切水管的方式，要優(yōu)秀很多。設(shè)計這個框架，我們主要做了兩件事情，一個是固定水管切口位置，另外一個是抽象出兩種水處理方式。

理解這兩件事情之后，我們可以來看下iptables，或者更準確的說法，netfilter的工作原理。netfilter實際上就是一個過濾器框架。netfilter在網(wǎng)絡(luò)包收發(fā)及路由的管道上，一共切了5個口，分別是PREROUTING，F(xiàn)ORWARD，POSTROUTING，INPUT以及OUTPUT;同時netfilter定義了包括nat、filter在內(nèi)的若干個網(wǎng)絡(luò)包處理方式。

需要注意的是，routing和forwarding很大程度上增加了以上netfilter的復(fù)雜程度，如果我們不考慮routing和forwarding，那么netfilter會變得更我們的水質(zhì)過濾器框架一樣簡單。

節(jié)點網(wǎng)絡(luò)大圖

現(xiàn)在我們看一下Kubernetes集群節(jié)點的網(wǎng)絡(luò)全貌。橫向來看，節(jié)點上的網(wǎng)絡(luò)環(huán)境，被分割成不同的網(wǎng)絡(luò)命名空間，包括主機網(wǎng)絡(luò)命名空間和Pod網(wǎng)絡(luò)命名空間;縱向來看，每個網(wǎng)絡(luò)命名空間包括完整的網(wǎng)絡(luò)棧，從應(yīng)用到協(xié)議棧，再到網(wǎng)絡(luò)設(shè)備。

在網(wǎng)絡(luò)設(shè)備這一層，我們通過cni0虛擬網(wǎng)橋，組建出系統(tǒng)內(nèi)部的一個虛擬局域網(wǎng)。Pod網(wǎng)絡(luò)通過veth對連接到這個虛擬局域網(wǎng)內(nèi)。cni0虛擬局域網(wǎng)通過主機路由以及網(wǎng)口eth0與外部通信。

在網(wǎng)絡(luò)協(xié)議棧這一層，我們可以通過編程netfilter過濾器框架，來實現(xiàn)集群節(jié)點的反向代理。

實現(xiàn)反向代理，歸根結(jié)底，就是做DNAT，即把發(fā)送給集群服務(wù)IP和端口的數(shù)據(jù)包，修改成發(fā)給具體容器組的IP和端口。

參考netfilter過濾器框架的圖，我們知道，在netfilter里，可以通過在PREROUTING，OUTPUT以及POSTROUGING三個位置加入NAT規(guī)則，來改變數(shù)據(jù)包的源地址或目的地址。

因為這里需要做的是DNAT，即改變目的地址，這樣的修改，必須在路由(ROUTING)之前發(fā)生以保證數(shù)據(jù)包可以被路由正確處理，所以實現(xiàn)反向代理的規(guī)則，需要被加到PREROUTING和OUTPUT兩個位置。

其中，PREOURTING的規(guī)則，用來處理從Pod訪問服務(wù)的流量。數(shù)據(jù)包從Pod網(wǎng)絡(luò)veth發(fā)送到cni0之后，進入主機協(xié)議棧，首先會經(jīng)過netfilter PREROUTING來做處理，所以發(fā)給服務(wù)的數(shù)據(jù)包，會在這個位置做DNAT。經(jīng)過DNAT處理之后，數(shù)據(jù)包的目的地址變成另外一個Pod的地址，從而經(jīng)過主機路由，轉(zhuǎn)發(fā)到eth0，發(fā)送給正確的集群節(jié)點。

而添加在OUTPUT這個位置的DNAT規(guī)則，則用來處理從主機網(wǎng)絡(luò)發(fā)給服務(wù)的數(shù)據(jù)包，原理也是類似，即經(jīng)過路由之前，修改目的地址，以方便路由轉(zhuǎn)發(fā)。

升級過濾器框架

在過濾器框架一節(jié)，我們看到netfilter是一個過濾器框架。netfilter在數(shù)據(jù)“管到”上切了5個口，分別在這5個口上，做一些數(shù)據(jù)包處理工作。雖然固定切口位置以及網(wǎng)絡(luò)包處理方式分類已經(jīng)極大的優(yōu)化了過濾器框架，但是有一個關(guān)鍵的問題，就是我們還是得在管道上做修改以滿足新的功能。換句話說，這個框架沒有做到管道和過濾功能兩者的徹底解耦。

為了實現(xiàn)管道和過濾功能兩者的解耦，netfilter用了表這個概念。表就是netfilter的過濾中心，其核心功能是過濾方式的分類(表)，以及每種過濾方式中，過濾規(guī)則的組織(鏈)。

把過濾功能和管道解耦之后，所有對數(shù)據(jù)包的處理，都變成了對表的配置。而管道上的5個切口，僅僅變成了流量的出入口，負責把流量發(fā)送到過濾中心，并把處理之后的流量沿著管道繼續(xù)傳送下去。

如上圖，在表中，netfilter把規(guī)則組織成為鏈。表中有針對每個管道切口的默認鏈，也有我們自己加入的自定義鏈。默認鏈是數(shù)據(jù)的入口，默認鏈可以通過跳轉(zhuǎn)到自定義鏈來完成一些復(fù)雜的功能。這里允許增加自定義鏈的好處是顯然的。為了完成一個復(fù)雜過濾功能，比如實現(xiàn)Kubernetes集群節(jié)點的反向代理，我們可以使用自定義鏈來模塊化我們規(guī)則。

用自定義鏈實現(xiàn)服務(wù)的反向代理

集群服務(wù)的反向代理，實際上就是利用自定義鏈，模塊化地實現(xiàn)了數(shù)據(jù)包的DNAT轉(zhuǎn)換。KUBE-SERVICE是整個反向代理的入口鏈，其對應(yīng)所有服務(wù)的總?cè)肟?KUBE-SVC-XXXX鏈是具體某一個服務(wù)的入口鏈，KUBE-SERVICE鏈會根據(jù)服務(wù)IP，跳轉(zhuǎn)到具體服務(wù)的KUBE-SVC-XXXX鏈;而KUBE-SEP-XXXX鏈代表著某一個具體Pod的地址和端口，即endpoint，具體服務(wù)鏈KUBE-SVC-XXXX會以一定算法(一般是隨機)，跳轉(zhuǎn)到endpoint鏈。

而如前文中提到的，因為這里需要做的是DNAT，即改變目的地址，這樣的修改，必須在路由之前發(fā)生以保證數(shù)據(jù)包可以被路由正確處理。所以KUBE-SERVICE會被PREROUTING和OUTPUT兩個默認鏈所調(diào)用。

總結(jié)

通過這篇文章，大家應(yīng)該對Kubernetes集群服務(wù)的概念以及實現(xiàn)，有了更深層次的認識。我們基本上需要把握三個要點。一、服務(wù)本質(zhì)上是負載均衡;二、服務(wù)負載均衡的實現(xiàn)采用了與服務(wù)網(wǎng)格類似的Sidecar的模式，而不是LVS類型的獨占模式;三、kube-proxy本質(zhì)上是一個集群控制器。除此之外，我們思考了過濾器框架的設(shè)計，并在此基礎(chǔ)上，理解使用iptables實現(xiàn)的服務(wù)負載均衡的原理。