Nephoo扩展Kubernetes解决云原生自动化

Nephio项目由Linux基金会于2022年启动，该基金会与谷歌和一系列电信运营商、解决方案供应商和集成商一起，着手构建一个统一平台，使用Kubernetes为大规模5G电信网络部署提供意图驱动的云原生自动化。

Nephoo社区的驱动力是在容器和虚拟机的大规模部署中，云原生自动化尚未完全实现。采用完全云原生堆栈仍然需要在资本和运营投资方面做出努力，而且对于采用者来说，结果并非100%完美。

目前，Kubernetes的部署正在促进容器的带外自动化。Nephoo使Kubernetes能够：

——在其上部署云基础设施和网络功能，无需带外管理。

——管理其自身的基础设施和网络功能的配置，减少对外部编排的需求。

Nephoo首先对Kubernetes的部署和配置进行了调整。我们知道，对于大型或电信网络，Kubernetes非常适合充当统一和自动化的控制平面，以配置可能分布的每个基础设施的所有方面和主机网络功能。

但据观察，Kubernetes并没有被用来自动执行云原生功能（CNF）和VNF。除了托管CNFs和VNFs（虚拟网络功能）之外，Nephoo架构还将在自动化方面使用Kubernetes。

典型的大型电信网络涉及来自多个供应商和不同网络管理标准的网络功能。但是，如果我们从不同的供应商那里实现配置，并比较一个网络功能或云基础设施，情况就不一样了。例如，有O-RAN（开放无线接入网络）或3GPP等标准，但部署的配置有所不同。

为了自动化供应，Nephoo将Kubernetes的声明性、主动协调的方法与机器可操作的配置相结合。它是声明性的，因为配置将作为基础设施自协调的意图提供，直到其达到预期状态（从观察到的状态进行检查）。

此时，大多数现代基础设施管理员都在使用Helm图表进行复杂的Kubernetes工作负载部署和配置，但使用它们仍然很复杂。Helm图表是数千个嵌套的YAML模板文件。使用Helm图表的缺点是它会产生有条件生成的配置输出。

在Helm图表中，基于意图的连续协调是不可能实现的，因为它会生成带有条件的配置。对于Nepho，这种方法将被CRD（自定义资源定义）所取代。

为了解决大规模Kubernetes环境中的配置问题，Nephoo将为不同的网络功能生成CRD和operator，以管理生命周期和配置。此外，随Helm提供的基础设施即代码（IaaC）将被配置即数据（CaD）取代。这些将部署在公共和私有云基础设施中，以实现自动化。CRD和operator的实施将符合3GPP、ORAN、O2等标准。

原文链接：

https://thenewstack.io/nephio-extends-kubernetes-to-solve-cloud-native-automation/