容器云平臺網(wǎng)絡(luò)架構(gòu)設(shè)計

1容器平臺網(wǎng)絡(luò)模型1.1容器網(wǎng)絡(luò)概述與傳統(tǒng)的虛擬化相比，容器其生命周期更短、數(shù)量密度更高、集群變更速度更快?；谶@些特性，容器平臺網(wǎng)絡(luò)就必須對集群節(jié)點之間的高速通信進行充分的考量。除此之外，在企業(yè)級的容器云平臺上，承載眾多租戶的計算負載之間資源的安全隔離，也必須要考慮到的因素。顯而易見，傳統(tǒng)的物理網(wǎng)絡(luò)架構(gòu)無法滿足容器平臺高靈活性的需求，容器平臺網(wǎng)絡(luò)構(gòu)建必須要有一種嶄新的設(shè)計架構(gòu)來滿足，這便推動了容器平臺網(wǎng)絡(luò)設(shè)計的發(fā)展。容器網(wǎng)絡(luò)發(fā)展到目前，已經(jīng)形成了Docker主導的CNM模型和Google、CoreOS、Kubernetes主導的CNI模型兩種模型共存的情況。CNM和CNI并不是網(wǎng)絡(luò)實現(xiàn)，他們是網(wǎng)絡(luò)規(guī)范和網(wǎng)絡(luò)體系。從研發(fā)的角度來看就是一些接口，主要是和網(wǎng)絡(luò)管理相關(guān)的問題。容器平臺的網(wǎng)絡(luò)方案，通常可以從協(xié)議棧、穿越方式、隔離方法三個維度去設(shè)計方案：圖1網(wǎng)絡(luò)架構(gòu)示意圖協(xié)議棧：二層（橋接、ARP+MAC）三層（路由轉(zhuǎn)發(fā)）二層+三層（節(jié)點內(nèi)部二層轉(zhuǎn)發(fā)、跨節(jié)點三層轉(zhuǎn)發(fā)）穿越方式：Overlay（隧道穿越底層基礎(chǔ)設(shè)施）Underlay（直接穿越底層基礎(chǔ)設(shè)施）隔離方法：VLANVXLAN1.2容器網(wǎng)絡(luò)分類介紹1.2.1協(xié)議棧二層解決方案，常見于傳統(tǒng)機房或者虛擬化場景中，針對ARP和MAC（橋接模式）學習，廣播風暴是這個方案最核心要解決的問題。眾所周知，二層廣播，對整個集群中節(jié)點的數(shù)量也會有嚴格的限制。三層解決方案一般是基于BGP協(xié)議實現(xiàn)路由轉(zhuǎn)發(fā)，通過自主學習完善整個數(shù)據(jù)中心的路由狀態(tài)。這個方案的優(yōu)勢是IP穿透性，可以實現(xiàn)IP網(wǎng)絡(luò)透傳。因為基于IP，所以其優(yōu)勢在于規(guī)模性，具有非常優(yōu)秀的擴展性。但在實際使用過程中，受限于各個企業(yè)自身網(wǎng)絡(luò)安全的考量，例如生產(chǎn)網(wǎng)和開發(fā)測試網(wǎng)隔離，或者網(wǎng)絡(luò)本身不支持BGP，那么這個方案就受限了。二層+三層的方案，集成了前面兩種方案的優(yōu)勢（既解決了二層規(guī)模性擴展的問題，又解決三層網(wǎng)絡(luò)隔離受限的問題），正成為容器云網(wǎng)絡(luò)場景下首選的協(xié)議棧層級的解決方案。1.2.2穿越方式Underlay網(wǎng)絡(luò)提到Underlay網(wǎng)絡(luò)，就必須從以太網(wǎng)說起，以太網(wǎng)從最開始設(shè)計出來就是一個分布式網(wǎng)絡(luò)，沒有中心的控制節(jié)點，網(wǎng)路中的各個設(shè)備之間通過協(xié)議傳遞的方式學習網(wǎng)絡(luò)的可達信息，由每臺設(shè)備自己決定要如何轉(zhuǎn)發(fā)，這直接導致了沒有整體觀念，不能從整個網(wǎng)絡(luò)的角度對流量進行調(diào)控。由于要完成所有網(wǎng)絡(luò)設(shè)備之間的互通，就必須使用通用的語言，這就是網(wǎng)絡(luò)協(xié)議，RFC就是網(wǎng)絡(luò)協(xié)議的法律，相當于國際法，各個設(shè)備供應商遵從國際法行事，就基本保證了整個網(wǎng)絡(luò)世界的正常運行。Underlay就是當前數(shù)據(jù)中心網(wǎng)路基礎(chǔ)轉(zhuǎn)發(fā)架構(gòu)的網(wǎng)絡(luò)，只要數(shù)據(jù)中心網(wǎng)絡(luò)上任意兩點路由可達即可，指的是物理基礎(chǔ)層。我們可以通過物理網(wǎng)絡(luò)設(shè)備本身的技術(shù)改良、擴大設(shè)備數(shù)量、帶寬規(guī)模等完善Underlay網(wǎng)絡(luò)，其包含了一切現(xiàn)有的傳統(tǒng)網(wǎng)絡(luò)技術(shù)。Overlay網(wǎng)絡(luò)Overlay技術(shù)可以分為網(wǎng)絡(luò)Overlay，主機Overlay和混合式Overlay三大類。網(wǎng)絡(luò)Overlay是指通過控制協(xié)議對邊緣的網(wǎng)絡(luò)設(shè)備進行網(wǎng)絡(luò)構(gòu)建和擴展，也就是本文所講的Overlay網(wǎng)絡(luò)技術(shù)。Overlay網(wǎng)絡(luò)技術(shù)多種多樣，一般采用TRILL、VXLAN、GRE、NVGRE等隧道技術(shù)。TRILL（TransparentInterconnectionofLotsofLinks）技術(shù)是電信設(shè)備廠商主推的新型環(huán)網(wǎng)技術(shù)；NVGRE（NetworkVirtualizationusingGenericRoutingEncapsulation）STT（StatelessTransportTunnelingProtocol）是IT廠商主推的Overlay技術(shù)；以及大家非常熟悉的LAN）等基于隧道的封裝技術(shù)。由于這些也都是新增的協(xié)議，均需要升級現(xiàn)有網(wǎng)絡(luò)設(shè)備才能支持。Overlay網(wǎng)絡(luò)中應用部署的位置將不受限制，網(wǎng)絡(luò)設(shè)備可即插即用、自動配置下發(fā)，自動運行，Overlay網(wǎng)絡(luò)業(yè)務變化，基礎(chǔ)網(wǎng)絡(luò)不感知，并對傳統(tǒng)網(wǎng)絡(luò)改造極少，最為重要的是虛擬機和物理服務器都可以接入Overlay網(wǎng)絡(luò)中。1.2.3根據(jù)基礎(chǔ)設(shè)施劃分VLAN(VirtualLocalAreaNetwork)意為虛擬局域網(wǎng)，是在交換機實現(xiàn)過程中涉及到的概念，由802.1Q標準所定義。由于交換機是工作在鏈路層的網(wǎng)絡(luò)設(shè)備，連接在同一臺交換機的終端處于同一個三層網(wǎng)中，同時也處于同一個廣播域。當交換機接入較多的終端時，任意一臺終端發(fā)送廣播報文時（例如：ARP請求），報文都會傳遍整個網(wǎng)絡(luò)。對于規(guī)模較大的組網(wǎng)場景，廣播報文的泛濫對于網(wǎng)絡(luò)通信將會造成較大的影響。VLAN技術(shù)為這一問題提供了解決方案，VLAN將同一網(wǎng)絡(luò)劃分為多個邏輯上的虛擬子網(wǎng)，并規(guī)定當收到廣播報文時，僅僅在其所在VLAN中進行廣播從而防止廣播報文泛濫。VLAN技術(shù)在鏈路層的層次中實現(xiàn)了廣播域的隔離。隨著大數(shù)據(jù)、云計算技術(shù)的興起以及虛擬化技術(shù)的普及，VLAN技術(shù)的弊端逐漸顯現(xiàn)出來，具體表現(xiàn)為如下3個方面：(1)虛擬化技術(shù)的發(fā)展促使大數(shù)據(jù)、云計算技術(shù)公司采用單個物理設(shè)備虛擬多臺虛擬機的方式來進行組網(wǎng)，隨著應用模塊的增加，對于支持VLAN數(shù)目的要求也在提升，802.1Q標準中的最多支持4094個VLAN的能力已經(jīng)無法滿足當下需求。(2)公有云提供商的業(yè)務要求將實體網(wǎng)絡(luò)租借給多個不同的用戶，這些用戶對于網(wǎng)絡(luò)的要求有所不同，而不同用戶租借的網(wǎng)絡(luò)有很大的可能會出現(xiàn)IP地址、MAC地址的重疊，傳統(tǒng)的VLAN僅僅解決了同一鏈路層網(wǎng)絡(luò)廣播域隔離的問題，而并沒有涉及到網(wǎng)絡(luò)地址重疊的問題，因此需要一種新的技術(shù)來保證在多個租戶網(wǎng)絡(luò)中存在地址重疊的情況下依舊能有效通信的技術(shù)。(3)虛擬化技術(shù)的出現(xiàn)增加了交換機的負擔，對于大型的數(shù)據(jù)中心而言，單臺交換機必須支持數(shù)十臺以上主機的通信連接才足以滿足應用需求，而虛擬化技術(shù)使得單臺主機可以虛擬化出多臺虛擬機同時運行，而每臺虛擬機都會有其唯一的MAC地址。這樣，為了保證集群中所有虛機可以正常通信，交換機必須保存每臺虛機的MAC地址，這樣就導致了交換機中的MAC表異常龐大，從而影響交換機的轉(zhuǎn)發(fā)性能?；谝陨闲枨?，VXLAN技術(shù)被提出。VXLAN技術(shù)是網(wǎng)絡(luò)Overlay技術(shù)的一種實現(xiàn)，對于Overlay技術(shù)，筆者的理解是：在基于物理網(wǎng)絡(luò)拓撲的基礎(chǔ)上通過一定的技術(shù)來構(gòu)建虛擬的、不同于物理網(wǎng)絡(luò)拓撲的邏輯網(wǎng)絡(luò)，而物理網(wǎng)絡(luò)的拓撲結(jié)構(gòu)對于Overlay終端而言是透明的，終端不會感知到物理網(wǎng)絡(luò)的存在，而僅僅能感知到邏輯網(wǎng)絡(luò)結(jié)構(gòu)。對于終端的視角，網(wǎng)絡(luò)的情況和直接通過物理設(shè)備實現(xiàn)邏輯拓撲的效果是相同的。VXLAN技術(shù)可以基于三層網(wǎng)絡(luò)結(jié)構(gòu)來構(gòu)建二層虛擬網(wǎng)絡(luò)，通過VLAN技術(shù)可以將處于不同網(wǎng)段網(wǎng)絡(luò)設(shè)備整合在同一個邏輯鏈路層網(wǎng)絡(luò)中，對于終端用戶而言，這些網(wǎng)絡(luò)設(shè)備似乎“真實地”部署在了同一個鏈路層網(wǎng)絡(luò)中。相比VLAN技術(shù)，VXLAN技術(shù)具有以下的優(yōu)勢：(1)24位長度的VNI字段值可以支持更多數(shù)量的虛擬網(wǎng)絡(luò)，解決了VLAN數(shù)目上限為4094的局限性的問題。(2)VXLAN技術(shù)通過隧道技術(shù)在物理的三層網(wǎng)絡(luò)中虛擬二層網(wǎng)絡(luò)，處于VXLAN網(wǎng)絡(luò)的終端無法察覺到VXLAN的通信過程，這樣也就使得邏輯網(wǎng)絡(luò)拓撲和物理網(wǎng)絡(luò)拓撲實現(xiàn)了一定程度的解耦，網(wǎng)絡(luò)拓撲的配置對于物理設(shè)備的配置的依賴程度有所降低，配置更靈活更方便。(3)VLAN技術(shù)僅僅解決了二層網(wǎng)絡(luò)廣播域分割的問題，而VXLAN技術(shù)還具有多租戶支持的特性，通過VXLAN分割，各個租戶可以獨立組網(wǎng)、通信，地址分配方面和多個租戶之間地址沖突的問題也得到了解決。1.3總結(jié)通過本章的學習，可以初步了解容器網(wǎng)絡(luò)相關(guān)的基礎(chǔ)概念，主要涉及到了容器網(wǎng)絡(luò)的協(xié)議棧、穿越方式以及隔離方式。針對協(xié)議棧，到底是采用二層互通，還是采用三層互通，還是結(jié)合兩種方式的優(yōu)點整合一個綜合的方式取決于業(yè)務場景；針對穿越方式，是采用傳統(tǒng)的Underlay網(wǎng)絡(luò)，還是基于SDN的Overlay網(wǎng)絡(luò)，和客戶現(xiàn)場情況，以及硬件設(shè)備支持的情況都有比較大的關(guān)聯(lián)；同樣，隔離方式采用VLAN還是VXLAN，也和場景強相關(guān)。由此可見，容器云網(wǎng)絡(luò)的設(shè)計，需要因地制宜，因材施教，從客戶需求以及現(xiàn)場情況發(fā)出，才能制定出一個完善的解決方案。2基于Docker網(wǎng)絡(luò)基礎(chǔ)和實現(xiàn)原理Docker網(wǎng)絡(luò)方案基于OpenStack平臺網(wǎng)絡(luò)解決方案，在不斷的摸索中，形成了自己的一套網(wǎng)絡(luò)模型。Docker網(wǎng)絡(luò)在整個Docker技術(shù)棧中的位置如圖：圖2Docker生態(tài)技術(shù)棧在容器網(wǎng)絡(luò)項目探索中，隨著容器的發(fā)展，容器網(wǎng)絡(luò)的發(fā)展也出現(xiàn)了分歧。主要分為兩派，一個是Docker原生的CNM（ContainerNetworkModel），另一個是兼容性更好的CNI（ContainerNetworkInterface）。CNI就是后來為Kubernetes等容器平臺廣泛推崇使用的接口技術(shù)，后面的章節(jié)會詳細講述。這里，我們簡要介紹CNM。原先Docker的網(wǎng)絡(luò)相關(guān)的代碼是直接在Docker中的，網(wǎng)絡(luò)功能也比較簡單，對網(wǎng)絡(luò)的詬病也是比較多。隨著Docker越來越向平臺化發(fā)展，將功能組件逐漸從Docker中解耦，Docker從1.7把網(wǎng)絡(luò)相關(guān)的代碼從Docker的代碼中剝離出來新建了一個Libnetwork項目，引入了CNM的網(wǎng)絡(luò)模型。圖3CNM（ContainerNetworkModel）CNM模型下的Docker網(wǎng)絡(luò)模型如上所示。它由Sandbox,Endpoint,Network三種組件組成。注意，該模型只是規(guī)定了三種組件各自的作用，他們都有各自的具體實現(xiàn)方式。Sandbox:Sandbox包含了一個Container的網(wǎng)絡(luò)相關(guān)的配置，如網(wǎng)卡Interface，路由表等。Sandbox在Linux上的典型實現(xiàn)是Network

