儘管網路在數據中心基礎設施中扮演核心角色，但是要解決網路設置，拓撲和性能的問題已經超出當前Mesos的範圍，通常情況下，提供一個一刀切的網路解決方案是一個巨大的挑戰。但是，Mesos提供了一個可插拔的機制可以簡化與現有網路解決方案的集成並啟用如IP-per-container，細粒度的任務隔離和服務發現等功能。

方案設計

從網路的角度來看，為了提供類似於虛擬機環境提供的最終用戶體驗，為每個容器提供自己的IP地址和網路命名空間是非常重要的。為容器提供隔離的網路堆棧可以確保邏輯網路隔離以及容器之間的網路性能隔離。此外，Ip-per-container允許用戶/開發人員使用傳統的網路操作工具（traceroute，tcpdump，wireshark）和他們熟悉的應用程序，並幫助他們在調試網路連接/性能問題方面的提高生產力。從操作的角度來看，識別容器特定流量也變得更容易，從而簡化了對容器的網路性能和安全策略的實施。

DC/OS的默認每容器IP解決方案需要與運行DC/OS的網路無關。因此，為了實現容器IP，需要使用虛擬網路。Overlay技術使容器網路拓撲與底層主機網路無關。此外，Overlay技術提供了容器流量與主機流量的完全隔離，使得對容器流量的策略執行更簡單並且獨立於主機流量。實現Overlay技術的挑戰是容器發送和接收流量時封裝和解封裝容器流量的成本。為了最小化這些封裝和拆分操作對容器網路吞吐量的影響，Overlay技術必須將封裝/拆分操作作為主機操作系統內核中的數據包處理流水線的一部分。

為了實現DC/OS的容器IP解決方案，使用Overlay技術，因此需要選擇Linux內核主動支持的Overlay技術。Linux內核支持的最常見的Overlay技術是VxLAN。

DC/OS的Overlay設計做出以下假設/約束：

• 由於集中式IPAM缺乏對可用性和可靠性的保證，方案無法使用集中的IPAM。

• 需要避免第2層的單播泛洪，使網路可擴展。這意味著方案不能依賴廣播ARP來獲取容器的MAC地址。

• 該解決方案需要支持MesosContainerizer和DockerContainerizer，即在同一個Overlay上，方案應該能夠同時運行Docker和Mesos容器，並允許它們相互通信。

基於上述假設/約束，DC/OS使用基於VxLAN的第三層Overlay技術。

術語

• 二層交換

  二層交換是工作在OSI七層協議的2層上，也就是數據鏈路層，數據鏈路層只有MAC地址沒有IP地址，無法配置靜態路由（有個例外是可以在vlan上配IP）。

• 三層交換

  三層交換是工作在OSI七層協議的3層上，可以啟用路由協議（靜態或動態），還可以啟用訪問控制列表，總之，路由能做的事三層交換基本都能做，三層交換沒有NAT。

• IPAM

  IPAM用於發現、監視、審核和管理企業網路上使用的IP地址空間。IPAM 可以對運行動態主機配置協議 (DHCP)和域名服務 (DNS) 的伺服器進行管理和監視。

• ARP

  地址解析協議，即ARP（Address Resolution Protocol），是根據IP地址獲取物理地址的一個TCP/IP協議。主機發送信息時將包含目標IP地址的ARP請求廣播到網路上的所有主機，並接收返回消息，以此確定目標的物理地址；收到返回消息後將該IP地址和物理地址存入本機ARP緩存中並保留一定時間，下次請求時直接查詢ARP緩存以節約資源。

• VXLAN

  VXLAN(Virtual Extensible LAN),是一種網路虛似化技術,試圖改進大型雲計算的部署時的擴展問題.可以說是對VLAN的一種擴展,由於VLAN Header頭部限長是12bit, 導致VLAN的限制個數是2^12=4096個,無法滿足日益增長的需求.目前 VXLAN 的報文 Header 內有 24 bit，可以支持 2^24次方的 VNI 個數(VXLAN中通過VNI來識別，相當於VLAN ID). 參考資料

• VTEP

  VXLAN隧道終端 (VXLAN Tunneling End Point)，用於多VXLAN報文進行封裝/解封，包括MAC請求報文和正常VXLAN數據報文，在一端封裝報文後通過隧道向另一端VTEP發送封裝報文，另一端VTEP接收到封裝的報文解封裝後根據被封裝的MAC地址進行轉發。VTEP可由支持VXLAN的硬體設備或軟體來實現。

