K8S從懵圈到熟練 – 叢集服務的三個要點和一種實現

以我的經驗來講，理解K8S叢集服務的概念，是比較不容易的一件事情。尤其是當我們基於似是而非的理解，去排查服務相關問題的時候，會非常不順利。

這體現在，對於新手來說，ping不通服務的IP地址這樣基礎的問題，都很難理解；而就算對經驗很豐富的工程師來說，看懂服務相關的iptables配置，也是相當的挑戰。

今天這邊文章，我來深入解釋一下K8S叢集服務的原理與實現，便於大家理解。

K8S叢集服務的本質是什麼

概念上來講，K8S叢集的服務，其實就是負載均衡、或反向代理。這跟阿里雲的負載均衡產品，有很多類似的地方。和負載均衡一樣，服務有它的IP地址以及前端埠；服務後邊會掛載多個容器組Pod作為其“後端伺服器”，這些“後端伺服器”有自己的IP以及監聽埠。

當這樣的負載均衡和後端的架構，與K8S叢集結合的時候，我們可以想到的最直觀的實現方式，就是叢集中某一個節點專門做負載均衡（類似LVS）的角色，而其他節點則用來負載後端容器組。

這樣的實現方法，有一個巨大的缺陷，就是單點問題。K8S叢集是Google多年來自動化運維實踐的結晶，這樣的實現顯然與其智慧運維的哲學相背離的。

自帶通訊員

邊車模式（Sidecar）是微服務領域的核心概念。邊車模式，換一句通俗一點的說法，就是自帶通訊員。熟悉服務網格的同學肯定對這個很熟悉了。但是可能比較少人注意到，其實K8S叢集原始服務的實現，也是基於Sidecar模式的。

在K8S叢集中，服務的實現，實際上是為每一個叢集節點上，部署了一個反向代理Sidecar。而所有對叢集服務的訪問，都會被節點上的反向代理轉換成對服務後端容器組的訪問。基本上來說，節點和這些Sidecar的關係如下圖所示。

把服務照進現實

前邊兩節，我們看到了，K8S叢集的服務，本質上是負載均衡，即反向代理；同時我們知道了，在實際實現中，這個反向代理，並不是部署在叢集某一個節點上，而是作為叢集節點的邊車，部署在每個節點上的。

在這裡把服務照進反向代理這個現實的，是K8S叢集的一個控制器，即kube-proxy。關於K8S叢集控制器的原理，請參考我另外一篇關於控制器的文章。簡單來說，kube-proxy作為部署在叢集節點上的控制器，它們透過叢集API Server監聽著叢集狀態變化。當有新的服務被建立的時候，kube-proxy則會把叢集服務的狀態、屬性，翻譯成反向代理的配置。

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

一種實現

K8S叢集節點實現服務反向代理的方法，目前主要有三種，即userspace、iptables以及ipvs。今天我們只深入分析iptables的方式，底層網路基於阿里雲flannel叢集網路。

過濾器框架

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

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

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

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

基於以上的設計，如果我們需要過濾雜質，就可以在化學變化這個功能模組裡增加一條過濾雜質的規則；如果我們需要增加溫度的話，就可以在物理變化這個功能模組裡增加一條加熱的規則。

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

理解這兩件事情之後，我們可以來看下iptables，或者更準確的說法，netfilter的工作原理。netfilter實際上就是一個過濾器框架。netfilter在網路包收發及路由的管道上，一共切了5個口，分別是PREROUTING，FORWARD，POSTROUTING，INPUT以及OUTPUT；同時netfilter定義了包括nat、filter在內的若干個網路包處理方式。

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

節點網路大圖

現在我們看一下K8S叢集節點的網路全貌。橫向來看，節點上的網路環境，被分割成不同的網路名稱空間，包括主機網路名稱空間和Pod網路名稱空間；縱向來看，每個網路名稱空間包括完整的網路棧，從應用到協議棧，再到網路裝置。

在網路裝置這一層，我們透過cni0虛擬網橋，組建出系統內部的一個虛擬區域網。Pod網路透過veth對連線到這個虛擬區域網內。cni0虛擬區域網透過主機路由以及網口eth0與外部通訊。

