久久精品五月,日韩不卡视频在线观看,国产精品videossex久久发布 ,久久av综合

站長資訊網
最全最豐富的資訊網站

一定搞得懂Docker容器間網絡互聯原理

本篇文章給大家帶來了關于docker容器間網絡互聯原理的相關知識,希望對大家有幫助。

一定搞得懂Docker容器間網絡互聯原理

一、今天我們要搞明白的實驗

一定搞得懂Docker容器間網絡互聯原理

如上紅字所描述:同一個宿主機上的不同容器之間的網絡如何互通的???

二、前置網絡知識

2.1、docker默認為我們創建的網絡

我們安裝完docker之后,docker daemon會為我們自動創建3個網絡,如下:

Copy~]# docker network ls NETWORK ID     NAME                DRIVER    SCOPE e71575e3722a   bridge              bridge    local ab8e3d45575c   host                host      local 0c9b7c1134ff   none                null      local

其實docker有4種網絡通信模型,分別是:bridge、host、none、container

默認的使用的網絡模型是bridge,也是我們生產上會使用到的網絡模型。

下文中跟大家分享docker容器互通原理到時候呢,用到的也是bridge網絡模型


2.2、怎么理解docker0網橋

另外,當我們安裝完docker之后,docker會為我們創建一個叫docker0的網絡設備

通過ifconfig命令可以查看到它,看起來它貌似和eth0網絡地位相當,像是一張網卡。然而并不是,docker0其實是一個Linux網橋

Copy[root@vip ~]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00     inet 127.0.0.1/8 scope host lo        valid_lft forever preferred_lft forever     inet6 ::1/128 scope host        valid_lft forever preferred_lft forever  2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000     link/ether 00:0c:29:b4:97:ee brd ff:ff:ff:ff:ff:ff     inet 10.4.7.99/24 brd 10.4.7.255 scope global noprefixroute eth0        valid_lft forever preferred_lft forever     inet6 fe80::20c:29ff:feb4:97ee/64 scope link        valid_lft forever preferred_lft forever  3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default     link/ether 02:42:db:fe:ff:db brd ff:ff:ff:ff:ff:ff     inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0        valid_lft forever preferred_lft forever     inet6 fe80::42:dbff:fefe:ffdb/64 scope link        valid_lft forever preferred_lft forever

何以見得?可以通過下面的命令查看操作系統上的網橋信息

Copy ~]# yum install bridge-utils  ~]# brctl show bridge name bridge id       STP enabled interfaces docker0     8000.0242f0a8c0be   no      veth86e2ef2                                                                     vethf0a8bcb

那大家怎么理解Linux網橋的概念呢?

其實大家可以把docker0理解成一臺虛擬的交換機!然后像下面這樣類比著理解,就會豁然開朗

一定搞得懂Docker容器間網絡互聯原理

1、它好比是大學在機房上課時,老師旁邊的那個大大的交換機設備。

2、把機房里的電腦都連接在交換機上,類比成docker 容器作為一臺設備都連接著宿主機上的docker0。

3、把交換機和機房中的機器的ip在同一個網段,類比成docker0、和你啟動的docker容器的ip也同屬于172網段。

Copy# docker0 ip是:  ~]# ifconfig 3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default     link/ether 02:42:db:fe:ff:db brd ff:ff:ff:ff:ff:ff     inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0        valid_lft forever preferred_lft forever     inet6 fe80::42:dbff:fefe:ffdb/64 scope link        valid_lft forever preferred_lft forever  # 進入容器中查看ip是: /# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500         inet 172.17.0.2  netmask 255.255.0.0  broadcast 172.17.255.255         ether 02:42:ac:11:00:02  txqueuelen 0  (Ethernet)         RX packets 13  bytes 1102 (1.0 KiB)         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

類比成這樣:

一定搞得懂Docker容器間網絡互聯原理


2.3、什么是veth-pair技術?