場景

下圖通過數據包的流動闡述了DC/OS中基於Overlay技術實現的容器網路通信方案。

上圖演示了一個擁有2個Agent的DC/OS集群，要讓DC/OS的Overlay工作，需要一個足夠大的地址空間為之上的容器分配地址。選定的地址空間不能覆蓋主機網路的地址空間以避免因為錯誤的配置影響整個主機網路。在上例中，主機網路使用10.0.0.0/8的地址空間，Overlay使用9.0.0.0/8的地址空間。

理想情況下，我們希望IPAM為Overlay層上的所有容器執行地址分配。然而，很難通過全球IPAM來解決可靠性和一致性問題。例如，當Agent宕機時，我們如何通知IPAM？IPAM應該提供多大的可用性來保證集群的99％正常運行時間（沒有IPAM容器無法運行）？鑒於全球IPAM引發的複雜性，DC/OS選擇採用更簡單的架構，將地址空間劃分為較小的塊，並允許Agent節點擁有這些塊。在該示例中，9.0.0.0/8的空間已被拆分為/24個子網，每個子網都由Agent擁有。在示例中，Agent 1已分配9.0.1.0/24，Agent 2已分配9.0.2.0/24。

給定Agent的一個/24子網，子網需要進一步拆分成更小的塊，因為Mesos的Agent可能需要同時啟動Mesos容器以及Docker容器。與Agent一樣，我們可以在Mesos容器和Docker容器之間進行靜態地址分配。在這個例子中，我們將/24空間靜態地刻畫成了一個/25空間，分別用於Mesos容器和Docker容器。此外，請注意，Mesos容器由MesosContainerizer在「m-dcos」橋上啟動，Docker容器由DockerContainerizer
使用Docker守護程序在「d-dcos」橋上啟動。下面看一下數據包在容器到容器通信過程中的具體流轉過程。

同一宿主機上的容器到容器通信

假設9.0.1.0/25上的Mesos容器想要與9.0.1.128/25上與Docker容器通信。報文流轉如下：

1. 9.0.1.0/25上的容器將數據包發送到默認網關，此示例中是「m-dcos」網橋，分配了IP地址9.0.1.1/25。

2. m-dcos網橋將處理數據包，並且由於m-dcos網橋存在於主機網路命名空間中，它將向網路堆棧發送數據包以進行路由。

3. 數據包將被發送到d-dcos，它將數據包切換到9.0.1.128/25子網。

跨宿主機的容器到容器通信

假設9.0.1.0/25（Agent 1）上的Mesos容器想要在9.0.2.128/25（Agent 2）上與Docker容器通信。報文流轉如下：

• 來自9.0.1.0/25的數據包將被發送到「m-dcos」網橋（9.0.1.1/25）上的默認網關。該網橋將處理數據包並將其發送到網路堆棧。由於橋接器已在主機網路命名空間中註冊，數據包將使用主機網路命名空間路由表進行路由。

• 主機網路路由表中存在一條路由9.0.2.0/24 -> 44.128.0.2（將在下一節中說明如何安裝此路由），這實質上是告訴主機此數據包需要通過VxLAN1024發送（主機網路路由表裡也存在44.128.0.0/20 -> VxLAN1024的路由條目）。

• 由於44.128.0.2直接連接在VxLAN1024上。內核會嘗試對44.128.0.2進行ARP解析。在配置Overlay期間，DC/OS會在ARP緩存中為VTEP端點44.128.0.2安裝一個條目，因此內核ARP查找會成功。

• 內核路由模塊會將目的MAC設置為70:B3:D5:00:00:02的數據包，發送給VxLAN設備VxLAN1024。

• 要轉發數據包，VxLAN1024需要一個MAC地址為70:B3:D5:00:00:01作為Key的條目。VxLAN轉發資料庫中的此條目是由DC/OS編程寫入，指向Agent 2的IP地址。DC/OS能夠對此條目進行編程的原因是因為它知道Agent的IP和所有Agent上存在的VTEP。

• 此時，數據包封裝在UDP頭（由VxLAN FDB指定）中，並發送到Agent 2上存在的VTEP。