namespace。在Linux系統(tǒng)上的Docker環(huán)境中，Container，Networknamespace，Sandbox這三者是綁定在一起的。一個Sandbox可以包含多個Endpoint，這些Endpoint可以來自多個Network。Endpoint:Sandbox加入Network的方式是通過Endpoint完成的。Endpoint的典型實現(xiàn)方式是Vethpair，每個Endpoint都是由某個Network創(chuàng)建。創(chuàng)建后，它就歸屬于該Network。同時，Endpoint還可以加入一個Sandbox。加入后，相當于該Sandbox也加入了此Network。Network:Network的一種典型實現(xiàn)是Linuxbridge。一個Network可以創(chuàng)建多個Endpoint。將這些Endpoint加入到Sandbox，即實現(xiàn)了多個Sandbox的互通?？偨Y(jié)起來：如果要想兩個Container之間可以直接通信，那么最簡單的辦法就是由一個Network創(chuàng)建兩個Endpoint，分別加入這兩個Container對應的Sandbox。注意:不同Network之間默認的隔離性是docker通過設(shè)置Iptables完成的，通過改變Iptables的設(shè)置，可以使得兩個Network互通。標準的Docker網(wǎng)絡(luò)支持以下4類網(wǎng)絡(luò)模式：host模式：使用--net=host指定container模式：使用--net=container:Name_or_ID指定none模式：使用--net=none指定bridge模式：使用--net=bridge指定，設(shè)為默認值橋接模式是最常見的Docker容器網(wǎng)絡(luò)類型。在橋接模式下，Docker會為每個容器分配IP地址及創(chuàng)建虛擬以太網(wǎng)網(wǎng)卡對（Veth）。所有的容器都被連接到Docker在主機綁定的橋接設(shè)備上。被連接到同一個橋接設(shè)備的所有容器，都可以實現(xiàn)互聯(lián)互通。如果容器要對外界提供服務，則用戶需要將容器內(nèi)的服務端口與宿主機的某一端口綁定。這樣所有訪問宿主機目標端口的請求都將通過Docker代理轉(zhuǎn)發(fā)到容器的服務端，最終到達應用。除了橋接模式，Docker也支持主機（host）模式，讓容器直接使用宿主機的網(wǎng)絡(luò)設(shè)備。宿主機模式使得容器占用宿主機的端口資源，而且要求容器具有更高的權(quán)限，因此只有特殊需求的容器，才會使用這種模式，如OpenShift集群中的Router組件。Router主機需要監(jiān)聽計算節(jié)點上的端口，以接受外部的請求，因此Router組件的Pod的容器網(wǎng)絡(luò)為主機模式。本章節(jié)主要介紹了Docker網(wǎng)絡(luò)的情況，從Docker整個生態(tài)棧入手，分析了基于單機和集群兩種不同場景的Docker網(wǎng)絡(luò)，著重分析了在單機模式下Docker網(wǎng)絡(luò)的情況（host/bridge/none/container）。3Kubernetes網(wǎng)絡(luò)場景分析在實際的業(yè)務場景中，業(yè)務組件之間的關(guān)系十分復雜，特別是微服務概念的提出，應用部署的粒度更加細小和靈活。為了支持業(yè)務應用組件的通信聯(lián)系，Kubernetes網(wǎng)絡(luò)的設(shè)計主要致力于解決以下場景：（1）緊密耦合的容器到容器之間的直接通信；（2）抽象的Pod到Pod之間的通信；（3）Pod到Service之間的通信；（4）集群外部與內(nèi)部組件之間的通信；3.1容器到容器的通信在同一個Pod內(nèi)的容器（Pod內(nèi)的容器是不會跨宿主機的）共享同一個網(wǎng)絡(luò)命名空間，共享同一個Linux協(xié)議棧。所以對于網(wǎng)絡(luò)的各類操作，就和它們在同一臺機器上一樣，它們甚至可以用localhost地址訪問彼此的端口。這么做的結(jié)果是簡單、安全和高效，也能減少將已經(jīng)存在的程序從物理機或者虛擬機移植到容器的難度。如圖4中的陰影部分就是Node上運行著的一個Pod實例。容器1和容器2共享了一個網(wǎng)絡(luò)的命名空間，共享一個命名空間的結(jié)果就是它們好像在一臺機器上運行似的，它們打開的端口不會有沖突，可以直接用Linux的本地IPC進行通信。它們之間互相訪問只需要使用localhost就可以。圖4

