思科网络云原生网络功能

本文章材料来源于网络，由思科网络Cisco相关技术文档整理而成，如有侵权，联系删除

云原生原理和技术已被证明是构建和持续运行世界上最大的云的有效加速技术。思科和业内其他公司已选择这项新技术来开发下一代虚拟网络功能（VNF），称为云原生网络功能（CNF）。这些CNF在电信场所内运行时，形成私有云，并且可以有效地使用相同的公共云原理。CNF 涵盖服务提供商市场的所有分支，包括电缆、移动、视频、安全和网络基础设施。

虚拟化和 VNF 帮助我们开始转向云原生应用程序。如果操作得当，虚拟化提供了具有更高灵活性的软件模型，并消除了硬件依赖性。但是，VNF 升级速度慢、重启需要很长时间、CLI 仍然是主界面、软件通常是直接操作、OpenStack 等虚拟机管理程序难以安装、弹性很小以及扩展存在问题。

云原生应用程序解决了这些限制。云原生应用程序通常具有以下特征：

• 使用微服务体系结构（即 12 因素应用）开发
• 由 Kubernetes 风格的编排管理
• 内置微服务发现机制
• 支持动态弹性和缩放
• 弹性服务
• 提高特征速度
• 占用空间更小，重启速度快
• 持续部署和自动化原则
• 跨容器的一致生命周期管理
• 现代运行状况和状态遥测

下图描述了云原生客户的优势。

• web 规模
  • 速度：乐高应用程序创建方法缩短了上市时间，并让客户控制创新步伐。
  • 灵活性：强大的基础架构产品允许人们专注于应用程序层，在那里他们创造价值/差异化，而不是重新创建通用基础架构。
  • 效率：跨团队和业务部门的可重用服务可降低开发人员和客户的运营支出成本。
  • 改善业务成果：速度、规模和敏捷性可带来收入增长。
• 部署
  • 标准 DevOps 原则和工具用于提高功能速度以及一致的部署。
• 安全
  • 用于安全扫描和云渗透测试的云原生工具增强了对解决方案安全性的信心。
  • 较小的CNF可以独立控制订户（限制爆炸区域）而不是单片盒方法。
• 监测
  • Kubernetes、Prometheus 和 Elastic Search 等标准工具提供了容器的常见运行状况和状态。

云原生方法已在 Web 规模公司中得到验证，并显示出更高的速度、灵活性、效率和业务成果，如前所述。团队现在可以更多地关注应用程序中的业务价值，而不是基础结构。

云原生主要构造

云原生是一种构建和运行应用程序的方法，可充分利用云模型的优势。云原生应用程序利用一组工具来管理和简化组成应用程序的服务的编排。这些服务都有自己的生命周期，通过 API 连接并部署为容器。这些容器由容器调度程序编排，该调度程序管理应在何时何地将容器预配到应用程序中，并负责生命周期管理。云原生应用程序设计为可移植到不同的部署环境：例如，在公共云、私有云或混合云中。持续交付和 DevOps 是用于自动构建、验证服务并将其部署到生产网络的过程的方法。

下图描述了云原生构造：

