在上一期中,我们提到了,由于基于etcd的flannel存在种种限制,硬件SDN方案的开发工程师们研究出了通过CNI插件,让基于EVPN + 硬件VXLAN网关的硬件SDN方案能够通过CNI插件,适配Kubernetes容器编排平台。这一类型的硬件SDN方案,最经典的有CISCO的ACI和H3C的SeerEngine。
由于CISCO的ACI中,私有协议的实现过多,我们先以SeerEngine SDN控制器为例:
假设我们已经熟悉了基于EVPN和VXLAN的硬件SDN方案,实际上可以很轻松地对二者做出对比——
而这种方案的转发平面,与虚拟机体系中的转发平面类似。
我们先看同一个node内,两个pod之间的二层转发:
可见,这种情况下,OVS就可以自行搞定Node内转发,与其他方案别无二致。
当两个POD不在同一个VLAN(当然,也不在同一个网段)的情况:
如图,OVS会将来自VLAN 100的数据包增加VLAN 100的TAG,送到硬件交换机,进行三层转发,带着VLAN 200的TAG送回OVS,OVS剥离VLAN TAG送到目的POD。回程数据包也类似。
这种情况下,未知数据包的MAC/ARP学习过程,实际上和普通三层交换机的转发流程也是类似的。
再让我们看看复杂的跨TOR转发:
如图,两个POD都在VLAN 100中,但位于两个不同的TOR下。假设这两台TOR的underlay为10.1.1.254和10.1.2.254。
来自POD的数据包会在OVS上打上了VLAN 100的TAG送到TOR。由于TOR上配置了VLAN 100到VXLAN1001的映射关系,TOR会将这个数据包封装进VXLAN 1001。对端TOR解封VXLAN数据包,并将带着VLAN 100的数据包送到目的POD所在的Node上的OVS。目的Node上的OVS剥离VLAN,并将数据包送到目的POD,完成了二层转发的过程。
跨TOR的三层转发则采用分布式网关 + 对称IRB的实现:
如图,假设POD 100和POD 200分别在VLAN 100和VLAN 200,它们所在的TOR交换机的IP地址分别为10.1.1.254和10.2.1.254。
TOR交换机上配置的VLAN-VXLAN映射关系为VLAN 100-VXLAN 1001, VLAN 200-VXLAN 1002;
由于采用了对称IRB模型,需要公用的L3VNI,这个VNI的编号假设为8001;
POD 100向POD 200发送的数据包,在OVS上加上了VLAN 100的TAG。VLAN 100在TOR上映射到VXLAN 1001。
由于这是一个跨网段转发的数据包,目的MAC为VSI的MAC (对应的分布式网关IP为10.10.100.254),数据包会被送到VSI 1001处理,进入三层转发流程。
TOR交换机查找目的IP,发现这是一个VXLAN 1002的IP地址,并且目的IP在远端TOR,它会做一次VXLAN RIOT,通过VXLAN的VNI为L3VNI 8001的VXLAN隧道,送到远端TOR 10.2.1.254。
远端TOR 10.2.1.254收到这一数据包后,查找路由表,并根据路由表做RIOT,将VXLAN的VNI替换为1002,然后映射回VLAN 200,剥离VXLAN头部,送到目的OVS,并最终被送到目的POD。
这样一看,SeerEngine控制容器网络时,转发平面的机制实际上与接管虚机+OpenStack Neutron网络的机制是一致的。
这正是:似曾相识燕归来!
这样一来,我们还可以赋予容器网络更多扩展的能力。
敬请期待下期。