容器到容器間通信3.2Pod之間的通信每一個Pod都有一個真實的全局IP地址，同一個Node內(nèi)的不同Pod之間可以直接采用對方Pod的IP地址通信，而不需要使用其他發(fā)現(xiàn)機制，例如DNS、Consul或者etcd。Pod既有可能在同一個Node上運行，也有可能在不用的Node上運行，所以通信也分為兩類：同一個Node內(nèi)的Pod之間的通信和不同Node上的Pod之間的通信。1）同一個Node內(nèi)的Pod之間的通信圖5同一個Node內(nèi)的Pod關(guān)系如圖，可以看出，Pod1和Pod2都是通過Veth連接在同一個Docker0網(wǎng)橋上的，它們的IP地址IP1、IP2都是從Docker0的網(wǎng)段上自動獲取的，它們和網(wǎng)橋本身的IP3是同一個網(wǎng)段的。另外，在Pod1、Pod2的Linux協(xié)議棧上，默認路由都是Docker0的地址，也就是說所有非本地的網(wǎng)絡(luò)數(shù)據(jù)，都會被默認發(fā)送到Docker0網(wǎng)橋上，由Docker0網(wǎng)橋直接中轉(zhuǎn)，它們之間是可以直接通信的。2）不同Node上的Pod之間的通信Pod的地址是與Docker0在同一個網(wǎng)段內(nèi)的，我們知道Docker0網(wǎng)段與宿主機網(wǎng)卡是兩個完全不同的IP網(wǎng)段，并且不同Node之間的通信只能通過宿主機的物理網(wǎng)卡進行，因此要想實現(xiàn)位于不同Node上的Pod容器之間的通信，就必須想辦法通過主機的這個IP地址來進行尋址和通信。另外一方面，這些動態(tài)分配且藏在Docker0之后的所謂“私有”IP地址也是可以找到的。Kubernetes會記錄所有正在運行Pod的IP分配信息，并將這些信息保存在etcd中（作為Service的Endpoint）。這些私有IP信息對于Pod到Pod的通信也是十分重要的，因為我們的網(wǎng)絡(luò)模型要求Pod到Pod使用私有IP進行通信。之前提到，Kubernetes的網(wǎng)絡(luò)對Pod的地址是平面的和直達的，所以這些Pod的IP規(guī)劃也很重要，不能有沖突。綜上所述，想要支持不同Node上的Pod之間的通信，就要達到兩個條件：（1）在整個Kubernetes集群中對Pod分配進行規(guī)劃，不能有沖突；（2）找到一種辦法，將Pod的IP和所在Node的IP關(guān)聯(lián)起來，通過這個關(guān)聯(lián)讓Pod可以互相訪問。根據(jù)條件1的要求，我們需要在部署Kubernetes的時候，對Docker0的IP地址進行規(guī)劃，保證每一個Node上的Docker0地址沒有沖突。我們可以在規(guī)劃后手工分配到每個Node上，或者做一個分配規(guī)則，由安裝的程序自己去分配占用。例如Kubernetes的網(wǎng)絡(luò)增強開源軟件Flannel就能夠管理資源池的分配。根據(jù)條件2的要求，Pod中的數(shù)據(jù)在發(fā)出時，需要有一個機制能夠知道對方Pod的IP地址掛在哪個具體的Node上。也就是說要先找到Node對應宿主機的IP地址，將數(shù)據(jù)發(fā)送到這個宿主機的網(wǎng)卡上，然后在宿主機上將相應的數(shù)據(jù)轉(zhuǎn)到具體的Docker0上。一旦數(shù)據(jù)到達宿主機Node，則哪個Node內(nèi)部的Docker0便知道如何將數(shù)據(jù)發(fā)送到Pod。具體情況，如下圖所示。圖6跨Node的Pod通信在圖6中，IP1對應的是Pod1，IP2對應的是Pod2。Pod1在訪問Pod2時，首先要將數(shù)據(jù)從源Node的eth0發(fā)送出去，找到并到達Node2的eth0。也就是說先要從IP3到IP4，之后才是IP4到IP2的送達。3.3Pod到Service之間的通信為了支持集群的水平擴展、高可用，Kubernetes抽象出Service的概念。Service是對一組Pod的抽象，它會根據(jù)訪問策略（LB）來訪問這組Pod。Kubernetes在創(chuàng)建服務時會為服務分配一個虛擬的IP地址，客戶端通過訪問這個虛擬的IP地址來訪問服務，而服務則負責將請求轉(zhuǎn)發(fā)到后端的Pod上。這個類似于反向代理，但是，和普通的反向代理有一些不同：首先它的IP地址是虛擬的，想從外面訪問需要一些技巧；其次是它的部署和啟停是Kubernetes統(tǒng)一自動管理的。Service在很多情況下只是一個概念，而真正將Service的作用落實的是背后的kube-proxy服務進程。在Kubernetes集群的每個Node上都會運行一個kube-proxy服務進程，這個進程可以看作Service的透明代理兼負載均衡器，其核心功能是將到某個Service的訪問請求轉(zhuǎn)發(fā)到后端的多個Pod實例上。對每一個TCP類型的KubernetesService，kube-proxy都會在本地Node上建立一個SocketServer來負責接收請求，然后均勻發(fā)送到后端某個Pod的端口上，這個過程默認采用RoundRobin負載均衡算法。Kube-proxy和后端Pod的通信方式與標準的Pod到Pod的通信方式完全相同。另外，Kubernetes也提供通過修改Service的service.spec.sessionAffinity參數(shù)的值來實現(xiàn)會話保持特性的定向轉(zhuǎn)發(fā)，如果設(shè)置的值為“ClientIP”，則將來自同一個ClientIP的請求都轉(zhuǎn)發(fā)到同一個后端Pod上。此外，Service的ClusterIP與NodePort等概念是kube-proxy通過Iptables和NAT轉(zhuǎn)換實現(xiàn)的，kube-proxy在運行過程中動態(tài)創(chuàng)建與Service相關(guān)的Iptables規(guī)則，這些規(guī)則實現(xiàn)了ClusterIP及NodePort的請求流量重定向到kube-proxy進程上對應服務的代理端口的功能。由于Iptables機制針對的是本地的kube-proxy端口，所以如果Pod需要訪問Service，則它所在的那個Node上必須運行kube-proxy，并且在每個Kubernetes的Node上都會運行kube-proxy組件。在Kubernetes集群內(nèi)部，對ServiceClusterIP和Port的訪問可以在任意Node上進行，這個因為每個Node上的kube-proxy針對該Service都設(shè)置了相同的轉(zhuǎn)發(fā)規(guī)則。綜上所述，由于kube-proxy的作用，在Service的調(diào)用過程中客戶端無需關(guān)心后端有幾個Pod，中間過程的通信、負載均衡及故障恢復都是透明的，如下圖所示。圖7Service的負載均衡轉(zhuǎn)發(fā)訪問Service的請求，不論是用ClusterIP+TargetPort的方式，還是用節(jié)點機IP+NodePort的方式，都會被節(jié)點機的Iptables規(guī)則重定向到kube-proxy監(jiān)聽Service服務代理端口。Kube-proxy接收到Service的訪問請求后，會如何選擇后端Pod？首先，目前kube-proxy的負載均衡只支持RoundRobin算法。該算法按照成員列表逐個選取成員，如果一輪循環(huán)完，便從頭開始下一輪，如此循環(huán)往復。Kube-proxy的負載均衡器在RoundRobin算法的基礎(chǔ)上還支持Session保持。如果Service在定義中指定了Session保持，則kube-proxy接收請求時會從本地內(nèi)存中查找是否存在來自該請求IP的affinityState對象，如果存在該對象，且Session沒有超時，則kube-proxy將請求轉(zhuǎn)向該affinityState所指向的后端Pod。如果本地存在沒有來自該請求IP的affinityState對象，記錄請求的IP和指向的Endpoint。后面的請求就會粘連到這個創(chuàng)建好的affinityState對象上，這就實現(xiàn)了客戶端IP會話保持的功能。接下來我們深入分析kube-proxy的實現(xiàn)細節(jié)。kube-proxy進程為每個Service都建立了一個“服務代理對象”，服務代理對象是kube-proxy程序內(nèi)部的一種數(shù)據(jù)結(jié)構(gòu)，它包括一個用于監(jiān)聽此服務請求的SocketServer，SocketServer的端口是隨機選擇的一個本地空閑端口。此外，kube-proxy內(nèi)部也建立了一個“負載均衡器組件”，用來實現(xiàn)SocketServer上收到的連接到后端多個Pod連接之間的負載均衡和會話保持能力。kube-proxy通過查詢和監(jiān)聽APIServer中Service與Endpoint的變化來實現(xiàn)其主要功能，包括為新創(chuàng)建的Service打開一個本地代理對象（代理對象是kube-proxy程序內(nèi)部的一種數(shù)據(jù)結(jié)構(gòu)，一個Service端口是一個代理對象，包括一個用于監(jiān)聽的服務請求的SocketServer），接收請求，針對發(fā)生變化的Service列表，kube-proxy會逐個處理。下面是具體的處理流程：（1）如果該Service沒有設(shè)置集群IP（ClusterIP），則不做任何處理，否則，獲取該Service的所有端口定義列表（spec.ports域）（2）逐個讀取服務端口定義列表中的端口信息，根據(jù)端口名稱、Service名稱和Namespace判斷本地是否已經(jīng)存在對應的服務代理對象，如果不存在就新建，如果存在且Service端口被修改過，則先刪除Iptables中和該Service相關(guān)的的規(guī)則，關(guān)閉服務代理對象，然后走新建流程，即為該Service端口分配服務代理對象并為該Service創(chuàng)建相關(guān)的Iptables規(guī)則。（3）更新負載均衡器組件中對應Service的轉(zhuǎn)發(fā)地址表，對于新建的Service，確定轉(zhuǎn)發(fā)時的會話保持策略。（4）對于已經(jīng)刪除的Service則進行清理。圖8Kube-proxy與APIServer的交互過程3.4外部到內(nèi)部的訪問Pod作為基本的資源對象，除了會被集群內(nèi)部的Pod訪問，也會被外部使用。服務是對一組功能相同Pod的抽象，以它為單位對外提供服務是最合適的粒度。由于Service對象在ClusterIPRange池中分配到的IP只能在內(nèi)部訪問，所以其他Pod都可以無障礙地訪問到它。但如果這個Service作為前端服務，準備為集群外的客戶端提供服務，就需要外部能夠看到它。Kubernetes支持兩種對外服務的Service的Type定義：NodePort和LoadBalancer。（1）NodePort在定義Service時指定spec.type=NodePort，并指定spec.ports.nodePort的值，系統(tǒng)就會在Kubernetes集群中的每個Node上打開一個主機上的真實端口號。這樣，能夠訪問Node的客戶端就能通過這個端口號訪問到內(nèi)部的Service了。（2）LoadBalancer如果云服務商支持外接負載均衡器，則可以通過spec.type=LoadBalancer定義Service，同時需要指定負載均衡器的IP地址。使用這種類型需要指定Service的NodePort和ClusterIP。對于這個Service的訪問請求將會通過LoadBalancer轉(zhuǎn)發(fā)到后端Pod上去，負載分發(fā)的實現(xiàn)方式依賴于云服務商提供的LoadBalancer的實現(xiàn)機制。（3）外部訪問內(nèi)部Service原理我們從集群外部訪問集群內(nèi)部，最終都是落在具體的Pod上。通過NodePort的方式就是將kube-proxy開放出去，利用Iptables為服務的NodePort設(shè)置規(guī)則，將對Service的訪問轉(zhuǎn)到kube-proxy上，這樣kube-proxy就可以使用和內(nèi)部Pod訪問服務一樣的方式來訪問后端的一組Pod了。這種模式就是利用kube-proxy作為負載均衡器，處理外部到服務進一步到Pod的訪問。而更常用的是外部均衡器模式。通常的實現(xiàn)是使用一個外部的負載均衡器，這些均衡器面向集群內(nèi)的所有節(jié)點。當網(wǎng)絡(luò)流量發(fā)送到LoadBalancer地址時，它會識別出這是某個服務的一部分，然后路由到合適的后端Pod。所以從外面訪問內(nèi)部的Pod資源，就有了很多種不同的組合。外面沒有負載均衡器，直接訪問內(nèi)部的Pod外面沒有負載均衡器，直接通過訪問內(nèi)部的負載均衡器來訪問Pod外面有負載均衡器，通過外部負載均衡器直接訪問內(nèi)部的Pod外面有負載均衡器，通過訪問內(nèi)部的負載均衡器來訪問內(nèi)部的Pod第一種情況的場景十分少見，只是在特殊的時候才需要。我們在實際的生產(chǎn)項目中需要逐一訪問啟動的Pod，給它們發(fā)送一個刷新指令。只有這種情況下才使用這種方式。這需要開發(fā)額外的程序，讀取Service下的Endpoint列表，逐一和這些Pod進行通信。通常要避免這種通信方式，例如可以采取每個Pod從集中的數(shù)據(jù)源拉命令的方式，而不是采取推命令給它的方式來避免。因為具體到每個Pod的啟停本來就是動態(tài)的，如果依賴了具體的Pod們就相當于繞開了Kubernetes的Service機制，雖然能夠?qū)崿F(xiàn)，但是不理想。第二種情況就是NodePort的方式，外部的應用直接訪問Service的NodePort，并通過Kube-proxy這個負載均衡器訪問內(nèi)部的Pod。第三種情況是LoadBalancer模式，因為外部的LoadBalancer是具備Kubernetes知識的負載均衡器，它會去監(jiān)聽Service的創(chuàng)建，從而知曉后端的Pod啟停變化，所以它有能力和后端的Pod進行通信。但是這里有個問題需要注意，那就是這個負載均衡器需要有辦法直接和Pod進行通信。也就是說要求這個外部的負載均衡器使用和Pod到Pod一樣的通信機制。第四種情況也很少使用，因為需要經(jīng)歷兩級的負載均衡設(shè)備，而且網(wǎng)絡(luò)的調(diào)用被兩次隨機負載均衡后，更難跟蹤了。在實際生產(chǎn)環(huán)境中出了問題排錯時，很難跟蹤網(wǎng)絡(luò)數(shù)據(jù)的流動過程。（4）外部硬件負載均衡器模式在很多實際的生產(chǎn)環(huán)境中，由于是在私有云環(huán)境中部署Kubernetes集群，所以傳統(tǒng)的負載均衡器都對Service無感知。實際上我們只需要解決兩個問題，就可以將它變成Service可感知的負載均衡器，這也是實際系統(tǒng)中理想的外部訪問Kubernetes集群內(nèi)部的模式。通過寫一個程序來監(jiān)聽Service的變化，將變化按照負載均衡器的通信接口，作為規(guī)則寫入負載均衡器。給負載均衡器提供直接訪問Pod的通信手段。如下圖，說明了這個過程。圖9自定義外部負載均衡器訪問Service這里提供了一個ServiceAgent來實現(xiàn)Service變化的感知。該Agent能夠直接從etcd中或者通過接口調(diào)用APIServer來監(jiān)控Service及Endpoint的變化，并將變化寫入外部的硬件負載均衡器中。同時，每臺Node上都運行著有路由發(fā)現(xiàn)協(xié)議的軟件，該軟件負責將這個Node上所有的地址通過路由發(fā)現(xiàn)協(xié)議組播給網(wǎng)絡(luò)內(nèi)的其他主機，當然也包含硬件負載均衡器。這樣硬件負載均衡器就能知道每個Pod實例的IP地址是在哪臺Node上了。通過上述兩個步驟，就建立起一個基于硬件的外部可感知Service的負載均衡器。3.5總結(jié)本章重點介紹了Kubernetes網(wǎng)絡(luò)的各種場景，包括容器之間、Pod之間、Pod到Service、外部到內(nèi)部的這4種場景下，不同的通信模式。在設(shè)計Kubernetes容器平臺的時候，建議按照這些通信模式，根據(jù)具體的場景，逐一比對選擇合適的解決方案。其中，需要注意的是外部到內(nèi)部的訪問，既可以通過NodePort，也可以通過LoadBalancer的方式亦或是Ingress模式，需要按照具體的場景來分析。NodePort服務是暴露服務的最原始方式，會在所有節(jié)點上打開特定的端口，并且發(fā)送到此端口的任何流量都將轉(zhuǎn)發(fā)到該服務。這種方法有很多缺點：每個端口只能有一個服務；默認只能使用端口30000～32767；如果節(jié)點IP地址發(fā)生更改，則會帶來問題。由于這些原因，不建議在生產(chǎn)中使用這種方法。如果服務可用性不是特別關(guān)注，或者特別關(guān)注成本，則這個方案比較合適。LoadBalancer是服務暴露的標準方式，將會啟動一個網(wǎng)絡(luò)負載均衡器，提供一個將所有流量轉(zhuǎn)發(fā)到服務的IP地址。如果直接暴露一個服務，這是默認的方法。指定的端口上所有的流量將被轉(zhuǎn)發(fā)到該服務，沒有過濾、路由等。這就意味著可以發(fā)送幾乎任何類型流量，如HTTP、TCP、UDP、Websocket、gRPC或其他。這個方式最大的缺點是，使用LoadBalancer公開的每項服務都將獲得自己的IP地址，并且必須為每個服務使用一個LoadBalancer，這將會付出比較大的代價。Ingress實際上不是一種服務。相反，它位于多個服務之前，充當集群中的“智能路由器”或入口點。默認的Ingress控制器將會啟動一個HTTP（s）負載均衡器。這將可以執(zhí)行基于路徑和基于子域名的路由到后端服務。Ingress可能是暴露服務最強大的方式了，但也可能是最復雜的。如果希望在相同的IP地址下暴露多個服務，并且這些服務都使用相同的L7協(xié)議，則Ingress是最有用的。4Kubernetes網(wǎng)絡(luò)組件介紹4.1Kubernetes網(wǎng)絡(luò)框架CNI基于Docker的Kubernetes平臺為什么沒有選擇CNM作為其網(wǎng)絡(luò)設(shè)計框架？畢竟大部分容器平臺肯定會支持Docker的網(wǎng)絡(luò)組件，為什么不使用相同的組件呢？這就要從Kubernetes平臺設(shè)計初衷說起，Kubernetes是一個支持多容器的運行環(huán)境，而Docker只是其中一個容器而已。Docker網(wǎng)絡(luò)驅(qū)動設(shè)計中，做了很多和Kubernetes不兼容的假設(shè)。例如，Docker中有“本地”驅(qū)動和“全局”驅(qū)動概念，“本地”驅(qū)動實現(xiàn)單機版，無法實現(xiàn)跨節(jié)點協(xié)作，“全局”驅(qū)動libkv可實現(xiàn)跨節(jié)點協(xié)作。但是，libkv接口太過于底層，而且架構(gòu)模式也是Docker內(nèi)部的量身定制版本，對于Kubernetes的應用會帶來性能、可擴展性和安全性方面的問題。CNI（ContainerNetworkingInterface）提供了一種Linux的應用容器的插件化網(wǎng)絡(luò)解決方案。最初是由rktNetworkingProposal發(fā)展而來。也就是說，CNI本身并不是完全針對Docker的容器，而是提供一種普適的容器網(wǎng)絡(luò)解決方案。模型涉及兩個概念：容器：擁有獨立Linux網(wǎng)絡(luò)命名空間的獨立單元。比如rkt/docker創(chuàng)建出來的容器。網(wǎng)絡(luò)（Networking）：網(wǎng)絡(luò)指代了可以相互聯(lián)系的一組實體。這些實體擁有各自獨立唯一的IP。這些實體可以是容器，是物理機，或者是其他網(wǎng)絡(luò)設(shè)備（比如路由器）等。CNI的接口設(shè)計非常簡潔，不需要守護進程，只有兩個接口ADD/DELETE，通過一個簡單的shell腳本就可以完成。相對于CNM的復雜設(shè)計，CNI更加適合快速開發(fā)和迭代。4.2CNI支持的開源組件4.2.1FlannelFlannel之所以可以搭建Kubernetes依賴的底層網(wǎng)絡(luò)，是因為它可以實現(xiàn)以下兩點：它給每個node上的docker容器分配相互不相沖突的IP地址；它能給這些IP地址之間建立一個覆蓋網(wǎng)絡(luò)，通過覆蓋網(wǎng)絡(luò)，將數(shù)據(jù)包原封不動的傳遞到目標容器內(nèi)。Flannel是CoreOS團隊針對Kubernetes設(shè)計的一個網(wǎng)絡(luò)規(guī)劃服務，簡單來說，它的功能是讓集群中的不同節(jié)點主機創(chuàng)建的Docker容器都具有全集群唯一的虛擬IP地址。在默認的Docker配置中，每個節(jié)點上的Docker服務會分別負責所在節(jié)點容器的IP分配。這樣導致的一個問題是，不同節(jié)點上容器可能獲得相同的內(nèi)外IP地址。并使這些容器之間能夠之間通過IP地址相互找到，也就是相互ping通。Flannel的設(shè)計目的就是為集群中的所有節(jié)點重新規(guī)劃IP地址的使用規(guī)則，從而使得不同節(jié)點上的容器能夠獲得“同屬一個內(nèi)網(wǎng)”且“不重復的”IP地址，并讓屬于不同節(jié)點上的容器能夠直接通過內(nèi)網(wǎng)IP通信。Flannel實質(zhì)上是一種“覆蓋網(wǎng)絡(luò)(OverlayNetwork)”，也就是將TCP數(shù)據(jù)包裝在另一種網(wǎng)絡(luò)包里面進行路由轉(zhuǎn)發(fā)和通信，默認的節(jié)點間數(shù)據(jù)通信方式是UDP轉(zhuǎn)發(fā)。圖10Flannel跨節(jié)點Pod通信圖舉個例子，上圖是跨節(jié)點Pod通信?？梢钥吹剑現(xiàn)lannel首先創(chuàng)建了一個名為flannel0的網(wǎng)橋，而且這個網(wǎng)橋的一端連接Docker0網(wǎng)橋，另一端連接一個叫做flanneld的服務進程。flanneld進程并不簡單，它上連etcd，利用etcd來管理可分配的IP地址段資源，同時監(jiān)控etcd中每個Pod的實際地址，并在內(nèi)存中建立了一個Pod節(jié)點路由表；它下連Docker0和物理網(wǎng)絡(luò)，使用內(nèi)存中的Pod節(jié)點路由表，將Docker0發(fā)給它的數(shù)據(jù)包包裝起來，利用物理網(wǎng)絡(luò)的連接將數(shù)據(jù)包投遞到目標flanneld上，從而完成Pod到Pod之間的直接地址通信。4.2.2OVSOpenvSwitch是一個開源的虛擬交換機軟件，有點像Linux中的bridge，但是功能要復雜的多。OpenvSwitch的網(wǎng)橋可以直接建立多種通信通道（隧道）。這些通道的建立可以很容易地通過OVS的配置命令實現(xiàn)。在Kubernetes、Docker場景下，主要是建立L3到L3點隧道。如下圖所示。圖11OVSwithGRE原理圖首先，為了避免Docker創(chuàng)建的Docker0地址產(chǎn)生沖突（因為DockerDaemon啟動且給Docker0選擇子網(wǎng)地址時只有幾個備選列表，很容易產(chǎn)生沖突），我們可以將Docker0網(wǎng)橋刪除，手動建立一個Linux網(wǎng)橋，然后手動給這個網(wǎng)橋配置IP地址范圍。其次，建立OpenvSwitch的網(wǎng)橋OVS，使用ovs-vsctl命令給OVS網(wǎng)橋增加GRE端口，在添加GRE端口時要將目標連接的NodeIP地址設(shè)置為對端的IP地址。對每一個對端IP地址都需要這么操作（對于大型集群網(wǎng)絡(luò)，這可是個體力活，要做自動化腳本來完成）。最后，將OVS的網(wǎng)橋作為網(wǎng)絡(luò)接口，加入Docker的網(wǎng)橋上（Docker0或者自己手工建立的新網(wǎng)橋）。重啟OVS網(wǎng)橋和Docker的網(wǎng)橋，并添加一個Docker的地址段到Docker網(wǎng)橋的路由規(guī)則項，就可以將兩個容器的網(wǎng)絡(luò)連接起來了。OVS的優(yōu)勢是，作為開源虛擬交換機軟件，它相對比較成熟和穩(wěn)定，而且支持各類網(wǎng)絡(luò)隧道協(xié)議，經(jīng)過了OpenStack等項目的考驗。另一方面，在前面介紹Flannel的時候可知Flannel除了支持建立Overlay網(wǎng)絡(luò)，保證Pod到Pod的無縫通信，還和Kubernetes、Docker架構(gòu)體系結(jié)合緊密。Flannel能夠感知Kubernetes的Service，動態(tài)維護自己的路由表，還通過etcd來協(xié)助Docker對整個Kubernetes集群中Docker0的子網(wǎng)地址分配。而我們在使用O