CN117640389A - 云原生路由器的意图驱动配置 - Google Patents

Abstract

总体上描述了用于利用编排平台的配置框架来配置实现针对云原生SDN架构中的容器化网络路由器的控制平面的软件的技术。在一个示例中，一种方法包括：由执行容器化路由协议过程的服务器接收从由自定义资源控制器管理的网络资源配置对象生成的配置数据；由服务器利用配置数据来配置容器化路由协议过程；并且由容器化路由协议过程基于从网络资源配置对象生成的配置数据来对虚拟路由器数据平面进行编程以转发网络业务。

Description

云原生路由器的意图驱动配置

本申请要求2022年12月28日提交的美国专利申请号18/147,599和2022年8月25日提交的美国临时专利申请号63/373,523的权益；每个申请的全部内容通过引用并入本文。

技术领域

本公开涉及虚拟化计算基础设施，并且更具体地涉及云原生联网。

背景技术

在传统的云数据中心环境中，存在大量互连服务器的集合，其提供计算和/或存储容量以运行各种应用。例如，数据中心可以包括为订户(即数据中心的客户)托管应用和服务的设施。例如，数据中心可以托管所有基础设施装备，诸如联网和存储系统、冗余电源和环境控制。在传统的数据中心中，存储系统和应用服务器的集群通过由一层或多层物理网络交换机和路由器所提供的高速交换结构而互连。更复杂的数据中心提供遍布世界的基础设施，其中用户支持装备位于各种物理托管设施中。

虚拟化数据中心正在成为现代信息技术(IT)基础设施的核心基础。特别地，现代数据中心已经广泛地利用了虚拟化环境，其中在物理计算设备的底层计算平台上部署和执行诸如虚拟机或容器之类的虚拟主机，在本文中也被称为虚拟执行元件。

数据中心或包括一个或多个服务器的任何环境内的虚拟化可以提供若干优势。一个优势是虚拟化可以显著提高效率。随着每个物理CPU具有大量核心的多核微处理器架构的出现，底层物理计算设备(即服务器)变得越来越强大，虚拟化变得更加容易和高效。第二个优势是：虚拟化提供了对计算基础设施的重要控制。随着物理计算资源成为可替代资源，诸如在基于云的计算环境中，计算基础设施的供应和管理变得更加容易。因此，企业IT员工通常更喜欢数据中心中的虚拟化计算集群是因为除了虚拟化所提供的效率和更高的投资回报率(ROI)之外还有它们的管理优势。

容器化是一种基于操作系统级虚拟化的虚拟化方案。容器是轻量级和可移植的执行元件，用于相互隔离并与主机隔离的应用。由于容器与主机硬件计算环境不紧密耦合，因此应用可以被绑定到容器映像并作为单个轻量级包在支持底层容器架构的任何主机或虚拟主机上被执行。如此，容器解决了如何使软件在不同的计算环境中工作的问题。容器提供了从一个计算环境到另一个虚拟或物理计算环境一致地运行的承诺。

由于容器固有的轻量级性质，与传统虚拟机(VM)相比，单个主机常常可以支持更多的容器实例。通常是短暂的容器可以比VM更有效地被创建和移动，并且它们也可以作为逻辑相关元件的群组来进行管理(对于某些编排平台(例如，Kubernetes)，有时被称为“网荚”)。这些容器特性影响了对容器联网解决方案的要求：网络应该是敏捷的和可扩展的。VM、容器和裸机服务器可能需要共存于同一个计算环境中，并在不同的应用部署之间实现通信。容器网络也应该是不可知的，以便与被用来部署容器化应用的多种类型的编排平台一起工作。

管理应用执行的部署和基础设施的计算基础设施可以涉及两个主要角色：(1)编排——用于在主机集群上自动化应用的部署、缩放和操作并且提供计算基础设施，其可以包括以容器为中心的计算基础设施；(2)网络管理——用于在网络基础设施中创建虚拟网络，以实现在虚拟执行环境(诸如容器或VM)上运行的应用之间以及在传统(例如物理)环境中运行的应用之间的分组化通信。软件定义联网有助于网络管理。

发明内容

总体上描述了用于利用编排平台的配置框架来配置实现云原生SDN架构中的容器化网络路由器的控制平面的软件的技术。云原生路由器(CNR)使用容器化路由协议守护进程(cRPD)控制平面和虚拟路由器数据平面来以较小占用空间的软件包递送高性能联网，该软件包在功能上类似于物理(即非虚拟)路由器(即，物理网络功能(PNF))。

CNR可以被并入到它所驻留在其上的主机中并且可以利用Kubernetes来进行部署/集成。由于CNR本身是云原生应用，所以它支持使用Kubernetes清单或Helm Charts的安装。这些包括路由器的初始配置，包括路由协议和第3层VPN。CNR可以在几秒钟内协调和配置所有与网络其余部分相邻的路由协议。在一些情况下，cRPD软件可能是从最初开发的软件移植而来，作为用于物理路由器的控制平面来操作，并暴露传统上被用来管理物理路由器的接口。通过暴露适当的设备接口，CNR可以将自身作为虚拟设施的操作模型规范化为物理设施的操作模型，从而消除在运营商的网络操作环境内采用的障碍。CNR可以向任何经训练的操作团队呈现熟悉的路由设施外观。CNR具有与基于硬件的平台类似的特征和能力，以及类似的操作模型。同样，域控制器可以使用它与对应物理路由器一起使用的协议来与CNR进行通信并控制CNR，例如使用Netconf/OpenConfig、gRPC、路径计算元件协议(PCEP)、命令行接口(CLI)和可编程路由守护进程(pRPD)API。但是，这些接口可能无法适应网络编排，没有IP地址管理(IPAM)，并且不支持协调特征。特别地，CLI通常将是专有的，并且仅针对特定厂商所开发的CNR是可操作的。此外，虽然cRPD的CLI可能成熟且功能丰富，但是其联网结构和语法可能不是针对通用联网而抽象的，而是特定于为其开发的物理路由器的。

在本公开的各个方面，系统利用SDN架构系统配置平面来编排cRPD配置。针对SDN架构系统配置平面限定的自定义资源(诸如BGP路由器、子网和路由实例的自定义资源)作为通用网络资源被并入到意图模型中，并经由扩展编排系统实现SDN架构系统配置平面的自定义API服务器而使其可用。

用户可以通过引用通用网络资源来创建网络资源配置对象从而创建用于网络编排的基于意图的规范。在一些方面，为控制和配置cRPD软件而开发的自定义控制器具有协调器，该协调器观察自定义API服务器上的网络资源的变化，并向在主机上运行并已订阅到cRPD自定义控制器中的网络资源对象的相关cRPD代理提供网络资源配置。分离的cRPD自定义控制器是中介，并且通过防止自定义API服务器由于成千上万的主机代理直接在自定义API服务器上观察网络资源变化而成为瓶颈，促进了可扩展性。驱动程序将抽象网络资源配置转换为符合cRPD的传统数据模型的配置数据，并将配置数据推送到主机上的cRPD以配置CNR控制平面。并行地，SDN架构系统的网络控制器可以提供虚拟路由器(数据平面)以实现数据平面中的意图——在一些情况下也由网络资源来限定。

这些技术在一些方面可以被用来配置物理网络设施的控制平面，诸如路由器和网络交换机、防火墙、网络地址转换(NAT)设备、负载均衡器、网关或其他设备。此类物理设施还可以具有可使用接口来进行配置的基于软件的控制平面，诸如上面为cRPD所列出的那些。与上述cRPD解决方案类似，可以为每个设备开发自定义控制器，以将设备的配置协调为用于网络编排的基于意图的规范，所有这些都使用通过自定义API服务器驱动的用于编排系统(例如，Kubernetes)的公共配置平面。作为此扩展的结果，Kubernetes意图模型可以成为数据中心中的覆盖和底层的通用模型。

这些技术可以提供一个或多个技术优势，这些优势解决了配置实现用于云原生SDN架构中的容器化网络路由器的控制平面的软件的客观技术问题。例如，这些技术将基于意图的网络资源转换为cRPD软件中的低级联网配置资源，以统一和简化网络编排。与SDN架构系统的其他方面一样，cRPD现在可以使用本公开的技术使用统一的意图模型来进行配置。利用意图驱动的配置模型(诸如由Kubernetes提供的配置模型)还可以不断地将实际状态协调为预期状态。也就是说，对网络资源的改变由cRPD自定义控制器和cRPD代理自动地应用于相关的cRPD。上述优势也可以应用于这些技术的扩展，以用于为其他网络设备配置控制平面。

此外，将CNR部署作为计算集群的CNI，该计算集群具有为SDN架构系统开发的配置平面但是使用基于分布式cRPD的控制平面，可能会在供应工作流中引入不和谐。具有原生Kubernetes集成的SDN架构系统具有基于意图的模型，以用于利用虚拟路由器(数据平面)和应用(网荚)来集中地编排虚拟网络，但是使用本文所描述的技术允许基于意图的模型扩展到配置CNR控制平面，而无需了解CLI或CNR的配置数据模型。

在一个示例中，一种软件定义联网(SDN)架构系统包括：网络控制器，该网络控制器包括处理电路和用于配置容器化路由协议过程的针对网络资源的自定义资源控制器，其中针对网络资源自定义资源的自定义资源控制器被配置用于由处理电路执行以：响应于检测到作为网络资源自定义资源的实例的网络资源配置对象的配置更新，通过向执行容器化路由协议过程的实例的服务器发送从网络资源配置对象生成的配置数据来协调网络资源配置对象的预期状态；以及该服务器，其中该服务器被配置为利用从网络资源配置对象被生成的配置数据来配置在服务器上执行的容器化路由协议过程的实例。

在一个示例中，一种方法包括：由执行容器化路由协议过程的服务器接收从由自定义资源控制器所管理的网络资源配置对象生成的配置数据；由服务器利用配置数据来配置容器化路由协议过程；并且由容器化路由协议过程基于从网络资源配置对象生成的配置数据来对虚拟路由器数据平面进行编程以转发网络业务。

在示例中，一种方法，包括：由用于网络资源自定义资源的自定义资源控制器响应于检测到作为网络资源自定义资源的实例的网络资源配置对象的配置更新来通过将从网络资源配置对象生成的配置数据发送到执行容器化路由协议过程的实例的服务器来协调网络资源配置对象的预期状态；并且利用服务器，利用从网络资源配置对象生成的配置数据来配置在服务器上执行的容器化路由协议过程的实例。

本公开的一个或多个示例的细节在附图和下面的说明书中进行阐述。其他特征、目的和优点将从说明书和附图以及权利要求中显而易见。

附图说明

图1是图示了在其中可以实现本文所描述的技术的示例的示例计算基础设施的框图。

图2是图示了根据本公开的技术的用于具有网络资源自定义资源的云原生联网的云原生SDN架构的示例的框图。

图3是根据本公开的技术更详细地图示了SDN结构200的组件的另一个视图的框图。

图4A-图4B是图示了根据本公开的技术的SDN架构的示例组件的框图。

图5是根据本公开中描述的技术的示例计算设备的框图。

图6是根据本公开的技术作为用于SDN架构系统的一个或多个集群的计算节点进行操作的示例计算设备的框图。

图7A是图示了根据本公开的技术的使用SDN架构的用于底层网络和覆盖网络配置的控制/路由平面的框图。

图7B是图示了根据本公开的技术使用在底层网络中配置的隧道来连接网荚的已配置的虚拟网络的框图。

图8是图示了根据本公开的技术的用于SDN架构配置的(多个)自定义资源的自定义控制器的示例的框图。

图9是图示了在对不同自定义资源类型具有依赖性的自定义资源类型之间创建、观察和协调的示例流程的框图。

图10是图示了根据本公开的技术的用于软件定义联网架构系统的示例操作模式的流程图。

图11是图示了根据本公开的技术的用于软件定义联网架构系统内的服务器的示例操作模式的流程图。

在整个描述和附图中，相似的参考字符标示相似的元件。

具体实施方式

图1是图示了在其中可以实现本文所描述的技术的示例的示例计算基础设施8的框图。由于例如生命周期管理的复杂性、强制性高资源分析组件、配置模块中的规模限制以及没有基于命令行接口(CLI)的(类似kubectl的)接口，用于虚拟网络的软件定义联网(SDN)架构系统的当前实现为云原生采用带来了挑战。计算基础设施8包括本文所描述的云原生SDN架构系统200，其应对这些挑战并针对电信云原生时代进行现代化。云原生SDN架构的示例用例包括5G移动网络以及云和企业云原生用例。SDN架构可以包括在计算节点(例如，服务器12)和网络设备(诸如路由器或交换机)中实现的数据平面元素，并且SDN架构还可以包括用于创建和管理虚拟网络的SDN控制器(例如，网络控制器24)。SDN架构配置和控制平面被设计为横向扩展的云原生软件，具有支持服务中升级的基于容器的微服务架构。

结果，SDN架构组件是微服务，并且与现有网络控制器相比，SDN架构假设基本容器编排平台管理SDN架构组件的生命周期。容器编排平台被用来启动SDN架构组件；SDN架构使用云原生监控工具，其可以与客户提供的云原生选项集成；SDN架构为SDN架构对象(即自定义资源)提供了一种使用聚合API的资源声明方式。SDN架构升级可能会遵循云原生模式，并且SDN架构可能会利用Kubernetes构造，诸如Multus、认证和授权、集群API、KubeFederation、KubeVirt和Kata容器。SDN架构可以支持数据平面开发工具包(DPDK)网荚，并且SDN架构可以扩展以支持具有虚拟网络策略和全局安全策略的Kubernetes。

对于服务供应商和企业，SDN架构对网络资源供应和编排进行自动化，以动态地创建高度可扩展的虚拟网络并且链接虚拟化网络功能(VNF)和物理网络功能(PNF)以按需形成差异化服务链。SDN架构可以与诸如Kubernetes、OpenShift、Mesos、OpenStack、VMwarevSphere之类的编排平台(例如，编排器23)集成，并与服务供应商操作支持系统/业务支持系统(OSS/BSS)集成。

一般来说，一个或多个数据中心10为具有一个或多个客户网络的客户站点11(被图示为“客户11”)提供用于应用和服务的操作环境，该一个或多个客户网络通过服务供应商网络被耦合到数据中心7。例如，(多个)数据中心10中的每一个都可以托管基础设施设备，诸如联网和存储系统、冗余电源和环境控制。服务供应商网络7耦合到公共网络15，公共网络15可以表示由其他供应商管理的一个或多个网络，并且因此可以形成大规模公共网络基础设施(例如，互联网)的一部分。公共网络15可以表示例如局域网(LAN)、广域网(WAN)、互联网、虚拟LAN(VLAN)、企业LAN、第3层虚拟专用网络(VPN)、由操作服务供应商网络7的服务供应商所操作的互联网协议(IP)内联网、企业IP网络或其某种组合。

尽管客户站点11和公共网络15主要被图示和描述为服务供应商网络7的边缘网络，但在一些示例中，客户站点11和公共网络15中的一个或多个可以是(多个)数据中心10中的任何一个内的租户网络。例如，(多个)数据中心10可以托管多个租户(客户)，每个租户与一个或多个虚拟专用网络(VPN)相关联，每个虚拟专用网络可以实现客户站点11中的一个。

服务供应商网络7向附接的客户站点11、(多个)数据中心10和公共网络15提供基于分组的连接性。服务供应商网络7可以表示由服务供应商所拥有和操作以对多个网络进行互连的网络。服务供应商网络7可以实现多协议标签交换(MPLS)转发并且在这种实例中可以被称为MPLS网络或MPLS骨干网。在一些实例中，服务供应商网络7表示诸如互联网之类的多个互连的自治系统，其提供来自一个或多个服务供应商的服务。

在一些示例中，(多个)数据中心10中的每一个可以表示多个地理分布式网络数据中心中的一个，这些数据中心可以经由服务供应商网络7、专用网络链路、暗光纤或其他连接而彼此连接。如图1的示例中所示，(多个)数据中心10可以包括为客户提供网络服务的设施。服务供应商的客户可以是诸如企业和政府之类的集体实体，也可以是个人。例如，网络数据中心可以为若干企业和最终用户托管web服务。其他示例性服务可以包括数据存储、虚拟专用网络、业务工程、文件服务、数据挖掘、科学计算或超级计算等。尽管被图示为服务供应商网络7的单独边缘网络，但是(多个)数据中心10的诸如一个或多个物理网络功能(PNF)或虚拟化网络功能(VNF)之类的元件可以被包括在服务供应商网络7核心内。

在该示例中，(多个)数据中心10包括经由由一层或多层物理网络交换机和路由器提供的交换结构14而与服务器12A-12X(在本文中，“服务器12”)互连的存储和/或计算服务器(或“节点”)，服务器12A-12X被描绘为耦合到架顶式交换机16A-16N。服务器12是计算设备并且在本文中也可以被称为“计算节点”、“主机”或“主机设备”。尽管在图1中仅详细示出了耦合到TOR交换机16A的服务器12A，但是数据中心10可以包括耦合到数据中心10的其他TOR交换机16的许多附加服务器。

所图示的示例中的交换机结构14包括耦合到机箱(或“脊”或“核心”)交换机18A-18M(统称为“机箱交换机18”)的分发层的互连架顶式(TOR)(或其他“叶”)交换机16A-16N(统称为“TOR交换机16”)。尽管未被示出，但是数据中心10还可以包括例如一个或多个非边缘交换机、路由器、集线器、网关、诸如防火墙之类的安全设备、入侵检测和/或入侵防御设备、服务器、计算机终端、膝上型计算机、打印机、数据库、无线移动设备(诸如蜂窝电话或个人数字助理)、无线接入点、网桥、电缆调制解调器、应用加速器或其他网络设备。(多个)数据中心10还可以包括一个或多个物理网络功能(PNF)，诸如物理防火墙、负载均衡器、路由器、路由反射器、宽带网络网关(BNG)、移动核心网络元件和其他PNF。

在该示例中，TOR交换机16和机箱交换机18向服务器12提供到IP结构20和服务供应商网络7的冗余(多宿主)连接性。机箱交换机18聚合业务流，并且提供TOR交换机16之间的连接性。TOR交换机16可以是提供第2层(MAC)和/或第3层(例如，IP)路由和/或交换功能性的网络设备。TOR交换机16和机箱交换机18可以各自包括一个或多个处理器和存储器并且可以执行一个或多个软件过程。机箱交换机18耦合到IP结构20，IP结构20可以执行第3层路由以通过服务供应商网络7来路由数据中心10和客户站点11之间的网络业务。(多个)数据中心10的交换架构仅仅是示例。例如，其他交换架构可以具有更多或更少的交换层。IP结构20可以包括一个或多个网关路由器。

术语“分组流”、“业务流”或简称为“流”是指源自特定源设备或端点并发送到特定目的地设备或端点的一组分组。单个分组流可以由5元组来标识：例如，<源网络地址，目的地网络地址，源端口，目的地端口，协议>。该五元组通常标识与接收分组相对应的分组流。n元组是指从5元组中提取的任何n项。例如，分组的二元组可以指分组的<源网络地址，目的地网络地址>或<源网络名称，源端口>的组合。

服务器12可以各自表示计算服务器或存储服务器。例如，每个服务器12可以表示计算设备，诸如基于x86处理器的服务器，其被配置为根据本文所描述的技术进行操作。服务器12可以为NFV架构提供网络功能虚拟化基础设施(NFVI)。

