11月9日，Kube-OVN社区与F5联合举办线上研讨会，共同探讨如何通过联合方案化解云原生网络下的应用交付挑战。

本篇文章为灵雀云首席架构师杜东明的主题分享《云原生网络方案：Kube-OVN赋能企业持续创新》，以下内容为分享回顾。

中国云原生的实践之路

2010年美国的Paul Fremantle第一次提出了云原生这个概念，2013年Docker发布，让云原生有了落地的基础。中国云原生的路线我认为应该是从2015年开始，在15年的时候，有一些企业像恒丰银行、中国人寿、兴业数金等等都开始启动一些实验性、创新性的项目，来去研究容器，如何去提升开发和运维的效率。在那个时代云原生的关键词应该是CaaS—— Container as a Service容器及服务，关注的是容器的管理、调度和编排。

时至2018年，云原生领域出现了一个大的技术方向，就是Kubernetes战胜了Mesos，战胜了Swarm，变成了云原生平台的事实标准。这一标准的确立，极大的推动了云原生在企业级的落地。我们灵雀云大量的客户也是在那个阶段和我们构建起合作关系的，比如像光大银行、中信银行、浦发银行、华夏银行、招商银行，国家电网、中石油等等。

在那个时代，我们在云原生领域更多关注的是PaaS关键词，关注的是应用的全生命周期管理，我们希望使用容器解决开发、测试、上线和运维一体化的流程问题。

到了2020年，云原生这个领域又出现了新方向，我们称之为“平台化趋势”和“下沉趋势”。

第一个趋势：“平台化趋势”

在2015、2016年，很多客户把K8s放到虚拟机上，当成一个应用去运维，K8s的网络相当于应用的网络。但是到了今天，有大量的应用放到K8s上，比如中信银行，最初我们平台上只放了两三个应用，到今天已经有280多个应用，还有部分a+类超核心的应用都在我们的平台上运行。客户也逐渐的意识到K8s就是一个平台，有了更多的功能上的诉求，比如需要支持DevOps，需要支持微服务，需要支持数据服务等。

第二个趋势：“下沉趋势”

随着K8s平台逐渐变大，客户意识到在虚拟机上构建K8s的平台，貌似没有额外的收益，还增加了管理和运维成本。所以有些客户开始尝试把K8s放到物理机上，我们现在大量的新客户默认采用物理机支持容器平台。
横向的平台化的趋势实际上是对于功能的更多诉求，纵向的下沉趋势，实际上要把容器平台变成基础设施。这两个趋势叠加在一起，就是今天的全栈云的诉求，我们看到现在有大量企业开始针对全栈云有一些项目在启动。

从石器时代到繁花似锦

容器网络在云原生的实践中始终是一个非常重要的位置。2013年Docker刚产生的时候，目标是做一个单机版的应用，实际上是解决应用打包和上线的问题，提供了4种网络，但是这4种网络全都是基于单机的，和今天我们的云原生网络其实相差很大。

2016年，在推广容器产品的过程中，一些客户向我抱怨，就是说我们那时候用的网络更多overlay，基于隧道的这种网络。客户会说我已经构建了sdn了，或者说我已经构建了NPM，或者是安全的一些规范和设备，但是你的隧道让我完全没有办法看到应用的流量，所以就导致客户就不太认可这种overlay的网络。基于此2016年我们和产品团队沟通，创建了一个macvlan的方案，直到今天macvlan依然是非常火活跃的一个容器网络解决方案。

2018年K8s成为容器编排的事实标准，CNI也彻底的战胜了CNM，成为了容器接口规范的标准。2018年我和行业内的一些朋友聊天了解到，事实上2018年在容器网络上依然是只有macvlan，Calico、Flannel三个网络解决方案，我就非常好奇那个时候IaaS网络sdn、云网一体化已经非常的成熟了，为什么容器还处于这样一个非常老旧的这种阶段？后来才知道灵雀云的一波工程师也意识到这个问题了，所以他们基于K8s去寻找一个更好的网络解决方案，他们找到的方案是OVN。OVN已经在IaaS时代很好地去解决了sdn的问题了。

