Docker容器网络
?
Docker的技術依賴于Linux內核的虛擬化技術的發展，Docker使用到的網絡技術有Network Namespace、Veth設備對、Iptables/Netfilter、網橋、路由等。接下來，我將以Docker容器網絡實現的基礎技術來分別闡述，在到真正的容器篇章節之前，能形成一個穩固的基礎知識網。
Network Namespace
為了支持網絡協議棧的多個實例，Linux在網絡棧引入了Network Namespace，這些獨立的協議棧被隔離到不同的Namespace中，處于不同Namespace中的網絡棧是完全隔離的，彼此無法通信。具體有關Linux Namespace的介紹，可以另行瀏覽之前寫的《Linux Namespace》。
Linux的網絡協議棧十分復雜，為了支持獨立的協議棧，相關的全局變量都必須修改為協議棧私有。Linux實現Network Namespace的核心就是讓這些全局變量稱為Network Namespace變量的成員，然后為協議棧的函數調用加入一個Namespace參數。與此同時，為了保證已開發程序及內核代碼的兼容性，內核代碼隱式地使用了Namespace空間內的變量。應用程序如果沒有對Namespace有特殊需求，那么不需要額外的代碼，Network Namespace對應用程序而言是透明的。
在建立了新的Network Namespace，并將某個進程關聯到這個網絡命名空間后，就出現了如下的命名空間下的內核數據結構，所有網絡棧變量都放入了Network Namespace的數據結構中，這個Network Namespace是屬于它進程組私有的，與其他進程組不沖突。
Docker正是利用了Network Namespace特性，實現了不同容器之間的網絡隔離。如果一個容器聲明使用宿主機的網絡棧（-net = host），即不開啟Network Namespace，例如：
docker run –d –net=host --name c_name i_name這種情況下，這個容器啟動之后監聽的是宿主機的80端口。像這樣直接使用宿主機網絡棧的方式，雖然可以為容器提供良好的網絡性能，但也不可避免的造成端口沖突等網絡資源沖突的問題。
所以在一般情況下，我們都希望程序引入Network Namespace里的網絡棧，即這個容器擁有自己的IP和端口。但是，這個時候也會帶來一個新的問題，被隔離的容器進程，是怎么與其它被隔離的進程進行網絡通信的？
Net Bridge
上文說到，Linux 可以支持不同的網絡，他們之間是怎么支持夠互相通信的呢？如果是兩臺主機，那需要的可能只是一根網線，把它們連接在一臺交換機上。而在Linux當中，網橋（Bridge）就起到相應的作用。本質上來說，這是一個數據鏈路層（data link）的設備，根據Mac地址的信息轉發到網橋的不同端口上。而Docker就是在宿主機上默認創建一個docker0的網橋，凡是連接docker0的網橋，都可以用它來通信。
細述Bridge
網橋是一個二層的虛擬網絡設備，把若干個網絡接口“連接”起來，使得網口之間的報文可以轉發。網橋能夠解析收發的報文，讀取目標的Mac地址信息，和自己的Mac地址表結合，來決策報文轉發的目標網口。為了實現這些功能，網橋會學習源Mac地址。在轉發報文時，網橋只需要向特定的端口轉發，從而避免不必要的網絡交互。如果它遇到了一個自己從未學過的地址，就無法知道這個報文應該向哪個網口轉發，就將報文廣播給除了報文來源之外的所有網口。
在實際網絡中，網絡拓撲不可能永久不變。如果設備移動到另一個端口上，而它沒有發送任何數據，那么網橋設備就無法感知到這個變化，結果網橋還是向原來的端口發數據包，在這種情況下數據就會丟失。所以網橋還要對學習到的Mac地址表加上超時時間，默認5min。如果網橋收到了對應端口MAC地址回發的包。則重置超時時間，否則過了超時時間后，就認為哪個設備不在那個端口上了，他就會廣播重發。
Linux為了支持越來越多的網卡以及虛擬設備，所以使用網橋去提供這些設備之間轉發數據的二層設備。Linux內核支持網口的橋接（以太網接口），這與單純的交換機還是不太一樣，交換機僅僅是一個二層設備，對于接受到的報文，要么轉發，要么丟棄。運行著Linux內核的機器本身就是一臺主機，有可能是網絡報文的目的地，其收到的報文要么轉發，要么丟棄，還可能被送到網絡協議的網絡層，從而被自己主機本身的協議棧消化，所以我們可以把網橋看作一個二層設備，也可以看做是一個三層設備。
Linux中Bridge實現
Linux內核是通過一個虛擬的網橋設備（Net Device）來實現橋接的。這個虛擬設備可以綁定若干個以太網接口，從而將它們連接起來。Net Device網橋和普通的設備不同，最明顯的是它還可以有一個ip地址。
如上圖所示，網橋設備br0綁定的eth0和eth1。對于網絡協議棧的上層來說，只看到br0。因為橋接是在數據鏈路層實現的，上層不需要關心橋接的細節，于是協議棧上層需要發送的報文被送到br0，網橋設備的處理代碼判斷報文被轉發到eth0還是eth1，或者兩者皆轉發。反之，從eth0或者從eth1接收到的報文被提交給網橋的處理代碼，在這里判斷報文應該被轉發、丟棄或者提交到協議棧上層。
而有時eth0、eth1也可能會作為報文的源地址或目的地址，直接參與報文的發送和接收，從而繞過網橋。
Bridge常用操作
Docker自動完成了對網橋的創建和維護。如果想要進一步理解網橋，可以看下如下舉的一些常用操作命令。
新增一個網橋：
brctl addbr xxxxx在新增網橋的基礎上增加網口，在linux中，一個網口其實就是一個物理網卡。將物理網卡和網橋連接起來：
brctl addif xxxx ethx網橋的物理網卡作為一個網口，由于在鏈路層工作，就不再需要IP地址了，這樣上面的IP地址自然失效：
ipconfig ethx 0.0.0.0給網橋配置一個IP地址：
ipconfig brxxx xxx.xxx.xxx.xxx這樣網橋就是一個有了IP地址，而連接在這之上的網卡就是一個純鏈路層設備了。
Veth Pair
上文說到，docker在宿主機上創建docker0網橋后，凡是連接到docker0上的網橋，就可以用它來通信。那么這里又有個問題，就是這些容器是如何連接到docker0網橋上的？所以這就是Veth Pair虛擬設備的作用了，Veth Pair就是為了在不同的Network Namespace之間進行通信，利用它，可以將兩個Network Namespace連接起來。
Veth Pair設備的特點是：它被創建出來后，總是以兩張虛擬網卡（Veth Peer）的形式出現。并且，其中一個網卡發出的數據包，可以直接出現在另一張“網卡”上，哪怕這兩張網卡在不同的Network Namespace中。
正是因為這樣的特點，Veth Pair成對出現，很像是一對以太網卡，常常被看做是不同Network Namespace直連的“網線”。在Veth一端發送數據時，他會將數據發送到另一端并觸發另一端的接收操作。我們可以把Veth Pair其中一端看做另一端的一個Peer。
Veth Pair操作命令
創建Veth Pair：
ip link add veth0 type veth peer name veth1創建后查看Veth Pair的信息：
ip link show將其中一個Veth Peer設置到另一個Namespace：
ip link set veth1 netns netns1在netns1中查看veth1設備：
ip netns exec netns1 ip link show當然，在docker里面，除了將Veth放入容器，還改名為eth0。想要通信必須先分配IP地址：
ip netns exec netns1 ip addr add 10.1.1.1/24 dev veth1ip addr add 10.1.1.2/24 dev veth0啟動它們：
ip netns exec netns1 ip link set dev veth1 upip link set dev veth0 up測試通信:
ip netns exec netns1 ping 10.1.1.2Veth Pair查看端對端
在實際操作Veth Pair時，可以使用ethtool便于操作。
在一個Namespace中查看Veth Pair接口在設備列表中的序列號：
ip netns exec netns1 ethtool -S veth1如果得知另一端的接口設備序列號，假如序列號為6，則可以繼續查看6代表了什么設備：
ip netns exec netns2 ip link | grep 6Iptables/Netfilter
Linux協議棧非常高效且復雜。如果我們想要在數據處理過程中對關心的數據進行一些操作，則需要Linux提供一套相應的機制幫助用戶實現自定義的數據包處理過程。
在Linux網絡協議棧有一組網絡回調函數掛接點，通過這些掛接點函數掛接的鉤子函數可以在Linux網絡棧處理數據包的過程中對數據包一些操作，例如過濾、修改、丟棄等。整個掛接點技術叫做Iptables和Netfilter。
Netfilter負責在內核中執行各種各樣的掛接規則，運行在內核模式中。而Iptables是在用戶模式下運行的進程，負責協助維護內核中Netfilter的各種規則表。通過二者的配合來實現整個Linux網絡協議棧中靈活的數據包處理機制。
規則表Table
這些掛載點能掛接的規則也分不同的類型，目前主要支持的Table類型如下：
?RAW?MANGLE?NAT?FILTER
上述4個規則鏈的優先級是RAW最高，FILTER最低。
在實際應用中，不同掛接點需要的規則類型通常不同。例如，在Input的掛接點上明顯不需要FILTER的過濾規則，因為根據目標地址，已經在本機的上層協議棧了，所以無需再掛載FILTER過濾規則。
Route
Linux系統包含了一個完整的路由功能。當IP層在處理數據發送或者轉發時，會使用路由表來決定發往哪里。通常情況下，如果主機與目的主機直接相連，那么主機可以直接發送IP報文到目的主機。
路由功能是由IP層維護的一張路由表來實現。當主機收到數據報文時，它用此表來決策接下來應該做什么操作。當從網絡側接收到數據報文時，IP層首先會檢查報文的IP地址是否與主機自身的地址相同。如果數據報文中的IP地址是自身主機的地址，那么報文將被發送到傳輸層相應的協議棧中去。如果報文中的IP地址不是主機自身的地址，并且配置了路由功能，那么報文將被轉發，否則報文將被丟棄。
路由表的數據一般以條目形式存在，一個典型的路由表條目通常包含以下主要的條目項：
?目的IP地址?下一個路由器的IP地址?標志?網絡接口規范
通過路由表轉發時，如果任何條目的第一個字段完全匹配目標條目的IP地址（主機）或部分匹配（網絡），那么它將指示下一個路由器的IP地址。這些信息將告訴主機數據包該轉發到哪一個“下一個路由器”。而條目中所有其它字段將提供更多的輔助信息來為路由轉發做決定。
如果沒有一個完全匹配的IP，則繼續搜索網絡ID。找到則轉發數據到指定路由器上。由此可知，網絡上所有主機都是通過這個路由表中的單個條目進行管理。
如果上述兩個條件都不匹配，則將數據報文轉發到一個默認路由器上。
如果上述步驟失敗，默認路由器也不存在，那么這個數據報文無法轉發。任何無法投遞的數據都會產生一個ICMP主機不可達或者ICMP網絡不可達的錯誤，并將該錯誤返回給生成此數據的應用程序。
Route Table
Linux路由表至少2個，一個是LOCAL，一個是MAIN。
Local表用于供Linux協議棧識別本地地址，以及進行本地各個不同網絡之間的數據轉發。MAIN表用于各類網絡IP的轉發。它的建立既可以使用靜態配置生成，也可以使用動態路由發現協議生成。動態路由發現協議一般使用組播功能來通過發送路由發現數據，動態獲取和交換網絡的路由信息，并更新到路由表中。
通過下列命令查看LOCAL表的內容：
ip route show table local type local路由表的查看：
ip route list管中窺豹
我們在執行docker run -d --name xxx之后，進入容器內部：
## docker ps 可查看所有docker## 進入容器docker exec -it 228ae947b20e /bin/bash并執行 ifconfig：
$ ifconfigeth0 Link encap:Ethernet HWaddr 22:A4:C8:79:DD:1A inet addr:192.168.65.28 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1440 Metric:1 RX packets:2231528 errors:0 dropped:0 overruns:0 frame:0 TX packets:3340914 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:249385222 (237.8 MiB) TX bytes:590701793 (563.3 MiB)lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)我們看到一張叫eth0的網卡，它正是一個Veth Pair設備在容器的這一端。
我們再通過 route 查看該容器的路由表：
$ routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Ifacedefault 169.254.1.1 0.0.0.0 UG 0 0 0 eth0169.254.1.1 * 255.255.255.255 UH 0 0 0 eth0我們可以看到這個eth0是這個容器的默認路由設備。我們也可以通過第二條路由規則，看到所有對 169.254.1.1/16 網段的請求都會交由eth0來處理。
而Veth Pair 設備的另一端，則在宿主機上，我們同樣也可以通過查看宿主機的網絡設備來查看它：
$ ifconfig......eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.16.241.192 netmask 255.255.240.0 broadcast 172.16.255.255 ether 00:16:3e:0a:f3:75 txqueuelen 1000 (Ethernet) RX packets 3168620550 bytes 727592674740 (677.6 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2937180637 bytes 8661914052727 (7.8 TiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0......docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:16:58:92:43 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0......vethd08be47: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 16:37:8d:fe:36:eb txqueuelen 0 (Ethernet) RX packets 193 bytes 22658 (22.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 134 bytes 23655 (23.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0......在宿主機上，容器對應的Veth Pair設備是一張虛擬網卡，我們再用brctl show命令查看網橋：
$ brctl showbridge name bridge id STP enabled interfacesdocker0 8000.0242afb1a841 no vethd08be47可以清楚的看到Veth Pair的一端 vethd08be47 就插在 docker0 上。
我現在執行docker run 啟動兩個容器，就會發現docker0上插入兩個容器的 Veth Pair的一端。如果我們在一個容器內部互相ping另外一個容器的IP地址，是不是也能ping通？
$ brctl showbridge name bridge id STP enabled interfacesdocker0 8000.0242afb1a841 no veth26cf2cc veth8762ad2容器1：
$ docker exec -it f8014a4d34d0 /bin/bash$ ifconfigeth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:03 inet addr:172.17.0.3 Bcast:172.17.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:76 errors:0 dropped:0 overruns:0 frame:0 TX packets:106 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16481 (16.0 KiB) TX bytes:14711 (14.3 KiB)lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:48 errors:0 dropped:0 overruns:0 frame:0 TX packets:48 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2400 (2.3 KiB) TX bytes:2400 (2.3 KiB)$ routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Ifacedefault 172.17.0.1 0.0.0.0 UG 0 0 0 eth0172.17.0.0 * 255.255.0.0 U 0 0 0 eth0容器2：
$ docker exec -it 9a6f38076c04 /bin/bash$ ifconfigeth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02 inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:133 errors:0 dropped:0 overruns:0 frame:0 TX packets:193 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:23423 (22.8 KiB) TX bytes:22624 (22.0 KiB)lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:198 errors:0 dropped:0 overruns:0 frame:0 TX packets:198 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:9900 (9.6 KiB) TX bytes:9900 (9.6 KiB)$ routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Ifacedefault 172.17.0.1 0.0.0.0 UG 0 0 0 eth0172.17.0.0 * 255.255.0.0 U 0 0 0 eth0從一個容器ping另外一個容器：
# -> 容器1內部 ping 容器2$ ping 172.17.0.3PING 172.17.0.3 (172.17.0.3): 56 data bytes64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.142 ms64 bytes from 172.17.0.3: seq=1 ttl=64 time=0.096 ms64 bytes from 172.17.0.3: seq=2 ttl=64 time=0.089 ms我們看到，在一個容器內部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（覆蓋網絡）。
?
?
總結
以上是生活随笔為你收集整理的Docker容器网络的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： linux命令之history命令
- 下一篇： JDK源码解析之 java.lang.E