容器網路需要面對的最重要的一個問題是容器的IP地址。DC/OS的容器網路在Mesos V0.25版本（2015年10月）之前沒有明確的方案，需要手動維護創建。在Mesos V0.25到V1.0（2016年7月）這段時期，Docker容器技術推出了網路擴展功能，Docker容器有了原生的網路擴展支持，典型的第三方插件有Weave，Calico等，此階段可以通過Marathon的API在創建容器的同時賦予一個IP地址。在Mesos V1.0之後，Mesos原生支持了CNI網路，無論是Docker容器還是AppC容器，IP-per-container變得非常簡單。

總之，Mesos支持Mesos容器化和Docker容器化兩種容器運行時方案，這兩種運行時都支持IP-per-container，允許容器綁定到不同的IP網路，不同的是兩種運行時支持的IP-per-container的實現機制。Mesos容器化使用network/cni隔離器實現的CNI為容器提供網路支持；Docker容器化依賴Docker Daemon通過Docker的容器網路模型提供網路支持。

IP-per-container僅是為容器隔離提供網路支持方案中的一種，Mesos容器化還可以通過其它方案為容器提供網路支持，如：埠映射隔離器。

Mesos容器化和Docker容器化在Mesos中使用相同的網路配置描述：

此外，Docker容器化在描述網路配置的同時還需要對容器進行定義：

在DC/OS中，通過Marathon管理容器（AppC或Docker）時，當前支持三種網路模式配置：

• BRIDGE

適用於Docker容器服務。在該模式下，容器埠（容器內部定義的埠）被映射為容器宿主機上對應的埠。在該模式下，容器中的應用綁定到容器的埠，Docker網路服務負責把這些埠綁定到主機的埠。

• USER

適用於Docker容器服務。在該模式下，容器埠（容器內部定義的埠）被映射為容器宿主機上對應的埠。在該模式下，容器中的應用綁定到容器的埠，Docker網路服務負責把這些埠綁定到主機的埠。該模式主要用於適配Docker自定義網路（通過Docker插件擴展實現），在Mesos中主要通過CNI插件結合Mesos CNI網路隔離組件來實現。

• HOST

同時適用於AppC容器應用和Docker容器應用。在該模式下，應用直接綁定到宿主機的一個或多個埠。

1. VIPs

DC/OS提供了一個名為Minuteman的伺服器端內部微服務之間的東-西向（區分於Client-Server的南-北向）4層負載均衡。為了易於服務的配置和發現，DC/OS採用命名（name-based）VIPs來定位服務。因此，客戶端訪問服務時連接的是一個服務地址而不是具體的IP地址，同時DC/OS可以很容易的將指向一個命名VIP的調用請求映射到多個具體的IP地址和埠，從而實現負載調度。採用命名VIPs的另一個好處是可以避免與基於IP的VIP產生衝突，在服務安裝時可以自動創建。

一個命名VIP包含3個組成部分：

• 私有的虛擬IP地址

• 埠（通過該埠提供服務）

• 服務名稱

VIPs的命名遵循如下規則：

.marathon.l4lb.thisdcos.directory:

根據Marathon所運行的是Docker容器鏡像還是AppC容器鏡像的不同，在Marathon應用定義中分別用portMappings和portDefinitions兩個不同的屬性節點進行配置。

1.1 AppC容器配置

如上示例，該配置定義了兩個VIP：

• myservice.marathon.l4lb.thisdcos.directory:6666

• myservice.marathon.l4lb.thisdcos.directory:7777

客戶端（註：此處指DC/OS集群中的其他服務）可以通過調用埠為6666的VIP訪問服務提供的JMX管理功能，可以通過調用埠為7777的VIP訪問服務提供的業務API。

上述配置也可以通過DC/OS的WEB管理控制台進行配置：

1.2. Docker容器配置

如上示例，該配置定義了一個名為myservice的服務，該服務通過Docker鏡像chrisrc/myservice提供。與上例類似，該服務也定義了兩個客戶端（註：此處指DC/OS集群中的其他服務）可以直接訪問的VIP：

• myservice.marathon.l4lb.thisdcos.directory:6666

• myservice.marathon.l4lb.thisdcos.directory:7777

