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

時間 2019-12-19

原文原文鏈接

以個人經驗來說，理解 Kubernetes 集羣服務的概念，是比較不容易的一件事情。尤爲是當咱們基於似是而非的理解，去排查服務相關問題的時候，會很是不順利。前端

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

今天這邊文章，我來深刻解釋一下 Kubernetes 集羣服務的原理與實現，便於你們理解。編程

Kubernetes 集羣服務的本質是什麼

概念上來說，Kubernetes 集羣的服務，其實就是負載均衡、或反向代理。這跟阿里雲的負載均衡產品，有不少相似的地方。和負載均衡同樣，服務有它的 IP 地址以及前端端口；服務後邊會掛載多個容器組 Pod 做爲其「後端服務器」，這些「後端服務器」有本身的 IP 以及監聽端口。後端

當這樣的負載均衡和後端的架構，與 Kubernetes 集羣結合的時候，咱們能夠想到的最直觀的實現方式，就是集羣中某一個節點專門作負載均衡（相似 LVS）的角色，而其餘節點則用來負載後端容器組。服務器

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

自帶通訊員

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

在 Kubernetes 集羣中，服務的實現，其實是爲每個集羣節點上，部署了一個反向代理 Sidecar。而全部對集羣服務的訪問，都會被節點上的反向代理轉換成對服務後端容器組的訪問。基本上來講，節點和這些 Sidecar 的關係以下圖所示。負載均衡

把服務照進現實

前邊兩節，咱們看到了，Kubernetes 集羣的服務，本質上是負載均衡，即反向代理；同時咱們知道了，在實際實現中，這個反向代理，並非部署在集羣某一個節點上，而是做爲集羣節點的邊車，部署在每一個節點上的。框架

在這裏把服務照進反向代理這個現實的，是 Kubernetes 集羣的一個控制器，即 kube-proxy。關於 Kubernetes 集羣控制器的原理，請參考我另一篇關於控制器的文章。簡單來講，kube-proxy 做爲部署在集羣節點上的控制器，它們經過集羣 API Server 監聽着集羣狀態變化。當有新的服務被建立的時候，kube-proxy 則會把集羣服務的狀態、屬性，翻譯成反向代理的配置。運維

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

一種實現

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

過濾器框架

如今，咱們來設想一種場景。咱們有一個屋子。這個屋子有一個入水管和出水管。從入水管進入的水，是不能直接飲用的，由於有雜質。而咱們指望，從出水管流出的水，能夠直接飲用。爲了達到目的，咱們切開水管，在中間加一個雜質過濾器。

過了幾天，咱們的需求變了，咱們不止要求從屋子裏流出來的水能夠直接飲用，咱們還但願水是熱水。因此咱們不得再也不在水管上增長一個切口，而後增長一個加熱器。

很明顯，這種切開水管，增長新功能的方式是很醜陋的。由於需求可能隨時會變，咱們甚至很難保證，在通過一年半載以後，這跟水管還能找獲得能夠被切開的地方。

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

基於以上的設計，若是咱們須要過濾雜質，就能夠在化學變化這個功能模塊裏增長一條過濾雜質的規則；若是咱們須要增長溫度的話，就能夠在物理變化這個功能模塊裏增長一條加熱的規則。

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

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

須要注意的是，routing 和 forwarding 很大程度上增長了以上 netfilter 的複雜程度，若是咱們不考慮 routing 和 forwarding，那麼 netfilter 會變得跟咱們的水質過濾器框架同樣簡單。

節點網絡大圖

如今咱們看一下 Kubernetes 集羣節點的網絡全貌。橫向來看，節點上的網絡環境，被分割成不一樣的網絡命名空間，包括主機網絡命名空間和 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 把規則組織成爲鏈。表中有針對每一個管道切口的默認鏈，也有咱們本身加入的自定義鏈。默認鏈是數據的入口，默認鏈能夠經過跳轉到自定義鏈來完成一些複雜的功能。這裏容許增長自定義鏈的好處是顯然的。爲了完成一個複雜過濾功能，好比實現 Kubernetes 集羣節點的反向代理，咱們可使用自定義鏈來模塊化咱們規則。

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

集羣服務的反向代理，實際上就是利用自定義鏈，模塊化地實現了數據包的 DNAT 轉換。KUBE-SERVICE 是整個反向代理的入口鏈，其對應全部服務的總入口；KUBE-SVC-XXXX 鏈是具體某一個服務的入口鏈，KUBE-SERVICE 鏈會根據服務 IP，跳轉到具體服務的 KUBE-SVC-XXXX 鏈；而 KUBE-SEP-XXXX 鏈表明着某一個具體 Pod 的地址和端口，即 endpoint，具體服務鏈 KUBE-SVC-XXXX 會以必定算法（通常是隨機），跳轉到 endpoint 鏈。