因此在2019年我们就开发并且开源了Kube-OVN的第一个版本。这是真正为K8s设计的网络解决方案。到了2021年，Kube-OVN正式进入到CNCF，成为CNCF的第一个容器网络沙箱项目。

最近，我到K8s的官网上搜索了解到，目前在K8s官网有包括Kube-OVN在内的27个CNI插件，当然大部分都是一些设备厂商或者是公有云的方案，不具有普适性，但是还有不少像Kube-OVN这种通用的网络插件方案。

所以说我们的容器网络应该说从2013年的石器时代，到2015年的双雄会，再到今天一个繁花似锦的时代。我们在容器网络的这个问题上已经解决了大部分客户诉求，进入到一个成熟阶段了。那么下一个阶段也许我们可以把视野放到容器之外，比如说虚拟机，比如说数据中心。

什么是云原生网络

想要了解什么是云原生网络，我们必然要去了解云原生是如何来管理应用的。

在这张图上我画了三个节点。三个节点之上构建了K8s的平台，并且在其上承载一个外部的应用，我放的是一个典型的三层架构的应用，前端由三个容器构成，三个容器可以抽象成services a，service a会有一个IP地址，向service a发流量，流量会被平均的分配到这三个容器上。那么后端是由一个容器来构成，那么它抽象成了service b。

第三层是数据库，我们放到了K8s平台之外，比如用oracle，这样一来我们的应用就是前端后端加数据库的形式。这个应用如果想要把它暴露到外部，我们至少需要先让互联网的用户能够访问到service a，那么我们使用的技术手段叫做Ingress。Ingress是K8s给出的一个工具，这个工具可以让一个主机的一个端口进入监听状态，然后把流量进一步导入到所指定的某一个服务上。

我们来看一下整个K8s的网络中应用从用户的访问中，需要遇到哪些网络问题：

第一步，把外部流量如何引入到service中。

第二步，service的流量如何能够被引入到后端的容器中。

第三步，容器如果去调用了另外的一个service，那么他不可能去调用service的IP地址，这个IP地址是易变的，所以我们一定是对于service要进行命名，然后需要有一个服务发现的过程，通常我们是用DNS的方式，那么对应有一个服务发现的网络诉求。

当我们平台内的容器要访问平台外的数据库的时候，对应需要由内部网络向外部网络能够进行访问。如果两个容器之间需要通信的话，还需要考虑容器pod和pod之间的通信。另外还有一种可能就是我们平台内所部署的服务具有一定的通用性，那么外部其他应用可能需要反向调用我们平台内的某些应用，某些容器，需要能够从外部直接访问Pod。最后所有的service、容器，我们全都要给他绑定IP地址，有可能是弹性IP，有可能是固定IP，可能是ipv4，可能是ipv6，但总之我们需要一个统一的IP地址管理。

那么所谓的云原生网络是为了支持云原生应用，在K8s平台上能够平稳使用，这样的网络我们称之为云原生网络。目前云原生网络和实现的方式都是通过CNI，CNI是K8s的一个标准，它规范了一定的接口，其他第三方的网络组件只要能够满足CNI的接口，就可以为容器去提供网络服务。

传统容器网络方案面临三类问题

这个例子是一个最简单的容器网络的用例，它只是解决了最基本的互联互通的问题，这个问题并不困难，事实上在2015年calico，flannel出现的时候就已经把这个问题解决了。

这么多年实践下来，我们在容器互联互通这个问题上没有存在任何的障碍，但是随着云原生进入到深水区，发现了更多些客户的需求，比如说应用场景变得更加的复杂。

现在K8s平台内的应用需要和平台外的应用进行互联互通，需要把overlay网络和外部的物理网络打通，有些应用需要有固定IP的需求，比如说应用的license是靠IP地址的方式来运算的，IP地址就不能老变，但是这个容器每次启停IP地址都会发生变化，所以有固定IP的需求。

多网卡的需求，可能一个网卡走多播，一个网卡走业务。

安全的诉求，比如说K8s对于安全的管理方法是使用network policy这样的工具，而Flannel根本就不支持network policy，要想使用Flannel，我们必须要放弃对于安全的network policy的支持。

