云原生宣言

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