① 四、Docker網路揭秘
Docker 之所以功能這么強大，其實就是充分利用了Linux Kernel的特性：NameSpace、CGroups、UnionFileSystem。通過這些特性實現了資源隔離、限制與分層等。本文這次就來揭曉Docker中的容器是如何做到網路互通的。
兩台機器如果要實現通信，其實就是通過底層的網卡進行數據傳輸，每個網卡都有一個唯一的MAC地址，網卡又會綁定一個ip地址，只要兩台機器的網路可以互通，那麼這兩台機器就可以進行通信。
想要實現通信，就得有兩個同一網段的網卡，兩個網卡必須是可以 ping 通的。
Docker在安裝成功後，會在宿主機創建一個docker0網卡，這個網卡就是負責容器與宿主機之間通信的橋梁。
通過Docker創建一個容器之後，會在宿主機再創建一個網卡，也就是上面的 veth3543ea3@if7 ，容器內也會創建一個網卡。
一般成對的網卡，網卡組件名稱後面的數字是連續的，比如宿主機的 @if7 和容器內的 @if8 ，正是這成對的網卡，才實現了容器與宿主機之間的通信。這其實是利用 Linux Kernel 的特性 NameSpace 實現的網卡隔離，不同NameSpace下的網卡是獨立的，就像Java程序中的 package 一樣。
從上面的例子中看到容器與宿主機之間的通信好像並不是通過docker0網卡實現的?
其實這只是單容器的狀態，可能看不出docker0的作用。用圖來表示一下單容器的網卡通信情況。
通過docker生成的 eth0 和 veth 兩個網卡實現同一網段內的通信，而這個網卡又是橋接在docker0網卡上的。
再看下有多個容器的情況。
兩個容器之間可以互相通信的原因就是因為docker0的存在，因為它們的網卡都是橋接在docker0上，所以也就有了和另一個容器通信的橋。
我們來驗證一下是不是這樣！
這種網路連接方法我們稱為Bridge，這也是docker中默認的網路模式。可以通過命令查看docker中的網路模式：
通過 docker network ls 命令查看到，docker提供了3種網路模式，brige模式我們已經知道了，那 host 和 none 又是什麼意思呢？不妨來驗證一下：
這種模式只會創建一個本地的環路網卡，無法與其他容器或宿主機進行通信。
在創建自己的network之前先來解釋一下為什麼要創建新的network。
我們用一個例子來演示一下不同容器之間的通信。
容器之間通過 ip 是可以正常訪問的，但是有沒有這種情況：如果一個容器出問題了，我們重啟之後它的ip變了，那是不是其他用到這個容器的項目配置是不是都得改。
有沒有可能直接通過容器名稱來訪問呢？來驗證一下：
發現並不能 ping 通，但是可以使用別的手段來達到這個目的。
通過上面這種方式就可以做到以容器名來 ping 通其他容器，其實它就跟windows系統中在 hosts 文件里加了個映射是一樣的。
可以看到創建自定義的 network 自動幫我們實現了這個功能，而且使用自定義的 network 也方便管理，不同業務類型的容器可以指定不同的 network。
不同的 network ip網段也不一樣，這樣也可以增加單機中可以創建的容器的數量。
在創建一個容器的時候，一般都需要講容器需要暴露的埠映射到物理主機的相同埠或其他埠，因為在外網環境下是不方便直接連接到容器的，所以需要通過映射埠的方式，讓外網訪問宿主機的映射埠來訪問容器。
如果想建立多個容器，勢必需要埠映射，以滿足不同容器使用相同埠的情況。
以上這些內容都是在單容器進行操作，容器之間通信也只是通過 docker0 實現的橋接模式。
如果要實現多機之間的docker通信，其實還是通過網卡，只不過需要其他的技術來實現了。
本章節就不在演示，到後面的章節再來分析！
② docker網路怎麼配置/
在你的宿主機啟動docker的時候會多出一個 docker0 的虛擬網卡，然後容器都通過這個和外面通信。容器和docker宿主機之間是NAT的方式共享網路的，也就是說宿主機可以訪問的資源，容器也是可以直接訪問，你要使用apt-get，你就要保證你的宿主機可以上外網，否則免談。
③ 雲計算Docker網路使用
在容器中運行的網路應用，需要讓外部可以訪問這些應用，我們可以通過
參數來指定埠映射。
使用命令運行nginx，-P指令隨機映射一個埠映射容器內部埠
我們使用 docker ps 或者 docker container ls 可以看到，宿主機的49154埠被映射到了容器的80埠，此時通過訪問宿主機的49154就可以訪問nginx默認頁面
語法格式：
OPTIONS註解：
首先我們先將我們之前運行的容器全部刪除
我們可以使用docker link鏈接容器，避免容器重啟ip地址變化的問題
格式如下：
我們進入mycentos2容器
查看容器的hosts,發現了別名webcentos的ip地址
ping mycentos1 容器的ip別名 webcentos ,發現容器可以ping通
docker創建以後默認使用的是Linux的 橋連接 ，在宿主機上虛擬創建了一個容器 網橋 (docker0),使用 ip addr 查看
Docker每啟動一個容器就會根據 docker0 的網段分配給容器一個IP地址，這個網橋docker0是所有容器的默認網關。因為宿主機內容器都使用網橋docker0，所以容器可以使用IP進行通信。
Docker就是很好的利用了Linux虛擬網路技術，在宿主機和容器內分別創建一個虛擬介面，實現他們彼此聯通.
網路模式配置說明 bridge模式--net=bridge 默認使用 ，在docke的默認網橋docker0上為容器創建網路 none模式--net=none不配置網路，用於稍後進入容器，自行配置網路 container模式--net=container:name/id容器可以和應一個容器共享network namespace,k8s的pod使用此模式 hots模式--net=host容器和宿主機共享Network namespace 用戶自定義--net=createnet用戶使用network相關指令創建網路
Docker的container模式是指，創建容器的時候，使用--net=container:name/id，指定創建的容器和已經有的容器共享一個Network Namespace。
docker網路的host模式容器和宿主機共享Network namespace
默認選擇bridge模式，容器啟動後通過網橋docker0獲取ip地址
我們首先使用 docker network 創建一個新的docker網路
-d指定docker的網路模型，有 bridge、overlay ,然後overlay網路模型使用的是Swarm mode。
使用ping來證明mycentos6容器和mycentos5可以相互鏈接
同理在mycentos5可以和mycentos5相互鏈接
④ Docker容器網路-實現篇
前面介紹了： Docker容器網路-基礎篇
前文說到容器網路對Linux虛擬化技術的依賴，這一篇章我們將一探究竟，看看Docker究竟是怎麼做的。通常，Linux容器的網路是被隔離在它自己的Network Namespace中，其中就包括：網卡（Network Interface）、回環設備（Loopback Device）、路由表（Routing Table）和iptables規則。對於一個進程來說，這些要素，就構成了它發起和響應網路請求的基本環境。
我們在執行 docker run -d --name xxx 之後，進入容器內部：
並執行 ifconfig：
我們看到一張叫eth0的網卡，它正是一個Veth Pair設備在容器的這一端。
我們再通過 route 查看該容器的路由表：
我們可以看到這個eth0是這個容器的默認路由設備。我們也可以通過第二條路由規則，看到所有對 169.254.1.1/16 網段的請求都會交由eth0來處理。
而Veth Pair 設備的另一端，則在宿主機上，我們同樣也可以通過查看宿主機的網路設備來查看它：
在宿主機上，容器對應的Veth Pair設備是一張虛擬網卡，我們再用 brctl show 命令查看網橋：
可以清楚的看到Veth Pair的一端 vethd08be47 就插在 docker0 上。
我現在執行docker run 啟動兩個容器，就會發現docker0上插入兩個容器的 Veth Pair的一端。如果我們在一個容器內部互相ping另外一個容器的IP地址，是不是也能ping通？
容器1：
容器2：
從一個容器ping另外一個容器：
我們看到，在一個容器內部ping另外一個容器的ip，是可以ping通的。也就意味著，這兩個容器是可以互相通信的。
我們不妨結合前文時所說的，理解下為什麼一個容器能訪問另一個容器？先簡單看如一幅圖：
當在容器1里訪問容器2的地址，這個時候目的IP地址會匹配到容器1的第二條路由規則，這條路由規則的Gateway是0.0.0.0，意味著這是一條直連規則，也就是說凡是匹配到這個路由規則的請求，會直接通過eth0網卡，通過二層網路發往目的主機。而要通過二層網路到達容器2，就需要127.17.0.3對應的MAC地址。所以，容器1的網路協議棧就需要通過eth0網卡來發送一個ARP廣播，通過IP找到MAC地址。
所謂ARP（Address Resolution Protocol），就是通過三層IP地址找到二層的MAC地址的協議。這里說到的eth0，就是Veth Pair的一端，另一端則插在了宿主機的docker0網橋上。eth0這樣的虛擬網卡插在docker0上，也就意味著eth0變成docker0網橋的「從設備」。從設備會降級成docker0設備的埠，而調用網路協議棧處理數據包的資格全部交給docker0網橋。
所以，在收到ARP請求之後，docker0就會扮演二層交換機的角色，把ARP廣播發給其它插在docker0網橋的虛擬網卡上，這樣，127.17.0.3就會收到這個廣播，並把其MAC地址返回給容器1。有了這個MAC地址，容器1的eth0的網卡就可以把數據包發送出去。這個數據包會經過Veth Pair在宿主機的另一端veth26cf2cc，直接交給docker0。
docker0轉發的過程，就是繼續扮演二層交換機，docker0根據數據包的目標MAC地址，在CAM表查到對應的埠為veth8762ad2，然後把數據包發往這個埠。而這個埠，就是容器2的Veth Pair在宿主機的另一端，這樣，數據包就進入了容器2的Network Namespace，最終容器2將響應（Ping）返回給容器1。在真實的數據傳遞中，Linux內核Netfilter/Iptables也會參與其中，這里不再贅述。
CAM就是交換機通過MAC地址學習維護埠和MAC地址的對應表
這里介紹的容器間的通信方式就是docker中最常見的bridge模式，當然此外還有host模式、container模式、none模式等，對其它模式有興趣的可以去閱讀相關資料。
好了，這里不禁問個問題，到目前為止只是單主機內部的容器間通信，那跨主機網路呢？在Docker默認配置下，一台宿主機的docker0網橋是無法和其它宿主機連通的，它們之間沒有任何關聯，所以這些網橋上的容器，自然就沒辦法多主機之間互相通信。但是無論怎麼變化，道理都是一樣的，如果我們創建一個公共的網橋，是不是集群中所有容器都可以通過這個公共網橋去連接？
當然在正常的情況下，節點與節點的通信往往可以通過NAT的方式，但是，這個在互聯網發展的今天，在容器化環境下未必適用。例如在向注冊中心注冊實例的時候，肯定會攜帶IP，在正常物理機內的應用當然沒有問題，但是容器化環境卻未必，容器內的IP很可能就是上文所說的172.17.0.2，多個節點都會存在這個IP，大概率這個IP是沖突的。
如果我們想避免這個問題，就會攜帶宿主機的IP和映射的埠去注冊。但是這又帶來一個問題，即容器內的應用去意識到這是一個容器，而非物理機，當在容器內，應用需要去拿容器所在的物理機的IP，當在容器外，應用需要去拿當前物理機的IP。顯然，這並不是一個很好的設計，這需要應用去配合配置。所以，基於此，我們肯定要尋找其他的容器網路解決方案。
在上圖這種容器網路中，我們需要在我們已有的主機網路上，通過軟體構建一個覆蓋在多個主機之上，且能把所有容器連通的虛擬網路。這種就是Overlay Network（覆蓋網路）。
關於這些具體的網路解決方案，例如Flannel、Calico等，我會在後續篇幅繼續陳述。