服务器12中的任何服务器都可以配置有虚拟执行元件，诸如网荚或虚拟机，通过虚拟化服务器的资源来提供在服务器上执行的一个或多个过程(应用)之间的某种隔离措施。“基于管理程序”或“硬件级”或“平台”虚拟化是指创建虚拟机，每个虚拟机都包括用于执行一个或多个过程的访客操作系统。一般来说，虚拟机提供用于在隔离的虚拟环境中执行应用的虚拟化/访客操作系统。因为虚拟机是从主机服务器的物理硬件虚拟化的，所以执行的应用与主机的硬件和其他虚拟机都是隔离的。每个虚拟机可以配置有一个或多个虚拟网络接口以用于在对应的虚拟网络上进行通信。

虚拟网络是在物理网络之上实现的逻辑结构。虚拟网络可以被用来取代基于VLAN的隔离并在虚拟化数据中心(例如(多个)数据中心10)中提供多租户。每个租户或应用可以具有一个或多个虚拟网络。除非安全策略明确允许，否则每个虚拟网络都可以与所有其他虚拟网络是隔离的。

虚拟网络可以使用数据中心10网关路由器(图1中未示出)来连接到物理多协议标签交换(MPLS)第3层虚拟专用网络(L3VPN)和以太网虚拟专用网络(EVPN)网络并在其间扩展。虚拟网络也可以被用来实现网络功能虚拟化(NFV)和服务链。

可以使用多种机制来实现虚拟网络。例如，每个虚拟网络都可以被实现为虚拟局域网(VLAN)、虚拟专用网络(VPN)等。虚拟网络也可以使用两个网络来实现——由IP结构20和交换结构14组成的物理底层网络和虚拟覆盖网络。物理底层网络的角色是提供“IP结构”，它提供从任何物理设备(服务器、存储设备、路由器或交换机)到任何其他物理设备的单播IP连接性。底层网络可以提供从网络中的任何点到网络中的任何其他点的统一的低时延、非阻塞、高带宽连接性。

如以下关于虚拟路由器21A-21X(被图示并且在本文中也统称为“虚拟路由器21”)进一步描述的，在服务器12中运行的虚拟路由器在物理底层网络之上创建虚拟覆盖网络——通过在它们之间使用动态“隧道”网格来实现。例如，这些覆盖隧道可以是在GRE/UDP隧道、VXLAN隧道或NVGRE隧道上的MPLS。底层物理路由器和交换机可能不存储用于虚拟机或其他虚拟执行元件的任何按租户状态，诸如任何媒体访问控制(MAC)地址、IP地址或策略。例如，底层物理路由器和交换机的转发表可能仅包括物理服务器12的IP前缀或MAC地址。(将虚拟网络连接到物理网络的网关路由器或交换机是一个例外，它们可以包括租户MAC或IP地址。)

服务器12的虚拟路由器21通常包括按租户状态。例如，它们可以包括每个虚拟网络的单独转发表(路由实例)。该转发表包括虚拟机或其他虚拟执行元件(例如，容器的网荚)的IP前缀(在第3层覆盖的情况下)或MAC地址(在第2层覆盖的情况下)。没有单个虚拟路由器21需要包括整个数据中心中的所有虚拟机的所有IP前缀或所有MAC地址。给定的虚拟路由器21只需要包括本地存在于服务器12上的那些路由实例(即，它们具有至少一个存在于服务器12上的虚拟执行元件。)

网络控制器24或物理网关路由器(或交换机)的控制平面节点之间的控制平面协议可以是BGP(并且也可以是用于管理的Netconf)。这是相同的控制平面协议也可以被用于MPLS L3VPN和MPLS EVPN。网络控制器24与虚拟路由器21之间的协议例如可以基于XMPP。

“基于容器的”或“操作系统”虚拟化是指操作系统的虚拟化，以在(虚拟的或物理的)单个机器上运行多个隔离系统。此类隔离系统表示容器，诸如由开源DOCKER Container应用或由CoreOSRkt(“Rocket”)提供的容器。就像虚拟机一样，每个容器被虚拟化，并且可以与主机机器和其他容器保持隔离。然而，与虚拟机不同的是，每个容器都可以省略个体操作系统，而是改为提供一个应用套件和特定于应用的库。一般来说，容器作为隔离的用户空间实例而由主机执行，并且可以与在主机上执行的其他容器共享操作系统和公共库。因此，容器可能需要比虚拟机更少的处理能力、存储和网络资源。一个或多个容器的群组可以被配置为共享一个或多个虚拟网络接口，以用于在对应的虚拟网络上进行通信。

在一些示例中，容器由它们的主机内核进行管理以允许资源(CPU、存储器、块I/O、网络等)的限制和优先化而不需要启动任何虚拟机，在一些情况下使用名称空间隔离功能性，该功能性允许对应用的操作环境视图进行完全隔离，包括过程树、联网、用户标识符和安装的文件系统。在一些示例中，可以根据Linux容器(LXC)来对容器进行部署，这是一种操作系统级的虚拟化方法，用于使用单个Linux内核在控制主机上运行多个隔离的Linux系统(容器)。

服务器12托管用于在此处由IP结构20和交换结构14表示的物理网络上运行的一个或多个虚拟网络的虚拟网络端点。尽管主要关于基于数据中心的交换网络进行描述，但是其他物理网络，诸如服务供应商网络7，可以在一个或多个虚拟网络之下。

每个服务器12可以托管一个或多个虚拟执行元件，每个虚拟执行元件具有用于在物理网络中配置的一个或多个虚拟网络的至少一个虚拟网络端点。用于虚拟网络的虚拟网络端点可以表示共享用于虚拟网络的虚拟网络接口的一个或多个虚拟执行元件。例如，虚拟网络端点可以是虚拟机、一组一个或多个容器(例如，网荚)或(多个)另外虚拟执行元件，诸如虚拟网络的第3层端点。术语“虚拟执行元件”包括虚拟机、容器和其他为应用提供至少部分独立的执行环境的虚拟化计算资源。术语“虚拟执行元件”还可以涵盖一个或多个容器的网荚。虚拟执行元件可以表示应用工作负载。如图1中所示，服务器12A以具有一个或多个容器的网荚22的形式托管一个虚拟网络端点。然而，给定服务器12的硬件资源限制，服务器12可以执行尽可能多的虚拟执行元件。每个虚拟网络端点可以使用一个或多个虚拟网络接口来执行分组I/O或以其他方式处理分组。例如，虚拟网络端点可以使用由NIC 13A所启用的一个虚拟硬件组件(例如，SR-IOV虚拟功能)来执行分组I/O并在与TOR交换机16A的一个或多个通信链路上接收/发送分组。下面描述了虚拟网络接口的其他示例。

服务器12各自包括至少一个网络接口卡(NIC)13，其各自包括至少一个接口以通过通信链路来与TOR交换机16交换分组。例如，服务器12A包括NIC 13A。NIC 13中的任一个可以为虚拟化输入/输出(I/O)提供一个或多个虚拟硬件组件21。用于I/O的虚拟硬件组件可能是物理NIC(“物理功能”)的虚拟化。例如，在外围组件接口特别兴趣小组SR-IOV规范中描述的单根I/O虚拟化(SR-IOV)中，网络接口卡(或“网络适配器”)的PCIe物理功能被虚拟化以将一个或多个虚拟网络接口呈现为“虚拟功能”以供在服务器12上执行的各个端点使用。以这种方式，虚拟网络端点可以共享相同的PCIe物理硬件资源并且虚拟功能是虚拟硬件组件21的示例。作为另一个示例，一个或多个服务器12可以实现Virtio，这是一种例如可用于Linux操作系统的半虚拟化框架，它提供模拟NIC功能性作为一种虚拟硬件组件，以向虚拟网络端点提供虚拟网络接口。作为另一个示例，一个或多个服务器12可以实现OpenvSwitch以在用于被托管虚拟机的一个或多个虚拟NIC(vNIC)之间执行分布式虚拟多层交换，其中这样的vNIC也可以表示将虚拟网络接口提供到虚拟网络端点的一种虚拟硬件组件。在一些实例中，虚拟硬件组件是虚拟I/O(例如NIC)组件。在一些实例中，虚拟硬件组件是SR-IOV虚拟功能。在一些示例中，服务器12中的任何服务器可以实现Linux网桥，其模拟硬件网桥并且在服务器的虚拟网络接口之间或者在服务器的虚拟网络接口和服务器的物理网络接口之间转发分组。对于由服务器托管的容器的Docker实现，在容器之间交换分组的在服务器上执行的Linux网桥或其他操作系统网桥可以被称为“Docker网桥”。本文中所使用的术语“虚拟路由器”可以涵盖Contrail或Tungsten Fabric虚拟路由器、OpenvSwitch(OVS)、OVS网桥、Linux网桥、Docker网桥或位于主机设备上并且在一个或多个虚拟网络的虚拟网络端点之间执行交换、桥接或路由分组的其他设备和/或软件，其中虚拟网络端点由服务器12中的一个或多个来托管。

服务器12中的一个或多个可以各自包括虚拟路由器21，虚拟路由器21为数据中心10内的对应虚拟网络执行一个或多个路由实例，以提供虚拟网络接口并在虚拟网络端点之间路由分组。每个路由实例可以与网络转发表相关联。每个路由实例可以表示用于互联网协议-虚拟专用网络(IP-VPN)的虚拟路由和转发实例(VRF)。例如，服务器12A的虚拟路由器21从数据中心10的底层物理网络结构(即，IP结构20和交换结构14)接收到的分组可以包括外部报头，以允许物理网络结构将有效负载或“内部分组”通过隧道传输到执行虚拟路由器的服务器12A的网络接口卡13A的物理网络地址。外部报头不仅可以包括服务器的网络接口卡13A的物理网络地址，还可以包括虚拟网络标识符，诸如标识虚拟网络之一以及由虚拟路由器21执行的对应路由实例的VxLAN标签或多协议标签交换(MPLS)标签。内部分组包括具有目的地网络地址的内部报头，该目的地网络地址符合用于由虚拟网络标识符所标识的虚拟网络的虚拟网络寻址空间。

虚拟路由器21终止虚拟网络覆盖隧道并基于分组的隧道封装报头来确定接收分组的虚拟网络，并将分组转发到分组的适当目的地虚拟网络端点。以下，主要针对虚拟路由器21A进行虚拟路由器的描述，但是这种描述与虚拟路由器21的其他实例相关。

针对服务器12A，例如，对于从由服务器12A托管的虚拟网络端点(例如，网荚22A-22C中的任何一个)出站的每个分组，虚拟路由器21A附加隧道封装报头，其指示分组的虚拟网络以生成封装或“隧道”分组，并且虚拟路由器21A经由用于虚拟网络的覆盖隧道将封装分组输出到物理目的地计算设备，诸如服务器12中的另一个。如本文中所使用的，虚拟路由器21A可以执行隧道端点的操作以封装源自虚拟网络端点的内部分组以生成隧道分组并对隧道分组进行解封装以获得内部分组以用于路由到其他虚拟网络端点。

在一些示例中，虚拟路由器21A可以是基于内核的并且作为服务器12A的操作系统的内核的一部分来执行。

在一些示例中，虚拟路由器21A可以是数据平面开发工具包(DPDK)启用的虚拟路由器。在这样的示例中，虚拟路由器21A使用DPDK作为数据平面。在这种模式下，虚拟路由器21A作为链接到DPDK库(未示出)的用户空间应用来运行。这是虚拟路由器的性能版本，并且通常由电信公司来使用，其中VNF通常是基于DPDK的应用。作为DPDK虚拟路由器的虚拟路由器21A的性能可以实现比作为基于内核的虚拟路由器进行操作的虚拟路由器高十倍的吞吐量。物理接口由DPDK的轮询模式驱动程序(PMD)来使用，而不是由Linux内核的基于中断的驱动程序来使用。

DPDK vRouter(DPDK虚拟路由器)的示例的附加细节可见于KiranKN等人的“DAYONE:CONTRAIL DPDK vROUTER”(2021年，Juniper网络有限公司)，其全部内容通过引用并入本文。

服务器12包括并执行容器化路由协议守护进程25A-25X(统称为“cRPD 25”)。容器化路由协议守护进程(cRPD)是一种路由协议过程，它被打包为容器，并且可以在基于Linux的环境中运行。cRPD可以作为容器化过程在主机的用户空间中被执行。因此，cRPD使基于Linux的计算节点(例如在一些情况下的服务器12)上的物理路由器的丰富路由软件谱系可用。cRPD提供控制平面功能性。这个控制平面因此被容器化。例如，cRPD 25A实现了由服务器12A执行的CNR 32A的控制平面。

同时，虚拟路由器21是在服务器12上提供数据平面功能性的软件实体。CRPD 25A可以使用由服务器12A的Linux内核为基于内核的虚拟路由器21A所提供的转发(或数据)平面。CRPD 25A可以替代地使用虚拟路由器21的DPDK启用或SmartNIC执行的实例。虚拟路由器21A可以与SDN控制器(例如，网络控制器24)一起工作，以通过交换路由、配置和其他数据来创建覆盖网络。虚拟路由器21A可以被容器化。在组合中，在一些示例中，容器化的cRPD和容器化的虚拟路由器可以是功能齐全的容器化的CNR 32A。

计算基础设施8实现了自动化平台，用于对在服务器12上的虚拟执行元件的部署、缩放和操作进行自动化，以提供用于执行应用工作负载和服务的虚拟化基础设施。在一些示例中，平台可以是编排系统。在一些情况下，编排系统是容器编排系统，其提供以容器为中心的基础设施以用于容器的自动化部署、缩放和操作以提供以容器为中心的基础设施。在虚拟化计算基础设施的上下文中，“编排”通常是指向编排平台可用的主机服务器提供、调度和管理虚拟执行元件和/或在此类虚拟执行元件上执行的应用和服务。具体而言，容器编排允许容器协调，并且指的是通过容器编排平台将容器部署、管理、缩放和配置到托管服务器。编排平台的示例实例包括Kubernetes(容器编排系统)、Docker swarm、Mesos/Marathon、OpenShift、OpenStack、VMware和Amazon ECS。

计算基础设施8的自动化平台的元件至少包括服务器12、编排器23和网络控制器24。可以使用基于集群的框架将容器部署到虚拟化环境，其中集群的集群主节点(masternode)管理将容器部署和操作到集群的一个或多个集群小节点(minion node)。在本文中所使用的术语“主节点”和“小节点”涵盖用于在集群的主要管理元素和集群的主要容器托管设备之间进行的类似设备的不同编排平台术语。例如，Kubernetes平台使用术语“集群主节点”和“小节点”，而DockerSwarm平台指的是集群管理器和集群节点。Kubernetes集群是编排系统集群的一个示例。

编排器23和网络控制器24可以在分开的计算设备上执行、在相同计算设备上执行。编排器23和网络控制器24中的每一个都可以是在一个或多个计算设备上执行的分布式应用。编排器23和网络控制器24可以为一个或多个集群实现各自的主节点，每个集群具有由各自的服务器12实现的一个或多个小节点(也被称为“计算节点”)。

一般来说，网络控制器24控制数据中心10结构的网络配置以例如建立用于虚拟网络端点之间的分组化通信的一个或多个虚拟网络。网络控制器24提供逻辑上并且在一些情况下物理上集中化的控制器，以用于促进数据中心10内的一个或多个虚拟网络的操作。在一些示例中，网络控制器24可以响应于从编排器23和/或管理员/操作员接收到的配置输入而操作。在2013年6月5日提交的题为“PHYSICAL PATH DETERMINATION FOR VIRTUALNETWORK PACKET FLOWS”的国际申请号PCT/US2013/044378和2014年3月26日提交的题为“Tunneled Packet Aggregation for Virtual Networks”的美国专利申请号14/226,509中找到了关于与数据中心10的其他设备或其他软件定义的网络一起操作的网络控制器24的示例操作的附加信息，其每一个都通过引用并入本文，如同在本文中完整阐述一样。

一般来说，编排器23控制跨服务器12集群的容器的部署、缩放和操作并提供计算基础设施，其可以包括以容器为中心的计算基础设施。编排器23以及在一些情况下的网络控制器24可以为一个或多个Kubernetes集群实现各自的集群主机。例如，Kubernetes是容器管理平台，其提供跨公共云和私有云的可移植性，每个云都可以为容器管理平台提供虚拟化基础设施。

Kubernetes使用各种Kubernetes对象(表示Kubernetes集群状态的实体)来操作。Kubernetes对象可以包括名称、名称空间、标签、注释、字段选择器和推荐标签的任意组合。例如，Kubernetes集群可以包括一个或多个“名称空间”对象。Kubernetes集群的每个名称空间都与Kubernetes集群的其他名称空间隔离。名称空间对象可以包括Kubernetes集群的组织、安全和性能中的至少一个。作为示例，网荚可以与名称空间相关联，从而将网荚与名称空间的特性(例如，虚拟网络)相关联。该特征可以使得多个新创建的网荚能够通过将网荚与一组公共特性相关联来进行组织。可以根据限定名称空间的特性的名称空间规范数据(包括名称空间名称)来创建名称空间。在一个示例中，名称空间可能被命名为“名称空间A”，并且每个新创建的网荚可以与由“名称空间A”所标示的一组特性相关联。此外，Kubernetes包括“默认”名称空间。如果新创建的网荚没有指定名称空间，则新创建的网荚可以与“默认”名称空间的特性相关联。

名称空间可以使得一个Kubernetes集群能够被多个用户、用户团队或具有多个应用的单个用户使用。此外，每个用户、用户团队或应用都可以在名称空间内与集群的每个其他用户隔离。因此，名称空间内的Kubernetes集群的每个用户都好像它是Kubernetes集群的唯一用户一样操作。多个虚拟网络可以与单个名称空间相关联。如此，属于特定名称空间的网荚有能力访问与该名称空间相关联的虚拟网络中的每个虚拟网络，包括用作虚拟网络群组的虚拟网络端点的其他网荚。

在一个示例中，网荚22A是Kubernetes网荚和虚拟网络端点的示例。网荚是一个或多个逻辑相关的容器的群组(图1中未示出)、容器的共享存储以及关于如何运行容器的选项。在为执行而实例化的情况下，网荚可以替代地被称为“网荚副本”。网荚22A的每个容器都是虚拟执行元件的示例。网荚的容器始终共同位于单个服务器上，被共同调度并在共享上下文中运行。网荚的共享上下文可以是一组Linux名称空间、cgroups和其他隔离方面。在网荚的上下文中，个体应用可能应用了进一步的子隔离。通常，网荚内的容器具有公共IP地址和端口空间，并且能够经由本地主机来相互检测。因为它们具有共享上下文，所以网荚内的容器也使用过程间通信(IPC)来相互通信。IPC的示例包括SystemV信号量或POSIX共享存储器。通常，作为不同网荚的成员的容器具有不同的IP地址，并且在没有启用此特征的配置的情况下无法通过IPC进行通信。作为不同网荚的成员的容器通常经由网荚IP地址来彼此通信。

服务器12A包括用于运行容器化应用(诸如网荚22的应用)的容器平台19A。容器平台19A从编排器23接收请求以在服务器12A中获得并托管容器。容器平台19A获得并执行容器。