服务和地址需求，在K8s正常的运行过程中是不确定的，服务的这个IP地址会发生变化，但是传统的监控手段是用IP来去对应到某一个服务上，它会让我们传统的监控手段失效。

多个业务如果在一个平台内并存的话，它们之间会发生流量资源的争抢，这种争抢会对于一些应用带来危害。

网络性能的问题，像微服务的数量在急增，我们看到每一个企业都有微服务，而微服务必须要保证每一个容器都会有一个独立的IP，那么我们现在管理IP的数量可能比过去虚拟机时代要多了一个数量级都不止。在这样的规模下，如何来保证网络的性能？我们任何对于网络的监控都可能会导致额外的性能损耗，而且K8s原生的IP tables这种机制在大规模情况下性能也会非常低下。

 面向企业场景的容器网络

在这样的背景下，Kube-OVN应运而生，因时而生。Kube-OVN的本质其实就是把K8s和open vSwitch这两个技术结合在了一起。open vSwitch是我们sdn的一个基础，已经实践了很多年，非常的稳定。

Kube-OVN核心所秉持的一个设计原则，是以K8s云原生的理念作为Kube-OVN的设计理念，这个非常重要。其实OVN支持K8s并不是Kube-OVN首创的。事实上在2018年OVN组织自身就发布了一个ovn for K8s的项目，这个项目2018年发布，2018年结束，一共发布了三个版本，后来相当于夭折了。夭折的原因就是一波懂网络的人，希望把他的网络组件适配到K8s，而这种适配是机械的，是生硬的。

但Kube-OVN的团队是一帮懂K8s的人，知道云原生的诉求，云原生的理念，Kube-OVN是为了适配云原生而生的，这就是设计Kube-OVN的基本原则和基本理念。

灵雀云多年支持客户的过程中，遇到形形色色的网络的需求，遇到各种各样的问题。我们把这些所有的问题，所有的方案整合在一起，浓缩到Kube-OVN方案中，其实它包含了对于大部分客户需求的满足。

Kube-OVN 的特点

这里希望用一张图，简单跟大家解释清楚Kube-OVN的特点。

在这张图上有两个Kube-OVN的网络，每一个Kube-OVN的网络其实都支持了一个独立的K8s的平台。

Kube-OVN的网络管理是子网作为基础，子网是Kube-OVN管理的最小单元。当我们创建一个子网的时候，我们可以为子网设定一个网段，设定它的隔离策略，它能不能够被别的子网所访问，如果不能够的话，能不能开一个白名单？能不能支持安全组？需不需要支持ipv6，这些都是在创建子网的时候可以赋予的属性。

当我们有了子网之后，可以把子网映射到K8s的命名空间，K8s命名空间相当于一个应用的范围，应用会部署在命名空间中。命名空间实际上是一个跨越多个节点的概念，是K8s平台中的一个概念，子网的设计我认为是Kube-OVN的一个亮点。

在Kube-OVN出现之前，子网的管理全都是以主机为单位，不能是以命名空间为单位，是以主机为单位，也就意味着一个应用虽然在一个命名空间中，但是上面的模块可能跑在不同的主机中，将会使用不同的子网，就没有办法使用一个统一的网络管控策略。比如说我这个应用是一个非常安全的应用，必须要运行在一个非常安全的网络环境中，我们正常的情况下给它一个子网，这个子网是隔离的就可以了。但是在传统calico和flannel以主机为单位的子网设计中，这个是完全没有办法去达到的。所以子网和命名空间能对应，是kube-OVN的一大创新。

今天可能已经有不少其他的一些插件已经也能支持子网类似的这种功能了，但是Kube-OVN已经走得更远了，这时候研究的话题是VPC。我们希望可以在网络中以VPC的形式来去给用户提供租户，每一个VPC的用户都可以去完整的创建出来一套三层的网络，可以去创建路由器，可以去创建虚拟机，可以去实现自组网。

那么VPC和VPC内部的这些IP地址甚至都可以去重叠，这在公有云中是非常有价值的，比如说天翼云下边的VPC使用的就是我们Kube-OVN的VPC概念，现在有不少客户在构建内部私有云的时候，也在和我们探讨VPC。

