在以Kubernetes 为代表的云原生浪潮席卷全球之前，OpenStack 一度风光无两，但是随着K8s的日益普及，有很多OpenStack用户开始转向云原生，OpenStack + Kubernetes 是目前相对流行的云应用解决方案栈。

在前不久举办的OpenInfra Days China 2021大会上，英特尔Chief Architect Andrew Zhang，以及Kube-OVN项目发起人/灵雀云资深研发工程师刘梦馨带来了一个联合分享，介绍怎样把OpenStack和K8s融合在一起。

以下为演讲实录：

云原生趋势下融合OpenStack与K8s（by Andrew Zhang）

多年以来， OpenStack都是业界私有云方案主流，企业用户也在这方面投资了很多，比如基础架构还有工作流等方面。现在又有了新的趋势，那就是云原生和微服务，很多企业用户都在快速进入这个领域。现在他们面临的最大问题是怎样把现有的 OpenStack架构迁移到云原生平台上。

简单来说，OpenStack上VM工作负载，有的需要花很多时间或者是资源才能重构成容器化微服务，有的甚至是不可能的，比如那种传统大型单体应用的架构就很难改变。目前来看，OpenStack在很多的企业客户里面还会继续使用，最起码在我们看得到的未来4~5年还会有持续的需求。但不可否认的是云原生是一个无法逆转的大趋势，怎样使得客户在保持以前的 OpenStack投资的同时，能够发掘云原生的红利，是目前很多企业都要解决的问题。

目前来看，绝大部分企业的做法都是用OpenStack来做云资源的管理，然后在上面部署K8s 去管理应用容器。这种做法实际上有一定的局限性。这个是这种方案的架构示意。刚才说到在这个方案里面，OpenStack作为底座，那么K8s是部署在 OpenStack上面，大家看到的橙色是K8s的集群，用K8s管理容器，黄颜色的容器都是工作负载。

这个方案的问题是，很多工作负载是在 VM里面由 OpenStack来管理，所以要让这些VM和 容器能够一起工作，就需要解决一些问题。一个就是网络要有双倍或者3倍的 overlay，这些问题还可以解决，比如说我们可以用Kuryr 连接到Neutron，用VLAN/trunk的形式，这样可以减少一些 overlay，但这种方案OpenStack还是作为整个架构的基础，这样以后往云原生发展会有非常大的局限性，因为OpenStack日积月累就尾大不掉了。

我们提出了一个新的方案，这个方案就是把现有的 OpenStack的集群，把它做lift & shift，不用大规模改动，就lift & shift到K8s上去，使得客户的基础设施能够更好的发展。

这个方案，使得目前有很多投资在 OpenStack上面的用户，可以继续沿用以前OpenStack的东西，同时又可以把新的云原生的K8s和容器用上，也不需要做很大的变化，比如说各种配置，所以这是一个优势。

这个方案采用了基于OVN/OVS统一的SDN（软件定义网络）技术，实现OpenStack和K8s同时工作，而且能够做service迁移。和其他方案比，这个方案还有一个好处，对于边缘计算端资源比较受限、工作负载也没那么大的场景，可以实现在同一个node上同时支持VM和容器。这种方案的灵活性，使得你可以根据自己的需求将VM和容器部署在不同的节点上或者是同一个节点，或者是比较少量或者很大量的节点上。K8s可以统一的、实时的来定义、连接或者断开网络，重新配置这些VM和容器的子网连接。

我这里举个多租户的例子，比如说同一个公司里面有不同的部门，他们可以是不同的租户，不同的公司也可以用到多租户的特性，那么这种网络方案提供了租户之间的隔离。

比如说这个租户的工作负载是使用的这个VM，连接了 NW4的子网，我们可以配置NW4跟NW2相连，NW2是跟这两个容器一起工作。

类似的第二个租户，比如说这个容器，它是和NW3连接，我们可以把NW3配置和NW5相连接，那NW5是和这个VM的工作负载连接的，这一个租户就能实现容器和VM的连接。

这两个租户之间他们是有逻辑类型的隔离的，也就是这个方案可以实现多用户的隔离。

同时OpenStack的管理平台网络是独立的,它是不和这些业务负载相连接的，可以和K8s的管理部署在另外的网络上面，这样就避免了它的控制平面和多租户用户平面的混杂，就保证了它的安全性，也保证了它的隔离度。

这个方案实际上对于我们以后的IPU（ interface with the internet processing unit）等扩展架构是完全兼容的。我们还可以实现OVS dpdk来加速 OVS 网络，使得它的数据平面能够更快，性能更好。

这个就是它的大的架构的示意图。细化到具体网络层面，目前是这样做的，例子中右边这个是OpenStack 的VM，左边是以K8s来做管理的容器，他们都是用 OVN来组网。怎么把二者合并成同一个OVN？比如说这是一个在 OpenStack里面的router，我们稍微修改这个router的配置，然后用CRD把它导出到K8s里面，使得它能够在K8s里面做统一的管理。这样就是把在OpenStack和K8s里面的这两个OVN统一起来。