容器网络接口(CNI)17A为虚拟网络端点配置虚拟网络接口。编排器23和容器平台19A使用CNI 17A来管理包括网荚22在内的容器的联网。例如，CNI 17A创建虚拟网络接口以将网荚22连接到虚拟路由器21A，并使得此类网荚的容器能够经由虚拟网络接口进行通信，通过虚拟网络而连接到其他虚拟网络端点。例如，CNI 17A可以将虚拟网络的虚拟网络接口插入到网荚22A中的容器的网络名称空间中，并在虚拟路由器21A中配置(或请求配置)虚拟网络的虚拟网络接口，使得虚拟路由器21A被配置为经由虚拟网络接口将从虚拟网络接收的分组发送到网荚22A的容器，并且发送经由虚拟网络接口从虚拟网络上的网荚22A的容器接收的分组。CNI 17A可以指派网络地址(例如，虚拟网络的虚拟IP地址)并且可以为虚拟网络接口设置路由。在Kubernetes中，默认情况下所有网荚都可以在不使用网络地址转换(NAT)的情况下与所有其他网荚通信。在一些情况下，编排器23和网络控制器24创建由所有名称空间共享的服务虚拟网络和网荚虚拟网络，分别从中分配服务和网荚网络地址。在一些情况下，在Kubernetes集群中生成的所有名称空间中的所有网荚可能能够相互通信，并且所有网荚的网络地址可以从编排器23指定的网荚子网中被分配。当用户为网荚创建隔离名称空间时，编排器23和网络控制器24可以为新的隔离名称空间创建新的网荚虚拟网络和新的共享服务虚拟网络。在Kubernetes集群中生成的隔离名称空间中的网荚从新的网荚虚拟网络中提取网络地址，并且这些网荚的对应服务从新的服务虚拟网络中提取网络地址

CNI 17A可以表示库、插件、模块、运行时或服务器12A的其他可执行代码。CNI 17A可以至少部分符合容器网络接口(CNI)规范或rkt联网提案。CNI 17A可以表示Contrail、OpenContrail、Multus、Calico、cRPD或其他CNI。CNI 17A可以替代地被称为网络插件或CNI插件或CNI实例。例如，可以由Multus CNI调用分开的CNI来为网荚22建立不同的虚拟网络接口。

CNI 17A可以由编排器23调用。出于CNI规范的目的，容器可以被认为与Linux网络名称空间同义。这对应什么单元取决于特定的容器运行时实现：例如，在诸如rkt之类的应用容器规范的实现中，每个网荚都运行在唯一网络名称空间中。然而，在Docker中，通常针对每个单独的Docker容器而存在网络名称空间。出于CNI规范的目的，网络是指可唯一寻址并且可以彼此通信的实体群组。这可以是个体容器、机器/服务器(真实的或虚拟的)或其他一些网络设备(例如，路由器)。容器可以在概念上被添加到一个或多个网络或从其中被移除。CNI规范为符合的插件(“CNI插件”)指定了数个注意事项。

因为cRPD 25A是云原生应用，所以它可以支持使用Kubernetes清单或HelmCharts的安装。这包括cRPD 25A的初始配置作为CNR 32A的控制平面，包括路由协议和一个或多个虚拟专用网络的配置。cRPD可以在几秒钟内被编排和配置，其中与网络其余部分的所有路由协议邻接都已启动并运行。根据本公开的技术，在cRPD 25A的生命周期内正在进行的配置更改可以经由网络控制器24进行，其在一些示例中可以通过CLI、Kubernetes清单、NetConf或Terraform或其他管理协议来进行补充。

通过在一些示例中采用Kubernetes CNI框架，CNR 32A可以减轻在使用容器化设施而不是其物理对应物时招致的传统操作开销。通过暴露适当的设备接口，CNR 32A可以将虚拟设施的操作模型规范化为物理设施，从而消除在运营商的网络操作环境内采用的障碍。CNR 32A(并且更具体地说，是与cRPD 25A的接口)可以为任何经训练的操作团队提供熟悉的路由设施外观和感觉。CNR 32A具有与基于硬件的平台类似的特征和能力以及类似的操作模型。同样，在一些情况下，域控制器可以使用它与任何其他路由器一起使用的协议来与CNR 32A通信并控制CNR 32A，例如Netconf/OpenConfig、gRPC、路径计算元件协议(PCEP)或其他接口。

CNR 32A实际上是虚拟化路由器并且可以参与IS-IS、开放最短路径优先(OSPF)、BGP和/或其他内部或外部路由协议并且与其他路由器交换路由协议消息，无论是物理路由器还是驻留在其他主机上的CNR 32B–32X(CNR 32A–32X在本文中被统称为“CNR 32”)。此外，通常基于分段路由(SR)，可以使用MPLS。这样做的原因有两个：在需要时允许业务工程，并通过使用VPN(诸如基于MPLS的第3层VPN或EVPN)来支持多租户。

每个网荚22包括一个或多个容器。在一些示例中，网荚22中的一个或多个包括容器化DPDK工作负载，其被设计为使用DPDK来例如通过使用DPDK库来与其他组件交换数据从而加速分组处理。在一些示例中，虚拟路由器21可以作为容器化DPDK工作负载来执行。

网荚22各自配置有一个或多个虚拟网络接口(VNI)26，用于与虚拟路由器21发送和接收分组。虚拟网络接口26可以是网荚22的默认接口。网荚22可以将虚拟网络接口26实现为以太网接口(例如，命名为“eth0”)，而虚拟路由器21可以将虚拟网络接口26实现为tap接口、virtio用户界面或其他类型的接口。尽管关于网荚进行了描述，但是VNI 26可以被附接到诸如虚拟机之类的其他虚拟执行元件。虚拟网络接口可以替代地被称为虚拟机接口(VMI)，即使它指的是用于网荚/容器的VNI。

网荚22和虚拟路由器21使用虚拟网络接口26来交换数据分组。虚拟网络接口26可以是DPDK接口。网荚22和虚拟路由器21可以使用vhost来建立虚拟网络接口26。网荚22可以根据聚合模型来进行操作。网荚22可以使用虚拟设备，诸如具有vhost-user适配器的virtio设备，用于虚拟网络接口26的用户空间容器过程间通信。下文的描述主要针对网荚22A进行，但是可以适用于其他网荚22或其他虚拟执行元件。

CNI 17A可以针对网荚22A结合图1中所示的一个或多个其他组件来配置虚拟网络接口26。网荚22A的任何容器都可以利用(即共享)网荚22A的(多个)虚拟网络接口26。

cRPD 25A包括默认VRF 28(被图示为“D.VRF 28”)和VRF 29A-29B(被统称为“VRF29”)。默认VRF 28存储全局路由表。cRPD 25A将从VRF 29的路由表导出的转发信息作为转发表编程到虚拟路由器21A中。以这种方式，虚拟路由器21A为VRF 29实现VPN，其被图示为被包括在虚拟路由器21A和cRPD 25A二者中。

cRPD 25A被配置为在主机网络模式下操作，也被称为本地联网。因此，cRPD 25A使用其主机(即服务器12A)的网络名称空间和(多个)IP地址。cRPD 25A具有对NIC 13A的网络接口30A-30B的可见性和访问权，这些接口被插入到默认VRF 28中并被cRPD 25A视为面向核心的接口。接口30A-30B连接到交换结构14，并且可以是以太网接口。接口30被cRPD 25A视为并用作面向核心的接口以用于提供VPN，因为接口30可以被用来在由交换结构14、IP结构20、服务供应商网络7或公共网络15中的一个或多个组成的第3层网络上传送VPN服务业务。

根据本公开的技术，CNI 17A使用由网络控制器24提供的虚拟网络接口配置数据来配置网荚22A-22C和虚拟化路由器32A之间的虚拟网络接口26(被图示为“VNI 26”)以实现网荚22和虚拟路由器21A之间的网络通信，从而允许通常被部署在服务供应商网络中的VPN服务模型的应用。网荚22A-22C被有效地建模为CE路由器或主机设备，并且使得网荚22A-22C能够经由虚拟网络接口26来与被建模为PE路由器的虚拟化路由器32A进行交互。虚拟网络接口26有效地成为VRF 29的附接电路(对于L3VPN)或以太网段的链路(对于EVPN)，其将网荚22连接到作为PE路由器进行操作的虚拟化路由器32A。

每个虚拟网络接口26被插入到虚拟化路由器32A的至少一个VRF 29A-29B中。在图1中，网荚22A具有与VRF 29A的虚拟网络接口26，网荚22B具有与VRF 29A和29B的虚拟网络接口26，网荚22C具有与VRF 29B的虚拟网络接口26。虚拟网络接口26可以表示veth对，其中veth对的每一端都是单独的设备(例如，Linux/Unix设备)，每个veth对的一端被插入到VRF中，而另一端被插入到网荚中。veth对或veth对的端部有时被称为“端口”。虚拟网络接口可以表示具有被指派给网荚22和虚拟路由器21A的媒体访问控制(MAC)地址的macvlan网络，以用于网荚22的容器和虚拟路由器21A之间的通信。在DPDK启用的虚拟路由器21A的情况下，虚拟网络接口26可以各自表示DPDK(例如，vhost)接口，DPDK接口的一端被插入到VRF中，而一端被插入到网荚中。在一些示例中，网荚22可以操作为vhost服务器，其中虚拟路由器21A操作为vhost客户端，以用于建立DPDK接口。在一些示例中，虚拟路由器21A可以操作为vhost服务器，其中网荚22操作为vhost客户端，以用于建立DPDK接口。例如，虚拟网络接口可以替代地被称为虚拟机接口(VMI)、网荚接口、容器网络接口、tap接口、veth接口或简称为网络接口(在特定上下文中)。

在图1的示例服务器12A中，网荚22是一个或多个虚拟网络中的虚拟网络端点。编排器23可以存储或以其他方式管理用于应用部署的配置数据，其指定虚拟网络并且指定网荚22(或其中的一个或多个容器)是虚拟网络的虚拟网络端点。编排器23可以例如从用户、操作员/管理员或其他机器系统接收配置数据。

作为创建网荚22A的过程的一部分，例如，编排器23请求网络控制器24为一个或多个虚拟网络创建相应的虚拟网络接口(在配置数据中指示)。网荚22A对于它所属的每个虚拟网络可以具有不同的虚拟网络接口。例如，虚拟网络接口26可以是特定虚拟网络的虚拟网络接口。可以为其他虚拟网络配置附加的虚拟网络接口(未示出)。网络控制器24处理为网荚22A的虚拟网络接口生成接口配置数据的请求。接口配置数据可以包括容器或网荚唯一标识符和列表或其他数据结构，其为虚拟网络接口中的每一个指定用于配置虚拟网络接口的网络配置数据。虚拟网络接口的网络配置数据可以包括网络名称、所指派的虚拟网络地址、MAC地址和/或域名服务器值。以下是JavaScript对象表示法(JSON)格式的接口配置数据的示例。

在一些示例中，网荚可以具有到不同cRPD VRF 29的多个接口，例如，一个用于管理业务，另一个用于数据业务。在图1中，例如，网荚22B可以将VRF 29B用于管理业务并且将VRF 29A用于数据业务。

网荚22，例如网荚22A，可能连接到一些物理接口，在这些接口上它正在获悉其他设备(诸如网荚正在实现移动网络网关的用户设备或网荚正在实现CE路由器或网关的客户网络子网)的IP地址。为了将这些IP地址通告到网络中，网荚22A将与VRF 29的虚拟网络接口26视为IP链路并将这些IP地址的路由通告给cRPD 25A。CRPD 25A然后可以通过cRPD 25A和网荚22A作为下一跳来通告这些IP地址的可达性，同样符合VPN服务模型。cRPD 25A用从VRF 29和默认VRF 28导出的对应的转发信息对虚拟路由器21进行编程，并且虚拟路由器21根据VPN服务模型来转发VPN业务以实现VPN。

例如，使用包括MPLS、SR-MPLS、SRv6、MPLSoUDP、MPLSoGRE，或IP-in-IP在内的各种底层隧道传输类型，CRPD 25A可以应用许多不同类型的覆盖网络/VPN，包括L3VPN或EVPN(类型2/类型5)。

CNI 17A可以针对网荚22s结合图1中所示的一个或多个其他组件来配置虚拟网络接口26。网荚22的任何容器都可以利用(即共享)网荚的任何虚拟网络接口。编排器23可以存储或以其他方式管理用于应用部署的虚拟网络接口配置数据。例如，编排器23可以从用户、操作员/管理员或其他机器系统接收用于容器化应用的规范(在Kubernetes的上下文中是“网荚规范”)和网络附接限定，并且网络控制器24可以从该信息中导出配置数据以用于配置VRF 29和默认VRF 28；并且配置虚拟网络接口26.

作为创建网荚22A的过程的一部分，例如，编排器23可以请求网络控制器24为网荚规范中指示的VRF 29A创建虚拟网络接口和网荚规范所引用的网络附接限定。根据本公开的技术，网络附接限定和网荚规范符合新模型，新模型允许操作员在网络附接限定中指定VPN，并将网荚连同网络接口规范一起配置为VPN的成员。网荚22对于它所属的每个网络可以具有不同的虚拟网络接口。网络控制器24处理为网荚22A的虚拟网络接口26生成接口配置数据的请求。接口配置数据可以包括容器或网荚唯一标识符和列表或其他数据结构，其为虚拟网络接口中的每一个指定用于配置虚拟网络接口的网络配置数据。虚拟网络接口的网络配置数据可以包括网络名称、所指派的虚拟网络地址、MAC地址和/或域名服务器值。以下是JavaScript对象表示法(JSON)格式的接口配置数据的示例。

网络控制器24将接口配置数据发送到服务器12A，并且更具体地，在一些情况下，发送到虚拟路由器21A。为了为网荚22A配置虚拟网络接口，编排器23可以调用CNI 17A。CNI17A从虚拟路由器21A获得接口配置数据并对其进行处理。CNI 17A创建接口配置数据中指定的每个虚拟网络接口。例如，CNI 17A可以将实现虚拟网络接口26的veth对的一端附接到虚拟路由器21A，并且可以将同一veth对的另一端附接到网荚22A，这可以使用virtio-user来实现它。

网络控制器24将接口配置数据发送到服务器12A，并且更具体地说，在一些情况下，发送到虚拟路由器21。为了为网荚22A配置虚拟网络接口，编排器23可以调用CNI 17A。CNI 17A从虚拟路由器21A获得接口配置数据并对其进行处理。CNI 17A创建接口配置数据中指定的每个虚拟网络接口。例如，CNI 17A可以将实现管理接口26的veth对的一端附接到虚拟路由器21A，并且可以将同一veth对的另一端附加到网荚22A，这可以使用virtio-user来实现它。

以下是用于虚拟网络接口26之一的网荚22A的示例接口配置数据。

传统的CNI插件由容器平台/运行时调用，从容器平台接收添加(Add)命令以将容器添加到单个虚拟网络，并且这样的插件随后可以被调用以从容器/运行时接收删除(Del(ete))命令并从虚拟网络中删除容器。术语“调用”可以是指存储器中的软件组件或模块的实例化，作为可执行代码，以供处理电路执行。

网络控制器24是用于软件定义联网(SDN)的云原生分布式网络控制器，其使用一个或多个配置节点30和一个或多个控制节点32来实现。每个配置节点30本身可以使用一个或多个云原生组件微服务而被实现。每个控制节点32本身可以使用一个或多个云原生组件微服务而被实现。

在一些示例中，并且如下文进一步详细描述的，配置节点30可以通过扩展本地编排平台以支持用于软件定义联网的编排平台的自定义资源来实现，并且更具体地，用于提供到编排平台的北向接口以通过例如为虚拟执行元件配置虚拟网络接口、配置连接服务器12的底层网络、配置包括用于虚拟网络的覆盖隧道和用于多播第2层和第3层的覆盖树的覆盖路由功能性来支持虚拟网络的意图驱动的/声明的创建和管理。

网络控制器24，作为图1中所图示的SDN架构系统200的一部分，可以是多租户感知的并且支持编排平台的多租户。例如，网络控制器24可以支持Kubernetes基于角色的访问控制(RBAC)构造、本地身份访问管理(IAM)和外部IAM集成。网络控制器24还可以支持Kubernetes限定的联网结构和高级联网特征，如虚拟联网、BGPaaS、联网策略、服务链和其他电信特征。网络控制器24可以使用虚拟网络结构来支持网络隔离并支持第3层联网。

为了互连多个虚拟网络，网络控制器24可以使用(并在底层和/或虚拟路由器21中配置)网络策略，被称为虚拟网络策略(VNP)并且在本文中替代地被称为虚拟网络路由器或虚拟网络拓扑结构。VNP限定虚拟网络之间的连接性策略。单个网络控制器24可以支持多个Kubernetes集群，并且因此VNP允许在名称空间、Kubernetes集群中以及跨Kubernetes集群连接多个虚拟网络。VNP还可以扩展以支持跨网络控制器24的多个实例的虚拟网络连接性。

网络控制器24可以使用网络策略来实现多层安全。Kubernetes默认行为是让网荚相互通信。为了应用网络安全策略，由网络控制器24和虚拟路由器21实现的SDN架构可以通过CNI 17A作为用于Kubernetes的CNI来操作。对于第3层，隔离发生在网络级别处，并且虚拟网络操作在L3处。虚拟网络通过策略来连接。Kubernetes原生网络策略在第4层处提供安全性。SDN架构可以支持Kubernetes网络策略。Kubernetes网络策略操作在Kubernetes名称空间边界处。SDN架构可以为增强的网络策略添加自定义资源。SDN架构可以支持基于应用的安全性。(这些安全策略在一些情况下可以基于元标记，从而以可扩展的方式应用细粒度安全策略)。对于第4层以上，在一些示例中SDN架构可以支持与容器化安全设备和/或Istio的集成，并且可以提供加密支持。

网络控制器24，作为图1中所图示的SDN架构的一部分，可以支持多集群部署，这对于电信云和高端企业用例很重要。例如，SDN架构可以支持多个Kubernetes集群。集群API可以被用来支持Kubernetes集群的生命周期管理。KubefedV2可以被用于跨Kubernetes集群的配置节点32联邦。集群API和KubefedV2是可选组件，用于对支持多个Kubernetes集群的网络控制器24的单个实例进行支持。

SDN架构可以使用web用户界面和遥测组件来提供对基础设施、集群和应用的洞察。遥测节点可以是云原生的，并且包括支持洞察的微服务。

作为上述特征和将在本文别处描述的其他特征的结果，SDN架构系统200是云原生的并且可以呈现以下技术优势中的一个或多个。例如，网络控制器24是一种云原生、轻量级分布式应用，具有简化的安装足迹。这也促进了用于配置(多个)节点30和控制(多个)节点32(以及本公开中描述的网络控制器的其他示例的任何其他组件)的各种组件微服务的更容易、模块化升级。这些技术可以进一步实现可选的云原生监控(遥测)和用户界面，使用连接到DPDK启用的网荚的基于DPDK的虚拟路由器的容器的高性能数据平面，以及在IE情况下利用诸如Kubernetes或Openstack之类的现有编排平台的配置框架的云原生配置管理。作为云原生架构，网络控制器24是一种可扩展且有弹性的架构，用于解决和支持多个集群。在一些情况下，网络控制器24还可以支持针对关键性能指示符(KPI)的可扩展性和性能要求。

具有诸如本文描述的那些之类的特征和技术优势的SDN架构可以被用来实现云原生电信云以支持例如5G移动联网(和后续几代)和边缘计算以及企业Kubernetes平台，包括例如高性能云原生应用托管。电信云应用正在迅速转向容器化云原生方法。5G固定和移动网络正在推动需求以将工作负载部署为具有显著分解的微服务，尤其是在5G下一代RAN(5GNR)中。5G下一代核心(5GNC)可能会被部署为一组基于微服务的应用，其对应于由3GPP描述的每个不同组件。当被视为递送应用的一组微服务时，5GNC可能是具有复杂联网、安全和策略要求的高度复杂的网荚组合。本文所描述的云原生SDN架构具有用于联网、安全和策略的明确限定的构造，该云原生SDN架构可以被用于此用例。网络控制器24可以提供相关的API以能够创建这些复杂的构造。

