【Kubernetes】两篇文章 搞懂 K8s 的 fannel 网络原理

近期公司的flannel网络很不稳定,花时间研究了下并且保证云端自动部署的网络能够正常work。

1.网络拓扑

拓扑如下:(点开看大图) 输入图片说明

  1. 容器网卡通过docker0桥接到flannel0网卡,而每个host对应的flannel0网段为 10.1.x.[1-255]/24,而flannel所组成的一个跨host的网段为10.1.x.x/16,而flannel0则为flanneld进程虚拟出来的网卡。
  2. docker0的地址是由 /run/flannel/subnet.env 的 FLANNEL_SUBNET 参数决定的。

2.HostA的Container1和HostB的Container2如何通信

host A的container1请求host B的container2的的数据时,流程如下:

  1. 根据host A的路由规则 "10.1.15.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0“ 数据交给docker0处理。
  2. docker0会收到数据,然后根据路由规则 ”10.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel0" 数据被交由给flannel0网卡处理。 flanneld会把数据封包然后送给eth0,用udp协议发送到对方host的eth0网卡。
  3. host B的 eth0网卡收到后,根据路由规则 10.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel0" 则交给flannel0网卡处理。
  4. flanneld会把数据解包,根据路由规则 “10.1.20.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0" 交给docker0处理。
  5. 则host B的container 2 将会收到数据。
    至此网路通信解释完毕。

3.自动部署程序中添加物理机需要注意的地方

基于上,故而:

    1. 网卡docker0、flannel0网卡的正确建立。
    2. 路由被正确配置!10.1.x.[1-255]/24 和 10.1.x.x/16 两个网段的正确路由配置。
    3. 我们的网络环境检查都基于此。通常情况下,以上两者可以自动正确建立成功,但有时候会出现异常。
    4. 添加物理机时候检查网络环境 ifconfig docker0 和 flannel0并且需要正确配置路由规则。
    5. flanneld的udp端口2375需要添加到iptables例外。

 

一篇文章带你了解Flannel

摘要:Flannel是 CoreOS 团队针对 Kubernetes 设计的一个覆盖网络(Overlay Network)工具,其目的在于帮助每一个使用 Kuberentes 的 CoreOS 主机拥有一个完整的子网。这次的分享内容将从Flannel的介绍、工作原理及安装和配置三方面来介绍这个工具的使用方法。

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页面有如下的一张原理图: 
一篇文章带你了解Flannel

这张图的信息量很全,下面简单的解读一下。 

数据从源容器中发出后,经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡,这是个P2P的虚拟网卡,flanneld服务监听在网卡的另外一端。 

Flannel通过Etcd服务维护了一张节点间的路由表,在稍后的配置部分我们会介绍其中的内容。 

源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务,数据到达以后被解包,然后直 接进入目的节点的flannel0虚拟网卡,然后被转发到目的主机的docker0虚拟网卡,最后就像本机容器通信一下的有docker0路由到达目标容 器。 

这样整个数据包的传递就完成了,这里需要解释三个问题。 

第一个问题,UDP封装是怎么一回事? 

我们来看下面这个图,这是在其中一个通信节点上抓取到的ping命令通信数据包。可以看到在UDP的数据内容部分其实是另一个ICMP(也就是ping命令)的数据包。 
一篇文章带你了解Flannel

原始数据是在起始节点的Flannel服务上进行UDP封装的,投递到目的节点后就被另一端的Flannel服务还原成了原始的数据包,两边的Docker服务都感觉不到这个过程的存在。 

第二个问题,为什么每个节点上的Docker会使用不同的IP地址段? 

这个事情看起来很诡异,但真相十分简单。其实只是单纯的因为Flannel通过Etcd分配了每个节点可用的IP地址段后,偷偷的修改了Docker的启动参数,见下图。 
一篇文章带你了解Flannel

这个是在运行了Flannel服务的节点上查看到的Docker服务进程运行参数。 

注意其中的“--bip=172.17.18.1/24”这个参数,它限制了所在节点容器获得的IP范围。 

这个IP范围是由Flannel自动分配的,由Flannel通过保存在Etcd服务中的记录确保它们不会重复。 

第三个问题,为什么在发送节点上的数据会从docker0路由到flannel0虚拟网卡,在目的节点会从flannel0路由到docker0虚拟网卡? 

我们来看一眼安装了Flannel的节点上的路由表。下面是数据发送节点的路由表: 
一篇文章带你了解Flannel

这个是数据接收节点的路由表: 
一篇文章带你了解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编写的程序,因此的安装十分简单。 

从 https://github.com/coreos/flannel/releases和 https://github.com/coreos/etcd/releases分别下载Flannel和Etcd的最新版本二进制包。 

解压后将Flannel的二进制文件“flanneld”和脚本文件“mk-docker-opts.sh”、以及Etcd的二进制文件“etcd”和“etcdctl”放到系统的PATH目录下面安装就算完成了。 

配置部分要复杂一些。 

首先启动Etcd,参考 https://github.com/coreos/etcd ... overy。 

访问这个地址: https://discovery.etcd.io/new?size=3 获得一个“Discovery地址” 

在每个节点上运行以下启动命令: 
1 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 /coreos.com/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数据中找到这些路由记录,如下图。 
一篇文章带你了解Flannel
 
 
 
参考资料:
docker下基于flannel的overlay网络分析:  https://my.oschina.net/xue777hua/blog/488345

一篇文章带你了解Flannel:  http://www.open-open.com/news/view/1aa473a/

DockOne技术分享(十八):一篇文章带你了解Flannel:  http://dockone.io/article/618

成为Docker Commiter需要具备哪些技术能力?:  http://dockone.io/question/196

强烈推荐系列文章:  http://dockone.io/topic/%E5%BE%AE%E4%BF%A1%E5%88%86%E4%BA%AB

etcd的简单使用:  http://www.cnblogs.com/opama/p/5836674.html

 
二层交换、路由和三层交换:  http://blog.sina.com.cn/s/blog_43c625f101012euf.html

二层交换与三层交换本质区别:  http://bbs.51cto.com/thread-724918-1.html

二层交换、三层交换和路由的原理及区别:  http://blog.csdn.net/chenfei_5201213/article/details/7879438

二层和三层转发:  http://blog.csdn.net/blueoceanindream/article/details/6413262

二层交换与三层IP转发:  http://blog.csdn.net/muaxi8/article/details/51953082

常说的二层跟三层有什么区别?:  http://bbs.c114.net/asktech/question.php?qid=17795

 
 
https://github.com/coreos/flannel
图解:  https://raw.githubusercontent.com/coreos/flannel/master/packet-01.png

Pipework、Weave、Flannel各自的优势和区别:  http://dockone.io/question/259

Kubernets,Flannel,Docker网络性能深度测试:  http://www.tuicool.com/articles/JNNFz2f

Docker网络详解及pipework源码解读与实践:  http://www.infoq.com/cn/articles/docker-network-and-pipework-open-source-explanation-practice/#anch142208

图解:  http://cdn2.infoqstatic.com/statics_s1_20161214-0550/resource/articles/docker-network-and-pipework-open-source-explanation-practice/zh/resources/1419560200174.png

尴尬的VXLAN:  http://www.c114.net/news/211/a876004.html

【华为悦读汇】技术发烧友:认识VXLAN:  http://support.huawei.com/huaweiconnect/enterprise/thread-334207.html

隧道和网络虚拟化:NVGRE vs VXLAN:  http://www.sdnlab.com/11819.html

 
原文地址:https://www.cnblogs.com/junneyang/p/6186754.html