• 微服务：一种体系结构样式，它将应用程序构造为松散耦合服务的集合，以实现业务功能。微服务通常部署在容器中，支持大型复杂应用程序的持续交付和部署。作为自动化系统的一部分，每个微服务都可以独立于应用程序中的其他服务进行部署、升级、扩展和重启，从而在不影响最终客户的情况下频繁更新实时应用程序。
• 器皿：容器是另一种形式的虚拟化，使用操作系统 （OS） 级别的虚拟化。单个操作系统实例在一个或多个隔离容器之间动态划分，每个容器都具有唯一的可写文件系统和资源配额。容器可以部署在裸机和虚拟机上。部署在裸机上的容器通过消除虚拟机管理程序开销为虚拟机提供性能优势。尽管每个微服务通常部署在单独的容器中，但每个容器可以部署多个微服务以满足应用程序和性能要求，例如，当服务的共置在逻辑上简化设计时，或者当服务在容器中分叉多个进程时。
• 持续交付：使单个应用程序更改准备就绪后立即准备好发布，而无需等待与其他更改捆绑到版本或事件（如维护时段）中。持续交付使发布变得简单可靠，因此组织可以频繁交付，风险更低，并得到最终用户的即时反馈。服务提供商如此频繁地使用软件的方式将彻底改变上市速度。最终，部署成为业务流程和企业竞争力不可或缺的一部分，利用现实世界中的金丝雀和A / B测试，而不是人工实验室。
• 开发运营：DevOps 是利用精益和敏捷技术将开发和运营整合到单个 IT 价值流中。DevOps 使组织能够通过应用持续集成和交付，以更快速、更迭代的方式构建、测试和发布软件。例如，DevOps 支持在隔离的生产环境中自动部署和验证新的软件功能，然后在证明后可以更广泛地将其推广到生产环境中。为了完全实现DevOps，服务提供商必须采用云原生技术，建立自动化的持续集成，并与供应商一起交付管道。

服务提供商希望通过自动化和简化其网络运营来降低运营支出，从而加快服务上市时间，并在广泛的云环境中进行部署。云原生技术为构建实现这些目标的应用程序提供了基本的构建块。

云原生的优势：

云原生架构有很多好处。以下部分介绍了将云原生原则应用于 CNF 的主要优势和最佳实践，以进一步定义思科的进展和战略。

分布式微服务

扩展前面的讨论，微服务是组件化的、可重用的软件模块，为客户和开发组织带来了许多好处。微服务通过 API 向应用程序公开较小的离散函数。API 进行维护和版本控制，并促进微服务在其他应用程序中的重用。例如，控制平面的微服务用于许多不同的应用程序。微服务 API 通常通过 RESTful 接口或通过消息总线公开，这允许每个服务选择可用于客户端操作的最佳技术。例如，Java 可用于控制平面服务，Go 可用于数据平面服务。这种组件化允许开源技术更容易集成到应用程序中，或者随着应用程序的发展而交换为不同的技术。

轻巧的占地面积

容器是虚拟化应用程序进程或进程集的一种方式，本质上是轻量级的，因为与虚拟机不同，操作系统在容器之间共享。在生命周期操作期间启动和升级容器时，可以实现显著的性能改进。容器可以部署在具有基本 Linux 操作系统的裸机上，也可以部署在驻留在虚拟机监控程序之上的虚拟机上。尽管在虚拟机上运行时容器的某些优势有限，但大多数实例不需要针对生命周期事件升级虚拟机。例如，在生命周期事件中升级软件容器不需要升级虚拟机。

服务发现

服务发现是云原生堆栈的主要组件之一，用于为所有可用服务提供实时服务注册表。服务注册表使新服务能够动态编排到应用程序中。如果服务不可用并且必须恢复服务，则服务将通过 Kubernetes 自动扩展和恢复。

生命周期管理

迁移到容器化微服务的主要好处之一是能够编排容器，以便可以将单独的生命周期管理流程应用于每个服务。这允许单独对每个服务进行版本控制和升级，而不是升级整个应用程序或虚拟机映像。升级应用程序时，容器调度程序确定哪些单独的服务已更改，并仅将这些特定服务部署到更广泛的应用程序中。当使用适当级别的状态分离实现应用程序时，此过程允许对组成应用程序的容器进行全自动的服务中升级和回滚。

状态分离

云原生应用程序中最常商定的设计模式之一是有状态（也称为后备服务）和无状态服务的干净分离。包含功能逻辑（数据库、文件系统或缓存）的应用程序服务应与有状态服务分开。例如，处理创建会话请求的服务实现用于创建会话的逻辑，但将会话信息存储在单独的有状态服务中，该服务将会话物理存储到内存或磁盘。这允许无状态应用程序服务自主、轻量级、可升级、可恢复和可快速扩展。

