当vpc遇到K8s overlay

大家好，我是二哥。新年第一篇肝文来了。在开始之前，我们先来看看下面几个问题：

• XX云上租用VM，你一定会碰到VPC。你是否好奇过VPC到底是如何实现的？
• 你在XX云上租用的VM和别人家的VM跑在一台物理机上，它们之间的网络流量又是如何被隔离的？
• 你的1000个K8s Pod分散在50个VM上，这50个VM又散落在10个物理机上，那这些Pod之间通信时，数据包是如何跨物理机流动的？

来吧，进入正题。

1. 数据中心网络拓扑回顾

在文章《广角-聊聊Underlay》中，二哥用一张大图画出了实现K8s“扁平网络”的三种典型实现方式：Overlay、主机间路由（host-gw）以及Underlay。

无论采用什么模式，K8s都需要寄生于宿主机的既有网络也即underlay network。图1所示的underlay network包括三个可用区。这三个可用区统一接进核心交换机。每个可用区里面装有若干个机架，一般在机架顶上会有接入交换机将机架上的物理机接进网络。接入交换机连接到性能更高的汇聚交换机，进而通过核心交换机、核心路由器、边界路由器连接到internet。在国内，这个internet由我们熟知的电信、联通等宽带运营商组成。

你一定发现了在图1的可用区A里，我标示出了VPC（Virtual Private Cloud），但那篇文章里没有做过多解释。二哥捂到现在，憋不住了。

图 1：数据中心拓扑及K8s扁平网络三种模式示意图

2. 从VLAN到VXLAN

2.1 VLAN

在谈VXLAN之前，我们先来看一个名字与它非常像的词：VLAN（Virtual LAN，虚拟局域网）。

大家在上大学的时候一定有过这个经验：用交换机在宿舍组一个局域网玩《魔兽争霸》。连接到这个交换机上的几台电脑处于同一个局域网，电脑之间的通信经由交换机负责转发。其实企业也是类似，只不过企业用的是更高级的、性能更好的、可以连接更多电脑的交换机。交换机用起来方便是方便，但它有一些问题：

• 它总是会把广播消息转发给所有的电脑。
• 如果大家按职能部门分楼层或分区域坐，就会出现有的交换机端口不够用，有的交换机却又空着一大片端口的现象。

如果把大家混着坐，共用这些交换机端口，又该如何保证不同职能部门之间的网络隔离呢？

聪明的IT工程师一拍大腿：简单啊，上VLAN啊。把所有交换机的LAN口归拢在一起，把它们按职能部门分类编码。比如给Sales部门编码10，给Accounting部门编码20，Research部门编码30。虽然他们都如图2一样混插在交换机上，但如果按照编码来分类，逻辑上就清晰多了。再对比看看图3的VLAN逻辑视图，是不是舒服很多？

图 2：LAN物理视图

图 3：VLAN物理和逻辑视图

这个编码放在网络包哪里呢？如下图所示，新加一个802.1Q Tag就行了。这样交换机在解析这个包的时候，只有VLAN ID相同的包才会相互转发。当然，因为这个Tag是新加的，得交换机认识才行。

图 4：带VLAN头的二层网络包对比示意图

你看看VLAN ID，总共12位，那就是说最多能支持4096个ID，这应付一个企业的日常组网需求足够了。

2.2 趣谈隧道协议

我想借助刘超在《趣谈网络协议》中举的从广州自驾海南游的一个例子来说明所谓隧道协议的概念。如图5所示，隧道协议分为三部分：乘客协议、隧道协议和承载协议。

图 5：隧道协议示意图

从广州出发自驾游海南，你的车怎么通过琼州海峡呢？得用轮渡，其实这就是隧道协议。

在广州这边开车是有“协议”的，例如靠右行驶、红灯停、绿灯行，这个就相当于“被封装”的乘客协议。海南那面，开车也是同样的“乘客”协议。

那我的车如何从广州运到海南呢？这就需要你先遵循开车协议，将车开上轮渡，所有车都关在船舱里面，按照既定的规则排列好，这就是隧道协议。在大海上，你的车是关在船舱里面的，就像在隧道里面一样，这个时候内部的乘客协议，也即驾驶协议没啥用处，只需要船遵从外层的承载协议，到达海南就可以了。