• Agent 2上的VxLAN1024對數據包進行解封，由於目標MAC地址設置為Agent 2上的VxLAN1024的MAC地址，因此該數據包將由Agent 2上的VxLAN1024進行處理。

• 在Agent 2中，路由表具有子網9.0.2.128/25的條目，直接連接到橋「d-dcos」。因此，數據包將被轉發到連接到「d-dcos」網橋的容器進行處理。

架構

上圖描述了DC/OS實現的用於實現Overlay疊加網路技術的軟體體系結構。圖中橙色的塊是必須建造的缺失組件。

DC/OS modules for Mesos

要配置基礎的DC/OS疊加網路，需要一個可以為每個Agent分配子網的實體組件。該實體組件還需要配置Linux網橋，以及在自己的子網中啟動Mesos和Docker容器。此外，每個Agent上的VTEP需要分配IP地址和MAC地址，並且Agent上的路由表需要配置正確的路由，以便於容器通過DC/OS疊加網路進行通信。

Master節點上的Overlay組件：

• 它將負責將子網分配給每個Agent。下述將更詳細地描述Master組件如何使用複製的日誌來檢查這些信息，以便在故障切換到新的Master時進行恢復。

• 它將監聽Agent疊加網路組件以便於註冊和恢復其分配的子網。Agent上的Overlay組件還將使用此端點來了解分配給Agent自身的疊加子網（在多個虛擬網路的情況下），分配給疊加網路中每個Mesos和Docker網橋的子網以及分配給容器的VTEP IP和MAC地址。

• 它通過HTTP端點「overlay-master/state」來展示DC/OS中所有虛擬網路的狀態。響應信息的詳細描述參考此處。

Agent節點上的Overlay組件：

• 它負責向Master節點上的Overlay組件（Master模塊）註冊。註冊後，它檢索分配的Agent子網，分配給其Mesos和Docker網橋的子網以及VTEP信息（VTEP的IP和MAC地址）。

• 基於分配的Agent子網，它負責生成用於MesosContainerizer的network/cni隔離器的CNI（容器網路介面）網路配置。

• 它負責創建DockerContainerizer使用的Docker網路。

• 它通過HTTP端點overlay-agent/overlays。虛擬網路服務使用此介面檢索有關該特定代理的疊加網路信息。

虛擬網路服務（疊加網路編排）

虛擬網路服務（Navstar）是在每個Agent上運行的疊加協調器服務，負責以下功能。它是一個包含DC/OS疊加網路的非實時組件以及其他與網路相關的DC/OS服務模塊的子系統。在每個Agent上運行的虛擬網路服務負責以下功能：

1. 與Agent疊加網路模塊對話，獲取分配給Agent的子網，VTEP IP和MAC地址。

2. 在Agent上創建VTEP。

3. 將路由寫入到各個Agent的各個子網。

4. 使用VTEP IP和MAC地址寫入ARP緩存。

5. 使用VTEP MAC地址和隧道端點信息寫入VxLAN FDB。

6. 使用Lashup（一個分布式CRDT存儲引擎）可以將Agent疊加網路信息可靠地傳播到集群內的所有Agent。這是虛擬網路服務執行的最重要的功能之一，因為只有擁有群集中所有Agent的全部信息，虛擬網路服務才能對所有Agent上的所有疊加子網的每個Agent進行路由。

配置MesosContainerizer和DockerContainerizer以使用已分配的子網

一旦DC/OS模塊從主DC/OS模塊檢索子網信息，它將執行以下操作，以允許MesosContainerizer和DockerContainerizer在疊加層上啟動容器：

對於MesosContainerizer，DC/OS模塊可以在指定位置生成CNI配置。 CNI配置將具有network/cni隔離器的橋接信息和IPAM信息，以在m-[虛擬網路名稱]橋上配置容器。

對於DockerContainerizer，DC/OS模塊在檢索子網後，將通過dockernetwork命令創建一個具有規範名稱d-[虛擬網路名稱]的容器網路。它將使用以下docker命令執行此操作：

注意：DockerContainerizer使用DC / OS覆蓋的假設是主機正在運行Docker v1.11或更高版本。

注意：默認的 [overlayMTU]= 1420位元組。

參考

• https://dcos.io/docs/1.9/overview/design/overlay/#using-replicated-log-to-coordinate-subnet-allocation-in-master-

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！