@

一、今天我们要搞明白的实验

如上红字所描述:同一个宿主机上的不同容器之间的网络如何互通的???

下面就一步一步探索答案!

点击阅读原文

点击查看视频讲解

点击查看视频讲解

二、前置网络知识

2.1、docker默认为我们创建的网络

我们安装完docker之后,docker daemon会为我们自动创建3个网络,如下:

~]# 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网络模型,另外如果你之前不了解也没关系,可以看下我下面的这篇文章补一下,不难,一看就懂!

1、白日梦的Docker网络入门笔记


2.2、怎么理解docker0网桥

另外,当我们安装完docker之后,docker会为我们创建一个叫docker0的网络设备

通过ifconfig命令可以查看到它,看起来它貌似和eth0网络地位相当,像是一张网卡。然而并不是,docker0其实是一个Linux网桥

[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

何以见得?可以通过下面的命令查看操作系统上的网桥信息

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

那大家怎么理解Linux网桥的概念呢?

其实大家可以把docker0理解成一台虚拟的交换机!然后像下面这样类比着理解,就会豁然开朗

1、它好比是大学在机房上课时,老师旁边的那个大大的交换机设备。

2、把机房里的电脑都连接在交换机上,类比成docker 容器作为一台设备都连接着宿主机上的docker0。

3、把交换机和机房中的机器的ip在同一个网段,类比成docker0、和你启动的docker容器的ip也同属于172网段。

# 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

类比成这样:


2.3、什么是veth-pair技术?

我们刚才做类比理解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设备呢?

如下:

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

回到宿主机

~]# 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

意思是就是说,容器545ed62d3abfeth0网卡和宿主机通过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地址,逻辑如下。

if 收到的数据包.MAC地址 == 自己的MAC地址{
// 接收数据
// 处理数据包
}else{
// 丢弃
}

那对于主机A来说,它想发送给主机B数据包,还不能让主机B把这个数据包扔掉,它只能中规中矩的按以太网网络协议要求封装将要发送出去的数据包,往下传递到数据链路层(这一层传输的数据要求,必须要有目标mac地址,因为数据链路层是基于mac地址做数据传输的)。

那数据包中都需要哪些字段呢?如下:

src 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

推荐阅读:白日梦的DNS笔记

简述这个过程:主机A想给主机B发包,那需要知道主机B的mac地址。

  1. 主机A查询本地的arp 高速缓存中是否已经存在dst ipdst mac地址的映射关系了,如果已存在,那就直接用。
  2. 本地arp高速缓存中不存在dst ipdst mac地址的映射关系的话那就只能广播arp请求包,同一网段的所有机器都能收到arp请求包。
  3. 收到arp请求包的机器会对比arp包中的src ip是否是自己的ip,如果不是则直接丢弃该arp包。如果是的话就将自己的mac地址写到arp响应包中。并且它会把请求包中src ipsrc mac的映射关系存储在自己的本地。

补充:

交换机本身也有学习能力,他会记录mac地址和交换机端口的映射关系。比如:mac=a,端口为1。

那当它接收到数据包,并发现mac=a时,它会直接将数据扔向端口1。

嗯,在arp协议的帮助下,主机A顺利拿到了主机B的mac地址。于是数据包从网络层流转到数据链路层时已经被封装成了下面的样子:

src 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地址判断。

// 主机B
if 收到的数据包.MAC地址 == 自己的MAC地址{
if dst ip == 本机ip{
// 本地处理数据包
}else{
// 查询路由表,根据路由表的规则,将数据包转某个某卡、或者默认网关
}
}else{
// 直接丢弃
}

这个例子比较简单,dst ip就是主机B的本机ip 所以它自己会处理这个数据包。

那数据包处理完之后是需要给主机A一个响应包,那问题又来了,响应包该封装成什么样子呢?对主机B来说响应包也需要src ipsrc macdst ipdst mac

src ip = 192.168.1.3
src mac = 主机B的mac地址
dst ip = 192.168.1.2
src mac = 主机A的mac地址 (之前通过arp记录在自己的arp高速缓存中了,所以,这次直接用)

同样的道理,响应包也会按照如下的逻辑被主机A接受,处理。

