重生的 SDN?云原生网络功能介绍

作者 | Wavell Watson
译者 | 明知山
策划 | 丁晓昀
在三类云资源(计算、存储和网络)中,网络似乎最经得起云原生非功能性需求的考验 。例如,计算弹性是通过虚拟机、容器和编配器合理分配的,并通过 CI/CD 管道进行管理 。网络在实现方面似乎缺乏弹性 。在本文中,我们将试图通过云原生网络功能将网络应用程序引入云原生世界 。但究竟什么是 CNF,为什么它们如此重要?
1
重生的 SDN?我们以前没试过吗?
软件定义网络(SDN)在过去和现在都是网络配置自动化的一种尝试 。云原生网络功能并不是重生的 SDN,它以一种完全不同的方式看待网络 。在某种意义上,云原生网络功能类似于 SDN,因为它们是基于软件而不是基于硬件的解决方案 。但是,云原生网络有一组完全不同于 SDN 的非功能性需求 。云原生非功能需求优先考虑通过弹性、自动化【脚注 1】,等等,比 SDN 要多得多 。这个需求的实现依赖于声明式配置 。换句话说,云原生配置更倾向于说它想要完成“什么”,而不是“如何”完成 。例如,有一个禁止硬编码 IP 地址的网络声明式配置 。声明式配置让整个系统具备了自愈的能力【脚注 2】,因为这样更容易读取和并做出适当的响应 。然后,系统可以不断地进行自我修正 。云原生系统的其他非功能需求是弹性和可用性,并通过横向扩展而不是垂直扩展技术来实现 。云原生系统试图通过让子组件具有更高的可服务性和冗余性来解决可靠性问题 。例如,在云原生环境中,拥有一个包含多个冗余子组件的顶级组件(其中几个组件可用,但少数组件出现故障)要比一个紧密耦合但“高可靠”的组件更可靠【脚注 3】 。
2
超越虚拟化网络
在某种意义上,“网络功能”并不是解耦的 。虚拟网络功能(VNF)始于网络硬件的虚拟化 。VNF 的硬件与虚拟化硬件是一一对应的,下至网卡、特定于应用程序的集成电路(ASIC)或整个交换机 。SDN 似乎是将物理网络机器虚拟化,但 CNF 不仅仅是容器化的网络虚拟机,它对网络功能进行进一步的解耦 。CNF 根据敏捷产品团队的发布周期,从大公司的大发布周期中脱离出来,在功能上把网络分成具有相似变化速度的组件 。由产品团队发布的软件【脚注 4】可以被认为是“厚”微服务 。“薄”微服务是指作为容器内的单个进程类型【脚注 5】交付的软件 。通过作为产品团队来开发软件,我们发现,在实践中,厚微服务常常看起来很像薄微服务 。
编配器的出现为管理微服务带来了福音 。编配器负责微服务的调度、启动、停止和监控(生命周期) 。现在有许多编配器,其中 Kube.NETes(K8s)是最流行的,但也有特定于领域的编配器,例如电信领域的编配器 。云原生生态系统早期的一个愿景是防止编配器 K8s 被“割据” 。这是通过提供官方的 K8s 认证来实现的,该认证由 CNCF 维护,以确保 K8s 的分支版本都将支持社区要求的 API 和最佳实践 。
3
究竟什么是云原生网络功能?
云原生网络功能存在于 OSI 网络栈【脚注 6】之上,已从云原生轨迹图中移除 。CNF 在网络栈的位置越低,就越难有好的云原生实现 。这可能是因为网络需要与编配器和底层主机集成,同时保留其云原生属性,也可能是因为如果不小心将以前的网络功能(比如转发平面)从共享内存 / 线程模型分离到无共享进程模型【脚注 7】会降低性能 。
要理解解耦网络功能的影响,就有必要了解一下网络分层背后的逻辑 。OSI 网络栈允许网络出现创新,同时保持层之间的互操作性 。在网络层,IP 协议最终成为大赢家 。在数据链路层,出现了 ARP 。供应商们在每一层的协议层进行迭代,创建出新的协议和新的协议实现 。云原生网络功能可以实现为包含在开发库、微服务中的协议,甚至可以作为网络应用程序中的一组微服务来实现 。
网络服务网格项目的 Ed Warnicke 曾经说过,对于网络服务来说,“数据包就是有效载荷” 。这意味着实际操作(转换、路由或分析)网络数据包或数据帧的是网络应用程序或服务 。以下是 OSI 模型各层网络功能的一些例子 。
第 7 层:CoreDNS;
第 6 层:NFF 包检查器;
第 5 层:Rsocket
第 4 层和第 3 层:Envoy/Network Service Mesh/Various CNI 插件;
第 2 层:基于 VPP 的 VSwitch 。
对于云原生网络应用,或更高阶的跨多层云原生网络功能,例如 MATRIXX Software 的 5G 融合计费系统和 PANTHEON.tech 的 BGP 服务器 。


推荐阅读