第30讲 | 容器网络之Flannel：每人一亩三分地

刘超



该思维导图由 AI 生成，仅供参考

上一节我们讲了容器网络的模型，以及如何通过 NAT 的方式与物理网络进行互通。
每一台物理机上面安装好了 Docker 以后，都会默认分配一个 172.17.0.0/16 的网段。一台机器上新创建的第一个容器，一般都会给 172.17.0.2 这个地址，当然一台机器这样玩玩倒也没啥问题。但是容器里面是要部署应用的，就像上一节讲过的一样，它既然是集装箱，里面就需要装载货物。
如果这个应用是比较传统的单体应用，自己就一个进程，所有的代码逻辑都在这个进程里面，上面的模式没有任何问题，只要通过 NAT 就能访问进来。
但是因为无法解决快速迭代和高并发的问题，单体应用越来越跟不上时代发展的需要了。
你可以回想一下，无论是各种网络直播平台，还是共享单车，是不是都是很短时间内就要积累大量用户，否则就会错过风口。所以应用需要在很短的时间内快速迭代，不断调整，满足用户体验；还要在很短的时间内，具有支撑高并发请求的能力。
单体应用作为个人英雄主义的时代已经过去了。如果所有的代码都在一个工程里面，开发的时候必然存在大量冲突，上线的时候，需要开大会进行协调，一个月上线一次就很不错了。而且所有的流量都让一个进程扛，怎么也扛不住啊！
没办法，一个字：拆！拆开了，每个子模块独自变化，减少相互影响。拆开了，原来一个进程扛流量，现在多个进程一起扛。所以，微服务就是从个人英雄主义，变成集团军作战。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

Flannel和VXLAN：解决微服务架构下容器网络通信难题微服务架构下，基于NAT的容器网络模型存在通信困难和性能问题。本文介绍了Flannel使用UDP实现Overlay网络的方案，以及通过VXLAN建立VTEP来改善跨物理机通信的性能。文章指出，基于NAT的容器网络模型在实现跨物理机通信时存在困难，因为容器内部的IP地址无法直接注册到注册中心，而注册物理机的IP地址又需要应用配合，这种设计不够合理。另外，基于NAT的模式也会导致端口冲突和奇怪的端口分配，给网络通信带来不便。通过Flannel和VXLAN的方案，可以有效解决这些问题，提高容器网络通信的效率和可靠性。 Flannel作为跨节点容器网络方案之一，提供的Overlay方案主要有两种方式，一种是UDP在用户态封装，一种是VXLAN在内核态封装，而VXLAN的性能更好一些。通过VXLAN将包转发到另一台机器的过程，展示了新方案的实际应用效果。基于NAT的容器网络模型存在的问题得到了解决，为读者提供了更合适的网络方案来解决微服务架构下的通信挑战。总的来说，本文提出了针对基于NAT的容器网络模型存在的问题的解决方案，为读者提供了更合适的网络方案来解决微服务架构下的通信挑战。Flannel和VXLAN的方案为解决微服务架构下容器网络通信难题提供了新的思路和解决方案。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《趣谈网络协议》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(27)

最新
精选

小宇宙
flannel的backend除了UDP和vxlan还有一种模式就是host-gw，通过主机路由的方式，将请求发送到容器外部的应用，但是有个约束就是宿主机要和其他物理机在同一个vlan或者局域网中，这种模式不需要封包和解包，因此更加高效。
作者回复: 对的
2018-08-27
5
46
jacy
回答自己提的udp丢包的问题，希望老师帮忙看看是否正确。 flannel实际上是将docker出来的包再加udp封装，以支持二层网络在三层网络中传输。udp确实可能丢包，丢包是发生在flannel层上，丢包后内层的docker（如果被封装的是tcp）无ack,源docker的虚拟网卡还会按tcp协议进行重发。无非是按flannel原理多来几次。
作者回复: udp会丢的
2019-03-14

17
超超
回答问题1：是不是在dockerX网卡上做NAT？
作者回复: 是的
2019-04-08

3
大星星
想问下老师，后一种使用VTEP，为什么flannel.id里面内部源地址配置的是flannel.id的mac地址，而不是使用第一种打开dev/net/tun时候源地址写的是容器A的源地址。为什么两种情况下不一样了，谢谢
作者回复: 这是flannel的一个问题，会造成很多困扰
2019-02-22

3
小宇
老师好，我这里有一个疑问，第28讲的VXLAN，虚拟机通信时包的结构， VTEP的设备ip为什么在VXLAN头之外，我的理解VTEP设备的ip应该和flannel的VXLAN模式一样，在VXLAN头里面。
作者回复: vxlan的格式都是一样的
2019-01-23

3
╯梦深处゛
对于 IP 冲突的问题，如果每一个物理机都是网段 172.17.0.0/16，肯定会冲突啊，但是这个网段实在太大了，一台物理机上根本启动不了这么多的容器，所以能不能每台物理机在这个大网段里面，抠出一个小的网段，每个物理机网段都不同，自己看好自己的一亩三分地，谁也不和谁冲突。 ----------------------------------------------------------------------------------------------------- 老师，不同节点之间不一定都是不同网段的，相反很多时候，一个K8S集群的所有节点都是在一个网段，请问在这种场景下，如果避免这种冲突的问题呢？
作者回复: 一个K8S集群的所有节点都是在一个大网段里面，但是不同的主机分了小网段。
2019-04-23

2
allwmh
flannel怎么做容器的IP保持呢？
作者回复: 不保持
2019-04-23


峻铭
如物理机A坏了，docker要迁移到C上去，物理机B内容器中的应用如何和C中的通信
作者回复: 会重新配置
2018-10-11


天王
1 快速迭代，单体应用不能满足快速迭代和高并发的要求，所以需要拆成微服务，容器作为集装箱，可以保证应用在不同的环境快速迁移，还需要一个容器的调度平台，可以将容器快速的调度到任意服务器，这个调度平台就是k8s。2 微服务之间存在服务调用的问题，就像集团军作战，需要解决各个部队位置和部队之间通讯的问题，2.1 位置问题用注册中心，但是可能会有ip端口冲突，Flannel是为了解决这种问题的技术，给每个物理机分配一小段网络段，每个物理机的容器只使用属于自己的网络段，2.2 部队之间通讯容器网络互相访问，Flannel使用UDP实现Overlay网络，每台物理机上都跑一个flannelid进程，打开dev/net/tun设备的时候，就会有这个网卡，所有发到flannel.1的网络包，都会被flannelid进程截获，会讲网络包封装进udp包，发到b的flannel.1，b的flannelid收到网络包以后，解开，由flannel.1发出去，通过dock0给到容器b。通讯比较慢，Flannel使用VXLAN技术，建立一个VXLAN的VTEP，通过netlink通知内核建立一个VTEP的网卡flannel.1，A物理机上的flannel.1就是vxlan的vtep，将网络包封装，通过vxlan将包转到另一台服务器上，b的flannel.1接收到，解包，变成内部的网络包，通过物理机上的路由转发到docker0，然后转发到容器B里面，通信成功。
2019-07-30

11
悟空聊架构
“例如物理机 A 是网段 172.17.8.0/24，物理机 B 是网段 172.17.9.0/24”，这里应该是指物理机A给docker分配的网段吧？老师，这个容易造成误解哦……
2018-08-03

6

收起评论