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

大濤學長發表於2019-09-24
以我的經驗來講，理解 Kubernetes 叢集服務的概念，是比較不容易的一件事情。尤其是當我們基於似是而非的理解，去排查服務相關問題的時候，會非常不順利。
這體現在，對於新手來說，ping 不通服務的 IP 地址這樣基礎的問題，都很難理解；而就算對經驗很豐富的工程師來說，看懂服務相關的 iptables 配置，也是有相當的挑戰的。
今天這邊文章，我來深入解釋一下 Kubernetes 叢集服務的原理與實現，便於大家理解。

Kubernetes 叢集服務的本質是什麼

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

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

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

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

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

自帶通訊員

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

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

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

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


把服務照進現實

前邊兩節，我們看到了，Kubernetes 叢集的服務，本質上是負載均衡，即反向代理；同時我們知道了，在實際實現中，這個反向代理，並不是部署在叢集某一個節點上，而是作為叢集節點的邊車，部署在每個節點上的。
在這裡把服務照進反向代理這個現實的，是 Kubernetes 叢集的一個控制器，即 kube-proxy。關於 Kubernetes 叢集控制器的原理，請參考我另外一篇 關於控制器的文章。簡單來說，kube-proxy 作為部署在叢集節點上的控制器，它們通過叢集 API Server 監聽著叢集狀態變化。當有新的服務被建立的時候，kube-proxy 則會把叢集服務的狀態、屬性，翻譯成反向代理的配置。

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

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

一種實現

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

過濾器框架

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

Kubernetes 從懵圈到熟練：叢集服務的三個要點和一種實現
過了幾天，我們的需求變了，我們不止要求從屋子裡流出來的水可以直接飲用，我們還希望水是熱水。所以我們不得不再在水管上增加一個切口，然後增加一個加熱器。

Kubernetes 從懵圈到熟練：叢集服務的三個要點和一種實現
很明顯，這種切開水管，增加新功能的方式是很醜陋的。因為需求可能隨時會變，我們甚至很難保證，在經過一年半載之後，這跟水管還能找得到可以被切開的地方。
所以我們需要重新設計。首先我們不能隨便切開水管，所以我們要把水管的切口固定下來。以上邊的場景為例，我們確保水管只能有一個切口位置。其次，我們抽象出對水的兩種處理方式：物理變化和化學變化。

Kubernetes 從懵圈到熟練：叢集服務的三個要點和一種實現
基於以上的設計，如果我們需要過濾雜質，就可以在化學變化這個功能模組裡增加一條過濾雜質的規則；如果我們需要增加溫度的話，就可以在物理變化這個功能模組裡增加一條加熱的規則。
以上的過濾器框架，顯然比切水管的方式，要優秀很多。設計這個框架，我們主要做了兩件事情，一個是固定水管切口位置，另外一個是抽象出兩種水處理方式。
理解這兩件事情之後，我們可以來看下 iptables，或者更準確的說法，netfilter 的工作原理。netfilter 實際上就是一個過濾器框架。netfilter 在網路包收發及路由的管道上，一共切了 5 個口，分別是 PREROUTING，FORWARD，POSTROUTING，INPUT 以及 OUTPUT；同時 netfilter 定義了包括 nat、filter 在內的若干個網路包處理方式。

Kubernetes 從懵圈到熟練：叢集服務的三個要點和一種實現
需要注意的是，routing 和 forwarding 很大程度上增加了以上 netfilter 的複雜程度，如果我們不考慮 routing 和 forwarding，那麼 netfilter 會變得跟我們的水質過濾器框架一樣簡單。

節點網路大圖

現在我們看一下 Kubernetes 叢集節點的網路全貌。橫向來看，節點上的網路環境，被分割成不同的網路名稱空間，包括主機網路名稱空間和 Pod 網路名稱空間；縱向來看，每個網路名稱空間包括完整的網路棧，從應用到協議棧，再到網路裝置。
在網路裝置這一層，我們通過 cni0 虛擬網橋，組建出系統內部的一個虛擬區域網。Pod 網路通過 veth 對連線到這個虛擬區域網內。cni0 虛擬區域網通過主機路由以及網口 eth0 與外部通訊。
在網路協議棧這一層，我們可以通過程式設計 netfilter 過濾器框架，來實現叢集節點的反向代理。
Kubernetes 從懵圈到熟練：叢集服務的三個要點和一種實現

實現反向代理，歸根結底，就是做 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 的過濾中心，其核心功能是過濾方式的分類（表），以及每種過濾方式中，過濾規則的組織（鏈）。

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

把過濾功能和管道解耦之後，所有對資料包的處理，都變成了對錶的配置。而管道上的5個切口，僅僅變成了流量的出入口，負責把流量傳送到過濾中心，並把處理之後的流量沿著管道繼續傳送下去。
如上圖，在表中，netfilter 把規則組織成為鏈。表中有針對每個管道切口的預設鏈，也有我們自己加入的自定義鏈。預設鏈是資料的入口，預設鏈可以通過跳轉到自定義鏈來完成一些複雜的功能。這裡允許增加自定義鏈的好處是顯然的。為了完成一個複雜過濾功能，比如實現 Kubernetes 叢集節點的反向代理，我們可以使用自定義鏈來模組化我們規則。

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

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

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

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

總結

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

本文作者：聲東 阿里雲售後技術專家
原文連結
本文為雲棲社群原創內容，未經允許不得轉載。


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69947441/viewspace-2658080/，如需轉載，請註明出處，否則將追究法律責任。

相關文章