我們剛才做類比理解docker0的時候說:把機房里的電腦都連接在交換機上,類比成docker 容器作為一臺設備都連接著宿主機上的docker0。那具體的實現落地實現用的是啥技術呢?

答案是:veth pair

veth pair的全稱是:virtual ethernet,就是虛擬的以太網卡。

說到以太網卡大家都不陌生呀,不就是我們常見的那種叫eth0或者是ens的網絡設備嗎?

那這個veth pair是怎么玩的呢?有啥用呢?大家可以看下面這張圖

一定搞得懂Docker容器間網絡互聯原理一定搞得懂Docker容器間網絡互聯原理

veth-pair設備總是會成對的出現,用于連接兩個不同network-namespace.

就上圖來說,從network-namespace1的veth0中發送的數據會出現在 network-namespace2的veth1設備中。

雖然這種特性很好,但是如果出現有多個容器,你就會發現組織架構會越來越復雜,越來越亂

一定搞得懂Docker容器間網絡互聯原理

不過好在我們已經循序漸進的了解Linux網橋(docker0),以及這里的veth-pair設備,于是我們可以把整體的架構圖重新繪制成下面這樣

一定搞得懂Docker容器間網絡互聯原理

因為不同容器有自己隔離后的network-namespace所以他們都有自己的網絡協議棧

那我們能不能找到容器里面的網卡和物理機上的哪張卡是一對網絡vethpair設備呢?

如下:

Copy# 進入容器 ~]# docker exec -ti 545ed62d3abf /bin/bash  /# apt-get install ethtool /# ethtool -S eth0 NIC statistics:      peer_ifindex: 55

回到宿主機

Copy~]# ip addr     ... 55: vethf0a8bcb@if54: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default     link/ether ae:eb:5c:2f:7d:c3 brd ff:ff:ff:ff:ff:ff link-netnsid 10     inet6 fe80::aceb:5cff:fe2f:7dc3/64 scope link        valid_lft forever preferred_lft forever

意思是就是說,容器545ed62d3abf的eth0網卡和宿主機通過ip addr命令查看的網絡設備標號55的設備組成一對vethpair設備,彼此流量互通!

三、同一個局域網中不同主機的互聯原理

先看個簡單的,同一個局域網中的不同主機A、B之間是如何互聯交換數據的。如下圖

一定搞得懂Docker容器間網絡互聯原理

那,既然是同一個局域網中,說明A、B的ip地址在同一個網段,如上圖就假設它們都在192.168.1.0網段。

還得再看下面這張OSI 7層網絡模型圖。

主機A向主機B發送數據,對主機A來說數據會從最上層的應用層一路往下層傳遞。比如應用層使用的http協議、傳輸層使用的TCP協議,那數據在往下層傳遞的過程中,會根據該層的協議添加上不同的協議頭等信息。

一定搞得懂Docker容器間網絡互聯原理

根據OSI7層網絡模型的設定,對于接受數據的主機B來說,它會接收到很多數據包!這些數據包會從最下層的物理層依次往上層傳遞,依次根據每一層的網絡協議進行拆包。一直到應用層取出主機A發送給他的數據。

那么問題來了,主機B怎么判斷它收到的數據包是否是發送給自己的呢?萬一有人發錯了呢?

答案是:根據MAC地址,邏輯如下。

