DockOne微信分享：PaaS網路模型設計

最新 07-12

【編者的話】PAAS的抽象邏輯使得其網路模型與IAAS有所不通，本次通過重點說明kubernetes和docker的網路，從而來探究PAAS的網路模型設計。

PaaS和IaaS的網路需求

概念上來說，IaaS是基礎架構即服務，PaaS是平台即服務。從服務化角度來說兩者對於網路的需求有共同點：

（1）一台宿主機的網路隔離，一台宿主機要運行多個環境黑盒（VM或者容器），這時候每個環境黑盒的網路需要隔離。

（2）環境變更後的訪問一致性，比如VM或者容器遷移到其他宿主機的時候，如何保證外部訪問不感知，比較通用的解決方案網路代理層來解決。

實現上來說，IaaS是VM管理，PaaS是容器編排，兩者的網路也會有些不同：

（1）容器比VM輕量級，啟停更快，更方便遷移，所以PaaS的整個調度策略會更靈活，容器的遷移頻率是高於VM，當容器遷移的時候，PaaS需要更加快速的解決變化後的網路訪問。

（2）VM安全高於容器，IaaS這部分會更多在隔離和安全上有所考慮，當然這個可能是公有雲和私有雲的一個定位，個人認為IaaS比較適合公有雲，PaaS比較適合私有雲。

PaaS的網路模型設計

以上部分我們討論了PaaS網路需求，總結來說PaaS需要解決宿主機的網路隔離和環境變更後的訪問一致性問題，然後在靈活性上需要更加註重，私有雲的定位可以減少因為安全和隔離的代價，保證高性能。

（1）宿主機的網路隔離

網路隔離最基本問題就是要解決埠衝突，一種思路是容器通過埠映射訪問，宿主機的埠由系統分配避免埠衝突，這種方式對使用的便利性是有意義的，但並不理想，因為需要對各種埠進行映射，這會限制宿主機的能力，在容器編排上也增加了複雜度。

埠是個稀缺資源，這就需要解決埠衝突和動態分配埠問題。這不但使調度複雜化，而且應用程序的配置也將變得複雜，具體表現為埠衝突、重用和耗盡。

NAT將地址空間分段的做法引入了額外的複雜度。比如容器中應用所見的IP並不是對外暴露的IP，因為網路隔離，容器中的應用實際上只能檢測到容器的IP，但是需要對外宣稱的則是宿主機的IP，這種信息的不對稱將帶來諸如破壞自註冊機制等問題。

所以就要引入一層網路虛擬層來解決網路隔離，現在說的比較多的大二層網路，L2 over L3，比如OVS, Flannel, Calico等等。

（2）環境變更後的訪問一致性

一個通用方案來說通過代理層提供不變的訪問入口，像Openstack的網路節點就是一個L3(IP)的訪問入口，而PaaS更多的是提供L4（TCP, UDP）和L7(HTTP)的訪問，L4比較流行的開源方案有LVS，L7的是Nginx和Haproxy.

因此PaaS的網路結構有：

（1）物理網路

（2）虛擬層網路

（3）代理層網路

Kubernetes和Docker的網路說明

Kubernete Docker作為目前最流行的開源PaaS實現，通過其實現細節可以更加理解PaaS的網路模型實踐。

容器網路

Docker使用Linux橋接，在宿主機虛擬一個Docker容器網橋(docker0)，Docker啟動一個容器時會根據Docker網橋的網段分配給容器一個IP地址，稱為Container-IP，同時Docker網橋是每個容器的默認網關。因為在同一宿主機內的容器都接入同一個網橋，這樣容器之間就能夠通過容器的Container-IP直接通信。

Docker網橋是宿主機虛擬出來的，並不是真實存在的網路設備，外部網路是無法定址到的，這也意味著外部網路無法通過直接Container-IP訪問到容器。

Pod內部容器通信

Kubernetes中Pod是容器的集合，Pod包含的容器都運行在同一個宿主機上，這些容器將擁有同樣的網路空間，容器之間能夠互相通信，它們能夠在本地訪問其他容器的埠。

實際上Pod都包含一個網路容器，它不做任何事情，只是用來接管Pod的網路，業務容器通過加入網路容器的網路從而實現網路共享。

Pod的啟動方式類似於：

$ docker run -p 80:80 --name network-container -d $ docker run --net container:network-container -d

所以Pod的網路實際上就是Pod中網路容器的網路，所以往往就可以認為Pod網路就是容器網路，在理解Kubernetes網路的時候這是必須要需要清楚的,比如說Pod的Pod-IP就是網路容器的Container-IP。

Pod間通信

Kubernetes網路模型是一個扁平化網路平面，在這個網路平面內，Pod作為一個網路單元同Kubernetes Node的網路處於同一層級。

在這個網路拓撲中滿足以下條件：

? Pod間通信：Pod1和Pod2（同主機），Pod1和Pod3(跨主機)能夠通信

為此需要實現：

? Pod的Pod-IP是全局唯一的。其實做法也很簡單，因為Pod的Pod-IP是Docker網橋分配的，所以將不同Kubernetes Node的 Docker網橋配置成不同的IP網段即可。

? Node上的Pod/容器原生能通信，但是Node之間的Pod/容器如何通信的，這就需要對Docker進行增強，在容器集群中創建一個覆蓋網路(Overlay Network)，聯通各個節點，目前可以通過第三方網路插件來創建覆蓋網路，比如Flannel和Open vSwitch等等。

Flannel由CoreOS團隊設計開發的一個覆蓋網路工具，Flannel 通過在集群中創建一個覆蓋網路，為主機設定一個子網，通過隧道協議封裝容器之間的通信報文，實現容器的跨主機通信。Flannel將會運行在所有的Node之上，Flannel實現的網路結構如圖所示：

代理層

Kubernetes中的Service就是在Pod之間起到服務代理的作用，對外表現為一個單一訪問介面，將請求轉發給Pod，Service的網路轉發是Kubernetes實現服務編排的關鍵一環。

Service都會生成一個虛擬IP，稱為Service-IP， Kuberenetes Porxy組件負責實現Service-IP路由和轉發，在容器覆蓋網路之上又實現了虛擬轉發網路。

Kubernetes Porxy實現了以下功能：

? 轉發訪問Service的Service-IP的請求到Endpoints(即Pod-IP)。

? 監控Service和Endpoints的變化，實時刷新轉發規則。

? 負載均衡能力。

Kubernetes Porxy是一種分布式L3代理轉發，默認是居於Iptables實現，這從設計上很值得借鑒，但是性能部分有待驗證。

Kubernetes中的Ingress提供了一個統一的對外代理入口配置，比如HTTP的訪問配置，然後通過實現Ingress-Controller，Ingress-Controller的實現可以用Nginx,LVS等等，以Nginx來說，就Ingress-Controller監控Kubernetes API, 生成Nginx配置，然後載入生效，而Nginx跟Pod的通信，可以走Service，但是考慮到Kubernetes Porxy的性能問題，建議直接和Pod通信。下面就是一個實現圖：