云原生宣言

云本地清单 NGMN联盟的运营商观点 版本:1.0 Date: 06.09.2023 文档类型: 最终交付物(批准) Confi机密性类: P-公共 领导力: 卡洛斯·费尔南德斯（德国电信） JavanErfanian（加拿大贝尔） ProgrammeOúce: 克里斯·霍格（代表NGMN） 批准人/日期:NGMN董事会，6th2023年9月 对于公共文件（P）： ©2023下一代移动网络联盟e.V.保留所有权利。本文档的任何部分不得在未经NGMN联盟e.V.事先书面许可，以任何形式或任何方式 本文档中包含的信息代表NGMN联盟e.V.对截至日期讨论的问题持有的当前观点本文档按“原样”提供，没有任何保证，包括任何适销性、不侵权、 orfitnessforanyparticularpurpose.Allliability(includingliabilityforinfrenceofanypropertyrights)relatedtotheuseofinformation inthisdocumentisdisclaimed.Nolicense,expressorimplied,toanyintellectualpropertyrightsaregrantedherein.Thisdocumentisdistribute- 发布仅供参考，如有更改，恕不另行通知。 执行摘要 术语“云原生”是指设计和操作应用程序、网络的方式功能和服务，在一个开放的、可扩展的环境中。容器与 Kubernetes，一个事实上的编排器，在微服务架构中，作为一个基础设计模式。这种方法利用了可扩展性、可靠性和自动化，并具有 成功地用于大型或超大型部署(例如，通过超缩放器 cloudproviders).Theintentionistobeechientandcosteective,allowingfasttimeto 市场和提供最佳的客户体验。 作为NGMN战略关键战略支柱的一部分，即掌握通往DIS的路线- 聚合，云原生辩论是一个高度优先事项。鉴于战略影响 在这种范式转变中，对运营商采用它们的预期影响，以及行业参与者提供的多种选择和路径，这是NGMN的信念 董事会成员认为，需要对云原生有明确的立场，以便整体生态- 系统可以使fit受益，并朝着更好、更有效的telco服务方向努力。 这份宣言文件背后的社区认为，电信- Nications行业及其最终客户可以受益于采用云原生 方法。这不是一个简单的复制练习，而是一个抽象相关云的方法原生原则，并将其应用于电信环境中，这需要巨大的e夫ort和网络和整个组织的变化。这份宣言文件， 因此，涉及到应用软件架构和基础设施和过程。 云原生基础设施需要一种声明式方法，以服务于所有的远程- 通过不同拓扑(核心、边缘分布式、RAN、FAN、传输、 等）和技术（VM，裸机）在任何地方都保持一致的部署模型。 这将使运营商能够一致地暴露可用的基础设施 功能，然后可以由应用程序请求；并且可以验证和动态执行提供者-消费者协议。 云原生应用程序和基础架构的内在动态特性将要求 过程监管的实质性转变，这将实现更大的多层次粒度基于控制循环和声明性目标的服务保证。 可靠可靠的真相来源库是云原生的核心组件 架构。此存储库将确保所需状态是可追踪的、可理解的、并且可复制-特别是在生产环境中-使用全自动数字 管道。 构建云原生架构需要电信运营商之间的共同努力， suppliers,andpartners.Thisisdescribedinthisdocumentbystatingafewprincipal 要求，并从操作员点概述此旅程的重点区域的观点。 在我们通往未来高度灵活、可持续和有弹性的网络的旅程中，我们相信将以下云原生原则应用于网络的所有层 基础架构、应用程序和服务*： 1.垂直整体上的解耦基础设施和应用程序生命周期;2.“APIfirst”通过手动配置网络资源； 3.对命令式工作进行声明性和基于意图的自动化； 4.GitOps**原则优于传统网络运营实践； 5.UnifiedKubernetes(或类似的)域特定的资源消耗模式fic 资源控制器； 6.UnifiedKubernetes(或类似的)在供应商上的闭环协调模式- 规范fic元素管理实践；以及 7.通过良好的defiNedCertifi阳离子过程在供应商特定fic优化上的互操作性。我们还认为，开放性和兼容性原则需要成为 未来的电信和网络服务实施，以确保我们利用云鼓励软件编排和硬件分解的原生原则。 *并不意味着优先顺序 **一切都作为代码，单一的真理点，不可变的信任来源。 CONTENTS 01 一个云本地人 抽象6 行业关注 04 交付云NATIVE11 02 CLOUDNATIVEINTHE TELCO空间7 2.1云原生应用7 2.2云原生基础设施7 2.3云原生运营模式8 03 原则和云的要求 本地电信9-10 05结论12 06缩写13 07ACKNOWLEDGEMENTS13 01ACLOUDNATIVE 抽象 云原生技术和架构是指实现开发和部署的方法 云和开放环境中的应用程序使用容器化、微服务架构和orchest- 定量工具，如Kubernetes。这种方法特别关注放在可伸缩性、弹性和fi灵活性上。云原生 应用程序通常构建为松散的集合 耦合服务。每个服务都执行特定的fic功能可以独立开发、部署和扩展 以及船上的任何基础设施(电信、私人或public)和容器平台。这种方法促进 模块化，使其更易于维护和更新单个组件，而不会影响整个系统。 此外，云原生方法带来了另一种吸引人的一组特征： •闭环基于意图的执行环境。 在大多数情况下，Kubernetes已成为选定的云原生部署的实际环境 (虽然不是唯一的一个和其他可能被开发出来的 inthefuture).Thisenvironmentcomeswiththeconcept 可以理解所需状态的“控制器” 并始终执行它。 •API驱动。Kubernetes是建立在API-first之上的-除了为彻底的“作为代码”奠定基础 方法，并允许清洁和可扩展的分离在产品编码和严格控制之间 全自动部署。 •支持为扩展和维护而构建的应用程序- 能力。基于容器的微服务应用程序 因为设计模式可能允许更大的可扩展性和更简单的生命周期。 上述“特征”可以被利用和额外的-注定要在电信领域注入激进和积极的整体运营模式的变化，从应用- 为基础设施建设和奠定基础 用于引入复杂的控制机制(例如 AI-like)toreachtheadvancedconceptsoftheautono-mous网络。 在下一章中，我们将提供一个关于云原生目标将看起来像应用程序，基础设施和运营。 •分离和抽象。Kubernetes框架 保持对一组特定fic功能的控制，同时指定面向基础架构的干净接口 （例如CNI，CSI）。此功能启用从Kubernetes集群运行的基础设施类型只要接口保持尊重。 02云本地 TELCO空间 2.1CLOUDNATIVEAPPLICATIONS 在应用程序端，CloudNative促进了高级服务的就业(例如切片、非公共网络(NPN)、网络即服务(NaaS)等)和与云原生企业应用互通。A 游戏改变属性的数量预计为： Procedures.自然可扩展性因为几乎没有任何限制从Kubernetes基础设施到地平线- 理货进出，然后把重点留给构建可以利用此功能的应用程序(也在网络集成)。 Procedures.改进的弹性：冗余和自动修复自然接受，从而提高网络可靠性， 并最大限度地减少停机时间和手动恢复。这还包括底层设备- 有定期升级或fixs，没有 •断路器逻辑，以隔离安全受损申请的一部分；以及 •创建与生态系统更自然的整合- 企业应用程序的项目(其中云原生是一个日益增长的趋势)。 2.2CLOUDNATIVE 基础设施 带来的内在分离和抽象 Kubernetes环境支持以下基础设施- 未来发展。 Procedures.不同类型的基础设施（VM，裸机，智能NIC和硬件加速器-Telco/PrivateCloud或公共云)在一致的和 可预测的方式，并由应用程序制造消耗品- 阳离子，根据需要。 对正在运行的应用程序的影响。Procedures.共享基础架构可以被网络使用域，包括核心、传输、RAN和fiX访问， Procedures.更快的部署和更简单的生命周期：因为基于模型的方法，组织可以快速 部署和更新网络服务(例如内联升级 和金丝雀测试)，减少上市时间和风险当前复杂的生命周期操作。 D.粒度安全性:云原生网络整合现代安全实践，如微细分， 实现fi对网络的粒度控制和隔离 trac，从而加强整体安全态势。 此外，通过快速可靠的升级和更新，安全修补将得到更好的本地管理。 功能集将为许多用例打开，例如： •在追求能源的应用中扩展和扩展 e-ciency、可持续性目标和成本e-ciency； •实现现代化并提供更有效的现有服务保证，采取纠正措施接近 根本原因； 以及IT(OSS、BSS、产品目录、客户接口等)。 Procedures.公开打开的API虚拟化和容器- 基础设施资产。(CISM、VIM等)。 D.独特的控制平面用于云基础设施因此，从核心到边缘，实现统一整个庄园的部署方法。这个 导致更统一的基础设施(如 Sylva）来简化CNF与基础架构的集成。 Procedures.构建复杂的业务流程和控制层在基础设施控制平面的顶部；打开介绍最新的技术发展(用于 利用AI类型的方法的示例)。 云原生基础架构功能有利于以下方面： •获得网络敏捷性和自动化创新新网络应用有效地，在网络上作为一种服务。 •与基础架构相匹配的智能工作负载布局然后可以部署的功能和容量 在某种程度上真正需要它们来fi和最优 所需投资的平衡和缩减 2.3云本地运营 MODEL 运营模式建立在以下支柱之上： Procedures.全自动化数字管道和相互关联与供应商和开发商的管道将照顾 基础架构和应用程序的生命周期。 每当资源未使用时。Procedures.一个独特的不可变的真理来源用于驱动部署；一旦共同和协调的艺术- •动态分配资源，保持其水平即使条件改变，如要求为true网络切片的实施。 •对异常迅速和有效地作出反应的可能性灾难或其他有计划或无计划的情况事件。 将事实放入信任存储库的来源，然后 进一步的变化是不可能的(类似于GitOps approach).Operatorsmustbuildthissourceoftruth 与各种库存相连。 Procedures.所需的部署目标通过 DefiNed规则和人工制品然后可以部署并以多种方式强制执行。 D.自动校正异常始终是默认方法这需要对 管理和处理相关信息。此操作模型允许： •创建一个明确而独特的definition是什么状态生产环境，并拥有- 提高可追溯性和审计水平的可能性 大幅降低fi配置漂移，这是一个主要的熵和误差的来源。 ·鼓励协调工具和手册亲- 忍受。 03原则和云的要求本地电信 1.Kubernetes或类似的性能相同的系统必须是云原生的运行环境application 2.基础设施层之间的独立性 4.基于意图的云原生应用描述- 阳离子和服务 a.该应用描述符应基于标准。 和应用层b.应该可以描述什么类型的抽象 基础设施暴露了资源。 a.基础架构以标准方式公开当前的 和Kubernetes层的未来功能(如HW 加速器或智能网卡)。 Procedures.应该可以在声明式中定义fine服务方式，并通过API向客户公开它们。 b.应用程序可以使用抽象的功能而不在外部创建隐式依赖项显式消费模型。 Procedures.应用程序必须限制特定ficKu的依赖关系- Be