云原生技术在飞速发展的过程中不断地进入更多的行业和领域，作为云原生网络发展的见证者、亲历者，Kube-OVN Team对大量用户的技术选型、应用场景、落地实践经验进行分析，看到了一套不同于以往的网络发展趋势。

当下网络的瓶颈和机遇在哪里？

是否有可参考的场景来印证这些方向？

本篇文章将和你一起发现和探讨我们眼中的“云原生网络”发展趋势及应对方法！

主要发现

•       单一 CNI 很难满足所有场景需求，不同场景会出现特定网络插件：

•       不依赖特定 CNI 的网络辅助组件会不断涌现

•       新技术涌现，传统技术回归

•       软硬件结合将会把云原生网络带向新的战场 

云原生网络主要应用场景 

近些年，云原生技术在飞速发展的过程中也在不断地进入更多的行业和领域。我们最早认为云原生技术，还主要是互联网企业以及一部分技术领先企业（比如应用微服务架构）的选择。但在灵雀云多年的实践中，我们看到更多领域的企业和场景在不断接纳云原生技术。主要有以下的几个比较明确的应用场景：

1、传统应用上云

一些传统行业的企业，如金融、能源、制造、车企的应用希望基于K8s做云原生应用现代化改造，是现在的一个大趋势。

2、数据中心基础设施建设

云原生技术现在来看不只是只针对应用、服务，而是不断地下沉到数据中心的基础设施中去。我们发现，现在的整个IT基础设施，趋于通过云原生的方式进行编排和管理。

3、边缘计算场景

这些年比较火边缘计算相当于把计算不断地推到离用户更近的地方。这种场景下，传统的CDN把计算往边缘CDN上推的过程中云原生也发挥了很大的作用。

4、多集群跨云管理

随着早期云原生用户规模的不断扩大，产生了多集群、跨云的管理问题。

5、“金融级”安全和审计要求

相较于K8s比较松散比较灵活的安全审计要求，在金融领域，我们看到了“金融级”更加严格的安全、审计应用场景。

6、运营商5G

运营商的5G业务在国内已经广泛布局，在这个过程中存在很多5G、流量编排的任务开始用云原生技术去做落地。

在总结应用场景这个过程中，我们发现网络经常成为这些云原生场景落地的瓶颈。在计算和存储部分，目前都有一些成熟的解决方案，但在网络部分不是功能不足，就是性能不够，或者监控、可视化等分析跟不上，又或者是安全的要求不达标……种种限制导致云原生网络还面临着很多的一个发展机遇和挑战。下面我就会结合各种各样的场景来分析，云原生网络网络面临哪些新的需求，以及目前来自于开源项目和商业化的厂商给出的解决方案。

首先来看一下最早的容器网络方案的基本的拓扑。这是一个Flannel的架构的一个示意图，最早的容器网络是针对K8s、微服务这种服务平台来设计的，所以它希望做到开箱即用，对底层的网络要求很低。在整个云原生早期的应用视角来看，平台希望把网络完全屏蔽掉，不希望暴露更多的网络细节给用户。

在这个方案里，每个节点固定有一个固定的网络IP段，这样、能够减少IP分配，通过iptable这样的一些内核技术来实现其安全策略。这样的一个网络模式和结构，在早期来说是与整个云原生的理念符合的，但是随着云原生向更多的领域渗透的过程，这样的网络模型就显得不够用了。 

场景一：传统应用云原生化

我们以“传统应用云原生化”这个场景为例做简单分析。

•       传统应用不管是开发、部署、运维模式都是和微服务框架完全不同。很多应用的开发运维都依赖于固定IP，需要对IP有很强的管控能力。但最早期的云原生网络是不具备这样能力的。

•       我们发现在传统的我们之前只是把一些应用部署在 K8s上，但是现在越来越多的人会把中间件等一些有状态服务部署在K8s里面，而且需要对外提供服务，相当于K8s集群中运行中间件，也是需要对外提供一个固定的服务地址并且是从外部可以访问的。

•       我们的一些用户由于历史原因，应用无法全部云原生化，需要集群内外互通直达。

•       我们的一些用户还存在应用、网络管理分离，需要传统网络友好的容器网络。

以上这些，是我们在传统的应用云原生化的场景中遇到的问题。 如果我们把这些问题抽象来看，其实是有以下几个需求：

1、Underlay 网络