有状态服务更具挑战性，因为状态的实际存储位置和方式：例如，在文件系统上、内存中或云存储文件系统中。有状态服务必须解决状态的可用性、一致性和可移植性问题，这通常需要跨一个或多个容器进行复制，同时确保保持状态的一致性。

可用性和复原能力

云原生应用程序通过跨无状态应用程序容器的服务发现和负载均衡事务，本质上为高可用性和复原能力提供支持。此外，由于容器是轻量级的，因此恢复时间远少于恢复整个虚拟机、物理盒或应用程序的时间。这允许更快、更精细地响应故障事件。

仅靠容器编排无法解决高可用性问题，并且在大多数情况下，应用程序本身具有复原能力要求。有状态服务（如弹性数据库）需要的复原能力超出了云原生体系结构的固有功能，这需要状态同步和数据完整性。此外，协议服务需要在协议级别定义的特定故障转移和可用性机制。

运营优势

从根本上说，在裸机上运行的容器化应用程序的性能优于在虚拟机上运行的应用程序，因为没有虚拟机监控程序的开销。由于容器占用空间轻量级，因此实例化或恢复服务的速度得到了优化。由于虚拟机实例化包括基础操作系统和磁盘资源，因此预配过程可能需要几分钟，而容器实例化可能需要几秒钟。当容器部署在虚拟机之上（例如，在 CNF 架构中）并且虚拟机管理程序开销仍然存在时，仍然存在许多运营优势，因为容器具有与虚拟机不同的生命周期。例如，软件升级或恢复可能不需要实例化新的虚拟机。因此，由于容器是轻量级的，因此启动、恢复和升级服务的好处要快得多。

可扩展性

容器化架构支持独立缩放每个微服务。根据 KPI 指标监视每个容器，使业务流程计划程序能够缩放/缩减单个容器。当新容器启动以进行扩展时，它们会在服务发现层中注册自己，并自动编排到更广泛的应用程序中。负载均衡用于透明地添加新容器实例，而不会影响依赖于该容器的容器。

组件技术堆栈

思科® CNF 应用通常遵循的模型。本节的其余部分将进一步总结每个主要领域，从顶部开始向下。

自动化和常用功能

客户希望思科 CNF 在应用之间以一致的方式运行，因此需要：

• 用于云原生容器管理的一致开放框架
• 能够从思科轻松部署和更新云原生容器
• 在整个客户的 VNF 生命周期中了解容器部署情况
• 在云和客户本地部署思科 CNF 容器的固有安全性
• 跨思科部署 CNF 的标准方法
• 一键式部署选项，方便客户使用
• 能够通过 API 完成所有操作

为了满足这些期望，思科在其容器结构中使用了通用的 Helm 图表格式。此结构包含所有部署信息以及 Kubernetes 部署说明。通过让每个容器遵循一致的图表结构，如果需要，客户可以更轻松地将容器集成到其云原生 CD 系统中。

对于希望使用思科部署的思科客户，部署用户界面/API 提供了更高级别的部署功能。思科正在使用Spinnaker等工具，该工具提供了一个框架，可以通过简单的操作工具大规模管理分布式部署。Spinnaker 和 Helm 等部署工具提供了以下优势：

• 多云位置：应用程序可以驻留在多个位置，包括私有数据中心和具有多个云提供商的云中。
• 自动发布：创建运行集成和系统验证、启动和关闭容器以及监视推出的部署管道。管道（即工作流）可以从事件触发。
• 能够构建部署最佳实践：创建和部署不可变映像，以便更快、更轻松地回滚并消除难以调试的配置偏移问题。内置部署策略，如红/黑和金丝雀。
• 通过自动化验证：包括以确保成功部署。

控制以及用户和数据平面微服务

思科提供控制平面和数据平面微服务。这些微服务通常通过 Kafka 消息进行通信，以实现控制到数据平面的交互，并通过专用接口进行通信，以便在延迟很重要的情况下进行高速数据传输。思科的微服务用于上游和下游数据处理以及直径路由等网络领域。配置通过 Etcd 等产品提供。

