Docker（73）
flannel（4）
可以为容器提供网络服务。
其模型为全部的容器使用一个network，然后在每个host上从network中划分一个子网subnet。
为host上的容器创建网络时，从subnet中划分一个ip给容器。
其采用目前比较流行的no server的方式，即不存在所谓的控制节点，而是每个host上的flanneld从一个etcd中获取相关数据，然后声明自己的子网网段，并记录在etcd中。
其他的host对数据转发时，从etcd中查询到该子网所在的host的ip，然后将数据发往对应host上的flanneld，交由其进行转发。
根据kubernetes的模型，即为每个pod提供一个ip。flannel的模型正好与之契合。因此flannel是最简单易用的kubernetes集群网络方案。
flannel与docker的结合
flannel的工作原理这里不重复赘述。网上有很多资料。本文主要讲一下flannel是怎么与docker结合起来的。
flannel服务启动
flannel服务需要先于docker启动。flannel服务启动时主要做了以下几步的工作：
从etcd中获取network的配置信息划分subnet，并在etcd中进行注册将子网信息记录到/run/flannel/subnet.env中
[root@localhost run]
FLANNEL_NETWORK=4.0.0.0/16
FLANNEL_SUBNET=4.0.34.1/24
FLANNEL_MTU=1472
FLANNEL_IPMASQ=false
之后将会有一个脚本将subnet.env转写成一个docker的环境变量文件/run/flannel/docker
[root@localhost run]
DOCKER_OPT_BIP=&--bip=4.0.34.1/24&
DOCKER_OPT_IPMASQ=&--ip-masq=true&
DOCKER_OPT_MTU=&--mtu=1472&
DOCKER_NETWORK_OPTIONS=& --bip=4.0.34.1/24 --ip-masq=true --mtu=1472 &
docker服务启动
接下来，docker daemon启动，使用/run/flannel/docker中的变量，作为启动参数，启动后的进程如下
[root@localhost ~]
00:08:04 /usr/bin/docker-current daemon --exec-opt native.cgroupdriver=systemd --selinux-enabled --log-driver=journald --bip=4.0.100.1/24 --ip-masq=true --mtu=1472
容器之后的启动，就是由docker daemon负责了。因为配置了bip，因此创建出来的容器会使用该网段的ip，并赋给容器。即容器其实还是按照bridge的模式，进行创建的。
flannel与docker结合原理
现在问题来了，容器之间是怎么互通的呢？这里先要说道flanneld，他会在宿主机host上创建一个flannel0的设备。
[root@localhost ~]
1: lo: &LOOPBACK,UP,LOWER_UP& mtu 65536 qdisc noqueue state UNKNOWN
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: enp0s3: &BROADCAST,MULTICAST,UP,LOWER_UP& mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:27:b7:7e:f3 brd ff:ff:ff:ff:ff:ff
inet 10.8.65.66/24 brd 10.8.65.255 scope global dynamic enp0s3
valid_lft 67134sec preferred_lft 67134sec
inet6 fe80::a00:27ff:feb7:7ef3/64 scope link
valid_lft forever preferred_lft forever
5: flannel0: &POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP& mtu 1472 qdisc pfifo_fast state UNKNOWN qlen 500
inet 4.0.100.0/16 scope global flannel0
valid_lft forever preferred_lft forever
6: docker0: &BROADCAST,MULTICAST,UP,LOWER_UP& mtu 1472 qdisc noqueue state UP
link/ether 02:42:2e:5e:cd:90 brd ff:ff:ff:ff:ff:ff
inet 4.0.100.1/24 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:2eff:fe5e:cd90/64 scope link
valid_lft forever preferred_lft forever
接下来我们在看宿主机host上的路由信息。
[root@localhost ~]#
255.255.0.0
255.255.255.0
10.8.64.10
255.255.255.255
255.255.255.0
现在有三个容器分别是A/B/C
当容器A发送到同一个subnet的容器B时，因为二者处于同一个子网，所以容器A/B位于同一个宿主机host上，而容器A/B也均桥接在docker0上。
[root@localhost ~]# brctl show
bridge name bridge id
STP enabled interfaces
veth2d1c803
veth916067e
借助于网桥docker0，容器A/B即可实现通信。
那么位于不同宿主机的容器A和C如何通信呢？这个时候就要用到了flannel0这个设备了。
容器A想要发送给容器C，查路由表，可以知道需要使用flannel0接口，因此将数据发送到flannel0。
flanneld进程接收到flannel0接收的数据，然后从etcd中查询出4.0.32.0/24的子网的宿主机host的ip10.8.65.53。
[root@localhost calico]
{&PublicIP&:&10.8.65.53&}
然后将数据封包，发送到10.8.65.53的对应端口，由10.8.65.53的flanneld接收，解包，并转发到对应的容器中。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：54908次
积分：1934
积分：1934
排名：第16446名
原创：117篇
转载：164篇
(10)(26)(19)(17)(5)(11)(13)(15)(10)(14)(21)(13)(22)(18)(13)(18)(7)(18)(15)Docker（73）
【编者的话】Flannel是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）工具，其目的在于帮助每一个使用 Kuberentes 的 CoreOS 主机拥有一个完整的子网。这次的分享内容将从Flannel的介绍、工作原理及安装和配置三方面来介绍这个工具的使用方法。
第一部分：Flannel介绍
Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
在Kubernetes的网络模型中，假设了每个物理节点应该具备一段“属于同一个内网IP段内”的“专用的子网IP”。例如：
节点A：10.0.1.0/24
节点B：10.0.2.0/24
节点C：10.0.3.0/24
但在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。
Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。
第二部分：Flannel的工作原理
Flannel实质上是一种“覆盖网络(overlay network)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，目前已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发方式。
默认的节点间数据通信方式是UDP转发，在Flannel的GitHub页面有如下的一张原理图：
这张图的信息量很全，下面简单的解读一下。
数据从源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡，这是个P2P的虚拟网卡，flanneld服务监听在网卡的另外一端。
Flannel通过Etcd服务维护了一张节点间的路由表，在稍后的配置部分我们会介绍其中的内容。
源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务，数据到达以后被解包，然后直接进入目的节点的flannel0虚拟网卡，然后被转发到目的主机的docker0虚拟网卡，最后就像本机容器通信一下的有docker0路由到达目标容器。
这样整个数据包的传递就完成了，这里需要解释三个问题。
第一个问题，UDP封装是怎么一回事？
我们来看下面这个图，这是在其中一个通信节点上抓取到的ping命令通信数据包。可以看到在UDP的数据内容部分其实是另一个ICMP（也就是ping命令）的数据包。
原始数据是在起始节点的Flannel服务上进行UDP封装的，投递到目的节点后就被另一端的Flannel服务还原成了原始的数据包，两边的Docker服务都感觉不到这个过程的存在。
第二个问题，为什么每个节点上的Docker会使用不同的IP地址段？
这个事情看起来很诡异，但真相十分简单。其实只是单纯的因为Flannel通过Etcd分配了每个节点可用的IP地址段后，偷偷的修改了Docker的启动参数，见下图。
这个是在运行了Flannel服务的节点上查看到的Docker服务进程运行参数。
注意其中的“--bip=172.17.18.1/24”这个参数，它限制了所在节点容器获得的IP范围。
这个IP范围是由Flannel自动分配的，由Flannel通过保存在Etcd服务中的记录确保它们不会重复。
第三个问题，为什么在发送节点上的数据会从docker0路由到flannel0虚拟网卡，在目的节点会从flannel0路由到docker0虚拟网卡？
我们来看一眼安装了Flannel的节点上的路由表。下面是数据发送节点的路由表：
这个是数据接收节点的路由表：
例如现在有一个数据包要从IP为172.17.18.2的容器发到IP为172.17.46.2的容器。根据数据发送节点的路由表，它只与172.17.0.0/16匹配这条记录匹配，因此数据从docker0出来以后就被投递到了flannel0。同理在目标节点，由于投递的地址是一个容器，因此目的地址一定会落在docker0对于的172.17.46.0/24这个记录上，自然的被投递到了docker0网卡。
第三部分：Flannel的安装和配置
Flannel是Golang编写的程序，因此的安装十分简单。
从和分别下载Flannel和Etcd的最新版本二进制包。
解压后将Flannel的二进制文件“flanneld”和脚本文件“mk-docker-opts.sh”、以及Etcd的二进制文件“etcd”和“etcdctl”放到系统的PATH目录下面安装就算完成了。
配置部分要复杂一些。
首先启动Etcd，参考。
访问这个地址：&获得一个“Discovery地址”
在每个节点上运行以下启动命令：
etcd&-initial-advertise-peer-urls&http://&当前节点IP&:2380&-listen-peer-urls&http://&当前节点IP&:2380&-listen-client-urls&http://&当前节点IP&:2379,http://&当前节点IP&:2379&-advertise-client-urls&http://&当前节点IP&:2379&&-discovery&&刚刚获得的Discovery地址&&&
启动完Etcd以后，就可以配置Flannel了。
Flannel的配置信息全部在Etcd里面记录，往Etcd里面写入下面这个最简单的配置，只指定Flannel能用来分配给每个Docker节点的拟IP地址段：
etcdctl&set&//network/config&'{&&Network&:&&172.17.0.0/16&&}'
然后在每个节点分别启动Flannel：
flanneld&&
最后需要给Docker动一点手脚，修改它的启动参数和docker0地址。
在每个节点上执行：
sudo&mk-docker-opts.sh&-i
source&/run/flannel/subnet.env
sudo&rm&/var/run/docker.pid
sudo&ifconfig&docker0&${FLANNEL_SUBNET}&
重启动一次Docker，这样配置就完成了。
现在在两个节点分别启动一个Docker容器，它们之间已经通过IP地址直接相互ping通了。
到此，整个Flannel集群也就正常运行了。
最后，前面反复提到过Flannel有一个保存在Etcd的路由表，可以在Etcd数据中找到这些路由记录，如下图。
问：数据从源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡，这种P2P实际生产中是否存在丢包，或者此机制有高可用保障么？
答：只是本机的P2P网卡，没有经过外部网络，应该还比较稳定。但我这里没有具体数据。
问：UDP数据封装，转发的形式也是UDP么？我们一般知道UDP发送数据是无状态的，可靠么？
答：转发的是UDP，高并发数据流时候也许会有问题，我这里同样没有数据。
问：实际上，kubernates是淡化了容器ip，外围用户只需关注所调用的服务，并不关心具体的ip，这里fannel将IP分开且唯一，这样做有什么好处？有实际应用的业务场景么？
答： IP唯一是Kubernetes能够组网的条件之一，不把网络拉通后面的事情都不好整。
问：Flannel通过Etcd分配了每个节点可用的IP地址段后，偷偷的修改了Docker的启动参数：那么如果增加节点，或删除节点，这些地址段（ETCD上）会动态变化么？如果不是动态变化，会造成IP地址的浪费么？
答会造成一些浪费，一般使用10.x.x.x的IP段。
问：sudo mk-docker-opts.sh -i 这个命令具体干什么了？非coreos上使用flannel有什么不同？
答：生成了一个Docker启动的环境变量文件，里面给Docker增加了启动参数。
没有什么不同，只是CoreOS集成了Flannel，在CoreOS上面启动Flannel只是一行命令：systemctl start flanneld。
问：容器IP都是固定的吗？外网与物理主机能ping通，也能ping通所有Docker集群的容器IP？
答：不是固定的，IP分配还是Docker在做，Flannel只是分配了子网。
问：Flannel的能否实现VPN？你们有没有研究过？
答： 应该不能，它要求这些容器本来就在一个内网里面。
问：Flannl是谁开发的？全是对k8s的二次开发吗？
答： CoreOS公司，不是k8s的二次开发，独立的开源项目，给k8s提供基础网络环境。
问：Flannel支持非封包的纯转发吗？这样性能就不会有损失了？
答：非封装怎样路由呢？发出来的TCP包本身并没有在网络间路由的信息，别忘了，两个Flannel不是直连的，隔着普通的局域网络。
问： Flanel现在到哪个版本了，后续版本有什么侧重点？性能优化，还是功能扩展？
答：还没到1.0，在GitHub上面有他们的发展计划，性能是很大的一部分。
问： 就是在CoreOS中，客户还需要安装Flannel吗？
答：不需要，在启动的Cloudinit配置里面给Etcd写入Flannel配置，然后加上flanneld.service command: start 就可以了，启动完直接可用，文档连接我不找了，有这段配置，现成的。
问： 可不可以直接用命令指定每个主机的ip范围，然后做gre隧道实现节点之间的通信？这样也可以实现不同主机上的容器ip不同且可以相互通信吧？
答：还不支持指定哪个节点用那段IP，不过貌似可以在Etcd手改。
问： Flannel只是负责通信服务，那是不是还要安装k8s？
答：是的，k8s是单独的。
问：现在Docker的网络组件还有什么可以选择或者推荐的?
答：Overlay网络的常用就是Flannel和Weave，其他OVS之类的另说了。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：54909次
积分：1934
积分：1934
排名：第16446名
原创：117篇
转载：164篇
(10)(26)(19)(17)(5)(11)(13)(15)(10)(14)(21)(13)(22)(18)(13)(18)(7)(18)(15)后使用快捷导航没有帐号？
查看: 544|回复: 2
一篇文章带你了解Flannel
中级会员, 积分 302, 距离下一级还需 198 积分
论坛徽章:6
Flannel是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（Overlay Network）工具，其目的在于帮助每一个使用 Kuberentes 的 CoreOS 主机拥有一个完整的子网。这次的分享内容将从Flannel的介绍、工作原理及安装和配置三方面来介绍这个工具的使用方法。
第一部分：Flannel介绍Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
在Kubernetes的网络模型中，假设了每个物理节点应该具备一段“属于同一个内网IP段内”的“专用的子网IP”。例如：
节点A：10.0.1.0/24节点B：10.0.2.0/24节点C：10.0.3.0/24
但在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。
Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。
第二部分：Flannel的工作原理Flannel实质上是一种“覆盖网络(overlay network)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，目前已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发方式。
默认的节点间数据通信方式是UDP转发，在Flannel的GitHub页面有如下的一张原理图：
这张图的信息量很全，下面简单的解读一下。
数据从源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡，这是个P2P的虚拟网卡，flanneld服务监听在网卡的另外一端。
Flannel通过Etcd服务维护了一张节点间的路由表，在稍后的配置部分我们会介绍其中的内容。
源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务，数据到达以后被解包，然后直 接进入目的节点的flannel0虚拟网卡，然后被转发到目的主机的docker0虚拟网卡，最后就像本机容器通信一下的有docker0路由到达目标容 器。
这样整个数据包的传递就完成了，这里需要解释三个问题。
第一个问题，UDP封装是怎么一回事？
我们来看下面这个图，这是在其中一个通信节点上抓取到的ping命令通信数据包。可以看到在UDP的数据内容部分其实是另一个ICMP（也就是ping命令）的数据包。
原始数据是在起始节点的Flannel服务上进行UDP封装的，投递到目的节点后就被另一端的Flannel服务还原成了原始的数据包，两边的Docker服务都感觉不到这个过程的存在。
第二个问题，为什么每个节点上的Docker会使用不同的IP地址段？
这个事情看起来很诡异，但真相十分简单。其实只是单纯的因为Flannel通过Etcd分配了每个节点可用的IP地址段后，偷偷的修改了Docker的启动参数，见下图。
这个是在运行了Flannel服务的节点上查看到的Docker服务进程运行参数。
注意其中的“--bip=172.17.18.1/24”这个参数，它限制了所在节点容器获得的IP范围。
这个IP范围是由Flannel自动分配的，由Flannel通过保存在Etcd服务中的记录确保它们不会重复。
第三个问题，为什么在发送节点上的数据会从docker0路由到flannel0虚拟网卡，在目的节点会从flannel0路由到docker0虚拟网卡？
我们来看一眼安装了Flannel的节点上的路由表。下面是数据发送节点的路由表：
这个是数据接收节点的路由表：
例如现在有一个数据包要从IP为172.17.18.2的容器发到IP为172.17.46.2的容器。根据数据发送节点的路由表，它只与 172.17.0.0/16匹配这条记录匹配，因此数据从docker0出来以后就被投递到了flannel0。同理在目标节点，由于投递的地址是一个容 器，因此目的地址一定会落在docker0对于的172.17.46.0/24这个记录上，自然的被投递到了docker0网卡。
第三部分：Flannel的安装和配置Flannel是Golang编写的程序，因此的安装十分简单。
从 和 分别下载Flannel和Etcd的最新版本二进制包。
解压后将Flannel的二进制文件“flanneld”和脚本文件“mk-docker-opts.sh”、以及Etcd的二进制文件“etcd”和“etcdctl”放到系统的PATH目录下面安装就算完成了。
配置部分要复杂一些。
首先启动Etcd，参考 。
访问这个地址：
获得一个“Discovery地址”
在每个节点上运行以下启动命令：
[size=1em][size=1em]1etcd -initial-advertise-peer-urls http://&当前节点IP&:2380 -listen-peer-urls http://&当前节点IP&:2380 -listen-client-urls http://&当前节点IP&:2379,http://&当前节点IP&:2379 -advertise-client-urls http://&当前节点IP&:2379&&-discovery &刚刚获得的Discovery地址& &
启动完Etcd以后，就可以配置Flannel了。
Flannel的配置信息全部在Etcd里面记录，往Etcd里面写入下面这个最简单的配置，只指定Flannel能用来分配给每个Docker节点的拟IP地址段：
etcdctl set //network/config '{ &Network&: &172.17.0.0/16& }'
然后在每个节点分别启动Flannel：
flanneld &
最后需要给Docker动一点手脚，修改它的启动参数和docker0地址。
在每个节点上执行：
sudo mk-docker-opts.sh -isource /run/flannel/subnet.envsudo rm /var/run/docker.pidsudo ifconfig docker0 ${FLANNEL_SUBNET}
重启动一次Docker，这样配置就完成了。
现在在两个节点分别启动一个Docker容器，它们之间已经通过IP地址直接相互ping通了。
到此，整个Flannel集群也就正常运行了。
最后，前面反复提到过Flannel有一个保存在Etcd的路由表，可以在Etcd数据中找到这些路由记录，如下图。
Q&A问：数据从源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡，这种P2P实际生产中是否存在丢包，或者此机制有高可用保障么？
答：只是本机的P2P网卡，没有经过外部网络，应该还比较稳定。但我这里没有具体数据。
问：UDP数据封装，转发的形式也是UDP么？我们一般知道UDP发送数据是无状态的，可靠么？
答：转发的是UDP，高并发数据流时候也许会有问题，我这里同样没有数据。
问：实际上，kubernates是淡化了容器ip，外围用户只需关注所调用的服务，并不关心具体的ip，这里fannel将IP分开且唯一，这样做有什么好处？有实际应用的业务场景么？
答： IP唯一是Kubernetes能够组网的条件之一，不把网络拉通后面的事情都不好整。
问：Flannel通过Etcd分配了每个节点可用的IP地址段后，偷偷的修改了Docker的启动参数：那么如果增加节点，或删除节点，这些地址段（ETCD上）会动态变化么？如果不是动态变化，会造成IP地址的浪费么？
答会造成一些浪费，一般使用10.x.x.x的IP段。
问：sudo mk-docker-opts.sh -i 这个命令具体干什么了？非coreos上使用flannel有什么不同？
答：生成了一个Docker启动的环境变量文件，里面给Docker增加了启动参数。
没有什么不同，只是CoreOS集成了Flannel，在CoreOS上面启动Flannel只是一行命令：systemctl start flanneld。
问：容器IP都是固定的吗？外网与物理主机能ping通，也能ping通所有Docker集群的容器IP？
答：不是固定的，IP分配还是Docker在做，Flannel只是分配了子网。
问：Flannel的能否实现VPN？你们有没有研究过？
答： 应该不能，它要求这些容器本来就在一个内网里面。
问：Flannl是谁开发的？全是对k8s的二次开发吗？
答： CoreOS公司，不是k8s的二次开发，独立的开源项目，给k8s提供基础网络环境。
问：Flannel支持非封包的纯转发吗？这样性能就不会有损失了？
答：非封装怎样路由呢？发出来的TCP包本身并没有在网络间路由的信息，别忘了，两个Flannel不是直连的，隔着普通的局域网络。
问： Flanel现在到哪个版本了，后续版本有什么侧重点？性能优化，还是功能扩展？
答：还没到1.0，在GitHub上面有他们的发展计划，性能是很大的一部分。
问： 就是在CoreOS中，客户还需要安装Flannel吗？
答：不需要，在启动的Cloudinit配置里面给Etcd写入Flannel配置，然后加上flanneld.service command: start 就可以了，启动完直接可用，文档连接我不找了，有这段配置，现成的。
问： 可不可以直接用命令指定每个主机的ip范围，然后做gre隧道实现节点之间的通信？这样也可以实现不同主机上的容器ip不同且可以相互通信吧？
答：还不支持指定哪个节点用那段IP，不过貌似可以在Etcd手改。
问： Flannel只是负责通信服务，那是不是还要安装k8s？
答：是的，k8s是单独的。
问：现在Docker的网络组件还有什么可以选择或者推荐的?
答：Overlay网络的常用就是Flannel和Weave，其他OVS之类的另说了。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上内容根据日晚微信群分享内容整理。分享人 林帆，ThoughtWorks成都Cloud&DevOps咨询师，目前主要研究内容是应用容器化和CoreOS系统相关领域。《CoreOS实践指南》和《CoreOS那些事》系列文章作者。
高级会员, 积分 575, 距离下一级还需 425 积分
论坛徽章:12
mycat 有他独自的历史价值，用sql 统一协调了后端， 当数据库压力上升的时候， 不可避免的引入类似的解决方案， mycat 是这里面比较好的一个开源的解决方案
论坛徽章:44
谢谢分享，，好像和老师讲课用的是一个例子！