// 主机A
if 收到的数据包.MAC地址 == 自己的MAC地址{
if dst ip == 本机ip{
// 本地处理数据包
}else{
// 查询路由表,根据路由表的规则,将数据包转某个某卡、或者默认网关
}
}else{
// 直接丢弃
}

这一次,让我在百度告诉你,当你请求www.baidu.com时都发生了什么?

四、容器网络互通原理

有了上面那些知识储备呢?再看我们今天要探究的问题,就不难了。

如下红字部分:同一个宿主机上的不同容器是如何互通的?

那我们先分别登陆容器记录下他们的ip

9001的ip是:172.17.0.2
9002的ip是:172.17.0.3

先看实验效果:在9001上curl9002

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

实验结果是网络互通!

我们再完善一下上面的图,把docker0、以及两个容器的ip补充上去,如下图:

那两台机器之前要通信是要遵循OSI网络模型、和以太网协议的。

我们管172.17.0.2叫做容器2

我们管172.17.0.3叫做容器3

比如我们现在是从:容器2上curl 容器3,那么容器2也必须按照以太网协议将数据包封装好,如下

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

那现在的问题是容器3的mac地址是多少?

删掉所有容器,重新启动,方便实验抓包

容器2会先查自己的本地缓存,如果之前没有访问过,那么缓存中也没有任何记录!

:/# arp -n

不过没关系,还有arp机制兜底,于是容器2会发送arp请求包,大概如下

1、这是一个arp请求包
2、我的ip地址是:172.17.0.2
3、我的mac地址是:容器2的mac地址
4、请问:ip地址为:172.17.0.3的机器,你的mac地址是多少?

容器2会查询自己的路由表,将这个arp请求从自己的gateway发送出去

/# 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设备吗?

并且我们通过下面的命令可以知道它的另一端对应着宿主机上的哪个网络设备:

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

而且我们可以下面的小实验,验证上面的观点是否正确

# 在容器中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

所以这个arp请求包会被发送到docker0上,由docker0拿到这个arp包发现,目标ip是172.17.0.3并不是自己,所以docker0会进一步将这个arp请求报文广播出去,所有在172.17.0.0网段的容器都能收到这个报文!其中就包含了容器3!

那容器3收到这个arp报文后,会判断,哦!目标ip就是自己的ip,于是它将自己的mac地址填充到arp报文中返回给docker0!

同样的我们可以通过抓包验证,在宿主机上

# 在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地址,以太网数据包需要的信息也就齐全了!如下:

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

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

容器3会收到很多数据包,那它怎么知道哪些包是发给自己的,那些不是呢?可以参考如下的判断逻辑

if 响应包.mac == 自己的mac{
// 说明这是发给自己包,所以不能丢弃
if 响应包.ip == 自己的ip{
// 向上转发到osi7层网络模型的上层
}else{
// 查自己的route表,找下一跳
}
}else{
// 直接丢弃
}

五、实验环境

# 下载
~]# 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

六、推荐阅读

1、白日梦的Docker网络入门笔记

2、这一次,让我在百度告诉你,当你请求www.baidu.com时都发生了什么?

3、白日梦的网络笔记:iptables、防火墙

4、白日梦的DNS笔记

七、原创不易!欢迎关注啊!

点击阅读原文

点击阅读原文

点击阅读原文

点击查看视频讲解

点击查看视频讲解

点击查看视频讲解

