联系电话:4006-252-832

灵雀动态

灵雀云是容器服务和企业级PaaS领军企业,团队拥有全球领先、超大规模企业级云平台的开发、运维和管理经验。致力于通过革命性技术,帮助企业客户在数字化转型中持续创新。
基于Kube-OVN打通OpenStack和K8s网络
2021-11-11

在以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投资的同时,能够发掘云原生的红利,是目前很多企业都要解决的问题。

1.jpg

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

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

2.jpg

我们提出了一个新的方案,这个方案就是把现有的 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 网络,使得它的数据平面能够更快,性能更好。

3.jpg

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

4.jpg

这个就是网络示意图。在这个框架图里面大家看到不同的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。

5.jpg

我们通过实例来演示。比如我们在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信息了。

6.jpg

当有了 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 功能完善以及更多新功能


为您数字化转型提供更为完善的解决方案和更加优质的全栈服务。

申请试用

联系电话:4006-252-832 隐私条款
© 2022 All Rights Reserved. 灵雀云 版权所有 备案号:京ICP备15011102号-2
欢迎访问灵雀云

您希望我们如何帮助您?


Canto Rep
您想了解云原生技术对企业数字化转型的价值吗?