Docker網路

一、概述

二、bridge網路模式

介紹

關於veth

容器與容器間通訊

　　啟動一個bs1的容器，並查看其IP地址為172.17.0.2，預設網關為172.17.0.1。而這個網關地址則是網橋docker0地址：

同時我們查看docker0橋接的網卡與剛纔容器對應的veth網卡：

同樣的在啟動一個容器為bs2,IP地址為172.17.0.3 ，網關172.17.0.1，即也是docker0：

此時docker0上會多了一個bs2的veth設備veth7833d44：

當我們從容器bs1中ping 172.17.0.3（容器bs2）時候，在bs1容器里，根據路由規則，數據包從eth0轉發址與之對應的veth（veth0737c95）上，該veth橋接在了docker0上，此時數據包到達了docker0，docker0此時扮演交換機角色並廣播ARP請求尋找172.17.0.3的mac地址，而此時的bs2的另一個veth設備橋接在了docker0上並收到該ARP請求，發現自己是172.17.0.3，將其mac地址回覆給bs1，此時的容器bs1就可以和bs2進行通訊了，並且在bs1上可以查看到緩存的172.17.0.3的mac地址：

以上的兩個容器間的通訊過程示意圖如下：

容器與外部網路通訊

　　同樣的，介紹了容器與容器間的通訊，容器與主機間的通訊就容易理解了，如果在容器bs1 ping 另一個主機10.168.0.3，它發出去的數據包經過docker0網橋流向eth0，eth0在將數據包轉發給與之相通的10.168.0.3，於是bs1就能和其主機節點進行通訊了。當然如果這個地址不是其他主機節點而是公網地址，只要eth0能到達，容器bs1都能與之通訊。以下是其示意圖：

宿主機與容器通訊

　　當宿主機訪問容器時，數據包從docker0流入到與容器對應的veth設備，在經容器的eth0到達到主機中，示意圖如下：

外部訪問容器

　　預設情況，其他外部網路（宿主機以外）無法訪問到容器內的埠，通常的做法是使用-p或者-P選項（使用方法參考docker基礎篇）來暴露容器中的埠到宿主機上，外部網路通過訪問宿主機的埠從而訪問到容器埠。本質上來說，該方式是通過iptables規則轉發實現的，例如以下啟動nginx容器並使用宿主機的8080映射到容器內部80埠：

查看其對應的iptables規則：

上述規則表明當訪問宿主機的8080埠時，NAT到容器中的172.17.0.4的80中。

自定義網橋

　　除了使用預設docker0作網橋以為還可以使用docker network 相關命令自定義網橋，以下將創建一個br1的網路，子網是172.30.0.0/16，網關為172.30.0.1:

查看docker網路：

查看對應網橋：

此時運行一個容器指明網路使用br1,此時的容器地址使用的是172.30.0.0段的網路,此時使用的網橋為br-9e5b3fba2e11，如下：

三、host網路模式

　　Host模式使用是在容器啟動時候指明--network host，此時容器共用宿主機的Network Namespace，容器內啟動的埠直接是宿主機的埠，並且容器不會創建網卡和IP，直接使用宿主機的網卡和IP，但是容器內的其他資源是隔離的，如文件系統、用戶和用戶組。這種模式的好處就是效率高，因為不需要額外的網路開始，直接使用宿主機網路。同樣啟動一個nginx，此時共用主機網路：

此時連入容器內部直接能看到docker0與宿主機網卡：

以上的host網路模式下的示意圖：

四、container網路模式

　　理解了host模式就很容易理解container模式，host模式是容器共用宿主機的Network Namespace，而container模式即共用已存在的容器的Network Namespace，此時這兩容器共同使用同一網卡、主機名、IP地址，容器間通訊可直接通過lo迴環介面通訊，但是其他名稱空間是隔離的，例如User、Mount。如果你瞭解kubernetes中的pod的話，pod內的網路也是靠這樣的共用方式來實現的。

　　這裡啟動一個bs-1容器，IP地址為172.17.0.2：

此時再運行一個容器共用bs-1的網路,此時在bs-2的容器同樣看到的是bs1的網卡：

示意圖：

五、none網路模式

　　使用--network none選項指定其網路模式，在該模式下雖然容器有著自己的Network Namespace，但是容器內沒有網卡、IP、路由信息，只有一個lo迴環介面。如果需要網路配置則需要用戶手動進行配置網卡、ip以及路由信息，通常這樣的容器用於承擔某些無需網路介入的工作，如離線任務、備份等。啟動一個none網路模式的容器如下：

示意圖：

總結