传统应用需要的并不总是灵活的overlay网络，可能更需要这种underlay网络。直接把容器网络以固定IP的方式在我二层暴露出去，通过交换机打通，这样整体的开发、部署、运维的冲击是最小的，尽管这个可能不太符合云原生最早的一些理念，但是从实践上来看，这种方式其实是落地最快的。

2、灵活的 IPAM

用户需要对IP有很强的管控，而且也不希望你的IP是和节点绑定的，所以需要一个更灵活的 IPAM来完成这样的功能。

3、Whereabouts, Macvlan, Bridge, Multus-CNI

在社区有一些开源的解决方案，比如像Whereabouts，它其实是一个 global级别的一个IPAM工具，就是你可以通过这个工具来设置一个全球的iPad其他的项目。Underlay网络可以通过Macvlan还有Bridge这样一些插件去实现。如果需要多网卡多IP，还可以通过Multus-CNI的方式去实现，尽管这些方式看上去很传统，但在传统应用云原生化的场景下是很实用的解决方案。

应用场景案例： 

云原生网络 Kube-OVN的企业级实践之路

Kube-OVN云原生网络性能的自我救赎 

场景二：数据中心基础设施

第二个大趋势是云原生技术向数据中心下沉，K8s托管的业务不再是应用，不再是微服务，而是整个IT基础设施。在这种大趋势下，网络不是一个单纯的容器网络，而需要同时承载容器、虚拟机、甚至是裸金属，以及很多异构基础设施。然后你的基础设施中有不同的交换机、路由器、防火墙等各种各样的网络设备和硬件设备，需要通过网络进行统一管理，而且在这种规模下，用户大多数情况都有多租户VPC的需求。

现有的很多K8s网络相当于二层、三层打通的统一的网络平面，但在数据中心的场景下更需要多租户的隔离。此外，数据中心对南北向的流量有一些更高的要求，他们在网关层面上可能需要有一些高性能、高可用横向扩展的能力，这些都是传统数据中心SDN的理念，现在是不断向云原生来迁移。

我们看到，一些传统的数据中心网络厂商，SDN厂商，以及一些硬件厂商现在都在不断的把他们的网络融合到K8s中来，因为用户对传统SDN的需求还在。

在开源的领域，由灵雀云开源的K8s CNI 插件Kube-OVN已经在做这样一些事情了，你可以创建VPC，可以创建subnet，可以给每个租户创建LB/EIP/NAT防火墙，甚至还有DHCP/DNS这样的一些租户内部的网络应用。

从商业化工具来看，像VMware的NSX-T也在做类似的事情。我们见到国内的一些传统的做SDN的厂商也开始往这个方向发展，所以大家很快就能看到一些很成熟的数据中心的基础网络商业化产品。

应用场景案例：  

基于Kube-OVN打通OpenStack和K8s网络

云原生虚拟化的最佳拍档:Kube-OVN + KubeVirt 
实践案例 | Kube-OVN在字节跳动的应用场景和技术探索

场景三：边缘计算场景

边缘跟数据中心的场景有很大的差异，因为在数据中心里整体的计算资源是相对充足，可以完善很多像VPC多租户这种设备托管理的高级功能。但在边缘的场景就会是完全另一种情况，它的资源紧张，而且节点与节点之间的网络很不稳定，设备之间无法直接互联。边缘场景下完全打破了K8s的网络模型，产生了一些特别的需求。

在这种情况下，需要一个更加简洁的网络，尽可能的减少资源的占有和消耗。同时，由于网络状况不稳定，不能像数据中心的网络有集中式的控制器，所以节点必须网络自制的能力，保证节点之间正常通信。由于设备之间连通性也相对较弱，在边缘的场景对路由、代理、VPN等功能会有更高的要求。

应用场景案例：  

实践案例 | 基于天翼云边缘计算场景，Kube-OVN社区最新拓展特性一览 

场景四：集群互联场景

近些年，集群网络管理需求变得越来越多。越来越多的用户不再是管理一个K8s，而是跨公有云、私有云,或者是跨地域的多个K8s,需要异构的网络集群的打通。

这种情况下，用户网络策略跨集群的打通；流量需要实现一个跨界型调度，完善多集群流量管理及加密；很多的这种高级的功能不断涌现。

基于这些需求，Kube-OVN做了以下方案应对：

•       基于隧道的跨集群互通网关

•       IPSec, wireguard 等加密方式支持