在海上坐船航行，也有它的协议，例如要看灯塔、要按航道航行等。这就是外层的承载协议。

到达之后，外部承载协议的任务就结束了，打开船舱，将车开出来，就相当于取下承载协议和隧道协议的头。接下来，在海南该怎么开车，就怎么开车，还是内部的乘客协议起作用。

2.3 VXLAN

VLAN看起来用得也凑合，大家按照既有技术和工作模式，在各自行当里埋头苦干，砥砺前行。直到有一天，一家叫做谷歌的公司发布了3篇产品设计论文，并颠覆性地提出“Google 101”计划，正式创造了“云”的概念。在2006年，亚马逊发布了AWS，凭借高效的系统利用率、方便的VM租赁方式、灵活的和可扩展的优势彻底颠覆了企业IT建设方式。

服务器虚拟化作为云计算的核心技术之一，一方面演变出了各类云产品供企业上云使用，另一方面却在多租户网络隔离问题上给云计算厂商出了一道难题：VLAN总共才能支持4096个ID，该如何满足大型数据中心的多租户间隔离需求呢？

修改VLAN协议？别逗了，这是一个不可能完成的工程，因为没有办法更新已经遍布全球的、正在工作中的交换机固件。可选套路就两种：要不就是来一个新版本的VLAN，兼容老的版本，老设备用老协议，新设备用新协议，渐进式升级，慢慢过渡；要不就是另起炉灶，重新搞一套，这不VXLAN（Virtual eXtensible Local Area Network，虚拟扩展局域网）由此诞生。

图 6：VXLAN数据帧

上图所示的VXLAN数据帧中，“Original Layer 2 Frame”就像是图5中提到的乘客协议，而VXLAN头如同我们说的隧道协议，Outer UDP头+Outer IP头+Outer MAC头则对应承载协议。

虽然从名字上看，VXLAN是VLAN的一种扩展协议，但其实它和VLAN完全不兼容。一句话来总结：VXLAN是一个隧道协议，利用一种协议来传输另外一种协议。

图 7：VXLAN网络模型示意图

了解了隧道协议，我们来结合图7看看VXLAN是如何在IP网络中模拟出一个隧道的。图中的TOR全称是Top Of Rack，就是机架顶端的意思。在机架顶端的交换机上运行有一个VTEP（VXLAN Tunnel End Point，虚拟隧道端点），它是VXLAN隧道的起点和终点，VXLAN对用户原始数据帧的封装和解封装均在VTEP上进行。

• 源VM发出的原始数据帧，在左端VTEP上被封装成VXLAN格式的报文，并塞进UDP payload中。
• 报文通过UDP协议在IP网络中传递到右端VTEP上。
• 右端VTEP解封装还原出原始的数据帧，最后转发给目的VM。

虽然实际上网络包还是在IP网络中传输的，通信双方分别是源IP 1.1.1.1和目的IP 2.2.2.2这两个VTEP，但是从躲在这两个VTEP后面的VM的眼中看来，就好像它俩之间有一个隧道，源数据从隧道这端塞进去，那端就能原样收到了。

3. VPC是如何实现的

图 8：VXLAN实现VPC和K8s Overlay扁平网络模型示意图

VXLAN一方面完美地弥补了前面提到的VLAN只能提供4096个ID这个硬伤，通过提供24位VNID字段，提供多达16M个标识能力，远大于VLAN的4096。

另一方面，它可以构建一条穿越数据中心基础IP网络的虚拟隧道，将数据中心网络虚拟成一个巨型“二层交换机”。我们借助图8来看看这个过程的详情。

二哥首先来把图8所包含的基本要素介绍一遍。机架填满了物理机。每个物理机上均装有Open vSwitch（后文简称OVS）。物理机上所有的VM都连接到了这些OVS上。你一定注意到了虚拟机里面还标示出了Pod、CNI、kubelet，别急，这个后文再讲。