本文所描述的SDN架构可以能够提供非常高的吞吐量数据平面(根据每部分比特数(bps)和每秒分组(pps)二者都如此)。与具有最新性能增强的DPDK虚拟路由器、eBPF和SmartNIC集成将有助于实现所需的吞吐量。基于DPDK的虚拟路由器在2022年2月1日提交的题为“CONTAINERIZED ROUTER WITH VIRTUAL NETWORKING”的美国申请号17/649,632中被更详细描述，该申请的全部内容通过引用并入本文。

根据本公开的技术，网络控制器24被扩展以配置cRPD 25A(和系统200中的其他cRPD)，其在云原生SDN架构系统200中实现用于CNR 32A的控制平面。因此，网络控制器24的配置节点30可以被用来编排cRPD配置。网络资源(NR)31是由配置节点30管理的自定义资源。例如，网络资源31可以包括用于BGP路由器、子网、路由实例、实例IP、路由目标、虚拟机接口/虚拟网络接口、虚拟网络路由器、虚拟路由器、池的自定义资源。网络资源31作为通用网络资源而被并入到意图模型中，并经由配置节点30而使其可用，配置节点30扩展编排系统以实现SDN架构系统200配置平面。网络资源31中的一些可以提示cRPD控制器305的观察和协调以用于配置cPRD 324，以及自定义资源控制器302的观察和协调以用于配置SDN架构的其他方面，诸如虚拟路由器数据平面。网络资源31可以是用于基于Kubernetes的编排平台的自定义资源。

用户可以通过引用通用网络资源31来为网络编排创建基于意图的规范。控制节点32观察网络资源31上的改变并且将网络资源配置提供给托管相关cRPD 25的适当服务器12。驱动程序33是这样一个软件，其将抽象网络资源31配置对象转换为符合用于cRPD 25A的传统数据模型的配置数据，并经由接口(例如，gRPC、Netconf、CLI)将配置数据推送到cRPD 25A以配置CNR 32A控制平面。并行地，用于SDN架构系统200的网络控制器24可以提供虚拟路由器(数据平面)以实现CNR 32A数据平面中的意图——在一些情况下也由网络资源31限定。网络控制器24以这种方式被扩展以允许cRPD 25的意图驱动的配置，cRPD 25在云原生SDN架构系统200中实现用于CNR 32的控制平面。

例如，该技术将基于意图的网络资源转换为cRPD软件中的低级联网配置资源以统一和简化网络编排。与SDN架构系统的其他方面一样，cRPD现在可以使用本公开的技术使用统一的意图模型来进行配置。利用意图驱动的配置模型，诸如由Kubernetes提供的配置模型，还可以不断地将实际状态协调为预期状态。也就是说，对网络资源的改变由cRPD自定义控制器和cRPD代理自动地应用于相关的cRPD。上述优势也可以应用于这些技术的扩展，以用于为其他网络设备配置控制平面。

SDN架构系统200，在一些情况下与原生Kubernetes集成，具有基于意图的模型，用于利用虚拟路由器32A(数据平面)和应用(网荚)来集中地编排虚拟网络，但是使用本文所描述的技术允许基于意图的模型扩展到配置CNR 32控制平面，即cRPD 25，而无需了解CLI或cRPD 25的配置数据模型。

这些技术可以被扩展以配置物理网络设施的控制平面，诸如路由器和网络交换机、防火墙、网络地址转换(NAT)设备、负载均衡器、网关或其他设备。此类物理设施还可以具有可使用接口来进行配置的基于软件的控制平面。可以将与该物理设施相关的抽象网络资源32配置转换为符合该物理应用的数据模型的配置数据的驱动程序可以在该设施(或设备外)上进行开发和执行，以类似于CNR 32A的驱动程序33来执行。

图2是图示了根据本公开的技术的用于具有网络资源自定义资源的云原生联网的云原生SDN架构的示例的框图。SDN架构系统200以抽象化各种组件之间的底层连接性的方式而被图示。在该示例中，SDN架构系统200的网络控制器24包括配置节点230A-230N(“配置节点”(configuration node)或“配置节点”(config node)，并且被统称为“配置节点230”)和控制节点232A-232K(被统称为“控制节点232””)。配置节点230和控制节点232可以分别表示图1的配置节点30和控制节点32的示例实现。配置节点230和控制节点232虽然被图示为与服务器12分离，但是可以作为一个或多个工作负载在服务器12和/或其他服务器中的一个或多个上被执行。

配置节点230可以提供北向表述性状态转移(REST)接口以支持SDN结构200的意图驱动的配置。可以被用来将意图推送到配置节点230的示例平台和应用包括虚拟机编排器240(例如，Openstack)、容器编排器242(例如，Kubernetes)、用户界面244或其他一个或多个应用246。在一些示例中，SDN结构200将Kubernetes作为其基础平台。

SDN结构200被分成配置平面、控制平面和数据平面，连同可选的遥测(或分析)平面。配置平面用水平可扩展配置节点230来实现，控制平面用水平可扩展控制节点232来实现，而数据平面用计算节点来实现。

在高级别处，配置节点230使用配置存储库224来管理SDN架构系统200的配置资源的状态。一般来说，配置资源(或更简单地“资源”)是包括描述自定义资源的方法和/或数据的命名对象概要，并且应用编程接口(API)被限定为通过API服务器来创建和操纵数据。种类是对象概要的名称。配置资源可以包括Kubernetes原生资源，诸如网荚、入口、配置图、服务、角色、名称空间、节点、网络策略或负载均衡器。根据本公开的技术，配置资源还包括自定义资源，包括网络资源31，它们被用来通过限定在Kubernetes平台的默认安装中可能不可用的应用编程接口(API)来扩展Kubernetes平台。自定义资源包括网络资源31、用于在服务器12中配置cRPD 324的资源集合。在SDN结构200的示例中，自定义资源通常可以描述物理基础设施、虚拟基础设施、配置和/或SDN结构200的其他资源。作为配置和操作SDN结构200的一部分，可以实例化各种自定义资源。实例化资源(无论是原生的还是自定义的)可以被称为资源的实例或对象，它们是SDN结构200中的持久实体，其表示SDN结构200的意图(期望状态)和状态(实际状态)。配置节点230提供用于对配置存储库224中的SDN结构200的配置资源执行操作(即，创建、读取、更新和删除)的聚合API。负载均衡器226表示一个或多个负载均衡器对象，其在配置节点230之间对配置请求进行负载均衡。配置存储库224可以表示一个或多个etcd数据库。配置节点230可以使用Nginx来实现。

SDN结构200可以为Openstack和Kubernetes两者提供联网。Openstack使用插件架构来支持网络。使用作为Openstack的虚拟机编排器240，Openstack联网插件驱动程序将Openstack配置对象转换为SDN结构200配置对象(资源)。计算节点运行Openstack nova以启动虚拟机。

利用作为Kubernetes的容器编排器242，SDN结构200用作Kubernetes CNI。如上面所指出，可以支持Kubernetes原生资源(网荚、服务、入口、外部负载均衡器等)，并且SDN结构200可以支持Kubernetes的自定义资源，以用于SDN结构200的高级联网和安全。

配置节点230向控制节点232提供REST观察以观察配置资源改变，控制节点232在计算基础设施内起作用。控制节点232通过观察资源来从配置节点230接收配置资源数据，并建立完整配置图表。给定的一个控制节点232消耗与控制节点和一些自定义资源相关的配置资源数据，可以经由到虚拟路由器21的控制平面方面(即，虚拟路由器代理(图1中未示出))的控制接口254将所需配置分发到计算节点(服务器12)。任何计算节点232都可以只接收处理所需要的部分图表。控制接口254可以是XMPP。所部署的配置节点230和控制节点232的数目可以是所支持的集群数目的函数。为了支持高可用性，配置平面可以包括2N+1个配置节点230和2N个控制节点232。

控制节点232在计算节点之间分发路由。控制节点232使用内部边界网关协议(iBGP)在控制节点232之间交换路由，并且控制节点232可以与任何外部BGP支持的网关或其他路由器对等。控制节点232可以使用路由反射器。

网荚250和虚拟机252是可以由虚拟机编排器240或容器编排器242部署到计算节点，并且由SDN结构200使用一个或多个虚拟网络进行互连的工作负载的示例。例如通过容器编排器242，cRPD 324也可以使用网荚来部署。

配置节点230经由接口向cRPD代理326提供网络资源31的抽象网络资源配置。cRPD代理326是在服务器12上执行的软件，用于与控制节点232进行接口以接收抽象网络资源配置。在服务器12上执行的驱动程序33(图2中未示出)的实例将抽象网络资源配置转换成符合cRPD 324的数据模型的配置数据，并将配置数据推送到cRPD 324。

图3是根据本公开的技术更详细地图示了SDN结构200的组件的另一个视图的框图。配置节点230、控制节点232和用户界面244被图示为具有它们各自的组件微服务以用于将网络控制器24和SDN结构200实现为云原生SDN架构。每个组件微服务都可以被部署到计算节点。

图3图示了被划分为网络控制器24、用户界面244、计算(服务器12)和遥测260特征的单个集群。配置节点230和控制节点232一起形成网络控制器24。

配置节点230可以包括组件微服务API服务器300(或“Kubernetes API服务器300”(对应控制器406在图3中未示出))、自定义API服务器301、自定义资源控制器302和SDN控制器管理器303(有时被称为“kube管理器”或“SDNkube管理器”，其中用于网络控制器24的编排平台是Kubernetes)。Contrail-kube管理器是SDN控制器管理器303的示例。配置节点230扩展API服务器300与自定义API服务器301的接口，以形成聚合层来支持用于SDN结构200的数据模型。SDN结构200配置意图可以是自定义资源，如上所述。

控制节点232可以包括组件微服务控制320。控制320执行配置分发和路由学习和分发，如上文关于图2所述。

计算节点由服务器12表示。每个计算节点包括虚拟路由器代理316和虚拟路由器转发组件(虚拟路由器(vRouter))318。虚拟路由器代理316和虚拟路由器318之一或两者可以是组件微服务。一般来说，虚拟路由器代理316执行控制相关功能。虚拟路由器代理316从控制节点232接收配置数据，并将配置数据转换为虚拟路由器318的转发信息。虚拟路由器代理316还可以执行防火墙规则处理，为虚拟路由器318建立流，并与编排插件进行接口(Kubernetes为CNI，而Openstack为Nova插件))。当工作负载(网荚或VM)在计算节点上启动时，虚拟路由器代理316生成路由，并且虚拟路由器316与控制节点232交换此类路由以分发到其他计算节点(控制节点232使用BGP来在控制节点232之间分发路由)。当工作负载终止时，虚拟路由器代理316也撤回路由。虚拟路由器318可以支持一种或多种转发模式，诸如内核模式、DPDK、SmartNIC卸载等。在容器架构或虚拟机工作负载的一些示例中，计算节点可以是Kubernetes worker/小节点或Openstack nova-计算节点，具体取决于使用中的特定编排器。

一个或多个可选的遥测节点260提供度量、警报、日志记录和流分析。SDN结构200遥测利用云原生监控服务，诸如Prometheus、Elastic、Fluentd、Kinaba stack(EFK)和Influx TSDB。配置节点230、控制节点232、计算节点、用户界面244和分析节点(未示出)的SDN架构组件微服务可以产生遥测数据。该遥测数据可以由(多个)遥测节点260的服务使用。(多个)遥测节点260可以向用户暴露REST端点并且可以支持洞察和事件相关。

可选的用户界面244包括web用户界面(UI)306和UI后端308服务。一般来说，用户界面244为SDN架构组件提供配置、监控、可视化、安全和故障排除。

遥测260、用户界面244、配置节点230、控制节点232和服务器12/计算节点中的每一个都可以被认为是SDN结构200节点，因为这些节点中的每一个都是一个实体，用于实现配置、控制或数据平面的功能性或UI和遥测节点的功能性。节点规模是在“启动”期间配置的，并且SDN结构200支持使用编排系统运营商(诸如Kubernetes运营商)自动扩展SDN结构200节点。

根据本公开的技术，每个服务器12还包括cRPD代理326和cRPD 324的实例。cRPD控制器305是一种用于网络资源31的自定义资源控制器，用于协调cRPD 324配置状态的意图。网络资源31是自定义资源，例如，Kubernetes自定义API资源，并且在一些情况下可以对应于cRPD 324配置数据模型的配置对象。网络资源31可以包括例如BGPRouter、GlobalSystemConfig、GlobalVrouterConfig、InstanceIP、RouteTarget、RoutingInstance、Subnet、VirtualMachineInterface、VirtualMachine、VirtualNetworkRouter、VirtualNetwork、VirtualRouter和Pool。BGPRouter(BGP路由器)是用于限定和配置cRPD以作为BGP路由器进行操作的自定义资源。GlobalSystemConfig(全局系统配置)是用于配置cRPD系统参数的自定义资源。GlobalVrouterConfig(全局虚拟路由器配置)是用于在集群中配置虚拟路由器318的自定义资源。InstanceIP是用于为虚拟执行元件(诸如容器/网荚或VM)配置IP地址的自定义资源。RouteTarget是用于为路由实例配置路由目标的自定义资源。RoutingInstance是用于配置路由实例以例如实现VRF的自定义资源。Subnet是用于限定网络子网的自定义资源。VirtualMachineInterface是用于配置虚拟执行元件和虚拟路由器318之间的虚拟网络接口(例如，任何VNI 26)的自定义资源。VirtualMachine是用于配置虚拟执行元件(诸如容器/网荚或VM)的自定义资源。VirtualNetworkRouter是用于配置虚拟网络路由器的自定义资源。VirtualNetwork是用于配置虚拟网络的自定义资源。VirtualRouter是用于配置虚拟路由器318的自定义资源，例如流表、防火墙策略或限定虚拟路由器318的分组处理和转发操作的转发信息。Pool是用于管理集群中的软件许可池的自定义资源。

以下针对特定计算节点“worker-0”的Kubernetes规范数据示出了使用BGPRouter自定义资源来配置cRPD。从概念上讲，worker-0，更具体地说是在其上的cRPD操作BGP路由器：

bgpRouterParameters是BGP/对等群组属性，并且bgpRouterReferences指定BGPRouter邻居worker-1。cRPD控制器305协调网络资源31的BGPRouter对象的状态，并将抽象BGPRouter配置数据推送到cRPD代理326，cRPD代理326将抽象BGPRouter配置数据转换为符合cRPD 324的数据模型的对象。以下配置数据已经以这种方式从上述worker-0BGPRouter的规范转换，并且符合JUNIPER网络有限公司的Junos配置数据模型：

如上面从网络资源(BGPRouter)规范和示例cRPD 324的配置数据所见，cRPD代理326有效地将抽象网络资源数据转换为cRPD 324的可用配置数据。cRPD代理326可以经由接口将上述配置数据推送到cRPD 324，其也可以经由CLI从cRPD 324读取。

以下命令行命令引导kubectl拉取规范数据，该规范数据被用于在cRPD 324中配置路由实例以实现虚拟网络“默认网荚网络”(default-podnetwork)：

然而在用于SDN/网络控制器的集中化模型中，网络控制器用适当的VRF转发表对虚拟路由器进行编程以实现路由实例，网络控制器24改为暴露网络资源31用于配置cRPD324以经由路由协议(例如，BGP)在cRPD 324之间进行分散式路由共享。RouteTarget和Subnet是网络资源31的示例，并且可以被用来在cRPD 324上配置路由实例。

如在前面的示例中，cRPD控制器305协调网络资源31的对象Subnet和RouteTarget的状态，并将抽象网络资源配置数据推送到cRPD代理326，cRPD代理326将抽象网络资源配置数据转换为符合cRPD 324的数据模型的对象。用于cRPD 324上的路由实例的以下配置数据已经以这种方式从上述worker-0规范转换，并且符合JUNIPER网络有限公司的Junos配置数据模型：

cRPD 324已经由配置节点230经由cRPD代理326配置为使用VRF实例来实现默认网荚网络，该实例已配置有用于其两个veth接口的数个静态路由和路由目标值，如在限定对应网络资源31的YAML中所指定的。

自定义API服务器被扩展以支持网络资源31，并且客户资源控制器(cRPD控制器305)进行工作以将cRPD 324的状态协调为网络资源31配置对象。更具体地，cRPD控制器305经由接口370进行接口连接以将抽象网络资源31配置发送到cPRD代理326，cPRD代理326将抽象网络资源31配置转换为符合cRPD 324的数据模型的配置数据并将配置数据推送到cRPD 324以配置CNR控制平面。接口370可以是RPC接口，诸如gRPC接口。

与由控制节点232之一控制的虚拟路由器318不同，cRPD 324可以独立于SDN架构的集中化方面，其中控制节点232管理路由信息并将路由推送到服务器以用于集群内的底层和覆盖路由。相反，多个服务器12上的分散式cRPD 324就像物理路由器的控制平面一样操作：一旦由cRPD控制器305配置了使用网络资源31表达的意图，cRPD 324就会执行路由协议以通告彼此的可达性，建立虚拟专用网络，并且对对应的虚拟路由器318进行编程以在服务器12之间并且甚至在集群之外转发业务以实现用于联网的用户意图。因此，用户可以利用编排平台的配置框架来配置cRPD 324，cRPD 324在云原生SDN架构中实现用于容器化网络路由器的控制平面，至少在一些情况下不需要单独地配置每个cRPD 324和/或甚至不需要具有cRPD配置数据模型的工作知识。

一般来说，在SDN架构400的上下文中使用cRPD 324适合分布式路由平面方法。每个计算节点(即，服务器12)运行cRPD 324的实例，而集中式路由反射器(未示出)在节点之间中继路由协议消息。智能被分布在各种计算节点/cRPD实例中。各个节点的配置数据可以是冗余的(同步的)(经过必要的修改)，并且路由反射器可以是简单的。

图4A-图4B是图示了根据本公开的技术的SDN架构的示例组件的框图。在此示例中，SDN架构400扩展并使用Kubernetes API服务器以用于实现网络配置的用户意图的网络资源配置对象。这样的配置对象，在Kubernetes术语中，被称为自定义资源，并且当被持久化在SDN架构中时，被简称为对象。网络资源配置对象主要是用户意图(例如，虚拟网络、BGPaaS、网络策略、服务链等)。

SDN架构400配置节点230可以将Kubernetes API服务器用于配置对象。

Kubernetes提供了向集群添加自定义资源的两种方式：

·自定义资源限定(CRD)很简单，并且无需任何编程即可被创建。

·API聚合需要编程，但是允许更好地控制API行为，诸如数据的存储方式以及API版本之间的转换。

聚合API是位于充当代理的主要API服务器之后的附属API服务器。这种布置被称为API聚合(AA)。对于用户来说，看起来只是扩展了Kubernetes API。CRD允许用户在不添加另一个API服务器的情况下创建新类型的资源。无论它们是如何安装的，新资源都被称为自定义资源(CR)，以将它们与原生Kubernetes资源(例如网荚)区分开来。CRD被用于最初配置原型中。该架构可以使用API Server Builder Alpha库来实现聚合API。API ServerBuilder是用于建立原生Kubernetes聚合扩展的库和工具的集合。

通常，Kubernetes API中的每个资源都需要处理REST请求和管理对象的持久存储的代码。主Kubernetes API服务器300(利用API服务器微服务300A-300J来实现)处理原生资源，并且通常也可以通过CRD处理自定义资源。聚合API 402表示扩展Kubernetes API服务器300的聚合层，以通过编写和部署自定义API服务器301(使用自定义API服务器微服务301A-301M)来允许自定义资源的专门实现。主API服务器300将对自定义资源的请求委托给自定义API服务器301，从而使此类资源对其所有客户端都可用。

