共计 4965 个字符，预计需要花费 13 分钟才能阅读完成。
云原生技术在飞速发展的过程中一直地进入更多的行业和畛域，作为云原生网络倒退的见证者、亲历者，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 做交融。与此同时，咱们也看到很多传统技术在一直的回归，很多网络需要其实都是很多传统网络的需要，这些云原生传统的技术可能会对整个云原生网络能力有一个一直的加强。
• 软硬件联合将会把云原生网络带向新的战场
咱们传统容器网络就只在软件层面，硬件只是在硬件层面，然而咱们看到这种软硬件联合的场景，可能会在不同的畛域、特定场景中施展微小的劣势。在这种模式下会给云原生网络的倒退带来一个新的可能。