同樣，上述配置也可以通過DC/OS的WEB管理控制台進行配置。

2. 服務埠配置

需要再次說明的是，這裡的應用服務是指Docker容器或AppC容器，如非特別指明為Docker容器，則適用於兩者。此外，DC/OS中的容器網路包括前述提到的BRIDGE、USER和HOST三種模式。

2.1. 埠配置相關的屬性

2.2. 隨機埠設置

在埠配置中，如果取值為0，則由Marathon為應用服務隨機分配埠。但是，如果在「portMappings」中，「containerPort」參數設置為0，Marathon會將「containerPort」和「hostPort」取相同的值。

2.3. 環境變數

Marathon會將每個應用配置的宿主機埠值以環境變數$PORT0，$PORT1，...的形式提供給應用容器環境。每一個Marathon應用默認都會分配一個埠，所以$PORT0總是可訪問的。這些變數在Marathon運行的Docker容器內也是可用的。此外，如果某個埠設置了NAME名稱，則也可以通過$PORT_NAME變數訪問。

在BRIDGE或USER網路模式下，要確保應用服務綁定到了「portMappings」中定義的「containerPort」參數。如果「containerPort」參數取值為0，其值與「hostPort」相同，可用通過$PORT變數來訪問。

2.4. 埠配置示例

2.4.1. HOST網路模式

HOST網路模式是Docker容器應用服務的默認網路模式，也是非Docker容器應用（AppC容器）的唯一可用網路模式。

啟用HOST網路模式

對Docker容器來說，HOST模式默認是啟用的，如果想顯式配置，可用通過network屬性配置：

對非Docker容器應用，不需要做任何設置。

設定埠

通過「ports」設置埠：

或通過「portDefinitions」設置埠：

在上述示例中，主機埠被隨機分配，可以通過環境變數$PORT0，$PORT1，$PORT2訪問。Marathon還會隨機的為三個主機埠分配三個服務埠。

如果要明確指定服務埠，則可以使用如下配置：

使用這種配置時，主機埠$PORT0，$PORT1和$PORT2仍然隨機分配。但是，三個服務埠分別是2001，2002，2003。上述兩種配置，可以使用HAProxy在服務埠和主機埠之間建立映射，通過服務埠訪問具體的容器應用服務。

如果想讓應用服務的服務埠與主機埠一致，可以將「requirePorts」參數值設置為「true」（默認值為「false」）。Marathon在調度應用時會確保調度到三個服務埠都可用的Agent主機上：

"ports": [ 2001, 2002, 3000 ], "requirePorts" : true

此時，服務埠，主機埠（包括環境變數$PORT0，$PORT1，$PORT2）都為2001，2002和3000。該屬性參數在未使用服務代理將服務埠請求映射到主機埠時特別有用。

屬性參數「portDefinitions」數組可以為每一個埠指定一個協議，一個名稱和一組標籤。當啟動新任務時，Marathon會將這些元數據信息提交給Mesos，Mesos會將這些信息添加到任務的「discovery」欄位中，自定義網路發現服務實現就可以使用這些信息。

引用埠

可以在Dockerfile定義中引用主機埠：

CMD ./my-app --http-port=$PORT0 --https-port=$PORT1 --monitoring-port=$PORT2

也可以在非Docker容器的Marathon應用定義中的「cmd」參數中引用主機埠：

"cmd": "./my-app --http-port=$PORT0 --https-port=$PORT1 --monitoring-port=$PORT2"

2.4.2. BRIDGE網路模式

BRIDGE網路模式允許在主機埠與容器內埠建立映射，這種模式僅適用於Docker容器。

啟用BRIDGE網路模式

啟用USER網路模式

設置埠

此示例中，「containerPort」和「hostPort」埠值相同。

也可以顯式指定埠的協議，默認值是「tcp」：

顯式指定服務埠：

引用埠

在Dockerfile中引用埠：

CMD ./my-app --http-port=$PORT0 --https-port=$PORT1 --monitoring-port=$PORT2

在Marathon應用定義中引用埠：

"cmd": "./my-app --http-port=$PORT0 --https-port=$PORT1 --monitoring-port=$PORT2"

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