还有第三个需求——平台和平台是不是能够连通？

这个客户大部分的需求是在多云管理或者是混合云上，那么客户有可能在北京一个数据中心中有一个K8s，上海有一个K8s，这两个K8s它的业务需要彼此的互联，有没有办法能够实现这种互联？还有客户为了实现一个更大规模的一个服务网格，这个服务网格可能会跨越多个K8s的平台，他们的网络需要直通。传统的情况下是做不到的，除非用Underlay网络，但是现在可以实现说两个Kube-OVN的网络，哪怕是Overlay的网络，都可以进行直连。两个网络中的某一个容器都可以以IP地址的方式来访问另一个网络中的另一个容器。

这个图应该就可以快速的给大家解释出来Kube-OVN的一些技术特点，以子网的方式去做管理，子网可以和命名空间完全对应，VPC是现在的一个重点， 满足K8s集群互联。

Kube-OVN 的原理

简单的分享一下Kube-OVN的原理，Kube-OVN的模式分为overlay和underlay。overlay的这个原理，事实上就是使用了Open vSwitch来实现跨主机的子网。

kube-OVN工作的Overlay模式

在这个示意图中一共有两台服务器，每台服务器中创建了两个子网。绿色的容器属于子网一，他们都会被连到一个Open vSwitch上，蓝色的容器都属于子网二，他们会连到另一个Open  vSwitch，同时我会为每一个主机中去创建一个虚拟的网卡，这些虚拟的网卡我又连接到了另外的一个Open  vSwitch上，所有的Open  vSwitch都会再在连接到一个虚拟路由器上，这样一来我们就可以实现子网内的互联，跨子网的互联，子网和主机之间的互联。那么当我们的容器想要去向K8s平台之外，去发数据包去访问的时候，我们有两种模式。

第一种模式我们称之为集中式网关，也就是说所有的流量我们都会通过路由器，然后再通过少量的几个网关统一做出网，这个非常有利于做统一的管控，而事实上我们和F5联合的创新方案也是在此基础上做了进一步的增强。

第二种出网方式我们称之为分布式出网，分布式出网就是每一个容器通过所在主机的网卡直接出网，这是两个不同的出网方式。 

kube-OVN工作的Underlay模式

Underlay非常容易理解，就是使用下层的物理网络，那么我们在Underlay模式上，我们支持的是Vlan也就意味着说我们不同的子网其实都对应到了下层的某一个Vlan。比如说在示例中我们有两个绿色的pod，它都属于一个Vlan，那么我们可以给它打一个统一的Vlan号，通过下层的本机上我们有一些组件，我们vSwitch的组件通过向外发包的时候，它就会自动把Vlan tag打上，发送到本机网络上。

Underlay的网络非常有利于像金融客户，网络强管控，自身有了大量的网络安全的规范，网络管理的要求，直接使用我们底层的网络就可以了，相当于不再创建一个虚拟网络了。另外我们还可以在Underlay网络上支持多播，现在我们看到一些军工的客户，证券类的客户，有这方面的需求。

Kube-OVN关键功能

下表是我们Kube-OVN的一些关键的功能。

1.支持多租户vpc。某一个vpc内我们都可以实现用户的自主网。

2.可以实现子网的管理。用户可以自定义组子网可以实现子网的IP地址段，ACL策略、东西/南北向的QOS、出口网关的策略等等。

3.支持Vlan和多播。

4.支持固定IP。固定IP不管是overlay还是underlay都可以支持。

5.支持EIP。也就是为某一个容器，我们可以绑定一个弹性IP，那么这个弹性IP会被暴露到平台之外，平台之外的应用直接去访问EIP，就可以访问到某一个容器。

6.支持IPv6v4双栈，这对金融客户可能是比较有价值的。

7.支持多网卡。某一个容器，它上面可以跑多个网卡，甚至可以实现在一个容器上同时兼容overlay网络和underly网络。