•       Multi-Cluster Service APIs 实现

•       跨集群 Ingress，NetworkPolicy 控制器

•       跨集群服务网关

•       Submariner, Clusternet, Cilium

除了Kube-OVN，这里也介绍几个开源社区中具备跨集群能力的网络组件：
Submariner可以做到集群的这种网络的互通；

Clusternet很多的像边缘计算的框架里面都会用这种代理;

Cilium也在做跨集群互通的事情，但Cilium的应用成本比较高，应用跨集群能力也需要同时用到它整个的数据平面控制平面。

应用场景案例：  

F5 & Kube-OVN 联合方案加速 PaaS 与基础架构的融合

场景五：“金融级”的安全和审计

灵雀云在金融客户中有很多落地案例，所以我们深刻总结了金融用户应用云原生网络的场景痛点和问题。在“金融级”场景下，存在更多监管方面的问题：

1、金融用户希望有根因分析，必须分析到很彻底原因故障到底是怎么产生的；

2、安全的规范也更加严格的，需要多层次细粒度的规范；

3、金融需要较强的流量审计需求，需要保存所有流量方便日后进行审计分析，甚至进行一些故障的回放，日后进行演练。

所以金融用户对云原生网络提出了更高的要求。我们需要有更细粒度、不同层次的网络安全策略，不单单是面向应用的网络策略，而是分层、分用户的安全策略。

与此同时，金融用户需要有一些容器流量镜像的能力，像银行传统的那种流量现象，其实都是有专门的团队做分析，像商业化npm公司目前也开始转型做云原生的流量分析。

应用场景案例：

金融行业企业级容器云平台网络方案
Kube-OVN：大型银行技术团队推荐的金融级云原生网络方案

场景六：运营商的云原生网络场景

运营商的特点与边缘有些类似，他们会更靠近终端的客户，但是资源比较充足。另一方面运营商对性能和延迟会比较敏感，在运营商的场景下，更多是OpenStack或者VM这种方式来部署应用，而不是通过容器化部署应用。另一个很明显的特点是，运营商同场很注重一些节点之间的网络性能。

对于运营商来说，他们对同住机制内的不同的容器或者是不同VM进行流量交互，基于此我们需要提供一些软硬件结合的一些网络加速方案，在延迟很敏感吞吐量特别大的情况下，用SR-IOV，DPDK，或者先进的智能网卡来完成流量处理和加速。当然，也可以使用像eBPF这样的工具来完成节点内的流量转发。

应用场景案例： 

联通天宫平台数字化虚拟网络基座实践
软硬兼施：多功能、零损耗的云原生网络方案

我们对云原生网络发展的解读 

以上，介绍了不同的场景下的挑战和对网络一些需求，以及现有的开源和商业化产品的应对措施。下面做一个简单的总结。

•       单一 CNI 很难满足所有场景需求，不同场景会出现特定网络插件：

从以上这些场景也可以了解到，，目前用户对于云原生网络的需求特别多，一些场景之间的需求是相互矛盾的，我们认为可能在不同的场景下可能会出现特定的网络插件，专门解决某一领域的问题。

•       不依赖特定 CNI 的网络辅助组件会不断涌现

例如Submariner或 Clusternet，不是一个完整的数据平面，但是他们是在数据平面不同的CNI之上再做了一个特殊场景化的功能。这种情况下，我们可能就不需要去因为某一个场景去完全实现一整套的网络功能，可能我只需要对某个场景实现特定的网络功能了，剩下的功能组件去不断辅助完成整个的功能。

•       新技术涌现，传统技术回归

我们看到一些新技术不断进入云原生领域，比如像eBPF、智能网卡这样的一些软硬件都在与K8s做融合。与此同时，我们也看到很多传统技术在不断的回归，很多网络需求其实都是很多传统网络的需求，这些云原生传统的技术可能会对整个云原生网络能力有一个不断的增强。

•       软硬件结合将会把云原生网络带向新的战场

我们传统容器网络就只在软件层面，硬件只是在硬件层面，但是我们看到这种软硬件结合的场景，可能会在不同的领域、特定场景中发挥巨大的优势。在这种模式下会给云原生网络的发展带来一个新的可能。
 

上一篇：Kube-OVN v1.10.0：新增Windows节点支持，用户自定义子网ACL等10+硬核功能

下一篇：如何构建高可用、高并发、高性能的云原生容器网络？