作者 | 聲東 阿里云售后技術(shù)專家

文章來源：Docker，點擊查看原文。

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

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

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

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

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

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

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

自帶通信員

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

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

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

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

在這里把服務(wù)照進(jìn)反向代理這個現(xiàn)實的，是 Kubernetes 集群的一個控制器，即 kube-proxy。關(guān)于 Kubernetes 集群控制器的原理，請參考我另外一篇關(guān)于控制器的文章。簡單來說，kube-proxy 作為部署在集群節(jié)點上的控制器，它們通過集群 API Server 監(jiān)聽著集群狀態(tài)變化。當(dāng)有新的服務(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è)想一種場景。我們有一個屋子。這個屋子有一個入水管和出水管。從入水管進(jìn)入的水，是不能直接飲用的，因為有雜質(zhì)。而我們期望，從出水管流出的水，可以直接飲用。為了達(dá)到目的，我們切開水管，在中間加一個雜質(zhì)過濾器。

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

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

所以我們需要重新設(shè)計。首先我們不能隨便切開水管，所以我們要把水管的切口固定下來。以上邊的場景為例，我們確保水管只能有一個切口位置。其次，我們抽象出對水的兩種處理方式：物理變化和化學(xué)變化。

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

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

理解這兩件事情之后，我們可以來看下 iptables，或者更準(zhǔn)確的說法，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 之后，進(jìn)入主機協(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ù)責(zé)把流量發(fā)送到過濾中心，并把處理之后的流量沿著管道繼續(xù)傳送下去。

如上圖，在表中，netfilter 把規(guī)則組織成為鏈。表中有針對每個管道切口的默認(rèn)鏈，也有我們自己加入的自定義鏈。默認(rèn)鏈?zhǔn)菙?shù)據(jù)的入口，默認(rèn)鏈可以通過跳轉(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 鏈?zhǔn)蔷唧w某一個服務(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 兩個默認(rèn)鏈所調(diào)用。

總結(jié)

通過這篇文章，大家應(yīng)該對 Kubernetes 集群服務(wù)的概念以及實現(xiàn)，有了更深層次的認(rèn)識。我們基本上需要把握三個要點：

• 服務(wù)本質(zhì)上是負(fù)載均衡；
• 服務(wù)負(fù)載均衡的實現(xiàn)采用了與服務(wù)網(wǎng)格類似的 Sidecar 的模式，而不是 LVS 類型的獨占模式；
• kube-proxy 本質(zhì)上是一個集群控制器。除此之外，我們思考了過濾器框架的設(shè)計，并在此基礎(chǔ)上，理解使用 iptables 實現(xiàn)的服務(wù)負(fù)載均衡的原理。

原文鏈接：https://yq.aliyun.com/articles/710873

“ 阿里巴巴云原生微信公眾號（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的技術(shù)公眾號?！?/strong>

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。