Copyif 收到的數據包.MAC地址 == 自己的MAC地址{   // 接收數據   // 處理數據包 }else{  // 丟棄 }

那對于主機A來說,它想發送給主機B數據包,還不能讓主機B把這個數據包扔掉,它只能中規中矩的按以太網網絡協議要求封裝將要發送出去的數據包,往下傳遞到數據鏈路層(這一層傳輸的數據要求,必須要有目標mac地址,因為數據鏈路層是基于mac地址做數據傳輸的)。

那數據包中都需要哪些字段呢?如下:

Copysrc ip = 192.168.1.2  //源ip地址,交換機 dst ip = 192.168.1.3  //目標ip地址 //本機的mac地址(保證從主機B回來的包正常送達主機A,且主機A能正常處理它) src mac = 主機A的mac地址 dst mac = 主機B的mac地址//目標mac地址

其中的dst ip好說,我們可以直接固定寫,或者通過DNS解析域名得到目標ip。

那dst mac怎么獲取呢?

這就不得不說ARP協議了! ARP其實是一種地址解析協議,它的作用就是:以目標ip為線索,找到目的ip所在機器的mac地址。也就是幫我們找到dst mac地址!大概的過程如下幾個step

一定搞得懂Docker容器間網絡互聯原理

推薦閱讀:白日夢的DNS筆記

簡述這個過程:主機A想給主機B發包,那需要知道主機B的mac地址。

  1. 主機A查詢本地的arp 高速緩存中是否已經存在dst ip和dst mac地址的映射關系了,如果已存在,那就直接用。
  2. 本地arp高速緩存中不存在dst ip和dst mac地址的映射關系的話那就只能廣播arp請求包,同一網段的所有機器都能收到arp請求包。
  3. 收到arp請求包的機器會對比arp包中的src ip是否是自己的ip,如果不是則直接丟棄該arp包。如果是的話就將自己的mac地址寫到arp響應包中。并且它會把請求包中src ip和src mac的映射關系存儲在自己的本地。

補充:

交換機本身也有學習能力,他會記錄mac地址和交換機端口的映射關系。比如:mac=a,端口為1。

那當它接收到數據包,并發現mac=a時,它會直接將數據扔向端口1。

嗯,在arp協議的幫助下,主機A順利拿到了主機B的mac地址。于是數據包從網絡層流轉到數據鏈路層時已經被封裝成了下面的樣子:

Copysrc ip = 192.168.1.2 src mac = 主機A的mac地址 dst ip = 192.168.1.3 dst mac = 主機B的mac地址

網絡層基于ip地址做數據做轉發

數據鏈路基于mac地址做數據轉發

根據OIS7層網絡模型,我們都知道數據包經過物理層發送到機器B,機器B接收到數據包后,再將數據包向上流轉,拆包。流轉到主機B的數據鏈路層。

那主機B是如何判斷這個在數據鏈路層的包是否是發給自己的呢?

答案前面說了,根據目的mac地址判斷。

Copy// 主機B if 收到的數據包.MAC地址 == 自己的MAC地址{   if dst ip == 本機ip{     // 本地處理數據包   }else{     // 查詢路由表,根據路由表的規則,將數據包轉某個某卡、或者默認網關   } }else{  // 直接丟棄 }

這個例子比較簡單,dst ip就是主機B的本機ip 所以它自己會處理這個數據包。

那數據包處理完之后是需要給主機A一個響應包,那問題又來了,響應包該封裝成什么樣子呢?對主機B來說響應包也需要src ip、src mac、dst ip、dst mac

Copysrc ip = 192.168.1.3 src mac = 主機B的mac地址 dst ip = 192.168.1.2 src mac = 主機A的mac地址 (之前通過arp記錄在自己的arp高速緩存中了,所以,這次直接用)

同樣的道理,響應包也會按照如下的邏輯被主機A接受,處理。

Copy// 主機A if 收到的數據包.MAC地址 == 自己的MAC地址{   if dst ip == 本機ip{     // 本地處理數據包   }else{     // 查詢路由表,根據路由表的規則,將數據包轉某個某卡、或者默認網關   } }else{  // 直接丟棄 }

這一次,讓我在百度告訴你,當你請求www.baidu.com時都發生了什么?

四、容器網絡互通原理

有了上面那些知識儲備呢?再看我們今天要探究的問題,就不難了。

如下紅字部分:同一個宿主機上的不同容器是如何互通的?

一定搞得懂Docker容器間網絡互聯原理

那我們先分別登陸容器記錄下他們的ip

Copy9001的ip是:172.17.0.2 9002的ip是:172.17.0.3

先看實驗效果:在9001上curl9002

Copy/# curl 172.7.88.3 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } ...

實驗結果是網絡互通!

我們再完善一下上面的圖,把docker0、以及兩個容器的ip補充上去,如下圖:

一定搞得懂Docker容器間網絡互聯原理

Docker容器間網絡互聯原理,講不明白算我輸

那兩臺機器之前要通信是要遵循OSI網絡模型、和以太網協議的。

我們管172.17.0.2叫做容器2

我們管172.17.0.3叫做容器3

比如我們現在是從:容器2上curl 容器3,那么容器2也必須按照以太網協議將數據包封裝好,如下

Copysrc ip = 172.17.0.2 src mac = 容器2的mac地址 dst ip = 172.17.0.3 dst mac = 容器3的mac地址 ???

那現在的問題是容器3的mac地址是多少?

刪掉所有容器,重新啟動,方便實驗抓包

容器2會先查自己的本地緩存,如果之前沒有訪問過,那么緩存中也沒有任何記錄!

Copy:/# arp -n

不過沒關系,還有arp機制兜底,于是容器2會發送arp請求包,大概如下

Copy1、這是一個arp請求包 2、我的ip地址是:172.17.0.2 3、我的mac地址是:容器2的mac地址 4、請問:ip地址為:172.17.0.3的機器,你的mac地址是多少?

容器2會查詢自己的路由表,將這個arp請求從自己的gateway發送出去

Copy/# route -n Kernel IP routing table Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 0.0.0.0         172.7.88.1      0.0.0.0         UG    0      0        0 eth0 172.7.88.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0

我們發現容器2的網關對應的網絡設備的ip就是docker0的ip地址,并且經由eth0發送出去!

哎?eth0不就是我們之前說的veth-pair設備嗎?

并且我們通過下面的命令可以知道它的另一端對應著宿主機上的哪個網絡設備:

Copy/# ethtool -S eth0 NIC statistics:      peer_ifindex: 53

而且我們可以下面的小實驗,驗證上面的觀點是否正確

Copy# 在容器中ping百度 ~]# ping 220.181.38.148  # 在宿主機上抓包 ~]# yum install tcpdump -y ~]# tcpdump -i ${vethpair宿主機側的接口名} host 220.181.38.148  ...

所以說從容器2的eth0出去的arp請求報文會同等的出現在宿主機的第53個網絡設備上。

通過下面的這張圖,你也知道第53個網絡設備其實就是下圖中的veth0-1

一定搞得懂Docker容器間網絡互聯原理

所以這個arp請求包會被發送到docker0上,由docker0拿到這個arp包發現,目標ip是172.17.0.3并不是自己,所以docker0會進一步將這個arp請求報文廣播出去,所有在172.17.0.0網段的容器都能收到這個報文!其中就包含了容器3!

那容器3收到這個arp報文后,會判斷,哦!目標ip就是自己的ip,于是它將自己的mac地址填充到arp報文中返回給docker0!

同樣的我們可以通過抓包驗證,在宿主機上

Copy# 在172.17.0.2容器上ping172.17.0.3 /# ping 172.17.0.3  ~]# tcpdump -i vethdb0d222 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vethdb0d222, link-type EN10MB (Ethernet), capture size 262144 bytes  17:25:30.218640 ARP, Request who-has 172.17.0.3 tell 172.17.0.2, length 28 17:25:30.218683 ARP, Reply 172.17.0.3 is-at 02:42:ac:11:00:03 (oui Unknown), length 28 17:25:30.218686 IP 172.17.0.2.54014 > 172.17.0.3.http: Flags [S], seq 3496600258, win 29200, options [mss 1460,sackOK,TS val 4503202 ecr 0,nop,wscale 7], length 0

于是容器2就拿到了容器3的mac地址,以太網數據包需要的信息也就齊全了!如下:

Copysrc ip = 172.17.0.2 src mac = 容器2的mac地址 dst ip = 172.17.0.3 dst mac = 容器3的mac地址

再之后容器2就可以和容器3正常互聯了!

容器3會收到很多數據包,那它怎么知道哪些包是發給自己的,那些不是呢?可以參考如下的判斷邏輯

Copyif 響應包.mac == 自己的mac{  // 說明這是發給自己包,所以不能丟棄   if 響應包.ip == 自己的ip{     // 向上轉發到osi7層網絡模型的上層   }else{     // 查自己的route表,找下一跳   } }else{  // 直接丟棄 }

五、實驗環境

Copy# 下載  ~]# docker pull registry.cn-hangzhou.aliyuncs.com/changwu/nginx:1.7.9-nettools  # 先啟動1個容器  ~]# docker run --name mynginx1 -i -t -d -p 9001:80 nginx-1.7.9-nettools:latest eb569b938c07e95ccccbfc654c1fee6364eea55b20f5394382ff42b4ccf96312  ~]# docker run --name mynginx2 -i -t -d -p 9002:80 nginx-1.7.9-nettools:latest 545ed62d3abfd63aa9c3ae196e9d7fe6f59bbd2e9ae4e6f2bd378f23587496b7  # 驗證 ~]# curl 127.0.0.1:9001

推薦學習:《docker視頻教程》

贊(0)
分享到: 更多 (0)
?
網站地圖   滬ICP備18035694號-2    滬公網安備31011702889846號
久久精品五月,日韩不卡视频在线观看,国产精品videossex久久发布 ,久久av综合
欧美成人国产| 久久国产精品亚洲77777| 在线一区二区三区视频| 中文国产一区| 欧美精品一区二区三区精品| 在线一区免费| 亚洲毛片网站| 欧美精品二区| 成人在线丰满少妇av| 秋霞国产精品| 亚洲免费中文| 久久狠狠久久| 国产一区二区三区不卡视频网站 | 午夜av成人| 亚洲福利免费| 美女被久久久| 欧美一区精品| 国产精品亚洲一区二区三区在线观看| 黑丝一区二区| 欧美午夜三级| 麻豆mv在线观看| 国产一区91| 欧美一区91| 亚洲成人精品| 日韩精品一区二区三区中文字幕| 国产精区一区二区| 日韩中文欧美| 中文字幕乱码亚洲无线精品一区| 欧美国产三级| 亚洲午夜一级| 欧美亚洲自偷自偷| 日韩av免费| 日韩欧美中文在线观看| 中文字幕成在线观看| 日韩精品一级中文字幕精品视频免费观看| 亚洲91网站| 亚洲精品在线影院| 日韩影片在线观看| 久久美女性网| 国产探花一区在线观看| 欧产日产国产精品视频| 四虎精品一区二区免费| 成人午夜精品| 国产欧美日韩亚洲一区二区三区| 99久久久久| 麻豆精品新av中文字幕| 日韩精品一区第一页| 波多野结衣久久精品| 欧美一区网站| 亚洲一区二区三区四区五区午夜 | 黄色亚洲精品| 国产精品1luya在线播放| 99久久亚洲精品| 国产精品巨作av| 免费日韩av片| 成人久久一区| 久久精品伊人| 日韩精品成人在线观看| 黄页网站一区| 亚洲人成在线网站| 欧美黑人做爰爽爽爽| 日韩一区精品| 香蕉成人久久| 欧美成人高清| 欧美片第1页| 久久久精品国产**网站| 奇米亚洲欧美| 女人av一区| 国产 日韩 欧美 综合 一区| 日韩va亚洲va欧美va久久| 99亚洲视频| 国精品一区二区三区| 丝袜诱惑一区二区| 国际精品欧美精品| 国产精品一线天粉嫩av| 亚洲欧美网站在线观看| 亚洲经典在线| 黄色不卡一区| 久久九九99| 日韩av首页| 新版的欧美在线视频| 精品国产a一区二区三区v免费| 欧美日韩一区二区三区不卡视频 | 国产精品三p一区二区| 在线国产日韩| 国产精品日韩久久久| 激情综合网址| 久久中文字幕av| 欧美日一区二区| 神马日本精品| 欧洲av一区二区| 在线视频观看日韩| 伊人精品一区| 欧美sss在线视频| 日韩久久一区二区三区| 日韩精品一区二区三区免费观看| 日韩另类视频| 精品91久久久久| 国产精品女主播一区二区三区| 91久久亚洲| 欧美资源在线| 中文字幕av一区二区三区四区| 日韩精品一区二区三区中文在线| 亚洲va久久久噜噜噜久久| 日韩一区二区三区在线看| 日韩一区二区三区四区五区| 欧美日韩一区二区三区在线电影| 国产精品一区二区三区美女| 91精品麻豆| 久久久亚洲欧洲日产| 超碰在线99| 不卡中文一二三区| 亚洲视频二区| 国产欧美午夜| 中文在线资源| 在线亚洲一区| 日韩一区二区三区四区五区| 国产日韩在线观看视频| 精品国产网站| 欧美久久精品一级c片| 日韩在线观看一区二区| 欧美亚洲三区| 成人福利视频| 狠狠色综合网| 国产亚洲一区| 日韩免费一区| 日韩制服丝袜av| 麻豆国产精品777777在线| 成人va天堂| 免费久久精品视频| 蜜桃精品视频| 波多野结衣一区| 91精品福利观看| 国产美女高潮在线| 亚洲在线国产日韩欧美| 国产伦理久久久久久妇女| 成人三级高清视频在线看| 最新亚洲一区| 国产日产精品_国产精品毛片 | 国产一卡不卡| 久久婷婷一区| 中文字幕日韩亚洲| 国际精品欧美精品| 鲁大师成人一区二区三区| 国产精品一区二区三区美女| 欧美日韩在线观看首页| 丝袜美腿亚洲一区| 精品国产亚洲一区二区三区| 91精品电影| 国产精品扒开腿做爽爽爽软件| 久久久久国产精品一区三寸| 日韩精品中文字幕吗一区二区| 伊人久久在线| 国产视频网站一区二区三区| 国产韩日影视精品| 美日韩一区二区三区| 亚洲精品免费观看| 久久不见久久见免费视频7| 久久精品国产99国产| 欧美在线亚洲综合一区| 国产精品网在线观看| 国产99精品| 精品国产一区二| 亚洲精品系列| 欧美日韩高清| a国产在线视频| 日本不卡在线视频| 91精品成人| 91嫩草亚洲精品| 欧美伊人影院| 国产亚洲毛片在线| 老牛国内精品亚洲成av人片| 蜜芽一区二区三区| 亚洲成人av观看| 欧美成a人片免费观看久久五月天| 国产麻豆综合| 久久精品国产精品亚洲毛片| 亚洲精品一二| 尤物在线精品| 99久久久久久中文字幕一区| 免费观看亚洲天堂| 日本精品一区二区三区在线观看视频| 国产高清一区二区| 亚洲综合在线电影| 国产精品精品| 麻豆国产精品777777在线| 亚洲图片久久| 亚洲欧美日韩视频二区| 欧美日韩国产传媒| 电影亚洲精品噜噜在线观看| 精品国产亚洲一区二区三区| 国产精品丝袜在线播放| 欧美一级一区| 欧美一区二区三区免费看| 亚洲精品动态| 亚洲精品影视| 日本在线视频一区二区| 少妇精品久久久一区二区| 丝瓜av网站精品一区二区 | 日韩专区视频网站|