后面的部分详细介绍了有关控制和数据平面以及电缆和移动用例的更多信息。

云原生服务

提供的云原生服务来自标准的云原生计算基础 （CNCF） 通用堆栈。我们通常将服务分为以下几个方面：

• 消息：使用卡夫卡的消费者和生产者。
• 数据存储：团队主要使用Mongo或Cassandra作为后备存储。
• 安全： 保管库用于使用 M-TLS 进行加密的证书存储。
• 伐木：典型的ELK堆栈与fluentd一起使用。
• 配置：蚀刻。
• 健康和状态：普罗米修斯与格拉法纳一起使用。
• 服务网格：伊斯蒂奥。
• 配器：Kubernetes 和 Docker 容器。

容器快速组网

基本容器网络使用 CNI 实施，如 Weave、Flannel、Cisco Contiv-VPP 等。

容器和外部网络之间的高速数据平面交互需要多个网络来实现 CNF 功能。思科凭借自己的高速数据平面应用在这一领域脱颖而出：例如 FD.io 和矢量数据包处理（VPP）。思科的方法利用容器的低开销，使用云原生技术构建网络功能，使其在与应用相同的网络和用户空间中运行，从而提供更高的性能。网络功能成为服务拓扑的一部分。网络功能实际上只是另一种服务，可以使用与具有相同速度的应用程序相同的工具来开发和部署。思科软件使用用户空间而不是内核，具有升级的便利性和速度、更少的系统呼叫开销以及减少对 Linux 网络的依赖等优势。技术使用情况 FD.io（VPP 数据平面）、DPDK（网络）和 SPDK（存储）。

VPP 平台是一个可扩展的框架，可提供开箱即用的生产质量交换机/路由器功能，这些功能可以在商用 CPU 上运行。VPP 的主要优点是其高性能、成熟的技术、模块化和灵活性以及丰富的功能集。该框架允许任何人插入新的图形节点，而无需更改核心或内核代码。VPP 支持云原生架构，能够作为 Docker 容器化解决方案的一部分进行编排。VPP 已在当今的许多网络中得到验证，是多种思科虚拟化网络功能的基础。

此外，思科数据平面容器使用 Go 语言代理来访问 VPP。这个Go语言库是由思科通过Ligato程序开源的。Ligato （github.com/ligato） 提供了一种机制，用于交付和管理云原生网络功能的代理，使它们能够成为应用程序服务拓扑的一部分，所有这些都在用户空间中。

为了集成CNI交互和高速数据平面交互，思科开发了与VPP集成的Contiv，以抽象容器连接和网络。Contiv 是面向 Kubernetes 的基于用户空间的高性能高密度网络插件，然后使用 FD.io/VPP 作为业界性能最高的数据平面。包括的功能包括将 IP 地址分配给与网络相关的 Pod （IPAM） 及其使用的底层基础架构（Linux TCP/IP 堆栈、OVS、VPP 等）的编程，以将 Pod 连接到群集中的其他 Pod 和/或外部世界。它还实现了 K8s 网络策略，这些策略定义了哪些 Pod 可以相互通信。

基础设施

思科云原生应用可在裸机以及基于虚拟机的环境中运行。思科提供思科UCS®裸机基础设施以及思科容器平台提供的云管理基础设施。思科选择Kubernetes作为其通用容器编排平台。思科通过思科容器平台提供托管 Kubernetes 服务，以确保为 CNF 提供安全可靠的平台。

思科容器平台是一个完全策划的轻量级容器管理平台，适用于生产级环境，由 Kubernetes 提供支持，并提供思科支持。它通过自动化以及思科的安全和网络最佳实践，降低了配置、部署、保护、扩展和管理容器的复杂性。思科容器平台（图 6）采用开放式架构构建，使用开源组件，因此您不会被任何单一供应商所束缚。它适用于本地和公有云环境。

好处是：