以这种方式，API服务器300(例如，kube-apiserver)接收根据本公开的技术所限定的Kubernetes配置对象、原生对象(网荚、服务)和自定义资源。SDN架构400的自定义资源可以包括作为自定义资源的实例的网络资源配置对象，并且当实现SDN架构400中的配置对象的预期状态时，实现SDN架构400的预期网络配置。自定义资源可以对应于传统上为网络配置限定的配置概要，但是根据本公开的技术，其被扩展为通过聚合API 402是可操纵的。此类自定义资源在本文中可以替代地被叫做和称为“用于SDN架构配置的自定义资源”。用于SDN架构配置的每个自定义资源可以对应于传统上由SDN控制器所暴露的一种配置对象，但是根据本文所描述的技术，配置对象使用自定义资源而被暴露并与Kubernetes原生/内置资源整合。这些网络资源配置对象可以包括虚拟网络(VirtualNetwork)、bgp即服务(BGPaaS)、子网(Subnet)、虚拟路由器(VirtualRouter)、服务实例、项目、物理接口、逻辑接口、节点、网络ipam、浮动IP(IPinstance)、告警、别名IP、访问控制列表、防火墙策略、防火墙规则、网络策略、路由目标(RouteTarget)、路由实例(RoutingInstance)等。因此，SDN架构系统400支持由聚合API 402暴露的统一意图模型，其由控制器406A-406N(例如，Kubernetes控制器)以及由自定义资源控制器302(在图4A-图4B中被示为组件微服务302A-302L)(包括cRPD控制器305)来实现，它进行工作以协调包括网络元件在内的计算基础设施的实际状态与预期状态。

API服务器300聚合层将API自定义资源发送到它们对应的、已注册的自定义API服务器301。可以有多个自定义API服务器/自定义资源控制器以支持不同种类的自定义资源。自定义API服务器301处理用于SDN架构配置的自定义资源，包括网络资源31，并写入到(多个)配置存储库304，其可以是etcd。自定义API服务器301可以暴露自定义资源控制器302可能需要的SDN控制器标识符分配服务。

(多个)自定义资源控制器302和cRPD控制器305开始应用业务逻辑以达到用户意图配置所提供的用户意图。业务逻辑被实现为协调循环。图8是图示了根据本公开的技术的用于SDN架构配置的(多个)自定义资源的自定义控制器的示例的框图。客户控制器814可以表示自定义资源控制器302的示例实例。在图8中所图示的示例中，自定义控制器814可以与自定义资源818相关联。自定义资源818可以是用于SDN架构配置的任何自定义资源。自定义控制器814可以包括协调器816，其包括执行协调循环的逻辑，在协调循环中自定义控制器814观测834(例如，监控)自定义资源818的当前状态832。响应于确定期望状态836与当前状态832不匹配，协调器816可以执行调整838自定义资源状态的操作，使得当前状态832与期望状态836匹配。API服务器300可以接收请求并将请求中继到自定义API服务器301以将自定义资源818的当前状态832改变为期望状态836。

在API请求是自定义资源的创建请求的情况下，协调器816可以对自定义资源的实例数据的创建事件起作用。协调器816可以为所请求的自定义资源依赖的自定义资源创建实例数据。作为一个示例，边缘节点自定义资源可以依赖于虚拟网络自定义资源、虚拟接口自定义资源和IP地址自定义资源。在该示例中，当协调器816接收到关于边缘节点自定义资源的创建事件时，协调器816还可以创建边缘节点自定义资源依赖的自定义资源，例如，虚拟网络自定义资源、虚拟接口自定义资源以及IP地址自定义资源。

默认情况下，自定义资源控制器302正在运行主动-被动模式并且使用主机选举来实现一致性。当控制器网荚启动时，它尝试使用指定的密钥在Kubernetes中创建ConfigMap资源。如果创建成功，该网荚将成为主机并开始处理协调请求；否则它阻止尝试在无限循环中创建ConfigMap。

自定义资源控制器302中的任何一个都可以跟踪它创建的自定义资源的状态。例如，虚拟网络(VN)创建路由实例(RI)，路由实例(RI)创建路由目标(RT)。如果路由目标的创建失败，则路由实例状态降级，并且因此虚拟网络状态也降级。自定义资源控制器300因此可以输出指示这些自定义资源的(多个)状态的自定义消息以用于故障排除。在图9中图示了在对不同自定义资源类型具有依赖性的自定义资源类型之间的创建、观察和协调的示例流程。

cRPD控制器305是自定义资源控制器，类似于自定义资源控制器302，它将网络资源31的预期状态协调为cRPD 324的实际状态。协调器462观察由自定义API服务器301中的一个或多个所暴露的网络资源31上的改变，并应用所开发的逻辑来将cRPD 324协调为网络资源31的状态。

由配置节点230实现的配置平面具有高可用性。配置节点230可以基于Kubernetes，包括kube-apiserver服务(例如，API服务器300)和存储后端etcd(例如，(多个)配置存储库304)。实际上，由配置节点230实现的聚合API 402像由控制节点232所实现的控制平面的前端一样操作。API服务器300的主要实现是kube-apiserver，它被设计为通过部署更多实例来进行水平扩展。如图所示，可以运行API服务器300的若干实例来对API请求和处理进行负载均衡。

(多个)配置存储库304可以被实现为etcd。etcd是一致且高度可用的键值存储库，其被用作集群数据的Kubernetes后备存储库。

在图4A-图4B的示例中，SDN架构400的服务器12各自包括编排代理420和容器化(或“云原生”)路由协议守护进程324。SDN架构400的这些组件在下面进一步详细描述。

SDN控制器管理器303可以作为Kubernetes核心资源(服务、名称空间、网荚、网络策略、网络附接限定)和扩展的SDN架构资源(虚拟网络、路由实例等)之间的接口来操作。SDN控制器管理器303观察Kubernetes API以了解Kubernetes核心和用于SDN架构配置的自定义资源上的改变，并且结果，可以对相关资源执行CRUD操作。一些Kubernetes核心资源和一些扩展的SDN架构资源可能适用于cRPD。网络资源31主要是扩展的SDN架构资源以及cRPD的自定义资源。

在一些示例中，SDN控制器管理器303是一个或多个Kubernetes自定义控制器的集合。在一些示例中，在单集群或多集群部署中，SDN控制器管理器303可以在它所管理的(多个)Kubernetes集群上运行。

SDN控制器管理器303侦听以下Kubernetes对象的创建、删除和更新事件：

·网荚

·服务

·节点端口

·入口

·端点

·名称空间

·部署

·网络策略

当生成这些事件时，SDN控制器管理器303创建适当的SDN架构对象，这些对象继而又被限定为用于SDN架构配置的自定义资源。响应于检测到关于自定义资源的实例的事件，无论是由SDN控制器管理器303和/或通过自定义API服务器301实例化的，控制节点232获得用于自定义资源的实例的配置数据并配置SDN架构400中的配置对象的对应实例。

例如，SDN控制器管理器303观察网荚创建事件，并且作为响应，可以创建以下SDN架构对象：VirtualMachine(工作负载/网荚)、VirtualMachineInterface(虚拟网络接口)和InstanceIP(IP地址)。控制节点232然后可以实例化SDN架构对象，在这种情况下是在选定的计算节点中实例化。

作为示例，基于观察，控制节点232A可以检测关于由客户API服务器301A暴露的第一自定义资源的实例的事件，其中第一自定义资源用于配置SDN架构系统400的一些方面并且对应于SDN架构系统400的配置对象类型。例如，配置对象类型可以是与第一自定义资源相对应的防火墙规则。响应于该事件，控制节点232A可以获得用于防火墙规则实例的配置数据(例如，防火墙规则规范)并在服务器12A的虚拟路由器中提供防火墙规则。配置节点230和控制节点232可以针对具有SDN架构的配置对象的对应类型的其他自定义资源执行类似的操作，诸如虚拟网络(VirtualNetwork)、bgp即服务(BGPaaS)、子网(Subnet)、虚拟路由器(VirtualRouter)、服务实例、项目、物理接口、逻辑接口、节点、网络ipam、浮动ip(IPinstance)、告警、别名ip、访问控制列表、防火墙策略、防火墙规则、网络策略、路由目标(RouteTarget)、路由实例(RoutingInstance)等。

然而，根据本公开的技术，SDN架构400还包括以分散式的方式操作以经由路由协议传播路由信息的cRPD 324的实例。因此，配置对象被扩展为在cRPD 324的传统数据模型中包括对象，并且这些配置对象经由自定义API服务器301而被暴露和操纵。自定义控制器(cRPD控制器305)将网络资源31的预期状态协调到cRPD 324的实际状态。现在描述用于使用网络资源31来使用图4A-图4B的各种组件对cRPD 324进行配置的示例过程。

图4A包括Startup/BGPRouter(设置/BGR路由器)观察的步骤。在图4A中，包括cRPD324的网荚的初始容器(未示出)将BGPRouter和VirtualRouter资源创建请求发送到API服务器300(1A)，其将这些中继(2A)到自定义API服务器301，自定义API服务器301将这些BGPRouter和VirtualRouter暴露为网络资源31并将所创建的资源存储到(多个)配置存储库304。初始容器是在网荚中的应用容器之前运行的专用容器，并且可以包括未被包括在应用中的实用程序或设置脚本。

用于SDN架构400的客户资源控制器302可以将BGPRouter和VirtualRouter资源的各方面协调到服务器12A(3A)的虚拟路由器(未示出)。

cRPD代理326启动(在一些情况下作为包括在具有cRPD 324的网荚中的容器)，并且订阅客户端456向订阅管理器460发送对BGPRouter资源和对所有所限定的BGPRouter引用(即，服务器12A的CNR的邻居)的订阅请求(4A)。协调器462观察对BGPRouter的任何改变以及在聚合API的402上引用的BGPRouter资源(5A)。订阅客户端456将抽象BGPRouter和引用的BGPRouter配置数据发送到cRPD 324的配置驱动程序454(6A)。配置驱动程序454将BGPRouter配置变换为符合cRPD 324的接口和数据模型(例如，XML)的配置数据，并经由接口370将变换后的配置数据发送到cRPD 324(7A)。接口370可以是RPC接口，诸如gRPC接口。

图4B包括用于部署新网荚的步骤。类似的过程可以被用于其他容器部署方案或用于VM。此网荚将用于应用工作负载而不是用于cRPD。在图4B中，API服务器300接收网荚创建请求(1B)。API服务器300通过向用于托管网荚的服务器12A(在该示例中)上的编排代理420发送网荚创建指令来部署所请求的网荚(2B-1)。在完成此操作时，SDN控制器管理器303观察(之前已对网荚创建进行观察)网荚创建并生成用于SDN架构配置的自定义资源的创建请求，并将其发送到自定义API服务器300(2B-2)。这些可以包括网荚的VirtualMachine、VirtualMachineInterface和InstanceIP，它们可以被用来将网荚的可寻址虚拟网络接口附接到虚拟路由器数据平面中。API服务器300可以将网荚创建请求转发到自定义API服务器301，自定义API服务器301验证并保持在配置存储库304中(3B-2)。

编排代理420利用添加命令来执行CNI 17并且发送网荚名称、名称空间和虚拟网络接口的名称(3B-1)。这些标识符将由编排代理420从API服务器300中接收。使用控制节点232Y的自定义资源控制器302在服务器12A上协调用于SDN架构配置(VirtualMachine、VirtualMachineInterface和InstanceIP)的新创建的自定义资源(4B-2)。

CNI 17向cRPD代理326的CNI服务器452发送对IP地址信息的请求(4B-1)。CNI服务器452将请求转发到订阅客户端456(5B)，订阅客户端456拉取用于SDN架构配置的相关资源(例如VirtualMachineInterface、VirtualNetwork、Subnet、RoutingInstance和InstanceIP)并向cRPD控制器305订阅VirtualMachineInterface和VirtualNetworkResources上的改变(6B)。CNI服务器452向CNI 17发送IP地址信息(响应于在4B-1处的请求)，并且CNI 17创建(多个)IP地址和网荚的虚拟网络接口；CNI服务器452还调用配置驱动程序454来生成用于这些各种自定义资源的配置数据，该配置数据符合cRPD324的配置数据模型(7B)。配置驱动程序454将转换后的配置数据发送到cRPD 324以配置cRPD 324(8B)。CNI 17向编排代理420用信号通知：网络设置成功(9B)。

本文所描述的用于利用编排平台的配置框架来配置实现云原生SDN架构中的容器化网络路由器的控制平面的软件的技术可以提供附加特征。这些可以包括职责分离——使用VirtualNetworks自定义资源管理的VRF和由网荚间接管理的接口(而不是在网荚注释中限定的VRF)。这些技术可以促进软件资源的自动指派，诸如IP、RT、VNI(尽管替代地，这些也可以被静态限定)。这些技术可以促进Kubernetes原生抽象，其中Kubernetes是编排平台，kubectl被用来在cRPD中创建BGP和VRF配置。这些技术可以通过将实际状态协调为预期状态来促进完全意图驱动的配置——自动应用对SDN架构配置的BGPRouter或VirtualNetwork自定义资源的改变——例如，对BGPRouter的配置的改变会导致具有此邻居的所有cRPD/BGP路由器使它们的配置被自动地调整。技术可以促进cRPD上的无状态配置(没有差异，cRPD上的配置总被替换为完全预期状态)，其中一些相关状态是用户映射。以前被用于配置虚拟路由器的SDN架构配置的核心原语也与cRPD(路由器控制平面)配置相关。

在一些示例中，该技术还可以包括用于动态更新cRPD的许可证的许可证控制器；不同数据平面封装类型之间的转发模式切换：例如，MPLS、MPLSoUDP、EVPN/VxLAN；控制节点232可以被cRPD用作路由反射器/用于cRPD的路由反射器；混合模式，其中主网荚接口由控制节点232提供服务，而次网荚接口由cRPD提供服务；cRPD作为控制节点232的集群内SDN网关；用于cRPD的BGP即服务(BGPaaS)；或者替代方案，混合控制节点232和cRPD架构。

图5是根据本公开中描述的技术的示例计算设备的框图。图2的计算设备500可以表示真实或虚拟服务器并且可以表示任何服务器12的示例实例并且可以被称为计算节点、主节点/小节点或主机。在该示例中，计算设备500包括耦合计算设备500硬件环境的硬件组件的总线542。总线542耦合网络接口卡(NIC)530、存储盘546和一个或多个微处理器210(以下称为“微处理器510”)。NIC 530可以是支持SR-IOV的。在一些情况下，前端总线可以耦合微处理器510和存储器设备524。在一些示例中，总线542可以耦合存储器设备524、微处理器510和NIC 530。总线542可以表示外围组件接口(PCI)高速(PCIe)总线。在一些示例中，直接存储器访问(DMA)控制器可以控制耦合到总线542的组件之间的DMA传送。在一些示例中，耦合到总线542的组件控制耦合到总线542的组件之间的DMA传送。

微处理器510包括用于执行指令的处理电路。微处理器510可以包括一个或多个处理器，每个处理器包括独立的执行单元以执行符合指令集架构的指令，指令被存储到存储介质。执行单元可以被实现为分离的集成电路(IC)，或者可以被组合在一个或多个多核处理器(或“众核”处理器)内，其每个处理器都使用单个IC(即芯片多处理器)来实现。

盘546表示计算机可读存储介质，其包括以用于存储诸如处理器可读指令、数据结构、程序模块或其他数据之类的信息的任何方法或技术来实现的易失性和/或非易失性、可移动和/或不可移动介质。计算机可读存储介质包括但不限于随机存取存储器(RAM)、只读存储器(ROM)、EEPROM、闪存、CD-ROM、数字通用光盘(DVD)或其他光学存储、磁盒、磁带、磁盘存储或其他磁存储设备、或者任何其他可以被用来存储期望信息并可由微处理器510访问的介质。

主存储器524包括一个或多个计算机可读存储介质，其可以包括随机存取存储器(RAM)，诸如各种形式的动态RAM(DRAM)例如DDR2/DDR3 SDRAM或静态RAM(SRAM)、闪存或任何其他形式的可以被用来以指令或数据结构的形式承载或存储期望程序代码和程序数据并且可以被计算机访问的固定或可移动存储介质。主存储器524提供由可寻址存储器位置组成的物理地址空间。

网络接口卡(NIC)530包括一个或多个接口532，其被配置为使用底层物理网络的链路来交换分组。接口532可以包括具有一个或多个网络端口的端口接口卡。NIC 530还可以包括卡上存储器例如来存储分组数据。NIC 530和耦合到总线542的其他设备之间的直接存储器访问传送可以从/向NIC存储器读取/写入。

存储器524、NIC 530、存储盘546和微处理器510可以为包括在内核空间中执行的操作系统内核580的软件堆栈提供操作环境。内核580可以表示例如Linux、伯克利软件分发(BSD)、另一个Unix变体内核或可从微软公司获得的Windows服务器操作系统内核。在一些实例中，操作系统可以执行管理程序和一个或多个由管理程序所管理的虚拟机。示例管理程序包括用于Linux内核的基于内核的虚拟机(KVM)、Xen、可从VMware获得的ESXi、可从微软公司获得的Windows Hyper-V以及其他开源和专有管理程序。术语管理程序可以涵盖虚拟机管理器(VMM)。包括内核580的操作系统为用户空间545中的一个或多个过程提供执行环境。

内核580包括使用网络接口卡530的物理驱动程序525。网络接口卡530还可以实施SR-IOV以实现在诸如容器529A或一个或多个虚拟机(图5中未示出)之类的一个或多个虚拟执行元件之间共享物理网络功能(I/O)。诸如虚拟功能之类的共享虚拟设备可以提供专用资源，使得虚拟执行元件中的每一个都可以访问NIC 530的专用资源，因此对于虚拟执行元件中的每一个而言，NIC 530都表现为专用NIC。虚拟功能可以表示与物理驱动程序525使用的物理功能以及与其他虚拟功能共享物理资源的轻量级PCIe功能。对于支持SR-IOV的NIC530，根据SR-IOV标准，NIC 530可以具有数千个可用的虚拟功能，但是对于I/O密集型应用，已配置的虚拟功能的数量通常要少得多。

计算设备500可以耦合到包括覆盖网络的物理网络交换结构，该覆盖网络将交换结构从物理交换机扩展到耦合到交换结构的物理服务器的软件或“虚拟”路由器，包括虚拟路由器506。虚拟路由器可以是由物理服务器(例如图1的服务器12)执行的过程或线程或其组件，其动态地创建和管理可用于虚拟网络端点之间的通信的一个或多个虚拟网络。在一个示例中，虚拟路由器使用覆盖网络来实现每个虚拟网络，覆盖网络提供了将端点的虚拟地址与端点正在其上执行的服务器的物理地址(例如，IP地址)解耦合的能力。每个虚拟网络都可以使用它自己的寻址和安全方案，并且可以被视为与物理网络及其寻址方案正交。可以使用各种技术在物理网络上的虚拟网络内和虚拟网络之间传送分组。本文中所使用的术语“虚拟路由器”可以涵盖Open vSwitch(OVS)、OVS网桥、Linux网桥、Docker网桥或位于主机设备上并在一个或多个虚拟网络的虚拟网络端点之间执行交换、桥接或路由分组的其他设备和/或软件，其中虚拟网络端点由服务器12中的一个或多个来托管。在图5的示例计算设备500中，虚拟路由器506作为基于DPDK的虚拟路由器在用户空间内执行，但是在各种实现中虚拟路由器506可以在管理程序、主机操作系统、主机应用或虚拟机内执行。