8.支持networkpolicy。像Flannel就没有办法支持Networkpolicy，Kube-OVN是完全支持的，我们可以实现这种到Pod到Pod，Namespace到Namespace，Pod到Namespace之间的的网络管控策略。

9.支持跨集群的通信。

10.支持像dpdk，智能卡硬件加速。

11.支持流量的镜像。可以把Kube-OVN的流量径向到指定的主机或者指定的网络设备上

12.支持虚拟机。

13.支持智能的运维。在Kube-OVN开源版本中我们就集成了Prometheus等工具，我们可以针对100多个指标进行监控。

Kube-OVN for Cloud

Kube-OVN在现代的IT中是怎样的位置？

Kube-OVN的Vision是什么？

未来Kube-OVN的发展方向在哪里？

这张图我想说明这个问题。我们认为未来的it一定会走向双模it或者双态it，就是稳态和敏态分离的双态it。

传统的稳态的业务系统，还是会使用像ETL这样的一个管理体系。但是现在新兴转型的数字化应用一定会放在敏态的平台上，敏态的平台它的管理方法构建方法是完全不一样的，而敏态的平台支撑的一个基本的工具就是K8s，也就意味着未来的敏态的基础设施应该通过K8s去统一管理起来。它向下管理服务器、管理网络、管理存储，那么向上去提供几种不同模式的计算能力，包括容器、虚拟机、物理服务器，包括边缘计算，然后我们再通过vpc把这些不同形式的计算能力组装在一起，让他们形成一个网络平面。比如说我们可以创建一个租户，租户中我可以创建容器，也可以创建虚机，他们是共用了同一个网段，他们甚至可以放在一个二层网里边，容器和虚机是可以完全去互访的。

事实上在今天这已经不是先进的vision了，这已经是实实在在正在发生的事情了。据我们所知，运营商、某些大型央企等集团性的客户，他们在内部构建私有云，正式采用了这样的一套架构。底层已经不再采用OpenStack而是采用K8s来去支持下层基础设施的统一管理，上层去提供不同容器虚机、物理机等等这样的一些服务，再通过VPC把这些服务和租户关联在一起。

Kube-OVN希望在未来中扮演的是敏态平台的sdn的角色。Kube-OVN中会包含了VPC的管理，传输的管理、安全的管理、跨云的管理、接口的管理等等。那么敏态IT和稳态IT需要有一个明显的管控的出入口，敏态和稳态本质上来说它并不矛盾，而是一个有机的结合，结合点上要进行安全的管控，管控的方案就是灵雀云Kube-OVN和F5联合创新的这套CES解决方案。

Kube-OVN Roadmap

刚才谈了Kube-OVN的Vision，下面谈一下Kube-OVN的Roadmap。在未来的一段时间内，我们会把工作集中在以下的7个方面。

1.子网的多网卡支持。我们一台主机上可能会有多个子网，那么现在这多个子网会共用一个网卡，那么未来我们希望把这多个子网可以分配到不同的网卡上。

2.vpc的产品化。现在我们看到有大量的vpc的需求，这些vpc的需求，目前我们还都是以开源社区的方法来去支持，我们希望把vpc能够进行产品化，变成企业级的vpc。

3.metall lb的支持。能够支持load balance的类型的service。

4.Pod Qos的优化。在目前的情况下Pod没有优先级的概念，只有流量的管控，但是没有办法去定义一个优先级，一个抢占的规则。那么未来我们会定义这个规则，一些高优先级的就可以优先保证自己的流量。

5.KubeVirt的优化。也就是我们要在虚拟机网络上要做更多的工作，因为我们认为Kube-OVN不仅仅能为容器提供服务，它应该能为云计算提供服务，能为数据中心提供服务。

6.性能的优化。这个是一个持续性的工作。

7.白盒交换机的支持。这是因为有不少的客户希望用Kube-OVN作为整个数据中心的sdn，那么我们物理机需要去支持存储等等这样不同的设备，就需要一个白盒交换机，这些是Kube-OVN短期内的一些Roadmap。

上一篇：灵雀云左玥：IT像城市一样演进

下一篇：云原生时代，应用更贴近基础设施｜灵雀云受邀出席英特尔数据平台技术峰会