Docker容器间网络互联原理,讲不明白算我输....的更多相关文章

  1. docker 容器间网络配置

    创建一个docker容器,docker系统会自动为该容器分配一个ip地址,通常是172.17开头. 我们可以在主机上用 docker inspect 命令 或者进入容器用ifconfig命令来查看容器 ...

  2. Docker容器的网络连接:

    yw1989@ubuntu:~$ ifconfig docker0 Link encap:Ethernet HWaddr 02:42:97:61:42:9f inet addr:172.17.0.1 ...

  3. Docker容器的网络连接

    Docker容器的网络连接 Docker容器的网络连接 我们用ifconfig命令来查看网络设备 我们可以看到上面有个叫docker0的网络设备,docker守护进程就是通过docker0为docke ...

  4. Docker基本命令与使用 —— Docker容器的网络连接(四)

    一.Docker容器的网络基础 通过ifconfig查看docker0的网络设备,docker守护进程就是通过docker0为docker的容器提供网络连接的各种服务. docker0是Linux虚拟 ...

  5. Docker学习(13) Docker容器的网络连接

    Docker容器的网络连接 Docker容器的网络基础 先安装网桥管理工具 Docker容器的互联 默认 Docker容器与外部网络的连接

  6. Docker 容器间的单向连接

    Docker 容器间的单向连接 前言 a. 本文主要为 Docker的视频教程 笔记. b. 环境为 CentOS 7.0 云服务器 c. 上一篇:Dockerfile 自动制作 Docker 镜像( ...

  7. Docker 容器的网络连接 & 容器互联

    1. Docker 容器网络基础架构 Docker0 ifconfig查看到的 docker0 是linux的虚拟网桥(OSI数据链路层) docker0 地址划分: 172.17.42.1 255. ...

  8. docker容器间通信

    现在在我们的docker中已经有了三个容器,分别是DB/API/UI三个容器,三个容器间肯定是要进行互相通信的 可以查看docker的官方文档,https://docs.docker.com/engi ...

  9. Docker容器技术的核心原理

    目录 1 前言 2 docker容器技术 2.1 隔离:Namespace 2.2 限制:Cgroup 2.3 rootfs 2.4 镜像分层 3 docker容器与虚拟机的对比 1 前言 上图是百度 ...

随机推荐

  1. 腾讯云 CIF 工程效能峰会,10 月 19 - 20 日震撼来袭!

    近年来,依托于云计算的飞速发展,腾讯云云产品更新迅猛,云原生生态构建初具规模,越来越多的企业也开始寻求与深入数字化转型之路.但在摸索与实践中,企业往往会进入"伪上云"的误区.除了单 ...

  2. Java开发基础平台带集成的审批工作流

    前言 activiti工作流,企业erp.oa.hr.crm等审批系统轻松落地,请假审批demo从流程绘制到审批结束实例. 一.项目形式 springboot+vue+activiti集成了activ ...

  3. python json格式化打印

    编写python脚本,调试的时候需要打印json格式报文,直接打印看不出层次,可以使用json.dumps格式化打印 import json import requests def test_json ...

  4. PolarDB PostgreSQL Buffer Management 原理

    背景介绍 传统数据库的主备架构,主备有各自的存储,备节点回放WAL日志并读写自己的存储,主备节点在存储层没有耦合.PolarDB的实现是基于共享存储的一写多读架构,主备使用共享存储中的一份数据.读写节 ...

  5. PC Register简介

    PC Regiter介绍: JVM中的程序计数寄存器(Program Counter Register)中,Register的命名源于CPU的寄存器,寄存器存储指令相关的现场信息,CPU只有把数据装载 ...

  6. html行内元素

    定义 行内元素只占据它对应标签的边框所包含的空间,没有换行效果 div{ /* 定义行内元素*/ display:inline } 特点 多个元素可以横排显示 不支持宽高和上下margin 支持pad ...

  7. 一文读懂 Serverless,将配置化思想复用到平台系统中

    作者 | 春哥大魔王 来源 | Serverless 公众号 写在前面 在 SaaS 领域 Salesforce 是佼佼者,其 CRM 的概念已经扩展到了 Marketing.Sales.Servic ...

  8. 题解 [CTSC2006]歌唱王国

    题目传送门 Desctiption 见题面. Solution 人类智慧... 考虑这样一个赌博游戏,现在有一个猴子,它随机从 \(1\sim n\) 中选一个打出来.现在有若干个赌徒,他们一开始都有 ...

  9. 项目问题记录------Mabatis动态sql语句

    现在在做一个模糊查询功能,使用两个查询条件: 条件1:下拉框选择的产品名 条件2:输入框输入的用户名 需求1:下拉框的选项是从数据库里导出来的产品名,此外,添加一个选项"全部产品" ...

  10. Hive SQL的底层编译过程详解

    本文结构采用宏观着眼,微观入手,从整体到细节的方式剖析 Hive SQL 底层原理.第一节先介绍 Hive 底层的整体执行流程,然后第二节介绍执行流程中的 SQL 编译成 MapReduce 的过程, ...