这些物理机所在的网段为10.1.5.7/16，VM按颜色分成了两个不同的网段和VXLAN ID：淡橙色部分的VM网段为172.20.6.35/16，VXLAN ID为1234；蓝色部分的网段为172.10.5.25/16，VXLAN ID为5678。除所在宿主机外，VM无法和其它物理机直接通信。

我们在XX云上创建VM的时候，会被要求设置一个VPC，还可以向这个VPC里添加多个VM。这些VM一定是散落地分布在不同的物理机上的。那么问题来了：我的VM和别人家的VM在一台物理机器上，它俩会串台不？我的多台VM分布在不同的物理机上，又是如何做到既能相互之间通信又能和别人家的隔离的呢？

答案无它，秘密藏在VXLAN里。OVS支持GRE、VXLAN等隧道协议，这里我们以VXLAN来举例。图8中物理机上安装的每个OVS都有一个VTEP。VTEP是VXLAN网络中绝对的主角，它既可以是一台独立的网络设备（比如图7中位于TOR上的接入交换机），也可以在服务器中的虚拟交换机中（比如图8的OVS）。

源VM发出的原始数据帧如同图5中的小汽车，我们将它封装成VXLAN格式的报文就如同把小汽车放到渡轮船舱，而UDP载着VXLAN格式穿过IP网络就类似装着一肚子小汽车的渡轮穿过琼州海峡。在另一个VTEP上解封装还原出原始的数据帧就好比轮渡到了海峡对岸后卸货的过程。

想象一下你坐在小车里，一路体验这个奇妙的旅程。无论在广州开车还是在海南自驾，交规完全一致，对你而言就像是穿过隧道一样，从位于大陆的一个城市切换到了另一个位于海岛上的城市。

对数据帧而言也是如此。数据帧如同你和你的小汽车，VM如同城市，而VTEP就是那个隧道。

通过建立如图8中的粉色VTEP隧道，我们解决了位于不同物理机上的VM之间的数据通信问题。那隔离问题是如何解决的呢？

还记得图2和图3中的VLAN以及VLAN ID的作用吗？是的，类似地，VXLAN ID用来解决隔离问题。不同的VPC使用不同的VXLAN ID来相互区分和隔离。不同的VXLAN ID就像不同的轮渡船，只有具有相同ID的小汽车才可以装载到同一个轮渡船上。

利用隧道和VXLAN ID技术，图8中的VM被分隔成了两类，一类是淡橙色，一类是蓝色。它们在各自的网段内自由飞翔，不同的网段之间如同两条铁轨一样平行永不相交。

4. 当VPC遇到K8s Overlay

二哥之前在《特洛伊木马-图解VXLAN容器网络通信方案》中详细讲述了K8s扁平网路模型的典型实现方式之一：Overlay方案。这个方案的细节如图9所示。2015年上映的《蚁人》看过吧？现在我们将图9如同蚁人缩小物体一样缩小到图8的K8s中。

图 9：K8s VXLAN容器网络方案

虽说K8s的网络是扁平的，但这种扁平是通过图8中的灰绿色的VXLAN隧道和图9所示的VXLAN隧道虚拟出来的。从Pod和容器的视角看，它是一个扁平的网络，可是它们又怎么可能会晓得外面的世界却是那么的复杂、雄伟和壮观。

当VPC和K8s Overlay相遇后，Pod之间通信的网络包就如同俄罗斯套娃一样，被一层又一层地包裹住。

在VPC和K8s的精心设计和呵护下，容器们会觉得它们彼此之间通信如此的简单，可是它们又怎么会知道每一次say hello都可能包装千次万遍，走过千山万水。

写到这里，突然想起来在学术界，一直有一种观点，那就是我们人类生活的这个世界，乃至整个宇宙，可能都是被某个更智慧的物体模拟出来的虚拟世界。嗯，或许我们也和这些Pod还有容器一样，活在虚幻的、被别人定义的世界里。

以上就是本文的全部内容。码字不易，喜欢本文的话请帮忙转发或点击“在看”。您的举手之劳是对二哥莫大的鼓励。谢谢！