虚拟路由器506可以替换和包括通常被用于网荚502的Kubernetes部署的Linux桥/OVS模块的虚拟路由/桥接功能性。虚拟路由器506可以执行用于虚拟网络的桥接(例如，E-VPN)和路由(例如，L3VPN、IP-VPN)。虚拟路由器506可以执行联网服务，诸如应用安全策略、NAT、多播、镜像和负载均衡。

虚拟路由器506(虚拟路由器的“数据”或“转发”平面)可以作为内核模块或作为用户空间DPDK过程来执行(虚拟路由器506在此在用户空间545中被示出)。虚拟路由器代理514(虚拟路由器的“控制”平面)也可以在用户空间中执行。在示例计算设备500中，虚拟路由器506作为基于DPDK的虚拟路由器在用户空间内执行，但是在各种实现中虚拟路由器506可以在管理程序、主机操作系统、主机应用或虚拟机内执行。虚拟路由器代理514使用信道连接到网络控制器24，该信道被用来下载配置和转发信息。虚拟路由器代理514将该转发状态编程到由虚拟路由器506表示的虚拟路由器数据(或“转发”)平面。虚拟路由器506和虚拟路由器代理514可以是过程。虚拟路由器506和虚拟路由器代理514可以是容器化的/云原生的。

虚拟路由器506可以替换和包括通常被用于网荚502的Kubernetes部署的Linux桥/OVS模块的虚拟路由/桥接功能性。虚拟路由器506可以执行用于虚拟网络的桥接(例如，E-VPN)和路由(例如，L3VPN、IP-VPN)。虚拟路由器506可以执行联网服务，诸如应用安全策略、NAT、多播、镜像和负载均衡。

虚拟路由器506可以是多线程的并且在一个或多个处理器核心上执行。虚拟路由器506可以包括多个队列。虚拟路由器506可以实现分组处理管道。管道可以由虚拟路由器代理514取决于要被应用于分组的操作而从最简单到最复杂的方式拼接。虚拟路由器506可以维护转发基础的多个实例。虚拟路由器506可以使用RCU(读取复制更新)锁来访问和更新表格。

为了向其他计算节点或交换机发送分组，虚拟路由器506使用一个或多个物理接口532。一般来说，虚拟路由器506与诸如VM或网荚502之类的工作负载交换覆盖分组。虚拟路由器506具有多个虚拟网络接口(例如，vifs)。这些接口可以包括内核接口vhost0，用于与主机操作系统交换分组；与虚拟路由器代理514的接口pkt0，以从网络控制器获得转发状态并发送异常分组。可以存在对应于一个或多个物理网络接口532的一个或多个虚拟网络接口。虚拟路由器506的其他虚拟网络接口用于与工作负载交换分组。

在虚拟路由器506的基于内核的部署中(未示出)，虚拟路由器506被安装为操作系统内部的内核模块。虚拟路由器506向TCP/IP堆栈注册它自己，以接收来自任何它想要的期望操作系统接口的分组。接口可以是绑定、物理、tap(用于VM)、veth(用于容器)等等。此模式下的虚拟路由器506依赖操作系统从不同接口发送和接收分组。例如，操作系统可以暴露由vhost-net驱动程序支持的tap接口，以便与VM进行通信。一旦虚拟路由器506针对来自这个tap接口的分组进行了注册，TCP/IP堆栈就将所有分组发送给它。虚拟路由器506经由操作系统接口发送分组。此外，NIC队列(物理或虚拟)由操作系统处理。分组处理可以以中断模式来操作，这会生成中断并且可能导致频繁的上下文切换。当分组速率很高时，伴随频繁中断和上下文切换的开销可能会使操作系统不堪重负并导致性能下降。

在虚拟路由器506的基于DPDK的部署中(图5中所示)，虚拟路由器506被安装为链接到DPDK库的用户空间545应用。这可能会带来比基于内核的部署更快的性能，尤其是在存在高分组速率的情况下。物理接口532不是由内核的基于中断的驱动程序而是由DPDK的轮询模式驱动程序(PMD)使用。物理接口532的寄存器可以被暴露到用户空间545中，以便可以访问PMD；以这种方式绑定的物理接口532不再由主机操作系统管理或对主机操作系统可见，并且基于DPDK的虚拟路由器506管理该物理接口532。这包括分组轮询、分组处理和分组转发。换言之，用户分组处理步骤由虚拟路由器506DPDK数据平面来执行。与分组速率高时的中断模式相比，这种“轮询模式”的性质使虚拟路由器506DPDK数据平面分组处理/转发更加有效。与内核模式虚拟路由器506相比，在分组I/O期间存在相对较少的中断和上下文切换，并且在一些情况下可以完全避免分组I/O期间的中断和上下文切换。

一般来说，每个网荚502A-502B可以被指派一个或多个虚拟网络地址以供在各自的虚拟网络内使用，其中每个虚拟网络可以与虚拟路由器506所提供的不同虚拟子网相关联。网荚502B例如可以指派它自己的虚拟第三层(L3)IP地址用于发送和接收通信，但是可能不知道网荚502B在其上执行的计算设备500的IP地址。因此，虚拟网络地址可能不同于底层物理计算机系统(例如计算设备500)的逻辑地址。

计算设备500包括虚拟路由器代理514，其控制用于计算设备500的虚拟网络的覆盖并且协调计算设备500内的分组的路由。一般来说，虚拟路由器代理514与用于虚拟化基础设施的网络控制器24通信，它生成用于创建虚拟网络和配置网络虚拟化端点的命令，诸如计算设备500并且更具体地说是虚拟路由器506，以及虚拟网络接口212。通过基于从网络控制器24接收的信息来配置虚拟路由器506，虚拟路由器代理514可以支持配置网络隔离、基于策略的安全、网关、源网络地址转换(SNAT)、负载均衡器和用于编排的服务链能力。

在一个示例中，由虚拟网络域内的容器529A-529B生成或消耗的网络分组，例如第三层(L3)IP分组或第二层(L2)以太网分组，可以被封装在另一个分组(例如，另一个IP或以太网分组)中，其由物理网络传送。在虚拟网络中传送的分组在本文中可以被称为“内部分组”，而物理网络分组在本文中可以被称为“外部分组”或“隧道分组”。物理网络分组内的虚拟网络分组的封装和/或解封装可以由虚拟路由器506执行。这个功能性在本文中被称为隧道传输并且可以被用来创建一个或多个覆盖网络。除了IPinIP之外，还可以使用的其他示例隧道传输协议包括通用路由封装(GRE)上的IP、VxLAN、GRE上的多协议标签交换(MPLS)、用户数据报协议(UDP)上的MPLS等。虚拟路由器506对源自/发往网荚502的任何容器的分组执行隧道封装/解封装，并且虚拟路由器506经由总线542和/或NIC 530的网桥来与网荚502交换分组。

如上面所指出，网络控制器24可以提供逻辑上集中化的控制器以促进一个或多个虚拟网络的操作。例如，网络控制器24可以维护路由信息库，例如存储用于物理网络以及一个或多个覆盖网络的路由信息的一个或多个路由表。虚拟路由器506为各自的虚拟网络(针对其，虚拟路由器506操作为各自的隧道端点)实现一个或多个虚拟路由和转发实例(VRF)，诸如VRF 222A。一般来说，每个VRF都存储用于对应的虚拟网络的转发信息，并且诸如利用隧道报头来标识分组要被转发到哪里以及分组是否要被封装在隧道传输协议中，隧道报头可以包括用于虚拟网络协议堆栈的不同层的一个或多个报头。每个VRF可以包括存储虚拟网络的路由和转发信息的网络转发表。

NIC 530可以接收隧道分组。虚拟路由器506处理隧道分组以从隧道封装报头中确定内部分组的源端点和目的地端点的虚拟网络。虚拟路由器506可以剥离第2层报头和隧道封装报头以仅内部地转发内部分组。隧道封装报头可以包括诸如VxLAN标签或MPLS标签之类的虚拟网络标识符，其指示虚拟网络，例如对应于VRF 222A的虚拟网络。VRF 222A可以包括内部分组的转发信息。例如，VRF 222A可以将内部分组的目的地第3层地址映射到虚拟网络接口212。作为响应，VRF 222A经由虚拟网络接口212将内部分组转发到网荚502A。

容器529A还可以将内部分组作为源虚拟网络端点。例如，容器529A可以生成第三层内部分组，该分组以另一个计算设备(即，不是计算设备500)执行的目的地虚拟网络端点或另一个容器为目的地。容器529A可以经由附接到VRF 222A的虚拟网络接口而将第3层内部分组发送到虚拟路由器506。

虚拟路由器506接收内部分组和第2层报头并确定内部分组的虚拟网络。虚拟路由器506可以使用任何上述虚拟网络接口实现技术(例如macvlan、veth等)来确定虚拟网络。虚拟路由器506使用与内部分组的虚拟网络相对应的VRF 222A来生成内部分组的外部报头，外部报头包括覆盖隧道的外部IP报头和标识虚拟网络的隧道封装报头。虚拟路由器506用外部报头封装内部分组。虚拟路由器506可以用新的第2层报头封装隧道分组，新的第2层报头具有与计算设备500外部的设备(例如，TOR交换机16或服务器12之一)相关联的目的地第2层地址。如果在计算设备500外部，虚拟路由器506使用物理功能221将具有新的第2层报头的隧道分组输出到NIC 530。NIC 530在出站接口上输出分组。如果目的地是在计算设备500上执行的另一个虚拟网络端点，则虚拟路由器506将分组路由到虚拟网络接口212、213中适当的一个。

在一些示例中，用于计算设备500的控制器(例如，图1的网络控制器24)在每个网荚502中配置默认路由以使虚拟机224使用虚拟路由器506作为出站分组的初始下一跳。在一些示例中，NIC 530配置有一个或多个转发规则以使从虚拟机224接收的所有分组被交换到虚拟路由器506。

网荚502A包括一个或多个应用容器529A。网荚502B包括cRPD代理326和容器化路由协议守护进程(cRPD)324的实例。cRPD代理326和CNI 570在该示例中通过gRPC接口582进行通信，但是也可以使用其他接口类型，例如REST。容器平台588包括容器运行时590、编排代理592、服务代理593和CNI 570。

容器引擎590包括可由微处理器510执行的代码。容器运行时590可以是一个或多个计算机过程。容器引擎590以容器529A-529B的形式运行容器化应用。容器引擎590可以表示Dockert、rkt或用于管理容器的其他容器引擎。一般来说，容器引擎590接收请求并管理诸如镜像、容器、网络和卷之类的对象。镜像是一个具有用于创建容器的指令的模板。容器是镜像的可执行实例。基于来自控制器代理592的指令，容器引擎590可以获得镜像并将它们实例化为网荚502A-502B中的可执行容器。

服务代理593包括可由微处理器510执行的代码。服务代理593可以是一个或多个计算机过程。服务代理593监控服务和端点对象的添加和移除，并且它维护计算设备500的网络配置以确保网荚和容器之间的通信，例如，使用服务。服务代理593还可以管理iptables(ip表)以捕获到服务的虚拟IP地址和端口的业务，并将业务重定向到代理所支持的网荚的代理端口。服务代理593可以表示用于Kubernetes集群的小节点的kube代理。在一些示例中，容器平台588不包括服务代理593或者服务代理593被禁用以有利于由CNI 570配置虚拟路由器506和网荚502。

编排代理592包括可由微处理器510执行的代码。编排代理592可以是一个或多个计算机过程。编排代理592可以表示服务器12的任何编排代理420或本公开中的其他编排代理。编排代理592可以表示用于Kubernetes集群的小节点的kubelet。编排代理592是编排器的代理(例如，图1的编排器23)，其接收容器的容器规范数据并确保容器由计算设备500执行。容器规范数据可以是从编排器23发送到编排代理592的清单文件的形式或经由命令行接口、HTTP端点或HTTP服务器而间接接收的。容器规范数据可以是容器的网荚502之一的容器规范(例如，PodSpec——描述网荚的YAML(另一种标记语言)或JSON对象)。基于容器规范数据，编排代理592引导容器引擎590以获得并实例化容器529的容器镜像，以供计算设备500执行容器529。

编排代理592实例化或以其他方式调用CNI 570以为每个网荚502配置一个或多个虚拟网络接口。例如，编排代理592接收网荚502A的容器规范数据并引导容器引擎590基于网荚502A的容器规格数据来创建具有容器529A的网荚502A。编排代理592还调用CNI 570来为网荚502A配置与VRF 222A相对应的虚拟网络的虚拟网络接口。在此示例中，网荚502A是与VRF 222A相对应的虚拟网络的虚拟网络端点。

CNI 570可以获得用于为网荚502配置虚拟网络接口的接口配置数据。虚拟路由器代理514作为虚拟网络控制平面模块操作，以用于使得网络控制器24能够配置虚拟路由器506。与编排控制平面(包括用于小节点和(多个)主节点的容器平台588(例如，编排器23)，其管理提供、调度和管理虚拟执行元件)不同，虚拟网络控制平面(包括用于小节点的网络控制器24和虚拟路由器代理514)管理部分地由小节点的虚拟路由器506在数据平面中实现的虚拟网络的配置。虚拟路由器代理514向CNI 570传送虚拟网络接口的接口配置数据，以使得编排控制平面元件(即CNI 570)能够根据网络控制器24所确定的配置状态来配置虚拟网络接口，从而桥接编排控制平面和虚拟网络控制平面之间的间隙。此外，这可以使得CNI570能够获得用于网荚的多个虚拟网络接口的接口配置数据并配置多个虚拟网络接口，这可以减少调用单独的CNI 570来配置每个虚拟网络接口所固有的通信和资源开销。

容器化路由协议守护进程在2022年2月1日提交的美国申请号17/649,632中被描述，该申请的全部内容通过引用并入本文。

图6是根据本公开的技术作为用于SDN架构系统的一个或多个集群的计算节点进行操作的示例计算设备的框图。计算设备1300可以表示一个或多个真实或虚拟服务器。在一些实例中，计算设备1300可以为相应的集群或为多个集群实现一个或多个主节点。

调度器1322、API服务器300A、控制器406A、自定义API服务器301A、自定义资源控制器302A、cRPD控制器305、控制器管理器1326、SDN控制器管理器1325、控制节点232A和配置存储库1328，尽管被图示和描述为由单个计算设备1300执行的，但是其可以被分布在构成计算系统或硬件/服务器集群的多个计算设备之中。换句话说，多个计算设备中的每一个可以为调度器1322、API服务器300A、控制器406A、自定义API服务器301A、自定义资源控制器302A、网络控制器管理器1326、网络控制器1324、SDN控制器管理器1325、控制节点232A或配置存储库1328中的任何一个或多个的一个或多个实例提供硬件操作环境。

在该示例中，计算设备1300包括耦合计算设备1300硬件环境的硬件组件的总线1342。总线1342耦合网络接口卡(NIC)1330、存储盘1346和一个或多个微处理器1310(以下称为“微处理器1310”)。在一些情况下，前端总线可以耦合微处理器1310和存储器设备1344。在一些示例中，总线1342可以耦合存储设备1344、微处理器1310和NIC 1330。总线1342可以表示外围组件接口(PCI)高速(PCIe)总线。在一些示例中，直接存储器访问(DMA)控制器可以控制耦合到总线242的组件之间的DMA传送。在一些示例中，耦合到总线1342的组件控制耦合到总线1342的组件之间的DMA传送。

微处理器1310可以包括一个或多个处理器，每个处理器包括独立的执行单元以执行符合指令集架构的指令，指令被存储到存储介质。执行单元可以被实现为分开的集成电路(IC)，或者可以被组合在一个或多个多核处理器(或“众核”处理器)内，其每个处理器都使用单个IC(即芯片多处理器)来实现。

盘1346表示计算机可读存储介质，其包括以用于存储诸如处理器可读指令、数据结构、程序模块或其他数据之类的信息的任何方法或技术来实现的易失性和/或非易失性、可移动和/或不可移动介质。计算机可读存储介质包括但不限于随机存取存储器(RAM)、只读存储器(ROM)、EEPROM、闪存、CD-ROM、数字通用光盘(DVD)或其他光学存储、磁盒、磁带、磁盘存储或其他磁存储设备、或者任何其他可以被用来存储期望信息并可由微处理器1310访问的介质。

主存储器1344包括一个或多个计算机可读存储介质，其可以包括随机存取存储器(RAM)，诸如各种形式的动态RAM(DRAM)例如DDR2/DDR3 SDRAM或静态RAM(SRAM)、闪存或任何其他形式的可以被用来以指令或数据结构的形式承载或存储期望程序代码和程序数据并且可以被计算机访问的固定或可移动存储介质。主存储器1344提供由可寻址存储器位置组成的物理地址空间。

网络接口卡(NIC)1330包括一个或多个接口3132，其被配置为使用底层物理网络的链路来交换分组。接口3132可以包括具有一个或多个网络端口的端口接口卡。NIC 1330还可以包括卡上存储器例如来存储分组数据。NIC 1330和耦合到总线1342的其他设备之间的直接存储器访问传送可以从/向NIC存储器读取/写入。

存储器1344、NIC 1330、存储盘1346和微处理器1310可以为包括在内核空间中执行的操作系统内核1314的软件堆栈提供操作环境。内核1314可以表示例如Linux、伯克利软件分发(BSD)、另一个Unix变体内核或可从微软公司获得的Windows服务器操作系统内核。在一些实例中，操作系统可以执行管理程序和一个或多个由管理程序所管理的虚拟机。示例管理程序包括用于Linux内核的基于内核的虚拟机(KVM)、Xen、可从VMware获得的ESXi、可从微软公司获得的Windows Hyper-V以及其他开源和专有管理程序。术语管理程序可以涵盖虚拟机管理器(VMM)。包括内核1314的操作系统为用户空间1345中的一个或多个过程提供执行环境。内核1314包括使用网络接口卡230的物理驱动程序1327。

计算设备1300可以耦合到包括覆盖网络的物理网络交换结构，该覆盖网络将交换结构从物理交换机扩展到耦合到交换结构的物理服务器的软件或虚拟路由器，诸如虚拟路由器21。计算设备1300可以使用一个或多个专用虚拟网络来配置集群的小节点。

API服务器300A、调度器1322、控制器406A、自定义API服务器301A、自定义资源控制器302A、控制器管理器1326和配置存储库1328可以实现集群的主节点并且替代地被称为“主组件”。集群可以是Kubernetes集群，并且主节点是Kubernetes主节点，在这种情况下，主组件是Kubernetes主组件。

API服务器300A、控制器406A、自定义API服务器301A、cRPD控制器305和自定义资源控制器302A中的每一个包括可由微处理器1310执行的代码。自定义API服务器301A验证并配置用于SDN架构配置的自定义资源的数据。服务可以是限定一组逻辑网荚和用于访问网荚的策略的抽象。基于服务定义来选择实现服务的一组网荚。服务可以部分地被实现为负载均衡器或以其他方式包括负载均衡器。API服务器300A和自定义API服务器301A可以实现表述性状态转移(REST)接口来处理REST操作，并且作为用于SDN架构的配置平面的一部分，将前端提供给存储到配置存储库1328的对应集群的共享状态。API服务器300A可以表示Kubernetes API服务器。

配置存储库1328是所有集群数据的后备存储库。集群数据可以包括集群状态和配置数据。配置数据还可以为服务发现提供后端和/或提供锁定服务。配置存储库1328可以被实现为键值存储库。配置存储库1328可以是中央数据库或分布式数据库。配置存储库1328可以表示etcd存储库。配置存储库1328可以表示Kubernetes配置存储库。