• 轻松管理多个集群的能力
• 安装和维护简单
• 网络和安全一致性
• 在本地和公共云中实现透明的应用程序部署
• 持久存储

思科容器平台将在裸机即服务上为Kubernetes提供支持。它将执行裸机硬件启动，包括操作系统的安装、系统的配置以及 Kubernetes 的后续部署。可以按需启动其他 Kubernetes 集群。为了支持混合世界，将支持OpenStack和VMware。

思科容器平台提供各种模式来直接支持云原生，以及从虚拟机到虚拟机和容器共存的容器（混合模式）的过渡。

思科容器平台将通过将前面提到的Contiv-VPP/Ligato工作本地集成到Kubernetes部署中来支持容器网络。通过这种方式，可以支持典型的基于 CNI 的容器网络以及高速网络用例，所有这些都由通用策略控制。

分布式电信云需求

基于容器的CNF系统将需要支持从数据中心到边缘的分布式电信云。容器将通过Contiv-VPP/Ligato框架映射到外部网络，该框架将支持DC互连（DCI）、虚拟路由器和虚拟交换机等领域的外部连接要求。思科正在积极研究容器快速网络的架构和技术方面，以及如何通过服务提供商WAN使网络架构成为更广泛的网络结构的一部分。此外，正在讨论与 SR-IOV 的互通，以及 CNF/VNF 链接用例中基于容器到虚拟机的互通。此体系结构考虑了多站点部署模型中的故障域注意事项，以及 MPLS/SR 与 TOR 的连接、MPLS/SR 与主机交换机的连接以及 MPLS/SR 与 CNF 的连接。

网络的不同区域对于放置很重要。图 7 显示了通过数据中心对边缘的较小环境的支持，以及跨所有环境对云原生技术的需求。

MANO集成

云优先的公司可能会在可能的情况下将公共云用于新应用程序，但由于延迟要求和数据包速率需求以及数据主权、合规性和其他需求，他们将在必要时使用私有云。在过渡过程中，公司将处于混合云模式一段时间。客户将拥有分布在公共云中的应用程序，这些应用程序通过与本地系统的专用连接进行访问。思科拥有深厚的网络背景，是帮助优化流量模式、保护交互、降低成本和提供灵活性的合适供应商。

在类似的类比中，混合世界正在推动基于容器的系统与虚拟机/裸机工作负载共存的需求，同时使用通用编排。这包括驱动VNF/CNF互通的混合虚拟机/容器系统。由于大多数服务提供商目前正在部署基于虚拟机上运行的VNF的NFV云解决方案，因此思科的云原生策略可以在NFV MANO架构中的虚拟机之上得到支持，如前所述，并且仍然具有显着的优势，因为它使用的是云原生自动化技术。将动态发现和容器调度等云原生技术集成到 CNF 中时，这种集成依赖关系将得到简化。

这些选项将需要云原生网络功能来支持许多部署管道集成，例如NFV管理和组织（MANO），开放式网络自动化平台（ONAP），重新架构为数据中心（CORD）的中央办公室，以及在裸机和虚拟机上运行的公共和私有云。

云原生应用程序支持增强级别的可移植性到多个部署管道，并具有满足这些要求所需的持续集成和部署功能。

思科 CNF 实施示例

云原生宽带路由器CNF

思科有线团队正在使用云原生技术将云原生虚拟化应用于CMTS DOCSIS技术。这项变革性工作能够更有效地管理和部署有线网络。这项工作被称为云原生宽带路由器。

与基于硬件的系统相比，新系统将控制和数据计划功能分离到微服务中，这些微服务可以分离并最终在混合云中运行。有线电视运营商和硬件供应商已经认识到云原生虚拟化的潜力，并生产了云原生虚拟化CMTS/CCAP系统的早期产品。这个概念很简单。执行繁重的路由流量和管理调制解调器的CMTS/CCAP处理组件被移动到在裸机或虚拟机上运行的虚拟化环境中。云原生 CNF 从根本上说是一个负载共享分布式系统。如果任何组件发生故障，可以通过 Kubernetes 编排将其负载移动到不同的地方。此外，纵向扩展或缩减可以使用相同的负载共享和分配系统，在这方面，故障只是“强制缩减”的情况。