这个就是网络示意图。在这个框架图里面大家看到不同的node上，有的是vm，有的是容器Pod，它们都统一在一个OVN网络里，由北向控制平面来管理，也就是OpenStack上的OVN和K8s上的OVN两个是统一的。

Intel目前和灵雀云合作融合OpenStack与K8s，采用了灵雀云Kube-OVN技术，这个方案提供了一个非常平滑的过渡，使得现在的OpenStack企业用户能够很好的过渡到 K8s上去，同时避免了比较大的迁移工程。这实际上是一个lift & shift的工作，同时也是统一的SDN方案，其好处就是能够做统一的部署，使得OpenStack和K8s能够同时部署和运行，并能够做服务关联。此外，可以发挥intel的一些优势，提高方案的性能。

方案的另外一个优点是很灵活的方式，同时它也是面向未来的架构，比如说smart dpu、ipu这些未来都可以。

Kube-OVN方案融合OpenStack与K8s（by 刘梦馨）

下面介绍一下如何通过Kube-OVN实现统一的架构，把共用一个OVN的Kube-OVN和Neutron实现SDN网络的打通。

在这套方案中，OVN作为唯一的数据中心，它有两个控制平面，一个是Neutron，一个是Kube-OVN。所以我们要做的事情，就是要把这两者的数据结构打通，也就是我们如何在K8s的一侧来识别出Neutron创建的VPC。

我们的做法是在Kube-OVN里面实现一个控制器，定期的去OVN里面扫描，看哪些是Kube-OVN创建的vpc，哪些是Neutron创建的vpc。

我们通过实例来演示。比如我们在OpenStack里面创建了一个router，然后通过OpenStack的命令行，就可以看到这个 router已经创建了。但这个时候 router只存在于OVN里面，并没有同步到Kube-OVN的CRD里面。

我们的Kube-OVN里面的控制器会不断的去扫描 OVN的数据库，当他发现在OVN里面有这样的一个router的时候，就会向K8s反写一个vpc的CR。这样，通过定期的扫描，我们就可以把Neutron的 vpc数据同步到K8s里面。这时我们在K8s里面就会看到如下的一个CR，它显示 vpc的类型是一个外部的类型，它的name是Neutron后面连接一个ID，也就是在Neutron里面的一串ID号。至此，我们就可以在K8s侧通过kubectl get crd cmd来拿到这个VPC信息了。

当有了 VPC的CR之后，我们就可以在K8s一侧来创建子网。这个子网我们可以选择关联到一个由OpenStack创建的 vpc，就像上面这个示例yaml所写的，我们创建一个subnet，名字叫net2。然后这里的vbc，我们不是使用的Kube-OVN自己创建的vpc，而是引用一个从Neutron导入的 vpc，这样的话我们就可以在Kube-OVN的控制侧，把这个 subnet和Neutron那一侧创建的一个router连接起来。

然后，下面其实就是Kube-OVN常规的一些操作，比如说我把这个subnet跟一个namespace关联，这个namespace是net2，再去设置 subnet的一些cidr还有它的一些触网的策略。

这时候，我们其实就可以创建Pod了。在创建 Pod的时候，我们可以在namespace侧选择net2，这样的话由于 net2关联的是 subnet的net2这样的一个子网，新创建的pod就会落在这个子网上。由于这个子网又和Neutron 侧创建的 VPC相连，也就等同于我们把这个pod运行在了Neutron一侧的 VPC网络上。

最后，大家可以看到，通过上面的一些操作之后，我们在OVN这一侧看到的数据结构的情况。

我们通过OVN的nbctl的命令，来观察OVN侧的一些数据结构。大家可以看到最上面的 switch是Neutron创建的一个subnet，然后下面这个net2其实就是我们通过Kube-OVN创建的一个subnet。在这个subnet里面，我们创建了一个Ubuntu的port，然后给它分配了对应的MAC和IP地址。然后再看这一个router的port这个端口，这个端口其实是将我们在Kube-OVN这一侧，也就是K8s这一侧，创建的一个子网router，进行了一个连接。

这时候我们其实就实现了在K8s这一侧的一个subnet和在Neutron 这一侧创建的一个vpc通过逻辑交换机的方式进行了一个互联。最终实现的效果就是，如果你在 openstack一侧对应的这个子网里面创建vm，它会在这里面创建逻辑端口。而你在K8s创建的pod会在 net2的logic switch下创建pod，但是他们最终都会通过router进行互联。也就是说，他们最终是统一到同一个 Neutron 侧的vpc下网络中，这里面的pod和vm的网络就可以达到互通了。

上一篇：第2期容器网络方案调研：Kube-OVN 迈向主流

下一篇：Kube-OVN V1.8: Underlay 多网卡强化，延迟大幅优化，VPC 功能完善以及更多新功能