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

        一定搞得懂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號
        主站蜘蛛池模板: 乱色精品无码一区二区国产盗| 91老司机深夜福利精品视频在线观看| 亚洲精品二区国产综合野狼| 911亚洲精品国内自产| 亚洲精品午夜无码专区| 亚洲国语精品自产拍在线观看| 亚洲精品夜夜夜妓女网| 精品久久久久久99人妻| 精品久久香蕉国产线看观看亚洲| 亚洲国产精品久久电影欧美| 老子影院午夜精品无码| 成人国产精品秘 果冻传媒在线| 国产日韩精品中文字无码 | 亚洲AV永久无码精品水牛影视| 99久久精品国产一区二区蜜芽| 99re这里只有精品国产精品| 久久久久久九九99精品| 无码人妻精品一区二区三区66 | 国内精品久久久久久野外| 人人妻人人澡人人爽人人精品电影| 三级高清精品国产| 久久久精品人妻无码专区不卡| 隔壁老王国产在线精品| 柠檬福利精品视频导航| 国产精品岛国久久久久| 99国产精品永久免费视频| 精品人妻系列无码天堂| 日韩精品专区在线影院重磅| 亚洲综合欧美精品一区二区| 欧美精品亚洲精品日韩专区| 久久996热精品xxxx| 国自产精品手机在线观看视| 国产精品理论片在线观看| 99久久精品无码一区二区毛片 | 国产成人精品日本亚洲11| 97精品人妻系列无码人妻| 日本午夜精品理论片A级APP发布| 精品无人码麻豆乱码1区2区| 无码精品久久一区二区三区| 日本精品久久久久影院日本 | 国产精品jizz视频|