电缆的云原生环境包括现代部署技术，例如一键点击、金丝雀测试和红/黑测试，允许对生产软件进行滚动更新。它还结合了用于运行状况和状态以及日志记录的云原生技术。将CMTS分解为云原生堆栈提高了Web和业务应用程序空间中的可靠性，可扩展性和功能速度，从而：

• 彻底改变基于电缆的软件开发和运营
• 通过生产中测试 （CI/CD） 实现快速服务开发和部署
• 实现弹性和弹性的资源扩展和持续服务升级
• DevOps 和自动化移动（大规模，低运营开销）
• 将相关的应用级概念应用于实时 DOCSIS 系统软件
• 根据需要公开现代 Web 原生界面，以简化整个系统并利用流式遥测等现代技术
• 加快实现真正的 DevOps，促进有线电视运营商的运营转型

体系结构抽象如下。它利用思科在重要技术领域的深厚专业知识和 DOCSIS 领导地位，以及在完整云原生堆栈方面的专业知识。它包括用于软件数据平面容器网络和编排以及微服务框架和生命周期管理的 VPP。所有这些都通过Ligato（ligato.io）基础设施变得更容易使用。

移动式数控

服务提供商希望通过将网络功能移近边缘来分解网络：移动边缘计算（MEC）。MEC 的一个例子是在控制用户平面分离 （CUPS） 架构中，其中移动核心的用户平面功能被移动到网络边缘，而控制平面则集中部署。由于这些用例，服务提供商需要灵活地在许多部署环境中部署网络功能。这些环境包括公有云、私有云和混合云。云原生技术提供了一组更丰富的基础架构和工具来实现这种级别的自动化。

思科超级服务平台 （USP） 为思科移动核心功能（包括用户平面和网关控制平面功能）以及策略、计费和用户数据管理功能提供符合 NFV 标准的通用平台。思科 USP 正在不断发展，以支持云原生网络功能。作为这一演变的一部分，Cisco VNF 被分解为多个微服务并部署为容器，然后每个微服务都可以根据移动运营商的业务需求独立扩展、升级和部署。USP 提供了一个通用的云原生平台，使思科能够将其移动 CNF 套件作为单个应用程序或作为端到端移动核心在各种云环境中交付，确保降低服务提供商运营支出和交付移动用例所需的自动化和简单性。

这项工作的结果是一套部署为 Docker 容器的微服务，并与通用的云原生管理堆栈集成，该堆栈可以作为单个 CNF 编排，也可以作为作为集成移动核心解决方案运行的多个 CNF 进行编排。

同样，思科向云原生的演变也在今天实现，发布了部署在云原生架构上的思科策略和计费规则功能（PCRF）和直径路由代理（DRA）应用，该架构利用具有集成容器编排和调度的Docker容器;服务发现;以及生命周期管理，例如自动缩放、升级/回滚和高可用性。移动数据平面是使用 VPP 技术开发的。

下图抽象了一般的移动CNF架构。

总结：

云原生原则和技术将帮助服务提供商实现网络规模。虚拟化和 VNF 帮助我们开始转向云原生应用程序，而云原生继续这一旅程。服务提供商必须完全自动化网络的部署和操作。在网络中实现云原生有一些特定的注意事项，这些注意事项并非基于 Web 的云原生解决方案所固有的，例如用户平面和协议注意事项。思科拥有确保从VNF到CNF平稳过渡的基础技术和经验。思科的云原生战略引入了一种新型技术租户，包括微服务、容器、编排、持续集成和部署以及 DevOps。这些租户及其底层设计结构和优势使 CNF 能够完全自动化和操作，以最大限度地提高自动化和编排，以实现新的收入机会和用例。思科实现云原生应用转型的方法正在顺利进行。