『壹』 docker如何查看容器使用的cgroups
1、正常啟動一個容器
docker run -itd -m 128m alpine:3.8 /bin/sh
2、進入到cgroup目錄
/sys/fs/cgroup/memory/docker/
其中為容器id
『貳』 docker哪種網路模式比較好
Docker的4種網路模式
我們在使用docker run創建Docker容器時，可以用--net選項指定容器的網路模式，Docker有以下4種網路模式：
host模式，使用--net=host指定。
container模式，使用--net=container:NAME_or_ID指定。
none模式，使用--net=none指定。
bridge模式，使用--net=bridge指定，默認設置。
下面分別介紹一下Docker的各個網路模式。
1、host模式
眾所周知，Docker使用了Linux的Namespaces技術來進行資源隔離，如PID Namespace隔離進程，Mount Namespace隔離文件系統，Network Namespace隔離網路等。一個Network Namespace提供了一份獨立的網路環境，包括網卡、路由、Iptable規則等都與其他的Network Namespace隔離。一個Docker容器一般會分配一個獨立的Network Namespace。但如果啟動容器的時候使用host模式，那麼這個容器將不會獲得一個獨立的Network Namespace，而是和宿主機共用一個Network Namespace。容器將不會虛擬出自己的網卡，配置自己的IP等，而是使用宿主機的IP和埠。
例如，我們在10.10.101.105/24的機器上用host模式啟動一個含有web應用的Docker容器，監聽tcp80埠。當我們在容器中執行任何類似ifconfig命令查看網路環境時，看到的都是宿主機上的信息。而外界訪問容器中的應用，則直接使用10.10.101.105:80即可，不用任何NAT轉換，就如直接跑在宿主機中一樣。但是，容器的其他方面，如文件系統、進程列表等還是和宿主機隔離的。
2、 container模式
在理解了host模式後，這個模式也就好理解了。這個模式指定新創建的容器和已經存在的一個容器共享一個Network Namespace，而不是和宿主機共享。新創建的容器不會創建自己的網卡，配置自己的IP，而是和一個指定的容器共享IP、埠范圍等。同樣，兩個容器除了網路方面，其他的如文件系統、進程列表等還是隔離的。兩個容器的進程可以通過lo網卡設備通信。
3、none模式
這個模式和前兩個不同。在這種模式下，Docker容器擁有自己的Network Namespace，但是，並不為Docker容器進行任何網路配置。也就是說，這個Docker容器沒有網卡、IP、路由等信息。需要我們自己為Docker容器添加網卡、配置IP等。
4、bridge模式
bridge模式是Docker默認的網路設置，此模式會為每一個容器分配Network Namespace、設置IP等，並將一個主機上的Docker容器連接到一個虛擬網橋上。
棧是一種常見的數據結構，它雖然有棧頂和棧底之分，但它只能從一端操作(插入或刪除)，從而是一種「先進後出」的操作模式。向棧內進數據稱為壓棧（Push），從棧里取出數據叫出棧（POp）。例如壓棧順序為1、2、3、4、5，著出棧的順序為5、4、3、2、1（只考慮一次性出棧的情況）。
棧按照存儲的方式，又分為順序棧和鏈表棧。順序棧基於數組實現，所以順序棧存儲數據的內存是連續的，在創建棧時規定好棧的大小，這樣對內存的使用效率並不高。而鏈式棧則是採用了鏈表來實現，其元素的存儲地址是不連續的，而且是動態分配內存。順序棧在使用的過程中可能出現 棧滿、棧空的情況，由於鏈式棧基於鏈表設計，因此不會有棧滿的情況（也會棧空）。
『叄』 docker網路問題 怎麼解決
網路基礎 Docker 現有的網路模型主要是通過使用 Network namespace、Linux Bridge、iptables、veth pair 等技術實現的。（出處8） Network namespace：它主要提供了網路資源的隔離，包括網路設備、IPv4/IPv6 協議棧、IP 路由表、防火牆、/proc/net 目錄、/sys/class/net 目錄、埠（socket）等。 Linux Bridge：功能相當於物理交換機，為連在其上的設備（容器）轉發數據幀，如 docker0 網橋。 Iptables：主要為容器提供 NAT 以及容器網路安全。 veth pair：兩個虛擬網卡組成的數據通道。在 Docker 中，用於連接 Docker 容器和 Linux Bridge。一端在容器中作為 eth0 網卡，另一端在 Linux Bridge 中作為網橋的一個埠。 容器的網路模式 用來設置網路介面的 docker run --net 命令，它的可用參數有四個： none：關閉了 container 內的網路連接。容器有獨立的 Network namespace，但並沒有對其進行任何網路設置，如分配 veth pair 和網橋連接，配置 IP 等。 bridge：通過 veth 介面來連接其他 container。這是 docker 的默認選項。 host：允許 container 使用 host 的網路堆棧信息。容器和宿主機共享 Network namespace。 container：使用另外一個 container 的網路堆棧信息。kubernetes 中的 pod 就是多個容器共享一個 Network namespace。 我們需要從中選一個作為我們的網路方案，實際上只有 bridge 和 host 兩種模式可選。（想了解這四個參數，請翻到附錄B之 Network settings。） 在 docker 默認的網路環境下，單台主機上的容器可以通過 docker0 網橋直接通信，如下圖（圖作者馮明振）所示：
『肆』 怎麼查看docker所在的網路模式
docker inspect可以查看當前容器所有信息 裡面就包含網路內容 可以看下linux就該這么學 網站上不少docker資料
『伍』 容器網路：盤點，解釋與分析
雖然許多人傾向用Overlays作為解決跨主機容器網路的實現方法，但是如果您想根據您的環境做出正確的網路選型，容器網路的功能和類型差異還是很大的，值得更深入的理解。 有些類型的網路是容器引擎不可知的，有些類型的網路被鎖定到特定的平台供應商或引擎。 一些類型主要關注組網的簡單性，另一些類型可能關注功能的廣度或IPv6支持以及組播能力。 哪一個適合您取決於您的應用程序需求，性能要求，工作負載布局（私有或公共雲）等。讓我們回顧一下目前比較常見的容器網路。
本文主要關注當前容器網路類型的細分，包括：
•None
•Overlay
•Underlay
曾經的容器網路隨著容器技術的進步與發展。 下面兩種模式的網路方案經消失。
Links and Ambassadors
在使用Swarm實現多主機網路支持和編排之前，Docker從單主機網路開始，通過links促成網路連接，作為允許容器通過環境變數或/ etc / hosts文件條目發現彼此的機制，並傳輸容器之間的信息。 links的能力通常與 ambassador pattern 相結合，以便於跨主機連接容器，並降低被寫死links的脆弱性。 這種方法的最大的問題是太靜態了。 一旦創建了容器並定義了環境變數，如果相關的容器或服務移動到新的IP地址，則不可能更新這些變數的值。
Container-Mapped Networking
在這種網路模式下，一個容器重用（映射到）另一個容器的網路命名空間。這種聯網模式只能用以下運行Docker容器的方式使用：-net：container：some_container_name_or_id。
這個運行命令標志告訴Docker將這個容器的進程放在已經在另一個容器中創建的網路棧中。當與第一個容器共享相同的IP和MAC地址和埠號時，新容器的進程仍然局限於自己的文件系統，進程列表和資源限制。這兩個容器上的進程將能夠通過loopback介面相互連接。
這種聯網方式對正在運行的容器執行診斷有用，並且容器缺少必要的診斷工具（例如curl或dig）。可以創建具有必要診斷工具的臨時容器並將其附加到第一容器的網路。
容器映射網路可以用於模擬pod式聯網，其中多個容器共享相同的網路命名空間。諸如共享本地主機通信和共享同一IP地址的優點是容器在同一個pod中運行的概念所固有的，這是rkt容器的行為。
現在的容器網路None
None 是比較直接的容器接收一個網路堆棧，但是缺少外部網路介面。 然而，它會接收一個loopback介面。 當使用無網路或空網路時，rkt和Docker容器項目均提供類似的行為。 這種容器網路的模式具有許多用途，包括測試容器，為稍後的網路連接分配容器，並且分配給不需要外部通信的容器。
Bridge
Linux網橋提供了主機內部網路，其中同一主機上的容器可以通信，但是分配給每個容器的IP地址不能從主機外部訪問。 Bridge網路利用iptables進行NAT和埠映射，從而提供單主機網路。橋接網路是默認的Docker網路類型（即，docker0），其中虛擬網路介面對的一端連接在網橋和容器之間。
這里有一個創建流程的例子：
1.在主機上設置網橋。
2.每個容器的命名空間都在該網橋中提供。
3.容器的ethX被映射到私有網橋介面。
4.使用帶有NAT的iptables來映射每個私有容器和主機的公共介面。
NAT用於提供主機之外的通信。雖然橋接網路解決埠沖突問題並為在一台主機上運行的容器提供網路隔離，但是會帶來一些NAT相關的性能成本。
Host
在這種方法中，新創建的容器與主機共享其網路命名空間，提供更高的性能（接近裸機），並且消除對NAT的需要; 然而，它確實遭受埠沖突問題。 雖然容器可以訪問所有主機的網路介面，但除非在特權模式下部署，容器可能不會重新配置主機的網路堆棧。
主機網路是Mesos中使用的默認類型。 換句話說，如果框架沒有指定網路類型，新的網路命名空間將不會與容器相關聯，而是與主機網路相關聯。 有時稱為本地網路，主機網路在概念上很簡單，使其更容易被理解，故障排除和使用。
Overlay
Overlays使用網路隧道在主機之間傳遞通信。這允許容器通過從一個主機到下一個主機隧道網路子網表現得好像它們在同一台機器上;實質上是一個網路跨越多個主機。目前存在許多隧道技術，例如虛擬可擴展區域網VXLAN。
VXLAN是Docker libnetwork的首選隧道技術，其多主機網路在1.9版本中作為原生功能。隨著這種能力的引入，Docker選擇利用HashiCorp的Serf作為gossip協議，選擇它的鄰居表交換和收斂時間的效率。
對於那些需要支持其他隧道技術的需求，Flannel可能是一個選擇。它支持udp，vxlan，host-gw，aws-vpc或gce。每個雲提供商隧道類型為您的帳戶或者VPC在提供商的路由表中創建路由。對公共雲的支持對於overlay驅動尤其重要，因為overlay能比較好的解決混合雲場景，並提供擴展和冗餘，而無需打開公共埠。
多主機網路在啟動Docker守護程序以及鍵值存儲時需要額外的參數。某些overlay依賴於分布式鍵值存儲。如果你正在做容器編排，你已經有一個分布式的鍵值存儲。
overlay層側重於跨主機通信挑戰。在同一主機上連接到兩個不同overlay網路的容器不能通過本地網橋彼此通信 - 它們是彼此分段的。
Underlays
底層網路驅動將主機介面（即，eth0處的物理網路介面）直接暴露給在主機上運行的容器或VM。 兩個這樣的底層驅動就是MACVLAN和IPVLAN。 網路工程師非常熟悉MACVLAN和IPVLAN驅動的操作和功能。 這兩個網路驅動在概念上比橋接網路更簡單，不需要埠映射，並且更高效。 此外，IPVLAN具有與許多網路工程師比較青睞的L3模式。 考慮到大多數公共雲中的限制（或缺乏能力），當您有本地工作負載，安全問題，流量優先順序或合規要求時，底層特別有用。 不同於每個VLAN需要一個網橋，底層網路允許每個子介面一個VLAN。
MACVLAN
MACVLAN允許在主機的單個物理介面後面創建多個虛擬網路介面。每個虛擬介面具有唯一的MAC和IP地址分配，有一個限制：IP地址需要在與物理介面相同的廣播域。雖然許多網路工程師可能更熟悉子介面這個術語（不要與輔助介面混淆），但用於描述MACVLAN虛擬介面的說法通常是上層或下層介面。 MACVLAN網路是一種消除對LINUX網橋需要的方式，NAT和埠映射，允許您直接連接到物理介面。
MACVLAN每個容器使用唯一的MAC地址，這可能導致啟用了防止MAC欺騙的這種安全策略（每個物理交換機介面僅允許一個MAC地址）的網路交換機出現問題。
容器流量被過濾掉，不能與底層主機通信，將主機和它上面運行的容器完全隔離。主機無法到達容器。容器與主機隔離。這對服務提供者或多租戶場景有用，並且具有比網橋模型更好的隔離。
MACVLAN需要混雜模式; MACVLAN有四種工作模式，Docker 1.12隻支持橋接模式。 MACvlan橋接模式和IPvlan L2模式在功能上等效。兩種模式都允許廣播和組播流量進入。這些底層協議的設計考慮了內部使用案例。您的公有雲里程將有所不同，因為它們的虛擬機介面上大多數不支持混合模式。
注意事項：MACVLAN橋接模式為每個容器分配唯一的MAC地址或許是跟蹤網路流量和端到端可見性的福音; 然而，對於具有512個唯一MAC地址的上限的典型網路介面卡（NIC），例如BR OADCOM，應該考慮這個上限。
IPVLAN
IPVLAN與MACVLAN類似，它創建新的虛擬網路介面並為每個IP地址分配一個唯一的IP地址。區別在於，相同的MAC地址用於主機上的所有pod和容器 - 物理介面的相同MAC地址。對這種行為的需要主要由以下事實驅動：許多交換機的通常配置的安全狀態是關閉具有來自多於一個MAC地址的業務的交換機埠。
最佳運行內核是4.2或更新版本，IPVLAN可以在L2或L3模式下運行。像MACVLAN一樣，IPVLAN L2模式要求分配給子介面的IP地址與物理介面在同一子網中。然而，IPvlan L3模式要求容器網路和IP地址在與父物理介面不同的子網上。
Linux主機上的802.1q配置（使用IP Link創建時）是短暫的，因此大多數運營商使用網路啟動腳本來保持配置。對於運行底層驅動程序和暴露API的程序化配置VLAN的容器引擎，自動化可以對其改進。例如，當在機架交換機頂部創建新VLAN時，這些VLAN可以通過暴露的容器引擎API.ico被推入Linux主機。
MACVLAN AND IPVLAN
當在這兩種底層類型之間進行選擇時，請考慮是否需要網路才能看到單個容器的MAC地址。
對於地址解析協議（ARP）和廣播通信，無論是底層驅動程序的L2模式，就像連接到交換機的伺服器那樣，通過將大量使用802.1D分組學習操作。然而，在IPVLAN L3模式中，網路堆棧在容器內處理，不允許多播或廣播流量。在這個意義之上，IPVLAN L3模式會按照您期望L3路由器的行為運行。
注意，上游L3路由器需要知道使用IPvlan創建的網路。網路廣告和重新分配網路仍然需要完成。今天，Docker正在嘗試邊界網關協議（BGP）。雖然靜態路 由可以在機架交換機的頂層創建，就像goBGP項目如雨後春筍般成立作為一個容器生態友好的方式來提供對等鄰居和路由交換功能。
盡管在給定主機上支持多種聯網模式，但是MACVLAN和IPVLAN不能同時在相同的物理介面上使用。總之，如果你習慣於在主機上運行trunks，可以用L2模式。如果你主要關注規模，L3則具有大規模的潛力。
DIRECT ROUTING
出於同樣的原因，IPVLAN L3模式被網路工程師所青睞，他們可能選擇專注於在第3層解決定址網路復雜性。這種方法受益於利用現有的網路基礎設施來管理容器網路。集中在L3的容器網路解決方案使用路由協議提供連接，這可以說更容易與現有的數據中心基礎設施，連接容器，VM和裸機伺服器進行相互操作。此外，L3網路擴展和提供在過濾和隔離網路流量方面的細粒度控制。
CALICO就是一個這樣的項目，使用BGP為每個網路分配路由 - 特別是對使用/ 32的工作負載，這允許它與現有的數據中心基礎設施無縫集成，並且不需要Overlays。沒有Overlays或封裝帶來的開銷，結果是可以組建具有卓越的性能和規模的網路。容器的可路由IP地址將IP地址與埠暴露於外部世界。被培訓並習慣於使用路由協議部署，診斷和操作網路的網路工程師可能發現直接路由更容易消化。然而，值得注意的是，CALICO不支持重疊的IP地址。
FAN NETWORKING
Fan網路是實現訪問更多IP地址的一種方式，從一個分配的IP地址擴展到250個IP地址。 這是一種獲得更多IP而不需要重疊網路的高效方法。 當在公有雲中運行容器時，這種類型的網路特別有用，其中單個IP地址被分配給主機並且啟動附加網路是禁止的，或者運行另一個負載均衡實例是昂貴的。
POINT-TO-POINT
點對點可能是CoreOS rkt使用的最簡單的網路類型和默認網路。 默認情況下，使用NAT或IPMASQ，它將創建一個虛擬乙太網對，將一個放在主機上，另一個放在容器pod中。 點到點網路利用iptables不僅為入站流量提供埠轉發，而且通過loopback介面為pod中的其他容器之間的內部通信提供埠轉發。
Capabilities在連接性之外，需要考慮對其他網路功能和網路服務的支持。容器網路的許多模式利用NAT和埠轉發或有意避免它們的使用。選擇網路時，IP地址管理IPAM，組播，廣播，IPv6，負載均衡，服務發現，策略，服務質量，高級過濾和性能都是需要額外考慮的。
問題是這些能力是否受到支持。即使您的runtime，編排引擎或插件支持容器網路功能，您的基礎架構也可能不支持該功能。雖然一些2級公有雲提供商提供對IPv6的支持，但是在頂級公有雲中卻缺乏對IPv6的支持，這也增加了用戶對其他網路類型（例如Overlays和FAN網路）的需求。
在IPAM方面，為了提高易用性，大多數容器runtime引擎默認使用host-local為容器分配地址，因為它們已連接到網路。host-local IPAM涉及定義要選擇的固定IP地址塊。跨容器網路項目普遍支持動態主機配置協議（DHCP）。容器網路模型（CNM）和容器網路介面（CNI）都具有用於與IPAM系統集成的IPAM內置和插件框架 - 這是在許多現有環境中採用的關鍵能力。
想了解更多關於容器網路模型（CNM）和容器網路介面（CNI）的技術細節請參考忘期文章： 容器網路聚焦：CNM和CNI
文末福利：請大家關注"Wise2C"公眾號並回復【進群】，睿雲小助手會第一時間拉你進入【 Docker企業落地實踐群】，我們分享的各個企業案例項目的技術專家與用戶代表，正在敬候您的光臨，期待大家就項目的更多細節與疑問與群里的大牛們進行咨詢探討。
需要了解更多有關睿雲智合的客戶項目細節，請在Wise2C公眾號中最佳實踐菜單中查看。
干貨放送系列之（一）： 富德生命人壽容器技術應用實戰案例
干貨放送系列之（二）： 中國平安容器技術應用實戰案例
干貨放送系列之（三）： 民生人壽容器技術應用實戰案例
干貨放送系列之（四）： 某中型人壽保險公司系統架構改造規劃咨詢實戰案例
年度盤點系列： 年度盤點 | 2016年金融行業容器技術應用 - 保險篇
年度盤點系列： 年度盤點 | 2016年金融行業容器技術應用 - 銀行篇
若需要了解更多有關Wise系列PaaS產品的詳情，請與我們的市場團隊聯系：
『陸』 如何查看docker容器狀態
docker ps
docker ps -a
網頁鏈接
參考一下吧
希望可以幫到你
『柒』 docker 的container模式
Docker網路container模式是指，創建新容器的時候，通過 --net container 參數，指定其和已經存在的某個容器共享一個 Network Namespace。如下圖所示，右方黃色新創建的container，其網卡共享左邊容器。因此就不會擁有自己獨立的 IP，而是共享左邊容器的 IP 172.17.0.2,埠范圍等網路資源，兩個容器的進程通過 lo 網卡設備通信。
但這兩個容器在其他的資源上，如文件系統、進程列表等還是隔離的。
使用busybox鏡像新建bb容器,bb容器網路模型默認採用的bridge模式
使用Nginx鏡像新建nginx容器,並用 --net container:bb 參數，指定該容器的網路模型為container模式，和bb容器共用相同的網路命名空間。
進入bb容器
使用命令查看網路埠情況
可以看到，nginx容器的80埠已經映射到了bb容器的80埠
在bb容器內部訪問bb容器本機的80商品，我們可以看到實際上可以訪問到nginx容器的
查看bb容器的ip地址，並退出bb容器
使用上面得到IP地址，從雲環境主機的環境，去訪問
也會得到
總結
Docker container網路模式，這種模式可以節約一定的網路資源，並能降低容器間的通信的難度。container網路模式使多個容器共享網路環境，在這種模式下容器可以通過訪問localhost來訪問 namespace下的其他容器,網路性能高
『捌』 Docker容器間網路互聯原理，講不明白算我輸
如上紅字所描述：同一個宿主機上的不同容器之間的網路如何互通的？？？
我們安裝完docker之後，docker daemon會為我們自動創建3個網路，如下：
其實docker有4種網路通信模型，分別是：bridge、host、none、container
默認的使用的網路模型是bridge，也是我們生產上會使用到的網路模型。
下文中跟大家分享docker容器互通原理到時候呢，用到的也是bridge網路模型
另外，當我們安裝完docker之後，docker會為我們創建一個叫docker0的網路設備
通過ifconfig命令可以查看到它，看起來它貌似和eth0網路地位相當，像是一張網卡。然而並不是，docker0其實是一個Linux網橋
何以見得？可以通過下面的命令查看操作系統上的網橋信息
那大家怎麼理解Linux網橋的概念呢？
其實大家可以把docker0理解成一台虛擬的交換機！然後像下面這樣類比著理解，就會豁然開朗
1、它好比是大學在機房上課時，老師旁邊的那個大大的交換機設備。
2、把機房裡的電腦都連接在交換機上，類比成docker 容器作為一台設備都連接著宿主機上的docker0。
3、把交換機和機房中的機器的ip在同一個網段，類比成docker0、和你啟動的docker容器的ip也同屬於172網段。
類比成這樣：
我們剛才做類比理解docker0的時候說：把機房裡的電腦都連接在交換機上，類比成docker 容器作為一台設備都連接著宿主機上的docker0。那具體的實現落地實現用的是啥技術呢？
答案是：veth pair
veth pair的全稱是：virtual ethernet，就是虛擬的乙太網卡。
說到乙太網卡大家都不陌生呀，不就是我們常見的那種叫eth0或者是ens的網路設備嗎？
那這個veth pair是怎麼玩的呢？有啥用呢？大家可以看下面這張圖
veth-pair設備總是會成對的出現，用於連接兩個不同network-namespace.
就上圖來說，從network-namespace1的veth0中發送的數據會出現在 network-namespace2的veth1設備中。
雖然這種特性很好，但是如果出現有多個容器，你就會發現組織架構會越來越復雜，越來越亂
不過好在我們已經循序漸進的了解Linux網橋（docker0），以及這里的veth-pair設備，於是我們可以把整體的架構圖重新繪製成下面這樣
因為不同容器有自己隔離後的network-namespace所以他們都有自己的網路協議棧
那我們能不能找到容器裡面的網卡和物理機上的哪張卡是一對網路vethpair設備呢？
如下：
回到宿主機
意思是就是說，容器545ed62d3abf的eth0網卡和宿主機通過ip addr命令查看的網路設備標號55的設備組成一對vethpair設備，彼此流量互通！
先看個簡單的，同一個區域網中的不同主機A、B之間是如何互聯交換數據的。如下圖
那，既然是同一個區域網中，說明A、B的ip地址在同一個網段，如上圖就假設它們都在192.168.1.0網段。
還得再看下面這張OSI 7層網路模型圖。
主機A向主機B發送數據，對主機A來說數據會從最上層的應用層一路往下層傳遞。比如應用層使用的http協議、傳輸層使用的TCP協議，那數據在往下層傳遞的過程中，會根據該層的協議添加上不同的協議頭等信息。
根據OSI7層網路模型的設定，對於接受數據的主機B來說，它會接收到很多數據包！這些數據包會從最下層的物理層依次往上層傳遞，依次根據每一層的網路協議進行拆包。一直到應用層取出主機A發送給他的數據。
那麼問題來了，主機B怎麼判斷它收到的數據包是否是發送給自己的呢？萬一有人發錯了呢？
答案是：根據MAC地址，邏輯如下。
那對於主機A來說，它想發送給主機B數據包，還不能讓主機B把這個數據包扔掉，它只能中規中矩的按乙太網網路協議要求封裝將要發送出去的數據包，往下傳遞到數據鏈路層（這一層傳輸的數據要求，必須要有目標mac地址，因為數據鏈路層是基於mac地址做數據傳輸的）。
那數據包中都需要哪些欄位呢？如下：
其中的dst ip好說，我們可以直接固定寫，或者通過DNS解析域名得到目標ip。
那dst mac怎麼獲取呢？
這就不得不說ARP協議了! ARP其實是一種地址解析協議，它的作用就是：以目標ip為線索，找到目的ip所在機器的mac地址。也就是幫我們找到dst mac地址！大概的過程如下幾個step
推薦閱讀：白日夢的DNS筆記
簡述這個過程：主機A想給主機B發包，那需要知道主機B的mac地址。
嗯，在arp協議的幫助下，主機A順利拿到了主機B的mac地址。於是數據包從網路層流轉到數據鏈路層時已經被封裝成了下面的樣子：
根據OIS7層網路模型，我們都知道數據包經過物理層發送到機器B，機器B接收到數據包後，再將數據包向上流轉，拆包。流轉到主機B的數據鏈路層。
那主機B是如何判斷這個在數據鏈路層的包是否是發給自己的呢？
答案前面說了，根據目的mac地址判斷。
這個例子比較簡單，dst ip就是主機B的本機ip 所以它自己會處理這個數據包。
那數據包處理完之後是需要給主機A一個響應包，那問題又來了，響應包該封裝成什麼樣子呢？對主機B來說響應包也需要src ip、src mac、dst ip、dst mac
同樣的道理，響應包也會按照如下的邏輯被主機A接受，處理。
這一次，讓我在網路告訴你，當你請求 www..com 時都發生了什麼？
有了上面那些知識儲備呢？再看我們今天要探究的問題，就不難了。
如下紅字部分：同一個宿主機上的不同容器是如何互通的？
那我們先分別登陸容器記錄下他們的ip
先看實驗效果：在9001上curl9002
實驗結果是網路互通！
我們再完善一下上面的圖，把docker0、以及兩個容器的ip補充上去，如下圖：
那兩台機器之前要通信是要遵循OSI網路模型、和乙太網協議的。
我們管172.17.0.2叫做容器2
我們管172.17.0.3叫做容器3
比如我們現在是從：容器2上curl 容器3，那麼容器2也必須按照乙太網協議將數據包封裝好，如下
那現在的問題是容器3的mac地址是多少？
容器2會先查自己的本地緩存，如果之前沒有訪問過，那麼緩存中也沒有任何記錄！
不過沒關系，還有arp機制兜底，於是容器2會發送arp請求包，大概如下
容器2會查詢自己的路由表，將這個arp請求從自己的gateway發送出去
我們發現容器2的網關對應的網路設備的ip就是docker0的ip地址，並且經由eth0發送出去！
哎？eth0不就是我們之前說的veth-pair設備嗎？
並且我們通過下面的命令可以知道它的另一端對應著宿主機上的哪個網路設備：
而且我們可以下面的小實驗，驗證上面的觀點是否正確
所以說從容器2的eth0出去的arp請求報文會同等的出現在宿主機的第53個網路設備上。
通過下面的這張圖，你也知道第53個網路設備其實就是下圖中的veth0-1
所以這個arp請求包會被發送到docker0上，由docker0拿到這個arp包發現，目標ip是172.17.0.3並不是自己，所以docker0會進一步將這個arp請求報文廣播出去，所有在172.17.0.0網段的容器都能收到這個報文！其中就包含了容器3！
那容器3收到這個arp報文後，會判斷，哦！目標ip就是自己的ip，於是它將自己的mac地址填充到arp報文中返回給docker0！
同樣的我們可以通過抓包驗證，在宿主機上
於是容器2就拿到了容器3的mac地址，乙太網數據包需要的信息也就齊全了！如下：
再之後容器2就可以和容器3正常互聯了！
容器3會收到很多數據包，那它怎麼知道哪些包是發給自己的，那些不是呢？可以參考如下的判斷邏輯
『玖』 docker swarm網路模式
docker swarm 網路模式
swarm service的路由辦法通常有兩種，VIP和DSN
這是預設情況設置，當用戶創建service的時候，這個service會被分配一個VIP，然後每一個具體的container都有一個獨立的IP，ingress會負責從VIP到各個container之間的路由。
舉例來說：
並且看到了它的屬性。
創建兩個service：
nslookup查看域名解析：
從這個例子我們可以看到：
我們再進入container看看：
每一個container有兩塊網卡：
eth0: 10.0.1.3 這就是我們前面看到的service container IP地址，是屬於網路my-network的。
eth1: 172.18.0.4，這是另一個網路地址；是誰的呢, 是網路docker_gwbridge。(另外bridge網路使用的是172.17網段)
也就是說每一個container屬於兩個網路，my-network和docker_gwbridge，分別用來service路由，和連接主機網路。
補充一點網卡eth1: 172.18.0.4，對應的網關地址是172.18.0.1，那個這個網關地址172.18.0.1是誰呢，它就是主機網路上的docker_gwbridge，在主機上運行ifconfig可以看到：
bridge網路的網段地址從172.17.X.X/16開始，第一個內置的docker0使用了172.17.X.X，後面每新增一個bridge網路就新增一個網地址，172.18.X.X, 172.19.X.X，。。。
至此兩個bridge網路都比較清楚了。
另外如果發布service的時候指定了主機埠映射，那麼container裡面會有三塊網卡分別屬於：
做一個總結：
發布service的時候：
注意swarm VIP使用的一個限制：
也就是說無法做到同一個client過來的請求保持路由到同一個container去。
適合使用自己的DSN Load-Balance演算法，例如HAProxy。
創建使用DSN輪詢的service。
由參數--endpoint-mode決定。
先看一下兩個container的ip 地址：
兩個contaienr的ip 地址分別是：
再看DSN解析結果：
每次運行ping解析出的IP地址在兩個container之間輪換，也就沒有虛IP概念了，而且swarm自動實現了DSN輪詢的功能。
再看一個nslookup結果：
可見nslookup直接把兩個container的地址都解析出來，說明一個域名(service name)對映有兩個IP地址。對照前面使用VIP的，一個service name只對映一個IP地址，就是VIP地址，而不管具體有多少個container實例。
『拾』 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等，我會在後續篇幅繼續陳述。