在網路協議棧這一層，我們可以透過程式設計netfilter過濾器框架，來實現叢集節點的反向代理。

實現反向代理，歸根結底，就是做DNAT，即把傳送給叢集服務IP和埠的資料包，修改成發給具體容器組的IP和埠。

參考netfilter過濾器框架的圖，我們知道，在netfilter裡，可以透過在PREROUTING，OUTPUT以及POSTROUGING三個位置加入NAT規則，來改變資料包的源地址或目的地址。

因為這裡需要做的是DNAT，即改變目的地址，這樣的修改，必須在路由（ROUTING）之前發生以保證資料包可以被路由正確處理，所以實現反向代理的規則，需要被加到PREROUTING和OUTPUT兩個位置。

其中，PREOURTING的規則，用來處理從Pod訪問服務的流量。資料包從Pod網路veth傳送到cni0之後，進入主機協議棧，首先會經過netfilter PREROUTING來做處理，所以發給服務的資料包，會在這個位置做DNAT。經過DNAT處理之後，資料包的目的地址變成另外一個Pod的地址，從而經過主機路由，轉發到eth0，傳送給正確的叢集節點。

而新增在OUTPUT這個位置的DNAT規則，則用來處理從主機網路發給服務的資料包，原理也是類似，即經過路由之前，修改目的地址，以方便路由轉發。

升級過濾器框架

在過濾器框架一節，我們看到netfilter是一個過濾器框架。netfilter在資料“管到”上切了5個口，分別在這5個口上，做一些資料包處理工作。雖然固定切口位置以及網路包處理方式分類已經極大的優化了過濾器框架，但是有一個關鍵的問題，就是我們還是得在管道上做修改以滿足新的功能。換句話說，這個框架沒有做到管道和過濾功能兩者的徹底解耦。

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

把過濾功能和管道解耦之後，所有對資料包的處理，都變成了對錶的配置。而管道上的5個切口，僅僅變成了流量的出入口，負責把流量傳送到過濾中心，並把處理之後的流量沿著管道繼續傳送下去。

如上圖，在表中，netfilter把規則組織成為鏈。表中有針對每個管道切口的預設鏈，也有我們自己加入的自定義鏈。預設鏈是資料的入口，預設鏈可以透過跳轉到自定義鏈來完成一些複雜的功能。這裡允許增加自定義鏈的好處是顯然的。為了完成一個複雜過濾功能，比如實現K8S叢集節點的反向代理，我們可以使用自定義鏈來模組化我們規則。

用自定義鏈實現服務的反向代理

叢集服務的反向代理，實際上就是利用自定義鏈，模組化地實現了資料包的DNAT轉換。KUBE-SERVICE是整個反向代理的入口鏈，其對應所有服務的總入口；KUBE-SVC-XXXX鏈是具體某一個服務的入口鏈，KUBE-SERVICE鏈會根據服務IP，跳轉到具體服務的KUBE-SVC-XXXX鏈；而KUBE-SEP-XXXX鏈代表著某一個具體Pod的地址和埠，即endpoint，具體服務鏈KUBE-SVC-XXXX會以一定演算法（一般是隨機），跳轉到endpoint鏈。

而如前文中提到的，因為這裡需要做的是DNAT，即改變目的地址，這樣的修改，必須在路由之前發生以保證資料包可以被路由正確處理。所以KUBE-SERVICE會被PREROUTING和OUTPUT兩個預設鏈所呼叫。

總結

透過這篇文章，大家應該對K8S叢集服務的概念以及實現，有了更深層次的認識。我們基本上需要把握三個要點。一、服務本質上是負載均衡；二、服務負載均衡的實現採用了與服務網格類似的Sidecar的模式，而不是LVS型別的獨佔模式；三、kube-proxy本質上是一個叢集控制器。除此之外，我們思考了過濾器框架的設計，並在此基礎上，理解使用iptables實現的服務負載均衡的原理。

本文作者：阿里雲支援與服務

原文連結

更多技術乾貨敬請關注雲棲社群知乎機構號：阿里云云棲社群 - 知乎