在上一期《美丽的法兰绒 (上)》中，我们遗留了两个问题：
- 一个bridge没有学到网络中其他pod的MAC地址的时候，bridge对于未知MAC数据包的处理是什么样的？
- pod如果需要跨网段互访，flannel将如何实现？
今天，让我们来揭晓这两个问题的谜底——
原来，在容器的世界中，大家都难以摆脱背后的神秘势力……
正如英国作家乔治奥威尔在《1984》中描述的，看似自由的社会，实际上由资本这个看不见的“老大哥”在幕后掌控一切那样，在容器与云原生的世界里，也有一个“老大哥”在看着你——
这个老大哥就是鼎鼎有名的分布式数据库etcd。
etcd是2013年由coreos发起的开源分布式键值(key-value)数据库项目。它采用了经典的raft算法保证各个分布式节点数据的一致性，由于它是一个轻量级、安全、使用简单的分布式数据库，并且能够在每个节点(实例)上支持2K 的读操作，在云原生领域成为了不可或缺的中间件。大量分布式中间件都会调用etcd来实现分布式数据同步，避免重复开发轮子。
======关于etcd，可以写一本书，容方老师赚到一个亿再说======
当然，flannel作为经典的云原生网络插件，也采用了etcd作为轻量级分布式数据库。
如下图所示：
图中，flanneld会与etcd互动，存储全局数据，同时要求bridge按照自身意图转发数据包。
flanneld会将以下数据储存在etcd中：
网络配置信息，包括IP地址、子网掩码、默认网关等信息…
当一个pod上线时，它的IP地址、MAC地址、子网掩码、上线的bridge上的虚拟以太网接口(veth)ID等……都会在etcd中储存。
我们知道，etcd是一个全局数据同步的分布式数据库，无论在任何一个加入etcd集群的节点，都可以读取到etcd中存储的全部数据。
这样一来，前面两个问题就都迎刃而解了。
问题1：一个bridge没有学到网络中其他pod的MAC地址的时候，bridge对于未知MAC数据包的处理是什么样的？
答案如下图：
如图，一个Pod需要和另一个node上的pod通信，它发送了一个以太网数据包。由于bridge不知道这个数据包应当发送到本node上的其他pod，它会通过flanneld向etcd查询。
由于任意一个pod连接到网络时，都会从etcd分配地址，并将自己的MAC地址、bridge上的虚拟端口信息等在etcd中登记在案，所以，etcd拥有全局所有Pod的信息，并可以回应任意bridge的查询。
bridge如果查询到目的Pod在其他node，将封装VXLAN隧道并发送到目的node。如果查询到目的pod在本node则直接执行二层转发。
问题2：pod如果需要跨网段互访，flannel将如何实现？
这个问题的答案类似问题1，flanneld会向etcd查询对端pod所拥有的IP地址对应的MAC地址、所在node等信息，让bridge进行VXLAN封装，用类似VXLAN三层转发的机制实现互通。
这样一来，flannel就可以利用etcd作为控制平面实现VXLAN overlay了。
大家思考一个问题：
flannel使用的这种控制平面机制，有没有什么问题和缺陷呢？
下期我们来分析一下。