调度器1322包括可由微处理器1310执行的代码。调度器1322可以是一个或多个计算机过程。调度器1322监控新创建或请求的虚拟执行元件(例如，容器的网荚)并选择虚拟执行元件将在其上运行的小节点。调度器1322可以基于资源要求、硬件约束、软件约束、策略约束、位置等来选择小型节点。调度器1322可以表示Kubernetes调度器。

一般来说，API服务器1320可以调用调度器1322来调度网荚。调度器1322可以选择小节点并将所选小节点的标识符返回给API服务器1320，API服务器1320可以将该标识符写入到与网荚相关联的配置存储库1328。API服务器1320可以为所选小节点调用编排代理310，这可以使所选小节点的容器引擎208从存储服务器获得网荚并在小节点上创建虚拟执行元件。所选小节点的编排代理310可以将网荚的状态更新给API服务器1320，API服务器1320将这个新状态保存到配置存储库1328。以这种方式，计算设备1300在计算基础设施8中实例化新的网荚。

控制器管理器1326包括可由微处理器1310执行的代码。控制器管理器1326可以是一个或多个计算机过程。控制器管理器1326可以嵌入核心控制循环，通过从API服务器1320获得通知来监控集群的共享状态。控制器管理器1326可以尝试将集群的状态朝向期望状态移动。示例控制器406A、自定义资源控制器302A和cRPD控制器305可以由控制器管理器1326管理。其他控制器可以包括复制控制器、端点控制器、名称空间控制器和服务账户控制器。控制器管理器1326可以执行生命周期功能，诸如名称空间创建和生命周期、事件垃圾收集、终止的网荚垃圾收集、级联-删除垃圾收集、节点垃圾收集等。控制器管理器1326可以表示用于Kubernetes集群的Kubernetes控制器管理器。

本文所描述的用于SDN架构的网络控制器可以为在网络基础设施上操作的计算架构提供云联网。云联网可以包括面向企业或服务供应商的私有云、基础设施即服务(IaaS)以及面向云服务供应商(CSP)的虚拟私有云(VPC)。私有云、VPC和IaaS用例可能涉及多租户虚拟化数据中心，诸如关于图1所描述的。在这种情况下，数据中心内的多个租户共享相同的物理资源(物理服务器、物理存储、物理网络)。每个租户都指派有它自己的逻辑资源(虚拟机、容器或其他形式的虚拟执行元件；虚拟存储；虚拟网络)。除非安全策略特别允许，否则这些逻辑资源彼此隔离。数据中心的虚拟网络也可以互连到物理IP VPN或L2 VPN。

网络控制器(或“SDN控制器”)可以向网络提供网络功能虚拟化(NFV)，诸如商业边缘网络、宽带订户管理边缘网络和移动边缘网络。NFV涉及联网功能的编排和管理，诸如虚拟机、容器或其他虚拟执行元件中的防火墙、入侵检测或预防系统(IDS/IPS)、深度分组检测(DPI)、高速缓存、广域网(WAN)优化等，而不是在物理硬件设施上。

SDN控制器管理器1325包括可由微处理器1310执行的代码。SDN控制器管理器1325可以是一个或多个计算机过程。SDN控制器管理器1325作为面向编排的元件(例如，调度器1322、API服务器300A和自定义API服务器301A、控制器管理器1326和配置存储库1328)之间的接口来操作。一般而言，SDN控制器管理器1325为了新的Kubernetes原生对象(例如，网荚和服务)而监控集群。SDN控制器管理器1325可以隔离虚拟网络中的网荚并将网荚与服务连接。

SDN控制器管理器1325可以作为集群的主节点的容器来执行。在一些情况下，使用SDN控制器管理器1325使得能够禁用小节点的服务代理(例如，Kubernetes kube代理)，使得所有网荚连接性都使用虚拟路由器来实现，如本文所述。

网络控制器24的组件可以作为Kubernetes的CNI来操作，并且可以支持多种部署模式。CNI 17、CNI 750是用于管理Kubernetes的联网的这个整体CNI框架的计算节点接口。部署模式可以被划分为两类：(1)作为集成到工作负载Kubernetes集群中的CNI的SDN架构集群，以及(2)作为与工作负载Kubernetes集群分离的CNI的SDN架构集群。

与工作负载Kubernetes集群集成

在该示例中，网络控制器24的组件(例如，自定义API服务器301、自定义资源控制器302、cRPD控制器305、SDN控制器管理器1325和控制节点232)运行在主节点上被管理的Kubernetes集群中，靠近Kubernetes控制器组件。在这种模式下，网络控制器24的组件实际上是与工作负载相同的Kubernetes集群的一部分。

与工作负载Kubernetes集群分离

网络控制器24的组件将由与工作负载Kubernetes集群分离的Kubernetes集群来执行。

SDN控制器管理器1325可以使用用于编排平台的控制器框架来侦听(或以其他方式监控)在Kubernetes原生API中限定的对象的改变并且向这些对象中的一些添加注释。注释可以是标签或指定对象属性的其他标识符(例如，“虚拟网络绿色”)。SDN控制器管理器1325是SDN架构的一个组件，它侦听Kubernetes核心资源(诸如网荚、网络策略、服务等)事件，并根据需要将这些事件转换为用于SDN架构配置的自定义资源。CNI插件(例如CNI 17、570)是支持Kubernetes联网插件标准的SDN架构组件：容器网络接口。

SDN控制器管理器1325可以使用由聚合API 402所暴露的REST接口来为应用创建网络解决方案，以限定诸如虚拟网络、虚拟网络接口和访问控制策略之类的网络对象。网络控制器24组件可以通过例如在虚拟路由器中配置一个或多个虚拟网络和虚拟网络接口来实现计算基础设施中的网络解决方案。(这只是SDN配置的一个示例。)

用于此应用的以下示例部署配置由网荚和用于网荚的虚拟网络信息组成：

这个元数据信息可以被复制到由控制器管理器1326创建的每个网荚副本。当SDN控制器管理器1325被通知这些网荚时，SDN控制器管理器1325可以创建如注释中所列的虚拟网络(“red-network”、“blue-network”和上例中的“default/extns-network”)，并为每个虚拟网络创建每个网荚副本(例如，网荚202A)的虚拟网络接口，具有来自虚拟网络的集群范围地址块(例如,10.0/16)的唯一私有虚拟网络地址。

下面描述根据本公开的附加技术。Contrail是一个示例网络控制器架构。云原生Contrail控制器可以是本公开中描述的网络控制器的示例，诸如网络控制器24。

图7A是图示了根据本公开的技术的使用SDN架构的用于底层网络和覆盖网络配置的控制/路由平面的框图。图7B是图示了根据本公开的技术使用在底层网络中配置的隧道来连接网荚的已配置的虚拟网络的框图。

SDN架构的网络控制器24可以使用分布式或集中式路由平面架构。SDN架构可以使用容器化的路由协议守护进程(过程)。

从网络信令的角度来看，路由平面可以根据分布式模型工作，其中cRPD运行在集群中的每个计算节点上。这实质上意味着智能内置于计算节点中，并涉及每个节点处的复杂配置。该模型中的路由反射器(RR)可能不会做出智能路由决策，而是被用作中继以反映节点之间的路由。分布式容器路由协议守护进程(cRPD)是可以被使用的路由协议过程，其中每个计算节点运行其自己的路由守护进程实例。同时，集中式cRPD主实例可以充当RR，以便在计算节点之间中继路由信息。路由和配置智能被分布在中央位置处的具有RR的节点上。

路由平面可以替代地根据更集中化的模型来工作，其中网络控制器的组件集中地运行并吸收处理配置信息、构建网络拓扑以及将转发平面编程到虚拟路由器中所需的智能。虚拟路由器代理是本地代理，用于处理由网络控制器所编程的信息。这种设计导致促进计算节点处所需的更有限的智能，并且倾向于导致更简单的配置状态。

集中式控制平面提供以下内容：

·允许代理路由框架更简单且更轻便。BGP的复杂性和局限性对代理是隐藏的。代理不需要理解像路由区分器、路由目标等概念。代理只需交换前缀并相应地构建其转发信息

·控制节点可以做的不仅仅是路由。它们建立在虚拟网络概念之上，并且可以使用路由复制和重新发起来生成新路由(例如支持像服务链和VN间路由等特征以及其他用例)。

·为最佳广播和多播转发构建BUM树。

注意，对于某些方面，控制平面具有分布式性质。作为支持分布式功能性的控制平面，它允许每个本地虚拟路由器代理发布其本地路由并在需要知道的基础上订阅配置。

那么从工具POV考虑控制平面设计并在它们最适合的地方适当地使用手头的工具是有意义的。考虑contrail-bgp和cRPD的优缺点。

以下功能性可以由网络控制器24的控制节点或cRPD来提供。

路由守护进程/过程

控制节点和cRPD二者都可以充当实现不同协议并具有在数据平面中对路由信息进行编程的能力的路由守护进程。

cRPD利用丰富的路由堆栈来实现路由协议，其包括内部网关协议(IGP)(例如，中间系统到中间系统(IS-IS))、BGP-LU、BGP-CT、SR-MPLS/SRv6、双向转发检测(BFD)、路径计算元件协议(PCEP)等。它还可以被部署为提供诸如路由反射器之类的仅控制平面服务，并且由于这些能力而在互联网路由用例中很受欢迎。

控制节点232还实现路由协议但是主要是基于BGP的。控制节点232理解覆盖联网。控制节点232在覆盖虚拟化中提供丰富功能集并迎合SDN用例。诸如虚拟化(使用虚拟网络的抽象)和服务链之类的覆盖特征在电信和云供应商之中非常流行。在一些情况下，cRPD可能不包括对此类覆盖功能性的支持。然而，CRPD丰富功能集为底层网络提供了强大的支持。

网络编排/自动化

路由功能性只是控制节点232的一部分。覆盖联网的一个集成部分是编排。除了提供覆盖路由之外，控制节点232帮助对编排功能性进行建模并提供网络自动化。控制节点232的编排能力的核心是使用基于虚拟网络(和相关对象)的抽象来对网络虚拟化进行模拟的能力。控制节点232与配置节点230进行接口以将配置信息中继到控制平面和数据平面二者。控制节点232还协助为多播第2层和第3层构建覆盖树。例如，控制节点可以构建它所服务的集群的虚拟拓扑来实现这一点。cRPD通常不包括此类编排能力。

高可用性和水平可扩展性

控制节点设计是更集中化的，而cRPD是更分布式的。每个计算节点上都运行着一个cRPD工作节点。另一方面，控制节点232不在计算上运行，并且甚至可以在远程集群上运行(即，与工作负载集群分开并且在一些情况下在地理上远离工作负载集群)。控制节点232还为HA提供水平可扩展性并以主动-主动模式来运行。计算负载在控制节点232之间共享。另一方面，cRPD通常不提供水平可扩展性。控制节点232和cRPD二者都可以为HA提供平稳重启，并且可以允许数据平面在无头模式下操作——其中即使控制平面重启，虚拟路由器也可以运行。

控制平面应该不仅仅是路由守护进程。它应该支持覆盖路由和网络编排/自动化，而cRPD作为路由协议在管理底层路由方面做得很好。然而，cRPD通常缺乏网络编排能力，并且不提供对覆盖路由的强大支持。

因此，在一些示例中，SDN架构可以在计算节点上具有cRPD，如图7A-图7B中所示。图7A图示了SDN架构700，其可以表示SDN结构200或400的示例实现。在SDN架构700中，cRPD324在计算节点上运行并提供到数据平面的底层路由，同时运行提供编排和覆盖服务的控制节点232的集中式(和水平可扩展的)集合。在一些示例中，代替在计算节点上运行cRPD324，可以使用默认网关。

计算节点上的cRPD 324通过使用接口540(其可以是gRPC接口)来与虚拟路由器代理514交互从而提供到数据平面的丰富底层路由。虚拟路由器代理接口可以允许对路由进行编程、为覆盖配置虚拟网络接口，以及以其他方式配置虚拟路由器506。这在美国申请号17/649,632中被更详细地描述。同时，一个或多个控制节点232作为提供覆盖服务的分开的网荚来运行。因此，SDN架构700可以获得由控制节点232提供的丰富覆盖和编排以及在计算节点上的cRPD 324的现代底层路由以补充控制节点232。单独的cRPD控制器720可以被用来配置cRPD 324。cRPD控制器720可以是设备/元件管理系统、网络管理系统、编排器、用户界面/CLI或其他控制器。cRPD 324运行路由协议并与路由器交换路由协议消息，包括其他cRPD 324。每个cRPD 324可以是容器化路由协议过程并且实际上作为路由器控制平面的纯软件版本来操作。

由cRPD 324提供的增强的底层路由可以替换在数据平面处的默认网关并且为可以支持的用例提供丰富的路由堆栈。在不使用cRPD 324的一些示例中，虚拟路由器506将依赖默认网关进行底层路由。在一些示例中，作为底层路由过程的cRPD 324将被限制为利用控制平面路由信息仅对默认inet(6).0结构进行编程。在这样的示例中，非默认覆盖VRF可以由控制节点232编程。

图7A-图7B图示了上述双路由/控制平面解决方案。如图7A中所示，cRPD 324向虚拟路由器代理514提供底层路由/转发信息，在一些方面类似于路由器控制平面如何对路由器转发/数据平面进行编程。

如图7B中所示，cRPD 324在路由协议会话714中交换可用于为VRF创建通过底层网络702的隧道的路由信息。隧道710是一个示例并且连接服务器12A和服务器12X的虚拟路由器506。隧道710可以表示分段路由(SR)或SRv6隧道、通用路由封装(GRE)隧道和IP-in-IP隧道、LSP或其他隧道。控制节点232利用隧道710来创建虚拟网络712，虚拟网络712连接附接到虚拟网络的VRF的服务器12A和服务器12X的网荚22。使用本公开中描述的用于利用编排平台的配置框架来配置实现云原生SDN架构中的容器化网络路由器的控制平面的软件的技术，可以实现具有VRF以实现虚拟网络创建的cRPD 324的配置。

如上面所指出，cRPD 324和虚拟路由器代理514可以使用gRPC接口来交换路由信息，并且虚拟路由器代理5145可以使用gRPC接口用配置对虚拟路由器506进行编程。还注意到，控制节点232可以被用于覆盖和编排，而cRPD 324可以被用于管理底层路由协议。虚拟路由器代理514可以使用gRPC接口与cRPD 324同时使用XMPP来与控制节点和域名服务(DNS)通信。

gRPC模型适用于cRPD 324，因为每个计算节点上可能有一个工作程序(worker)在运行，并且虚拟路由器代理314充当gRPC服务器，为客户端(cRPD 324)暴露服务以用于对路由和配置信息进行编程(用于底层)。因此，在与XMPP相比时，gRPC作为一种解决方案很有吸引力。特别地，它将数据作为二进制流来传送，并且在对通过它发送的数据进行编码/解码时不会增加开销。

在一些示例中，控制节点232可以使用XMPP来与虚拟路由器代理514进行接口。在虚拟路由器代理514充当gRPC服务器的情况下，cRPD 324充当gRPC客户端。这意味着客户端(cRPD)需要启动与服务器(虚拟路由器代理vRouter Agent)的连接。SDN架构700，虚拟路由器代理514选择它将订阅到的一组控制节点232(因为存在多个控制节点)。在那方面，控制节点232充当服务器并且虚拟路由器代理514作为客户端进行连接并订阅更新。

利用gRPC，控制节点232将需要挑选它需要连接到的虚拟路由器代理514，然后作为客户端进行订阅。由于控制节点232不在每个计算节点上运行，这将需要实现一个算法来选择它可以订阅到的虚拟路由器代理514。此外，控制节点232需要在彼此之间同步该信息。这也使发生重启的情况变得复杂，并且需要在控制节点232之间进行同步以挑选它们所服务的代理。诸如平稳重启(GR)和快速收敛之类的特征已经在XMPP之上被实现。XMPP已经是轻量级且高效的。因此，对于控制节点232到虚拟路由器代理514的通信，XMPP可能优于gRPC。

对控制节点232的附加增强及其使用如下。具有三个控制节点的HA和水平可扩展性。与任何路由平台一样，仅具有两个控制节点232就足以满足HA要求。在许多情况下，这是有利的。(然而，可以使用一个或多个控制节点232)。例如，它提供更具确定性的基础设施并且符合标准路由最佳实践。每个虚拟路由器代理514被附接到唯一一对控制节点232以避免随机性。利用两个控制节点232，调试可能更简单。此外，用于构造多播/广播树的边缘复制可以被简化为只有两个控制节点232。目前，由于虚拟路由器代理314仅连接到三个控制节点中的两个，所以所有控制节点在一段时间内可能没有树的完整图片并且依靠BGP在它们之间对状态进行同步。由于虚拟路由器代理314可以随机选择两个，因此三个控制节点232会加剧这种情况。如果只有两个控制节点232，则每个虚拟路由器代理314将连接到相同的控制节点。这反过来意味着控制节点232不需要依赖BGP来对状态进行同步，并且将具有相同的多播树图片。

SDN结构200可以提供入口复制作为边缘复制的替代并且为用户提供选项。入口复制可以被视为一般覆盖多播树的一种特殊退化情况。然而，在实践中，入口复制树的信令比一般覆盖多播树的信令简单得多。利用入口复制，每个虚拟路由器21都以一棵树结束，该树以它自己为根并且每个其他虚拟路由器为叶。理论上，虚拟路由器21发生故障不会导致树的重建。注意，入口复制的性能随着集群的增大而恶化。但是，它适用于较小的集群。此外，对于许多客户来说，多播并不是一个流行和普遍的需求。它主要限于传送广播BUM业务，这只会在最初发生。

配置处理模块增强

在传统的SDN架构中，网络控制器处理所有用例的编排。配置节点基于数据模型将意图转换为配置对象，并将它们写入到数据库(例如，Cassandra)中。在一些情况下，同时例如经由RabbitMQ向所有等待配置的客户端发送通知。

控制节点不仅充当BGP扬声器，而且具有配置处理模块，其通过以下方式从数据库中读取配置对象。首先，当控制节点出现(或重启)时，它连接到数据库并直接从数据库读取所有配置。其次，控制节点也可以是消息传递客户端。当配置对象有更新时，控制节点接收到列出了已被更新的对象的消息通知。这再次导致配置处理模块从数据库中读取对象。

配置处理模块读取控制平面(BGP相关配置)和虚拟路由器数据平面的配置对象。配置可以被存储为图表，其中对象作为节点并且关系作为链接。然后可以将该图表下载到客户端(BGP/cRPD和/或虚拟路由器代理)。

根据本公开的技术，常规配置API服务器和消息传递服务在一些示例中被Kubeapi服务器(API服务器300和自定义API服务器301)替换并且之前的Cassandra数据库被Kubernetes中的etcd替换。通过此更改，对配置对象感兴趣的客户端可以直接观察etcd数据库以获取更新，而不是依赖RabbitMQ通知。

用于CRPD的控制器编排

可以向cRPD 324提供BGP配置。在一些示例中，cRPD控制器720可以是Kubernetes控制器，以开发它自己的控制器以迎合Kubernetes空间，并实现编排和供应cRPD 324所需的CRD。

分布式配置处理

如本节早先所提及的，配置处理模块可以是控制节点232的一部分。它直接从数据库读取配置，将数据转换成JSON格式，并将其作为图表而存储在其本地IFMAP数据库中，在图表中，对象作为节点并且它们之间的关系作为链接。该图表随后经由XMPP而被下载到计算节点上感兴趣的虚拟路由器代理514。虚拟路由器代理514也在本地构造基于IFMAP的依赖性图表以存储这些对象。

作为中间模块的IFMAP和用于存储依赖性图表的需要可以通过让虚拟路由器代理514直接观察API服务器300中的etcd服务器来避免。相同的模型可以由运行在计算节点上的Crpd 324来使用。这将避免需要IFMAP-XMPP配置通道。Kubernetes配置客户端(用于控制节点232)可以被用作此配置的一部分。这个客户端也可以被虚拟路由器代理使用。

然而，这会增加从etcd服务器读取配置的客户端的数量，尤其是在具有数百个计算节点的集群中。添加更多观察器(watcher)最终会导致写入率下降，并且事件率达不到理想水平。etcd的gRPC代理从一个服务器观察器重新广播到许多客户端观察器。gRPC代理将同一键或范围上的多个客户端观察器(c-watcher)合并为连接到etcd服务器的单个观察器(s-watcher)。代理将来自单个观察器的所有事件广播到它的客户端观察器。假设N个客户端观察同一个键，一个gRPC代理可以将etcd服务器上的观察负载从N减少到1。用户可以部署多个gRPC代理来进一步分发服务器负载。这些客户端共享一个服务器观察器；代理有效地减轻了核心集群的资源压力。通过添加代理，etcd可以每秒服务一百万个事件。

SDN架构中的DNS/Named

在以前的架构中，DNS服务由contrail-dns和contrail-named过程来提供，它们协同工作以向网络中的VM提供DNS服务。Named充当提供BIND协议的实现的DNS服务器。contrail-dns从虚拟路由器代理接收更新并将这些记录推送给named。

在系统中支持四种DNS模式，IPAM配置可以选择需要的DNS模式。

1.无——没有DNS支持VM。

2.默认DNS服务器——VM的DNS解析是基于服务器基础设施中的名称服务器配置来完成的。当VM获得DHCP响应时，子网默认网关被配置作为VM的DNS服务器。VM发送到此默认网关的DNS请求经由在相应计算节点上配置的(结构)名称服务器而被解析，并且响应被发送回VM。

3.租户DNS服务器——租户可以使用这种模式来使用他们自己的DNS服务器。可以在IPAM中配置服务器列表，然后在DHCP响应中将其作为(单个)DNS服务器而发送到VM。基于可用路由信息像任何其他分组一样路由VM发送的DNS请求。

4.虚拟DNS服务器——在此模式下，系统支持虚拟DNS服务器，提供对来自VM的DNS请求进行解析的DNS服务器。我们可以在系统中在每个域下限定多个虚拟域名服务器。每个虚拟域名服务器都是针对已配置的DNS域的权威服务器。

本文所描述的SDN架构在其提供的DNS服务方面是高效的。云原生世界中的客户将从各种DNS服务中受益。然而，随着转向下一代基于Kubernetes的架构，SDN架构可能会改为使用coreDNS来提供任何DNS服务。

数据平面

数据平面由两个组件组成：虚拟路由器代理514(又名：代理)和虚拟路由器数据平面506(也称为DPDK虚拟路由器/内核虚拟路由器)。SDN架构解决方案中的代理514负责管理数据平面组件。代理514与两个控制节点232建立XMPP邻居关系，然后与它们交换路由信息。虚拟路由器代理514还动态地生成流条目并将它们注入到虚拟路由器506中。这向虚拟路由器506给出了关于如何转发分组的指令。

代理514的职责可以包括：与控制节点232进行接口以获得配置。将接收到的配置转换为数据路径可以理解的形式(例如，将数据模型从IFMap转换为由数据路径使用的数据模型)。与控制节点232进行接口以管理路由。并从数据路径收集统计数据并将其导出到监控解决方案。

虚拟路由器506实现可以允许虚拟网络接口与VRF相关联的数据平面功能性。每个VRF都有它自己的转发表和流表，而MPLS表和VXLAN表在虚拟路由器506内是全局的。转发表可以包括针对目的地的IP地址和MAC地址的路由，并且IP到MAC的关联被用来提供代理ARP能力。MPLS表中的标签的值在VM/容器接口出现时由虚拟路由器506选择，并且仅对该虚拟路由器在本地有意义。VXLAN网络标识符在域内的不同虚拟路由器506中的同一虚拟网络的所有VRF上是全局的。

在一些示例中，每个虚拟网络具有分配给它的默认网关地址，并且每个VM或容器接口在初始化时接收到的DHCP响应中接收该地址。当工作负载向其子网外部的地址发送分组时，它将对与网关的IP地址相对应的MAC进行ARP，并且虚拟路由器506以其自己的MAC地址进行响应。因此，虚拟路由器506可以支持所有虚拟网络的完全分布式默认网关功能。

以下是由虚拟路由器506实现的分组流转发的示例。

同一子网中的VM/容器接口之间的分组流。

工作节点可以是VM或容器接口。在一些示例中，分组处理过程如下：

·VM1/容器接口需要向VM2发送分组，因此虚拟路由器506首先在其自己的DNS高速缓存中查找IP地址，但是由于这是第一个分组，因此没有条目。

·VM1向当其接口出现时在DHCP响应中所供应的DNS服务器地址发送DNS请求。

·虚拟路由器506捕获DNS请求并将其转发到在SDN架构控制器中运行的DNS服务器。

·控制器中的DNS服务器用VM2的IP地址进行响应

·虚拟路由器506向VM1发送DNS响应

·VM1需要形成以太网帧，因此需要用于VM2的MAC地址。它检查它自己的ARP高速缓存，但是没有条目，因为这是第一个分组。

·VM1发出ARP请求。

·虚拟路由器506捕获ARP请求并在其自己的转发表中查找用于IP-VM2的MAC地址，并在控制器为VM2而发送的L2/L3路由中找到关联。

·虚拟路由器506向VM1发送ARP回复，其中包括VM2的MAC地址

·VM1的网络堆栈中发生TCP超时

·VM1的网络堆栈重试发送分组，并且这次在ARP高速缓存中找到了VM2的MAC地址，并且可以形成以太网帧并将其发送出去。

·虚拟路由器506查找用于VM2的MAC地址并且找到封装路由。虚拟路由器506构建外部报头并将得到的分组发送到服务器S2。

·服务器S2上的虚拟路由器506对分组进行解封装并查找MPLS标签以识别将原始以太网帧发送到的虚拟接口。以太网帧被发送到该接口并被VM2接收。

不同子网中的VM之间的分组流

在一些示例中，除了虚拟路由器506作为默认网关进行响应之外，将分组发送到不同子网中的目的地时的顺序是相似的。VM1将在以太网帧中发送分组与默认网关的MAC地址，其IP地址在VM1启动时虚拟路由器506所供应的DHCP响应中被供应。当VM1对网关IP地址进行ARP请求时，虚拟路由器506以其自己的MAC地址进行响应。当VM1使用该网关MAC地址发送以太网帧时，虚拟路由器506使用帧内的分组的目的地IP地址来查找VRF中的转发表以找到路由，该路由将经由封装隧道到达在其上运行目的地的主机。

图10是图示了根据本公开的技术的用于软件定义联网架构系统的示例操作模式1000的流程图。网络控制器包括用于网络资源自定义资源的自定义资源控制器305(以下称为“控制器305”)，其可以被用来配置容器化路由协议过程，诸如cRPD 324。控制器305响应于检测到作为网络资源自定义资源的实例的网络资源31配置对象的配置更新，通过将从网络资源31配置对象生成的配置数据发送到执行容器化路由协议过程的实例的服务器来协调网络资源31配置对象的预期状态(1002)。服务器12A利用从网络资源31配置对象生成的配置数据来配置在服务器12A上执行的容器化路由协议过程cRPD 324的实例(1004)。

图11是图示了根据本公开的技术的软件定义联网架构系统内的服务器的示例操作模式1100的流程图。作为服务器进行操作的计算设备500执行cRPD 324，容器化路由协议过程，并且接收从由诸如cRPD控制器305之类的自定义资源控制器所管理的网络资源31配置对象生成的配置数据(1102)。计算设备500利用配置数据来配置cRPD 324(1104)。cRPD324基于从网络资源31配置对象生成的配置数据来对虚拟路由器数据平面506进行编程以转发网络业务(1106)。

除上述之外或作为上述的替代，描述了以下示例。在以下任何示例中描述的特征可以与本文所描述的任何其他示例一起使用。

示例1：一种软件定义联网(SDN)架构系统，包括：网络控制器，该网络控制器包括用于配置容器化路由协议过程的用于网络资源自定义资源的自定义资源控制器和处理电路，其中用于网络资源自定义资源的自定义资源控制器被配置用于由处理电路执行以：响应于检测到作为网络资源自定义资源的实例的网络资源配置对象的配置更新，通过将从网络资源配置对象生成的配置数据发送到执行容器化路由协议过程的实例的服务器来协调网络资源配置对象的预期状态；以及该服务器，其中该服务器被配置为利用从网络资源配置对象生成的配置数据来配置在服务器上执行的容器化路由协议过程的实例。

示例2：根据示例1所述的SDN架构系统，其中从网络资源配置对象生成的配置数据包括用于路由器的抽象配置数据。

示例3：根据示例2所述的SDN架构系统，还包括将抽象配置数据转换成配置数据，该配置数据被结构化为符合容器化路由协议过程的数据模型；并且利用配置数据来配置容器化路由协议过程的实例。

示例4：根据示例1至3中任一项所述的SDN架构系统，其中网络控制器还包括配置节点，该配置节点被配置用于由处理电路执行，并且其中该配置节点包括自定义应用编程接口(API)服务器，用于处理对用于SDN架构配置的自定义资源的操作请求，该自定义资源包括与网络资源配置对象相对应的网络资源。

示例5：根据示例4所述的SDN架构系统，其中自定义API服务器被配置为接收对网络资源的实例的操作请求并且应用该操作来为配置存储库中的网络资源的实例创建预期状态数据，并且其中自定义资源控制器被配置为响应于预期状态数据的创建，将网络资源的实例的实际状态协调为配置存储库中的预期状态数据。

示例6：根据示例1至5中任一项所述的SDN架构系统，其中网络控制器由包括服务器的编排系统集群来实现。

示例7：根据示例1至6中任一项所述的SDN架构系统，其中网络控制器被配置为接收在服务器上创建虚拟执行元件的请求，其中响应于在服务器上创建虚拟执行元件的请求，网络控制器使容器网络接口插件(CNI)通知用于容器化路由协议过程的实例的代理，其中代理从自定义资源控制器获得虚拟执行元件的虚拟网络接口配置数据，并且将虚拟网络接口配置数据提供给CNI，并且其中CNI使用虚拟执行元件的虚拟网络接口配置数据来配置虚拟执行元件的虚拟网络接口。

示例8：根据示例7所述的SDN架构系统，其中网络控制器包括SDN控制器管理器，其被配置为：响应于检测到在服务器上创建虚拟执行元件的请求，创建网络资源配置对象。

示例9：根据示例7和8中任一项所述的SDN架构系统，其中网络资源配置对象用于配置虚拟网络接口、虚拟网络或互联网协议地址之一。

示例10：根据示例7至9中任一项所述的SDN架构系统，其中代理订阅到自定义资源控制器以接收从网络资源配置对象生成的配置数据。

示例11：根据示例7至10中任一项所述的SDN架构系统，其中网络资源配置对象是路由实例的实例。

示例12：根据示例1至11中任一项所述的SDN架构系统，其中用于容器化路由协议过程的实例的代理获得BGPRouter资源的配置对象，并且其中代理利用从配置对象生成的配置数据来配置容器化路由协议过程的实例。

示例13：一种方法，包括：由执行容器化路由协议过程的服务器接收从由自定义资源控制器所管理的网络资源配置对象生成的配置数据；由服务器利用配置数据来配置容器化路由协议过程；以及由容器化路由协议过程基于从网络资源配置对象生成的配置数据来对虚拟路由器数据平面进行编程以转发网络业务。

示例14：根据示例13所述的方法，其中从网络资源配置对象生成的配置数据包括用于路由器的抽象配置数据。

示例15：根据示例14所述的方法，还包括：将抽象配置数据转换为配置数据，该配置数据被结构化为符合容器化路由协议过程的数据模型；以及利用配置数据来配置容器化路由协议过程的实例，该配置数据被结构化为符合容器化路由协议过程的数据模型。

示例16：根据示例13至15中任一项所述的方法，由在服务器上执行的容器网络接口插件(CNI)通知用于网荚部署的容器化路由协议过程的代理，该代理在服务器上执行；由代理从自定义资源控制器获得网荚的虚拟网络接口配置数据，并将虚拟网络接口配置数据提供给CNI；并且由CNI使用网荚的虚拟网络接口配置数据配置网荚的虚拟网络接口。

示例17：根据示例13至16中任一个所述的方法，还包括：由代理订阅到自定义资源控制器以接收从网络资源配置对象生成的配置数据。

示例18：根据示例13至17中任一项所述的方法，还包括：由用于容器化路由协议过程的实例的代理获得BGPRouter资源的配置对象，其中代理在服务器上执行；并且由代理利用从配置对象生成的配置数据来配置容器化路由协议过程的实例。

示例19：一种方法，包括：响应于检测到作为网络资源自定义资源的实例的网络资源配置对象的配置更新，由用于网络资源自定义资源的自定义资源控制器通过将从网络资源配置对象生成的配置数据发送到执行容器化路由协议过程的实例的服务器来协调网络资源配置对象的预期状态；以及利用服务器，利用从网络资源配置对象生成的配置数据来配置在服务器上执行的容器化路由协议过程的实例。

示例20：根据示例19所述的方法，其中从网络资源配置对象生成的配置数据包括用于路由器的抽象配置数据。

本文所描述的技术可以以硬件、软件、固件或其任何组合来实现。被描述为模块、单元或组件的各种特征可以在集成逻辑设备中一起实现，或者单独被实现为分立但可互操作的逻辑设备或其他硬件设备。在一些情况下，电子电路的各种特征可以被实现为一个或多个集成电路设备，诸如集成电路芯片或芯片组。

如果以硬件来实现，则本公开可以涉及诸如处理器或集成电路设备之类的装置，诸如集成电路芯片或芯片组。替代地或附加地，如果以软件或固件来实现，则这些技术可以至少部分地由包括指令的计算机可读数据存储介质来实现，这些指令在被执行时使处理器执行上述方法中的一个或多个。例如，计算机可读数据存储介质可以存储这样的指令以供处理器执行。

计算机可读介质可以形成计算机程序产品的一部分，其可以包括封装材料。计算机可读介质可以包括计算机数据存储介质，诸如随机存取存储器(RAM)、只读存储器(ROM)、非易失性随机存取存储器(NVRAM)、电可擦除可编程只读存储器(EEPROM)、闪存、磁性或光学数据存储介质等等。在一些示例中，制造品可以包括一个或多个计算机可读存储介质。

在一些示例中，计算机可读存储介质可以包括非暂时性介质。术语“非暂时性”可以指示存储介质未被体现在载波或传播的信号中。在某些示例中，非暂时性存储介质可以存储会随时间变化的数据(例如，在RAM或高速缓存中)。

代码或指令可以是由包括一个或多个处理器的处理电路执行的软件和/或固件，处理器诸如一个或多个数字信号处理器(DSP)、通用微处理器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其他等效的集成或分立逻辑电路。因此，本文中所使用的术语“处理器”可以指代任何前述结构或适合于实现本文所描述的技术的任何其他结构。此外，在一些方面，本公开中描述的功能性可以被提供在软件模块或硬件模块内。

Claims (14)

1.一种软件定义联网SDN架构系统，包括：

网络控制器，所述网络控制器包括处理电路和用于配置容器化路由协议过程的针对网络资源自定义资源的自定义资源控制器，

其中针对所述网络资源自定义资源的所述自定义资源控制器被配置用于由所述处理电路执行以：响应于检测到针对网络资源配置对象的配置更新，通过向执行容器化路由协议过程的实例的服务器发送从所述网络资源配置对象生成的配置数据，协调所述网络资源配置对象的预期状态，所述网络资源配置对象是所述网络资源自定义资源的实例；以及

所述服务器，其中所述服务器被配置为利用从所述网络资源配置对象生成的所述配置数据来配置在所述服务器上执行的所述容器化路由协议过程的所述实例。

2.根据权利要求1所述的SDN架构系统，

其中从所述网络资源配置对象生成的所述配置数据包括针对路由器的抽象配置数据。

3.根据权利要求2所述的SDN架构系统，还包括：由所述服务器执行的配置驱动程序，所述配置驱动程序被配置为：

将所述抽象配置数据转换为被结构化为符合针对所述容器化路由协议过程的数据模型的配置数据；以及

利用所述配置数据来配置所述容器化路由协议过程的所述实例。

4.根据权利要求1-3中任一项所述的SDN架构系统，

其中所述网络控制器还包括配置节点，所述配置节点被配置用于由所述处理电路执行，并且

其中所述配置节点包括自定义应用编程接口API服务器，以处理针对对用于SDN架构配置的自定义资源的操作的请求，所述自定义资源包括与所述网络资源配置对象相对应的网络资源。

5.根据权利要求4所述的SDN架构系统，

其中所述自定义API服务器被配置为：接收针对对所述网络资源的实例的操作的请求，并且应用所述操作来针对配置存储库中的所述网络资源的所述实例创建预期状态数据，并且

其中所述自定义资源控制器被配置为：响应于所述预期状态数据的创建，将所述网络资源的所述实例的实际状态协调为所述配置存储库中的所述预期状态数据。

6.根据权利要求1-3中任一项所述的SDN架构系统，其中所述网络控制器由包括所述服务器的编排系统集群实现。

7.根据权利要求1-3中任一项所述的SDN架构系统，

其中所述网络控制器被配置为接收在所述服务器上创建虚拟执行元件的请求，

其中响应于在所述服务器上创建所述虚拟执行元件的所述请求，所述网络控制器使容器网络接口插件CNI通知针对所述容器化路由协议过程的所述实例的代理，

其中所述代理从所述自定义资源控制器获得针对所述虚拟执行元件的虚拟网络接口配置数据，并且向所述CNI提供所述虚拟网络接口配置数据，并且

其中所述CNI使用针对所述虚拟执行元件的所述虚拟网络接口配置数据来配置针对所述虚拟执行元件的虚拟网络接口。

8.根据权利要求7所述的SDN架构系统，其中所述网络控制器包括SDN控制器管理器，所述SDN控制器管理器被配置为：

响应于检测到在所述服务器上创建所述虚拟执行元件的请求，创建所述网络资源配置对象。

9.根据权利要求7所述的SDN架构系统，其中所述网络资源配置对象用于配置虚拟网络接口、虚拟网络、或互联网协议地址中的一个。

10.根据权利要求7所述的SDN架构系统，其中所述代理向所述自定义资源控制器订阅以接收从所述网络资源配置对象生成的所述配置数据。

11.根据权利要求7所述的SDN架构系统，其中所述网络资源配置对象是路由实例的实例。

12.根据权利要求1-3中任一项所述的SDN架构系统，

其中针对所述容器化路由协议过程的所述实例的代理获得针对BGPRouter资源的配置对象，并且

其中所述代理利用从所述配置对象生成的配置数据来配置所述容器化路由协议过程的所述实例。

13.一种软件定义联网SDN方法，所述SDN方法由权利要求1-12所述的SDN架构系统中的任一个执行。

14.一种计算机可读存储介质，所述计算机可读存储介质被编码有指令，所述指令用于使一个或多个可编程处理器执行方法，所述方法由权利要求1-12所述的软件定义联网SDN架构系统中的任一个执行。