CN115941593A

CN115941593A - 用于云本地软件定义网络架构的虚拟网络路由器

Info

Publication number: CN115941593A
Application number: CN202211213578.6A
Authority: CN
Inventors: 迈克尔·亨克尔; 普拉萨德·梅里亚拉; 爱德华·图卢洛; 纳根德拉·普拉萨特·马纳塔迈·普雷姆·钱德兰; 阿图尔·S·莫盖
Original assignee: Juniper Networks Inc
Current assignee: Juniper Networks Inc
Priority date: 2021-10-04
Filing date: 2022-09-30
Publication date: 2023-04-07
Also published as: EP4160411A1; US20230106531A1

Abstract

本公开涉及用于云本地软件定义网络架构的虚拟网络路由器。总体上，描述了用于在软件定义网络(SDN)架构内创建虚拟网络路由器的技术。用于SDN架构系统的网络控制器可以包括被配置为执行配置节点和控制节点的处理电路。配置节点可以对创建虚拟网络路由器(VNR)的请求进行处理，其中，虚拟网络路由器可以致使网络控制器使第一虚拟网络(VN)与第二VN互连。VNR可以表示一个或多个策略的逻辑抽象，该一个或多个策略致使在第一VN与第二VN之间的路由信息的导入和/或导出。控制节点根据该一个或多个策略对第一VN和第二VN进行配置，以使得经由VNR在第一VN与第二VN之间导入和/或导出路由信息。

Description

用于云本地软件定义网络架构的虚拟网络路由器

相关申请

本申请要求保护于2022年6月29日提交的美国专利申请号17/809,659、于2022年5月6日提交的美国临时专利申请号63/364,283、以及于2021年10月4日提交的印度临时专利申请号202141044924的权益，通过引用将各个申请的全部内容结合在此。

技术领域

本公开涉及一种虚拟化的计算基础设施，并且更具体地，涉及云本地网络。

背景技术

在典型的云数据中心环境中，存在提供运行各种应用的计算和/或存储能力的互连服务器的大型集合。例如，数据中心可以包括托管用户(即，数据中心的客户)的应用和服务的设施。例如，数据中心可以托管全部的基础设施设备，诸如联网与存储系统、冗余电源、以及环境控制。在典型的数据中心中，存储系统与应用服务器的集群经由由一层或多层物理网络交换机和路由器提供的高速交换结构而互连。更精密的数据中心为遍布世界各地的基础设施提供位于各种物理托管设施中的用户支持设备。

虚拟化数据中心正变成现代信息技术(IT)基础设施的核心基础。具体地，现代数据中心具有广泛应用的虚拟化环境，在该环境中，诸如虚拟机或容器的虚拟主机，此处，也被称为虚拟运行元件，被部署在物理计算设备的底层计算平台上并且在物理计算设备的底层计算平台上运行。

数据中心或包括一个或多个服务器的任意环境内的虚拟化能够提供若干优点。一个优点在于，虚拟化能够提供显著提高的效率。由于底层物理计算设备(即，服务器)随着每个物理CPU具有大量内核的多核微处理器架构的出现而变得日益强大，虚拟化变得更容易并且更高效。第二个优点在于，虚拟化提供对计算基础设施的有效控制。由于诸如基于云的计算环境中的物理计算资源变成可替代的资源，计算基础设施的提供与管理变得更容易。由此，企业IT员工通常除虚拟化所提供的效率和增加投资回报率(ROI)之外，由于其管理优势而喜欢数据中心的虚拟化计算集群。

容器化是基于操作系统级虚拟化的虚拟化方案。容器是用于彼此隔离并且与主机隔离的应用的轻量级与便携式运行元件。因为容器并不紧密地耦接至主机硬件计算环境，所以应用能够被绑定至容器图像并且作为单个轻量级包在支持底层容器架构的任意主机或虚拟主机上运行。因此，容器解决了如何使软件在不同的计算环境中工作的问题。容器提供从一个计算环境到另一虚拟或物理环境的持续运行的保证。

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

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

发明内容

总之，描述了用于云本地软件定义网络(SDN)架构的技术。在一些实施例中，SDN架构可以包括在计算节点中实现的数据平面元件、以及诸如路由器或交换机的网络设备，并且SDN架构还可以包括用于创建和管理虚拟网络的网络控制器。将SDN架构配置与控制平面设计成具有支持服务中升级的基于容器的微服务架构的扩展的云本地软件。可以实施用于配置平面的配置节点而暴露自定义资源。用于SDN架构配置的这些自定义资源可以包括通常由网络控制器暴露的配置元件，但是，可以使配置元件与Kubernetes本地/内置资源一起进行合并，以支持由聚合API层暴露、由Kubernetes控制器和自定义资源控制器实现的统一预期模型，自定义资源控制器致力于协调SDN架构的实际状态与预期状态。

用于SDN架构配置的自定义资源包括虚拟网络路由器，虚拟网络路由器表示用于使通过SDN架构所实现的虚拟网络之间互联并且实现通信的逻辑抽象。虚拟网络路由器自定义资源的实例便于使用针对相应的虚拟网络而在路由实例内配置的导入和导出路由目标而交换(指非对称或对称的导入和导出)路由信息。因此，实际上，虚拟网络路由器能够实现针对SDN架构所定义的虚拟网络资源之间的路由泄露。因为虚拟网络路由器资源隐藏了用于实现各种虚拟网络资源的VRF之间的虚拟路由与转发实例(VRF或“路由实例”)配置的复杂细节，所以该技术提供用于定义SDN架构中所配置的虚拟网络资源与相应的虚拟网络之间的互连的直观、基于预期的模型并且甚至改善对边界网关协议和VRF配置不熟悉的人的使用性。

该技术可以提供一个或多个额外的技术优点。例如，云本地SDN架构可以解决常规SDN架构中与生命周期管理的复杂性、强制性高的资源分析组件、配置管理中的规模限制、以及基于命令行接口(CLI)的接口缺少有关的限制。例如，用于SDN架构的网络控制器是具有简化安装占用面积的云本地、轻量级分布式应用。这还便于更容易并且模块化地升级配置和控制平面的配置节点与控制节点的各种组件微服务。

该技术可以进一步实现可选的云本地监测(遥测)与用户接口、使用连接至支持DPDK容器池的基于数据平面开发的开发套件(基于DPDK)虚拟路由器的容器的高性能数据平面、以及在一些情况下利用诸如Kubernetes或Openstack的已有编排平台的配置框架的云本地配置管理。作为云本地架构，网络控制器是可扩展的并且具有弹性，以解决并且支持多个集群。在一些情况下，网络控制器还可以支持关键性能指示符(KPI)的扩展性与性能需求。

在一个实施例中，该技术的各个方面涉及一种用于软件定义网络(SDN)架构系统的网络控制器，网络控制器包括：处理电路；配置节点，被配置为由处理电路执行；以及控制节点，被配置为由处理电路执行；其中，配置节点可执行为对创建虚拟网络路由器的请求进行处理，其中，虚拟网络路由器被配置为致使网络控制器使在SDN架构系统内操作的第一虚拟网络和第二虚拟网络互连，虚拟网络路由器表示一个或多个策略的逻辑抽象，一个或多个策略致使发生在第一虚拟网络与第二虚拟网络之间的路由信息的导入和导出的一项或多项；并且其中，控制节点根据该一个或多个策略对第一虚拟网络和第二虚拟网络进行配置，以能够实现经由虚拟网络路由器在第一虚拟网络与第二虚拟网络之间的路由信息的导入和导出的一项或多项。

在另一实施例中，该技术的各个方面涉及一种方法，包括：由网络控制器对创建虚拟网络路由器的请求进行处理，其中，虚拟网络路由器被配置为致使网络控制器使在SDN架构系统内操作的第一虚拟网络和第二虚拟网络互连，虚拟网络路由器表示一个或多个策略的逻辑抽象，该一个或多个策略致使发生在第一虚拟网络与第二虚拟网络之间的路由信息的导入和导出的一项或多项；并且由网络控制器根据该一个或多个策略对第一虚拟网络和第二虚拟网络进行配置，以能够实现经由虚拟网络路由器在第一虚拟网络与第二虚拟网网络之间的路由信息的导入和导出的一项或多项。

在另一实施例中，该技术的各个方面涉及一种包括指令的非暂时性计算机可读介质，指令用于致使网络控制器的处理电路：对创建虚拟网络路由器的请求进行处理，其中，虚拟网络路由器被配置为致使网络控制器使在SDN架构系统内操作的第一虚拟网络和第二虚拟网络互连，虚拟网络路由器表示一个或多个策略的逻辑抽象，该一个或多个策略致使发生在第一虚拟网络与第二虚拟网络之间的路由信息的导入和导出的一项或多项；并且根据该一个或多个策略对第一虚拟网络和第二虚拟网络进行配置，以能够实现经由虚拟网络路由器在第一虚拟网络与第二虚拟网网络之间的路由信息的导入和导出的一项或多项。

在下面所附附图与描述中对本公开的一个或多个实施例的细节进行了阐述。从描述与附图、并且从权利要求中，其他特征、目标、以及优点将显而易见。

附图说明

图1是示出示例性计算基础设施的框图，其中，可以实现此处所描述的技术的实施例。

图2是示出根据本公开的技术的用于云本地网络的云本地SDN架构的实施例的框图。

图3是进一步详细地示出根据本公开的技术的SDN架构的组件的另一视图的框图。

图4是示出根据本公开的技术的SDN架构的示例性组件的框图。

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

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

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

图7B是示出根据本公开的技术的使用底层网络中所配置的隧道连接容器池的已配置虚拟网络的框图。

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

图9是示出在依赖于不同的自定义资源类型的自定义资源类型之间创建、监视、并且协调的示例性的流的框图。

图10、图11、图12A、图12B、图13A、图13B、图14、图15和图16是示出根据本公开中所描述的技术的各个方面的虚拟网络路由器可以被配置为实现虚拟网络之间的互连的各个实例的示图。

图17A、图17B、图17C和图17D是示出根据本公开中所描述的技术的各个方面的当在SDN架构内建立一个或多个虚拟网络路由器时所执行的操作的流程图。

图18是示出执行本文所描述的技术的各个方面的图1的实施例中所示的计算机架构的操作的另一流程图。

类似参考标号标识贯穿描述与图的类似元件。

具体实施方式

图1是示出可以实现此处所描述的技术的示例的示例性计算基础设施8的框图。用于虚拟网络的软件定义网络(SDN)架构的当前实现方式由于例如生命周期管理的复杂性、资源分析组件的强制性高、配置模块的扩展性限制、以及无基于命令行接口(CLI)的(如kubectl)接口而使得云本地采用面临挑战。计算基础设施8包括此处所描述的云本地SDN架构系统，云本地SDN架构系统解决了这些挑战并且使得电信云本地时代现代化。云本地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架构可以与编排平台(例如，编排器23)进行集成，诸如，Kubernetes、OpenShift、Mesos、OpenStack、VMware vSphere，并且可以与服务供应商操作支持系统/业务支持系统(OSS/BSS)进行集成。

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

尽管主要将客户站点11和公共网络15示出并且描述为服务供应商网络7的边缘网络，然而，在一些实施例中，客户站点11与公共网络15中的一个或多个网络可以是任意数据中心10内的租户网络。例如，数据中心10可以托管各自与一个或多个虚拟私有网(VPN)相关联的多个租户(客户)，其中每个租户可以实现一个或多个客户站点11。

服务供应商网络7提供到所附接的客户站点11、数据中心10、以及公共网络15的基于封包的连接。服务供应商网络7可以表示由服务供应商所持有并且操作的网络，以使多个网络互连。服务供应商网络7可以实现多协议标签切换(MPLS)转发，并且在该实例中，可以被称为MPLS网络或MPLS骨干网。在一些实例中，服务供应商网络7表示提供来自一个或多个服务供应商的服务的多个互连的自主系统，诸如，互联网。

在一些实施例中，每个数据中心10可以表示多个地理分布的网络数据中心中的一个网络数据中心，多个地理分布的网络数据中心可以经由服务供应商网络7、专用网络链路、黑光纤、或其他连接而连接至彼此。如图1的示例中示出的，数据中心10可以包括为客户提供网络服务的设施。服务供应商的客户可以是诸如企业和政府或个体的统称实体。例如，网络数据中心可以托管若干企业与端用户的网络服务。其他示例性的服务可以包括数据存储、虚拟私有网、流量工程、文件服务、数据挖掘、科学或超计算等。尽管被示出为服务供应商网络7的分立边缘网络，然而，可以将诸如一个或多个物理网络功能(PNF)或虚拟化网络功能(VNF)的数据中心10中的元件包括在服务供应商网络7的核心内。

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

在示出的示例中，交换结构14包括耦合至机箱式(或“脊”或“核心”)交换机18A-18M(统称“机箱式(chassis)交换机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元组：<源网络地址，目的地网络地址，源端口，目的地端口，协议>对封包的单个流进行识别。通常，该5元组识别与所接收的封包所对应的封包流。n元组指从5元组中抽取的任意n项。例如，封包的2元组可以指该封包的<源网络地址，目的地网络地址>或<源网络地址，源端口>的组合。

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

可以通过对服务器的资源进行虚拟化而使服务器12中的任意一服务器配置有诸如容器池或虚拟机的虚拟执行元件，以提供在服务器上运行的一个或多个进程(应用)之间的某种程度的隔离。“基于管理程序”、或“硬件级”、或“平台”虚拟化指创建各自包括用于运行一个或多个进程的访客操作系统的虚拟机。通常，虚拟机提供用于在隔离的虚拟环境中执行应用的虚拟化/访客操作系统。因为从主机服务器的物理硬件对虚拟机进行可视化，所以执行应用与主机的硬件及其他虚拟机隔离。每个虚拟机可以配置有用于在对应的虚拟网络上进行通信的一个或多个虚拟网络接口。

虚拟网络指在物理网络之上实现的逻辑构造。虚拟网络可以用于替代基于VLAN的隔离并且在虚拟化数据中心中提供多租户，例如，数据中心10。每个租户或应用能够具有一个或多个虚拟网络。除非安全策略明确允许，否则，每个虚拟网络必须与全部其他的虚拟网络隔离。

虚拟网络可以使用数据中心10网关路由器(图1中未示出)连接至物理多协议标签交换(MPLS)第3层虚拟私有网(L3VPN)和以太网虚拟私有网(EVPN)网络，并且在物理多协议标签交换(MPLS)第3层虚拟私有网(L3VPN)和以太网虚拟私有网(EVPN)网络上扩展。虚拟网络还可以用于实现网络功能虚拟化(NFV)和服务链接。

能够使用各种机制实现虚拟网络。例如，每个虚拟网络可以实现为虚拟局域网(VLAN)、虚拟私有网(VPN)等。还能够使用两个网络-由IP结构20和交换结构14构成的物理底层网络与虚拟覆盖网络，实现虚拟网络。物理底层网络的作用是提供“IP结构”，IP结构提供从任意物理设备(服务器、存储设备、路由器、或交换机)到任意其他物理设备的单播IP连接。底层网络可以提供从网络中的任意点到该网络中的任意其他点的统一低延迟、非阻塞、高带宽连接。

如下面关于虚拟路由器21进一步描述的(被示出为并且此处也被称为“vRouter21”)，在服务器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上的至少一个虚拟执行元件。)

“基于容器的”或“操作系统”虚拟化指操作系统在单个机器(虚拟或物理)上运行多个隔离系统的虚拟化。该隔离系统表示诸如由开源DOCKER容器应用或由CoreOS Rkt(“Rocket”)提供的这些容器。如同虚拟机，每个容器被虚拟化并且可以保持与主机及其他容器隔离。然而，不同于虚拟机，每个容器可以省去独立的操作系统并且反而提供应用套件和应用特定的库。通常，容器由主机运行作为隔离的用户-空间实例并且容器可以与在主机上运行的其他容器共享操作系统和共同的库。由此，容器可能需要比虚拟机(“VM”)更低的处理能力、存储、以及网络资源。一组一个或多个容器可以被配置为共享用于在对应的虚拟网络上进行通信的一个或多个虚拟网络接口。

在一些示例中，由其主机内核管理容器，以允许在一些情况下使用命名空间隔离功能对资源(CPU、存储器、块I/O、网络等)进行限制和优先化，而无需启动任意的虚拟机，命令空间隔离功能允许操作环境的应用(例如，给定容器)视图完全隔离，包括进程树、联网、用户标识符、以及挂载文件系统。在一些实施例中，可以根据Linux容器(LXC)、使用单个Linux内核在控制主机上运行多个隔离的Linux系统(容器)的操作系统级虚拟化方法，对容器进行部署。

服务器12托管在此处由IP结构20和交换结构14表示的物理网络上进行操作的一个或多个虚拟网络的虚拟网络端点。尽管主要相对于基于数据中心的交换网络进行了描述，然而，诸如服务供应商网络7的其他物理网络可以位于一个或多个虚拟网络的底层。

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

服务器12各自包括至少一个网络接口卡(NIC)13，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可以实现例如Linux操作系统可用的Virtio，半虚拟化框架，Virtio提供仿真NIC功能作为一种类型的虚拟硬件组件，以向虚拟网络端点提供虚拟网络接口。作为另一示例，一个或多个服务器12可以实现Open vSwitch，以在所托管的虚拟机的一个或多个虚拟NIC(vNIC)之间执行分布式虚拟多层切换，其中，该vNIC还可以表示向虚拟网络端点提供虚拟网络接口的一种类型的虚拟硬件组件。在一些实例中，虚拟硬件组件是虚拟I/O(例如，NIC)组件。在一些实例中，虚拟硬件组件是SR-IOV虚拟功能。在一些示例中，服务器12中的任意一服务器可以实现Linux网桥，该Linux网桥仿真硬件网桥并且在服务器的虚拟网络接口之间或在服务器的虚拟网络接口与服务器的物理网络接口之间转发封包。对于由服务器托管的容器的Docker实现方式，在服务器上运行、在容器之间切换封包的Linux网桥或其他操作系统网桥可以被称为“Docker网桥”。如此处使用的，术语“虚拟路由器”可以涵盖Contrail或钨结构虚拟路由器、Open vSwitch(OVS)、OVS网桥、Linux网桥、Docker网桥、或位于主机设备上并且在一个或多个虚拟网络的虚拟网络端点之间执行切换、桥接、或路由封包的其他设备和/或软件，在虚拟网络中，由一个或多个服务器12托管虚拟网络端点。

任意NIC 13可以包括在与NIC相关联的虚拟硬件组件之间切换数据的内部设备交换机。例如，对于支持SR-IOV的NIC，内部设备交换机可以是在SR-IOV虚拟功能之间并且对应地在被配置为使用SR-IOV虚拟功能的端点之间进行切换的虚拟以太网网桥(VEB)，其中，每个端点可以包括访客操作系统。可替代地，内部设备交换机可以被称为NIC交换机，或对于SR-IOV实现方式，可以被称为SR-IOV NIC交换机。与NIC 13A相关联的虚拟硬件组件可以与由NIC 13A或负责配置NIC 13A的软件进程分配的第2层目的地地址相关联。物理硬件组件(或SR-IOV实现方式的“物理功能”)也与第2层目的地地址相关联。

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

虚拟路由器21终止虚拟网络覆盖隧道并且基于封包的隧道封装报头确定所接收的封包的虚拟网络、并且将封包转发至该封包的适当目的地虚拟网络端点。例如，对于服务器12A，对于从由服务器12A托管的虚拟网络端点(例如，容器池22)出站的每个封包，虚拟路由器21为该封包附加指示虚拟网络的隧道封装报头，以生成封装或“隧道”封包，并且虚拟路由器21经由虚拟网络的覆盖隧道将封装封包输出至诸如另一个服务器12的物理目的地计算设备。如此处使用的，虚拟路由器21可以执行隧道端点的操作，以对源自虚拟网络端点的内部封包进行封装，以生成隧道封包，并且解封隧道封包，以获得用于路由至其他虚拟网络端点的内部封包。

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

在一些示例中，虚拟路由器21可以是支持数据平面开发套件(DPDK)的虚拟路由器。在该示例中，虚拟路由器21使用DPDK作为数据平面。在该模式下，虚拟路由器21作为链接至DPDK库(未示出)的用户空间应用而运行。这就是虚拟路由器的执行版本并且通常由电信公司使用，其中，VNF通常是基于DPDK的应用。虚拟路由器21作为DPDK虚拟路由器的执行能够实现比操作为基于内核的虚拟路由器的虚拟路由器高十倍的吞吐量。由DPDK的轮询模式驱动器(PMD)、而非Linux内核的基于中断的驱动器，使用物理接口。

诸如vfio或uio_pci_generic的用户-I/O(UIO)内核模块可以用于使物理网络接口的寄存器暴露至用户空间，以使得DPDK PMD可访问寄存器。当NIC 13A被绑定至UIO驱动器时，使NIC 13A从Linux内核空间移至用户空间并且因此Linux OS不再进行管理、亦不可见。因此，DPDK应用(即，在该示例中，为虚拟路由器21A)完全管理NIC 13。这包括封包轮询、封包处理、以及封包转发。可以由虚拟路由器21DPDK数据平面执行用户封包处理步骤，内核(其中，在图1中未示出内核)参与有限或不参与。与中断模式相比较，具体当封包速率较高时，该“轮询模式”的性质使得虚拟路由器21DPDK数据平面封包处理/转发更高效。在封包I/O期间存在有限的中断或不存在中断、并且存在上下文切换。在瞻博网络公司的Kiran KN等人于2021年发表的“DAY ONE:CONTRAIL DPDK vROUTER”中找到了DPDK vRouter的示例的额外细节，通过引用将其全部内容结合在此。

计算基础设施8实现用于使跨服务器12的虚拟执行元件的部署、扩展、以及操作自动化的自动化平台，以提供用于执行应用工作负载和服务的虚拟化基础设施。在一些示例中，平台可以是提供以容器为中心的基础设施的容器编排系统，以使容器的部署、扩展、以及操作自动化，从而提供以容器中心的基础设施。在虚拟化计算基础设施的上下文中，“编排”通常指向编排平台可用的主机服务器供应、调度、并且管理在该虚拟执行元件上运行的虚拟执行元件和/或应用以及服务。例如，容器编排可以便于容器协调并且指由容器编排平台将容器部署、管理、扩展、并且配置到主机服务器。编排平台的示例性实例包括Kubernetes(容器编排系统)、Docker swarm、Mesos/Marathon、OpenShift、OpenStack、VMware、以及亚马逊ECS。

计算基础设施8的自动化平台的元件至少包括服务器12、编排器23、以及网络控制器24。可以使用基于集群的框架将容器部署到虚拟化环境，在框架中，集群的集群主节点管理容器到集群的一个或多个集群从节点的部署与操作。此处使用的术语“主节点”与“从节点”涵盖区分集群的主管理元件与集群的主容器托管设备的模拟设备的不同编排平台术语。例如，Kubernetes平台使用术语“集群主节点”和“从节点”，而Docker Swarm平台指集群管理器与集群节点。

编排器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是跨公共云和私有云提供便携性的容器管理平台，其中每个云可以向容器管理平台提供虚拟化基础设施。下面参考图3对Kubernetes编排系统的示例性组件进行描述。

在一个示例中，容器池22是Kubernetes容器池并且是虚拟网络端点的示例。容器池是一组中一个或多个逻辑相关的容器(图1中未示出)、用于容器的共享存储器、以及关于如何运行容器的选项。可替代地，如果针对执行被实例化，则容器池可以被称为“容器池复制品”。容器池22的每个容器是虚拟执行元件的示例。容器池的容器始终共同位于单一服务器上、被共同调度、并且在共享上下文中运行。容器池的共享上下文可以是Linux命名空间、cgroups、以及其他隔离方面的集合。

在容器池的上下文中，各个应用可能进一步应用子隔离。通常，容器池内的容器具有共同的IP地址和端口空间并且能够经由本地主机而对彼此进行检测。因为他们具有共享上下文，所以容器池内的容器还可以使用进程间通信(IPC)而彼此进行通信。IPC的示例包括SystemV信号量或POSIX共享存储器。通常，作为不同容器池的成员的容器具有不同的IP地址，并且在缺少用于启用该特征的配置的情况下，容器不能通过IPC进行通信。作为不同容器池的成员的容器反而通常经由容器池IP地址而彼此进行通信。

服务器12A包括用于运行诸如容器池22中的这些容器化应用的容器平台19。容器平台19从编排器23接收请求，以获得容器并且使容器托管在服务器12A中。容器平台19获得并且运行容器。

容器网络接口(CNI)17配置用于虚拟网络端点的虚拟网络接口。编排器23与容器平台19使用CNI 17来管理容器池(包括容器池22)的网络。例如，CNI 17创建使容器池连接至虚拟路由器21的虚拟网络接口并且能够使得该容器池的容器经由虚拟网络接口而通信至虚拟网络上的其他虚拟网络端点。例如，CNI 17可以将用于虚拟网络的虚拟网络接口插入到容器池22的容器的网络命名空间中并且配置(或请求配置)用于虚拟路由器21中的虚拟网络的虚拟网络接口，以使得虚拟路由器21被配置为将经由虚拟网络接口从虚拟网络接收的封包发送至容器池22的容器并且从容器池22的容器发送经由虚拟网络上的虚拟网络接口所接收的包。CNI17可以分配网络地址(例如，用于虚拟网络的虚拟IP地址)并且可以设置用于虚拟网络接口的路由。

在Kubernetes中，默认全部容器池能够在不使用网络地址转换(NAT)的情况下与全部其他的容器池进行通信。在一些情况下，编排器23与网络控制器24创建由全部命名空间所共享的服务虚拟网络和容器池虚拟网络，从命名空间分别分配服务与容器池网络地址。在一些情况下，在全部命名空间中Kubernetes集群中产生的全部容器池彼此能够进行通信，并且可以从由编排器23指定的容器池子网分配全部容器池的网络地址。当用户为容器池创建隔离的命名空间时，编排器23与网络控制器24可以为新的隔离命名空间创建新的容器池虚拟网络和新的共享服务虚拟网络。在隔离命名空间中在Kubernetes集群中产生的容器池从新的容器池虚拟网络中获得网络地址，并且该容器池的对应服务从新的服务虚拟网络中获得网络地址。

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

可以由编排器23调用CNI 17。出于CNI规范之目的，容器可以被认为与Linux网络命名空间是同步的。与此对应的单元取决于具体的容器运行时实现方式：例如，在诸如rkt的应用容器规范的实现方式中，每个容器池在唯一的网络命名空间中运行。然而，在Docker中，通常存在对每个单独的Docker容器的网络命名空间。出于CNI规范之目的，网络指可唯一寻址并且能够彼此进行通信的一组实体。这可以是单个的容器、机器/服务器(实际或虚拟)、或某一其他网络设备(例如，路由器)。可以将容器概念性地添加至一个或多个网络或者从一个或多个网络中概念性地移除容器。CNI规范规定了一致插件(“CNI插件”)的许多考虑因素。

容器池22包括一个或多个容器。在一些示例中，容器池22包括容器化DPDK工作负载，该容器化DPDK工作负载被设计成使用DPDK来加快封包处理，例如，通过使用DPDK库与其他组件交换数据而加快封包处理。在一些示例中，虚拟路由器21可以作为容器化DPDK工作负载而运行。

容器池22配置有用于通过虚拟路由器21发送并且接收封包的虚拟网络接口26。虚拟网络接口26可以是容器池22的默认接口。容器池22可以将虚拟网络接口26实现为以太网接口(例如，命名为“eth0”)，而虚拟路由器21可以将虚拟网络接口26实现为分接接口、virtio用户接口、或其他类型的接口。

容器池22与虚拟路由器21使用虚拟网络接口26交换数据封包。虚拟网络接口26可以是DPDK接口。容器池22与虚拟路由器21可以使用vhost设置虚拟网络接口26。容器池22可以根据聚合模型进行操作。容器池22可以使用诸如具有vhost-用户适配器的virtio设备的虚拟设备，用于虚拟网络接口26的用户空间容器进程间通信。

CNI 17可以结合图1中所示的一个或多个其他组件为容器池22配置虚拟网络接口26。容器池22中的任意容器可以利用(即，共享)容器池22的虚拟网络接口26。

虚拟网络接口26可以表示虚拟以太网(“veth”)对，其中，该对的每端是独立设备(例如，Linux/Unix设备)，且该对的一端被分配给容器池22并且该对的一端被分配给虚拟路由器21。veth对或veth对的一端有时被称为“端口”。虚拟网络接口可以表示具有被分配给容器池22和虚拟路由器21的媒体接入控制(MAC)地址的macvlan网络，以在容器池22的容器与虚拟路由器21之间进行通信。可替代地，例如，虚拟网络接口可以被称为虚拟机接口(VMI)、容器池接口、容器网络接口、分接接口、veth接口、或简称网络接口(在具体地上下文中)。

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

作为创建容器池22的过程的一部分，编排器23请求网络控制器24为一个或多个虚拟网络(配置数据中所指示的)创建相应的虚拟网络接口。对于其所归属的每个虚拟网络，容器池22可以具有不同的虚拟网络接口。例如，虚拟网络接口26可以是用于具体虚拟网络的虚拟网络接口。可以为其他虚拟网络配置额外的虚拟网络接口(未示出)。

网络控制器24处理请求，以生成用于容器池22的虚拟网络接口的接口配置数据。接口配置数据可以包括容器或容器池唯一标识符以及针对各个虚拟网络接口指定用于配置虚拟网络接口的网络配置数据的列表或其他数据结构。用于虚拟网络接口的网络配置数据可以包括网络名称、所分配的虚拟网络地址、MAC地址、和/或域名服务器值。下面是JavaScript对象符号(JSON)格式的接口配置数据的示例。

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

下面是用于容器池22的虚拟网络接口26的示例性接口配置数据。

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

根据本公开中所描述的技术，网络控制器24是使用一个或多个配置节点30以及一个或多个控制节点32实现的用于软件定义网络(SDN)的云本地分布式网络控制器。每个配置节点30自身可以使用一个或多个云本地组件微服务而实现。每个控制节点32自身可以使用一个或多个云本地组件微服务而实现。

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

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

为了使多个虚拟网络互连，网络控制器24可以使用(并且在底层和/或虚拟路由器21中配置)利用虚拟网络路由器(VNR)资源所定义的导入和导出策略。虚拟网络路由器资源可以用于通过配置用于实现SDN架构中的虚拟网络的相应路由实例之间的路由信息的导入和导出而定义虚拟网络之间的连接。单一网络控制器24可以支持多个Kubernetes集群，并且由此，VNR允许在一个命名空间中连接多个虚拟网络、在不同的命名空间中连接虚拟网络、在Kubernetes集群中连接虚拟网络、并且跨Kubernetes集群连接虚拟网络。VNR还可以扩展为跨网络控制器24的多个实例支持虚拟网络连接。可替代地，此处，VNR可以被称为虚拟网络策略(VNP)或虚拟网络拓扑。

如图1的实施例中所示，网络控制器24可以保持代表表示策略的虚拟网络(VN)50A-50N(“VN 50”)的配置数据(例如，配置数据30)以及用于通过物理底层网络和/或诸如虚拟路由器21(“vRouter 21”)的虚拟路由器而在数据中心10内建立VN 50的其他配置数据。网络控制器24还可以保持表示至少可以部分使用策略而实现的虚拟网络路由器(VNR)52A-52N(“VNR 52”)的配置数据(例如，配置数据30)以及用于在VN50之间建立互连的其他配置数据。

诸如管理员的用户可以与网络控制器24的UI 60交互，以对VN 50和VNR 52进行定义。在一些实例中，UI 60表示便于键入定义VN 50和VNR 52的配置数据的图形用户接口(GUI)。在其他实例中，UI 60可以表示命令行接口(CLI)或其他类型的接口。假设UI 60表示图形用户接口，管理员则可以通过布置表示不同容器池(诸如，容器池22)的图形元件使容器池与VN 50相关联而对VN 50进行定义，其中，任意VN 50能够实现被分配给该VN的一个或多个容器池之间的通信。

在该方面，管理员可以理解Kubernetes或其他编排平台，但是，并非完全理解支持VN 50的底层基础设施。诸如Contrail的一些控制器架构可以基于与传统物理网络中的路由协议相似(如果不是大致相似)的联网协议对VN 50进行配置。例如，Contrail可以利用来自边界网关协议(BGP)的构思，即，在所谓的自主系统(ASes)内并且有时在ASes之间通信路由信息所使用的路由协议。

存在不同版本的BGP，诸如，用于在ASes内通信路由信息的内部BGP(iBGP)、以及用于在ASes之间通信路由信息的外部BGP(eBGP)。ASes可能与Contrail内的项目构思有关，即，也与Kubernetes中的命名空间相似。在AS、项目、以及命名空间的各个实例中，AS、类似项目、以及命名空间可以表示共享路由信息并且由此便于网络之间互连(或在该实例中，为VN 50)的一个或多个网络(例如，一个或多个VN 50)的统称。

VNR 52以最简单的形式表示在Kubernetes的上下文中所设定的路由器的逻辑抽象，其中，可以将VNR 52定义为便于VN 50之间互连的自定义资源。假设Kubernetes管理员不能根据诸如BGP的复杂路由协议而完全理解路由信息的复杂传播，云本地联网技术的各个方面可能便于将底层路由协议(或Contrail或其他控制器架构的补充过程)抽象画成VNR52。

即，并非诉诸于定义如何在两个以上VN 50之间进行路由，而是管理员可以定义使VN 50互连的一个或多个VNR 52，而无需手动开发和部署大量的策略和/或路由实例配置，以能够在该VN 50之间交换路由信息。替代地，管理员(可能略微理解路由协议)可以使用熟悉的Kubernetes语法/语义(或甚至仅通过拖曳图形元件并且指定例如表示VNR 52A的该图形元件与再次例如表示VN 50A和50N的图形元件之间的互连)对自定义资源(例如，一个或多个VNR 52)进行定义。

在该方面，管理员可能易于使用图1中的实施例所示的逻辑抽象作为VNR 50而使VN 50互连，因此，网络控制器24可以将VNR 50转换成底层路由目标，以自动(即，干预较少或可能无任何人类干预)致使交换VN 50A和50N的路由信息并且能够实现VN 50A与50N之间的通信(即，交换封包或其他数据)。

假定管理员可以采用熟悉的Kubernetes语法/语义对VNR 50进行配置，而非对符合路由协议语法/语义的复杂配置数据进行配置，网络控制器24可以促进更好的用户体验，同时还促进数据中心8自身的更高效操作。即，管理员键入该管理员不熟悉的配置数据可能导致错误配置，从而浪费数据中心8的底层资源(就处理周期、存储器、总线带宽等、以及相关联的功率而言)，同时还使得网络拓扑的适当实现方式延迟(可能阻止在VN 50之间成功地路由封包及其他数据)。该延迟可能不仅使得管理员受挫，而且还使得与VN 50相关联、需要VN 50的提示操作来实现业务目标的客户受挫。通过使管理员使用被示出为VNR 52的逻辑抽象而易于促进VN50之间的通信，数据中心8自身可能经历更高效的操作(就上述计算资源而言，包括处理器周期、存储器、总线带宽、以及相关联的功率)，同时为管理员和客户提供更好的用户体验。

在操作中，网络控制器24(表示数据中心10的SDN架构系统)包括实现配置节点和控制节点的处理电路(参考图3中的实施例进行了更详细地描述)。网络控制器24可以被配置为使在由数据中心10表示的SDN架构系统内操作的第一虚拟网络(例如，VN 50A)和第二虚拟网络(例如，VN 50N)互连。网络控制器24可以被配置为对一个或多个策略的逻辑抽象进行定义，以经由一个或多个VNR 52(例如，VNR 52A)执行该互连。

策略可以包括与通过虚拟网络(在该实施例中，可以指VN 50A和50N)而维护的路由信息有关的导入和导出策略。即，可以经由表示VNR 52A的自定义资源对Kubernetes进行扩展，以将VNR 52A转换成相对于VN 50A和VN 50N所部署的一个或多个导入和导出策略，以经由VN 50A与VN 50N之间的路由信息分布而对相互通信进行配置。一旦被配置，VN 50A则可以将路由信息(例如，表示VN 50A的路由)导出至VN 50N并且将路由信息(例如，表示VN50N的路由)导入至VN 50A。同样，VN 50N可以将路由信息(例如，表示VN 50N的路由)导出至VN 50A并且将路由信息(例如，表示VN 50A的路由)导入至VN 50N。

抽象化可以隐藏底层路由配置，以能够实现该路由泄露，诸如，定义到用于实现VN50A与VN 50N的路由实例的路由信息导入和导出的路由目标。替代地，网络控制器24可以将VNR 52A转换成共同的路由目标并且经由用于实现VN 50A与VN 50N(在该示例中)的路由实例的共同路由目标，对路由信息的通信进行配置。

为了实现网状连接，网络控制器24可以将VN 50A、VN 50N、以及VNR 52A的路由实例的导入和导出配置有与VN 50A、VN 50N、以及VNR 52A相关联的路由目标。为了实现轴辐式(hub-and-spoke)连接，网络控制器24可以对与VN 50A和VN 50N相关联的路由实例的导出进行配置，以将路由信息导出至与VNR 52A(用作中心)相关联的路由实例和VNR 52A的路由实例，以将路由信息导入至与VN 50A和VN 50N相关联的路由实例。在该轴辐式连接中，VN50A和VN 50N彼此可能不直接进行通信。

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

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

SDN架构可以使用网络用户接口和遥测组件提供基础设施、集群、以及应用方面的见解。遥测节点可以是云本地并且包括支持见解的微服务。

由于此处其他地方所描述的上述及其他特征，计算基础设施8实现云本地的SDN架构并且可以提供一个或多个下列技术优点。例如，网络控制器24是具有简化安装足迹的云本地、轻量级分布式应用。这还便于更容易并且模块化地升级配置节点30及控制节点32的各种组件微服务(以及本公开中所描述的网络控制器的其他示例的任意其他组件)。本技术可以进一步实现可选的云本地监测(遥测)与用户接口、使用连接至支持DPDK的容器池的基于DPDK的虚拟路由器的容器的高性能数据平面、以及在一些情况下利用现有编排平台的配置框架(诸如Kubernetes或Openstack)的优点的云本地配置管理。作为云本地架构，网络控制器24是对多个集群进行寻址并且支持多个集群的可扩展和弹性架构。在一些情况下，网络控制器24还可以支持关键性能指标(KPI)的扩展性和性能需求。

例如，具有诸如此处所描述的特征和技术优点的SDN架构能够用于实现云本地电信云，以支持5G移动网络(以及后续几代)和边缘计算、以及包括例如高性能的云本地应用托管的企业Kubernetes平台。电信云应用迅速地移向容器化的云本地方案。5G固定与移动网络正在驱动将工作负载部署为具有显著解聚的微服务的需求，具体地，在5G下一代RAN(5GNR)中进行部署。5G下一代核心网(5GNC)可能被部署成与3GPP描述的各个不同组件对应的基于微服务的应用集。当被视为交付应用的微服务组时，5GNC可能是具有复杂网络、安全性、以及策略需求的容器池的高度复杂组合。对于这种用例，能够利用此处所描述的具有用于网络、安全性、以及策略的良好定义构造的云本地SDN架构。网络控制器24可以提供能够创建这些复杂构造的相关API。

同样，5GNC内的用户平面功能(UPF)是超高性能应用。其可以作为高度分布的高性能容器池集进行交付。此处所描述的SDN架构能够提供非常高吞吐量的数据平面(就每个区段的比特(bps)和每秒的封包(pps)而言)。与具有近期性能增强eBPF的DPDK虚拟路由器并且与智能NIC进行集成，将有助于实现所需吞吐量。在于2022年2月1日提交的题为“CONTAINERIZED ROUTER WITH VIRTUAL NETWORKING”的美国申请号17/649,632中对基于DPDK的虚拟路由器进行了进一步详细的描述，通过引用将其全部内容结合在此。

由于工作负载从更传统的虚拟化工作负载迁移至容器化微服务，所以在GiLAN中，高性能处理也可能是相关的。在UPF与GiLAN服务的数据平面中，诸如GiLAN防火墙、入侵检测与预防、虚拟化IP多媒体子系统(vIMS)语音/视频等，吞吐量较高并且在bps和pps方面持续不变。对于5GNC功能的控制平面，诸如接入与移动管理功能(AMF)、会话管理功能(SMF)等，以及对于一些GiLAN服务(例如，IMS)，当绝对流量在bps方面可以适中时，小封包的优势是pps将保持较高。在一些示例中，SDN控制器与数据平面为服务器12上实现的每个虚拟路由器21每秒提供数百万的封包。在5G无线电接入网络(RAN)中，为了从由传统无线电供应商提供的专有垂直集成RAN堆栈移开，开放式RAN对多个组件中的RAN硬件和软件进行解耦，组件包括非RT的无线电智能控制器(RIC)、近实时RIC、集中单元(CU)控制平面与用户平面(CU-CP与CU-UP)、分布式单元(DU)、以及无线电单元(RU)。如果需要，将软件组件部署在利用可编程加速器实现的商业服务器架构上。此处所描述的SDN架构可以支持O-RAN规范。

边缘计算可能主要针对两种不同的用例。第一种情况是作为容器化电信基础设施(例如，5G RAN、UPF、安全功能)的支撑，并且第二种情况是用于电信以及诸如供应商或企业客户的第三方的容器化服务工作负载。在两种情况下，边缘计算实际上是GiLAN的特殊情况，其中，流量中断，以在高度分布的位置处进行特殊处理。在许多情况下，这些位置将具有有限的资源(功率、冷却、空间)。

此处所描述的SDN架构可能非常适合于支持非常轻量级的占用面积的需求、可以支持与相关联的控制功能较远的站点中的计算与存储资源、并且可以通过部署工作负载与存储器的方式而感知位置。一些站点可能具有如一个或两个一样少的计算节点，计算节点将非常具体的服务集交付至高度本地化的用户或其他服务集。可能存在站点的层次结构，其中，中心站点与多个路径密集地连接，区域站点与两个或四个上行链路路径多重连接，并且远程边缘站点可以具有仅到一个或两个上游站点的连接。

这需要可以部署SDN架构的方式与覆盖内的隧穿流量终止并且被绑定到核心传输网络(SRv6、MPLS等)的方式(和位置)的极端灵活性。同样，在托管电信云基础设施工作负载的站点中，此处所描述的SDN架构可以支持高性能工作负载所需的专用硬件(GPU、智能NIC等)。还可能存在需要SR-IOV的工作负载。因为，SDN架构还可以支持在ToR处创建VTEP并且使VTEP作为VXLAN链接回至覆盖。

预期存在每个站点运行其自身的主集群的全分布Kubernetes微集群的混合，并且SDN架构可以支持类似远程计算的情景。

对于涉及企业Kubernetes平台、高性能云本地应用功率金融服务平台、在线游戏服务、以及所托管的应用服务供应商的用例，交付这些应用的云平台必须提供高性能、针对故障的弹性、高安全性以及可见性。这些平台上所托管的应用趋于在内部开发。应用开发人员和平台拥有者与基础设施团队一起工作，以对组织应用的实例进行部署和操作。这些应用趋于需要高吞吐量(每个服务器>20Gbps)和低延迟。一些应用还可以使用多播用于信令或有效载荷流量。可以利用额外的硬件与网络基础设施来确保可用性。应用与微服务利用集群内的命令空间进行分区。在高度安全的环境中，命名空间之间的隔离至关重要。当默认拒绝策略是零置信应用部署环境中的标准态势时，使用虚拟路由与转发实例(VRF)的额外网络分割添加了额外的安全层并且允许使用重叠的网络范围。重叠网络范围是管理应用托管环境的关键需求，其趋于使全部管理客户的可到达端点集标准化。

基于复杂的微服务的应用趋于利用复杂的网络滤波器。此处所描述的SDN架构可以规模性地交付高性能防火墙滤波。无论规则集长度或序列如何，该滤波能够表现出一致的转发性能，以及更低的延迟退化。对于不仅是网络层上、而且还是内核中的应用分割，一些客户还可能具有与电信相同的某种监管压力。具体地，当在公共云上运行时，金融、而且还有其他服务对数据平面加密具有需求。在一些示例中，此处所描述的SDN架构可以包括满足这些需求的特征。

在一些示例中，当通过应用dev/test/stage/prod连续集成/连续部署(CI/CD)管道对SDN架构进行自动化时，SDN架构可以为产品每天若干次、甚至每天数百次发生变化的严格变更管理控制、审计、以及可靠性提供GitOps友好型的UX。

图2是示出根据本公开的技术的用于云本地网络的云本地SDN架构的示例的框图。通过使各个组件之间的底层连接抽象化的方式而示出SDN架构200。在该示例中，SDN架构200的网络控制器24包括配置节点230A-230N(“配置节点”或“config节点”并且统称“配置节点230”)与控制节点232A-232K(统称“控制节点232”)。配置节点230与控制节点232可以分别表示图1中的配置节点30与控制节点32的示例性实现方式。尽管被示出为与服务器12分离，然而，配置节点230与控制节点232可以作为服务器12上的一个或多个工作负载而执行。

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

将SDN架构200分割成配置平面、控制平面、与数据平面、以及可选的遥测(或分析)平面。利用可水平扩展的配置节点230实现配置平面，利用可水平扩展的控制节点232实现控制平面，并且利用计算节点实现数据平面。

在高层级，配置节点230使用配置存储224来管理SDN架构200的配置资源状态。通常，配置资源(或更简单地“资源”)是包括描述自定义资源的数据和/或方法的命名对象模式，并且定义了用于通过API服务器创建并且操纵数据的应用编程接口(API)。种类是对象模式的名称。配置资源可以包括Kubernetes本地资源，诸如容器池、入口、配置图、服务、角色、命名空间、节点、网络策略、或负载平衡。

根据本公开的技术，配置资源还包括自定义资源，该自定义资源用于通过定义Kubernetes平台的默认安装中不可用的应用编程接口(API)而扩展Kubernetes平台。在SDN架构200的示例中，自定义资源可以描述SDN架构200的物理基础设施、虚拟基础设施(例如，VN 50和/或VNR52)、配置、和/或其他资源。作为配置与操作SDN架构200的一部分，可以对各种自定义资源进行实例化(例如，vRouter 21内的VNR 52)。被实例化的资源(无论本地还是自定义)可以被称为资源的对象或实例，即，SDN架构200中表示SDN架构200的意图(所需状态)和状况(实际状态)的永久实体。

配置节点230提供用于对配置存储224中的SDN架构200的配置资源执行操作(即，创建、读取、更新、以及删除)的聚合API。负载平衡226表示在配置节点230之间对配置请求进行负载平衡的一个或多个负载平衡对象。配置存储224可以表示一个或多个etcd数据库。可以使用Nginx实现配置节点230。

SDN架构200可以为Openstack和Kubernetes提供联网。Openstack使用插件架构来支持联网。利用虚拟机编排器240，即，Openstack，Openstack联网插件驱动器将Openstack配置对象转换成SDN架构200的配置对象(资源)。计算节点运行Openstack nova，以搭建虚拟机。

利用容器编排器242，即，Kubernetes，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使用一个或多个虚拟网络而互连的工作负载的示例。

图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-管理器”或“SDN kube-管理器”，其中，用于网络控制器24的编排平台是Kubernetes)。Contrail-kube-管理器是SDN控制器管理器303的示例。配置节点230利用自定义API服务器301对API服务器300的接口进行扩展，以形成聚合层来支持SDN架构200的数据模型。如上所述，SDN架构200的配置意图可以是自定义资源。

控制节点232可以包括组件微服务控制320和核心DNS 322。如上面参考图2所描述的，控制320执行配置分配与路由学习及分配。

由服务器12表示计算节点。每个计算节点包括虚拟路由器代理316与虚拟路由器转发组件(vRouter)318。虚拟路由器代理316与vRouter 318中的任一个可以是组件微服务或者两者都是组件微服务。通常，虚拟路由器代理316执行与控制有关的功能。虚拟路由器代理316从控制节点232接收配置数据并且将配置数据转换成vRouter 318的转发信息。虚拟路由器代理316还可以执行防火墙规则处理、设置vRouter 318的流、并且与编排插件(用于Kubernetes的CNI与用于Openstack的Nova插件)对接。当在计算节点上调出工作负载(容器池或VM)时，虚拟路由器代理316生成路由，并且虚拟路由器代理316与控制节点232交换该路由，以分配到其他计算节点(控制节点232使用BGP在控制节点232之间分配路由)。当工作负载被终止时，虚拟路由器代理316还撤回路由。vRouter 318可以支持一种或多种转发模式，诸如，内核模式、DPDK、智能NIC卸载等。在容器架构或虚拟机工作负载的一些示例中，计算节点可以是Kubernetes工作者/从节点或Openstack nova-计算节点，视所使用的具体编排器而定。

一个或多个可选的遥测节点260提供度量、警报、记录、以及流分析。SDN架构200的遥测利用了云本地监测服务，诸如，Prometheus、Elastic、Fluentd、Kinaba stack(EFK)、以及Influx TSDB。配置节点230、控制节点232、计算节点、用户接口244、以及分析节点(未示出)的SDN架构组件微服务可以产生遥测数据。遥测节点260的服务可以使用该遥测数据。遥测节点260可以为用户暴露REST端点并且可以支持见解和事件关联。

可选地，用户接口244包括网络用户接口(UI)306和UI后端308服务。通常，用户接口244为SDN架构组件提供配置、监测、可视化、安全性、以及故障排除。

遥测260、用户接口244、配置节点230、控制节点232、以及服务器12/计算节点中的每个可以被视为SDN架构200的节点，在于，这些节点中的每个节点是实现配置平面、控制平面、或数据平面、或UI与遥测节点的功能的实体。在“搭建”过程中配置节点规模，并且SDN架构200使用诸如Kubernetes操作器的编排系统操作器，支持SDN架构200的节点的自动扩展。

如上所述，SDN架构200配置意图可以是自定义资源。该一个自定义资源可以包括VNR 52(图1的实施例中所示)，通过VNR 52，以上述所述方式在两个以上VN 50之间建立通信。如上所述，VNR 52可以表示用于配置VN 50之间的路由信息的导入和导出的策略的逻辑抽象，因此，VNR 52可以使用针对各个VNR 52所建立的共同路由目标而促进路由信息的交换(指非对称或对称的导入和导出)。可以对共同的路由目标进行定义并且使共同的路由目标与用于实现VN 50的路由实例相关联。

诸如Kubernetes管理员的管理员可以与用户接口244(例如，网络UI306)对接，以经由可能具有表示容器池、VN 50等的图形元件的图形用户接口而对VNR 52进行定义。为了对VNR 52进行定义，管理员可以使VNR 52与被分配给VN 50的一个或多个标签相关联。使用这些标签，VNR 52可以建立到对VNR 52进行实例化时所创建的共同路由目标的导入策略和来自该共同路由目标的导出策略。网络UI 306可以与配置控制器230对接，以创建共同的路由目标，从而经由控制节点232将共同的路由目标安装到一个或多个虚拟路由器318中。网络UI 306还可以经由配置控制器230和控制节点232对共同路由目标的路由实例进行定义(以区分共同的路由目标与其他的共同路由目标)，从而利用该路由域来促进下面针对多个不同的联网方案而进行更为详细描述的VN 50之间的互连。

图4是示出根据本公开的技术的SDN架构的示例性组件的框图。在该示例中，SDN架构400对用于网络配置对象的Kubernetes API服务器进行扩展和使用，以实现该网络配置的用户意图。在Kubernetes术语中，该配置对象被称为自定义资源，并且当在SDN架构中存留时，被简称为对象。配置对象主要是用户意图(例如，诸如VN 50、VNR 52的虚拟网络、BGPaaS、网络策略、服务链等)。

SDN架构400的配置节点230可以使用Kubernetes API服务器用于配置对象。在kubernetes术语中，将其称为自定义资源。

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

·自定义资源定义(CRD)是简单的并且能够不经过任意编程而创建。

·API聚合需要编程，但是，允许对API行为进行更多的控制，诸如，控制如何存储数据并且控制API版本之间的转换。

聚合API是位于主API服务器的后面、用作代理的从属API服务器。该布置被称为API聚合(AA)。对于用户，其看上去仅是对Kubernetes API进行了扩展。CRD允许用户在不添加另一API服务器的情况下创建新类型的资源。与如何安装无关，将新的资源称为自定义资源(CR)，以区分其与本地Kubernetes资源(例如，容器池)。在初始Config原型中使用CRD。该架构可以使用API服务器构建器阿尔法(API Server Builder Alpha)库来实现聚合API。API服务器构建器是构建本地Kubernetes聚合扩展的库与工具的统称。

通常，Kubernetes API中的每种资源需要处理REST请求并管理对象的持久性存储的代码。主Kubernetes API服务器300(通过API服务器微服务300A–300J实现)处理本地资源并且还能够通过CRD对自定义资源进行一般性的处理。聚合API 402表示对KubernetesAPI服务器300进行扩展的聚合层，以通过写入和部署自定义API服务器301(使用自定义API服务器微服务301A–301M)而允许提供自定义资源的专用实现方式。主API服务器300将对自定义资源的请求委托给自定义API服务器301，由此使得其全部客户端可用该资源。

如此，API服务器300(例如，kube-apiserver)接收Kubernetes配置对象、本地对象(容器池、服务)、以及自定义资源。SDN架构400的自定义资源可以包括配置对象，当实现SDN架构400中的配置对象的预期状态时，配置对象实现SDN架构400的预期网络配置，包括将各个VNR 52实现为一个或多个导入策略和/或一个或多个导出策略以及共同的路由目标(和路由实例)。如上所述，在SDN架构400内实现VNR 52可能生成使在下面更为详细描述的两个以上VN 50互连的导入和/或导出策略。

在该方面，自定义资源可以与通常针对网络配置所定义、但是根据本公开的技术而通过聚合API 402扩展为可操纵的配置方案对应。该自定义资源可以被替代地定义并且此处称为“用于SDN架构配置的自定义资源”。这些可以包括VN、VNR、bgp-as-a-service(BGPaaS)、子网、虚拟路由器、服务实例、项目、物理接口、逻辑接口、节点、物理ipam、浮动ip、警报、alias ip、访问控制列别、防火墙策略、防火墙规则、网络策略、路由目标、路由实例。用于SDN架构配置的自定义资源可以与通常由SDN控制器保护的配置对象对应，但是，根据此处所述的技术，将配置对象暴露为自定义资源并且与Kubernetes本地/内置资源进行合并，以支持由聚合API 402暴露、通过Kubernetes控制器406A–406N并且通过自定义资源控制器302(图4中所示的具有组件微服务302A–302L)实现的同一意图模型，自定义资源控制器302致力于将包括网络元件的计算基础设施的实际状态协调成预期状态。

假定就与Kubernetes本地/内置资源进行合并的暴露自定义资源而言的统一性质，Kubernetes管理员(或其他Kubernetes用户)可以使用随后被转换成详述路由信息导入和导出的复杂策略的共同Kubernetes语义对诸如VNR 52的VNR进行定义，以促使VN 50互连，如果对通常用于使VN 50互连的BGP及其他路由协议有任何的理解，则不需要进行过多地理解。因此，该技术的各个方面可以促进潜在产生较少的错误配置和试错的更统一的用户体验，这可以改进SDN架构400自身的执行(就利用较少的处理周期、存储器、带宽等、以及相关联的功率而言)。

API服务器300的聚合层将API自定义资源发送至其对应的已注册的自定义API服务器301。可能存在支持不同种类的自定义资源的多个自定义API服务器/自定义资源控制器。自定义API服务器301对用于SDN架构配置的自定义资源进行处理并且将自定义资源写入至配置存储304(其可能是etcd)。自定义API服务器301可以是主机并且暴露自定义资源控制器302所需的SDN控制器标识符分配服务。

自定义资源控制器302开始应用业务逻辑，以满足设置有用户意图配置的用户意图。将业务逻辑实现为协调循环。图8是示出根据本公开的技术的用于SDN架构配置的自定义资源的自定义控制器的示例的框图。自定义控制器814可以表示自定义资源控制器302的示例性实例。在图8示出的示例中，自定义控制器814可以与自定义资源818相关联。自定义资源818可以是用于SDN架构配置的任意自定义资源。自定义控制器814能够包括协调器816，协调器816包括执行协调循环的逻辑，其中，自定义控制器814监视834(例如，监测)自定义资源818的当前状态832。响应于确定所需状态826不与当前状态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)。如果创建路由目标失败，路由实例状况则发生退化，并且由此，虚拟网络状况也发生退化。因此，自定义资源控制器302可以输出指示这些自定义资源的状况的自定义消息，来排除故障。同样，VNR创建RI，RI以与上面参考VN所讨论的相似方式而创建RT，还参考图17A至图17D中的实施例对VN进行了更详细地描述。图9中示出了在依赖于不同的自定义资源类型的自定义资源类型之间创建、监视、并且协调示例性的流。

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

配置存储304可以实现为etcd。etcd是用作集群数据的Kubernetes备份存储的一致性和高度可用的关键值存储。

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

SDN控制器管理器303可以操作为Kubernetes核心资源(服务、命名空间、容器池、网络策略、网络附件定义)与所扩展的SDN架构资源(虚拟网络、路由实例等)之间的接口。SDN控制器管理器303监视Kubernetes API在Kubernetes核心网与SDN架构配置的自定义资源上的变化并且因此能够对相关资源执行CRUD操作。

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

SDN控制器管理器303收听下列Kubernetes对象以进行创建、删除、以及更新事件：

·容器池

·服务

·节点端口

·入口

·端点

·命名空间

·部署

·网络策略。

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

例如，SDN控制器管理器303监视容器池创建事件，并且相应地，可以创建下列SDN架构对象：虚拟机(工作负载/容器池)、虚拟机接口(虚拟网络接口)、以及实例IP(IP地址)。然后，在这种情况下，控制节点232可以对所选择的计算节点中的SDN架构对象进行实例化。

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

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

微处理器510可以包括一个或多个处理器，该一个或多个处理器各自包括执行与指令集架构、存储到存储介质的指令相符合的指令的独立执行单元。执行单元可以实现为独立的集成电路(IC)或可以在各自使用单一IC(即，芯片微处理器)实现的一个或多个多核处理器(或“多核”处理器)内进行组合。

盘546表示计算机可读存储介质，包括在用于存储诸如处理器可读指令、数据结构、程序模块、或其他数据的信息的任意方法或技术中所实现的易失性和/或非易失性、可移除和/或不可移除介质。计算机可读存储介质包括、但不限于随机访问存储器(RAM)、只读存储器(ROM)、EEPROM、闪存存储器、CD-ROM、数字通用盘(DVD)、或其他光学存储器、磁盒、磁带、磁盘存储器、或其他磁性存储设备、或能够用于存储所需信息并且微处理器510能够访问的任意其他介质。

主存储器544包括一个或多个计算机可读存储介质，该一个或多个计算机可读存储介质可以包括诸如各种形式的动态RAM(DRAM)(例如，DDR2/DDR3 SDRAM)、或静态RAM(SRAM)、闪存存储器的随机访问存储器(RAM)、或能够用于携带或存储指令或数据结构形式并且计算机能够访问的所需程序代码和程序数据的任意其他形式的固定或可移除存储介质。主存储器544提供由可寻址存储器位置构成的物理地址空间。

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

存储器544、NIC 530、存储盘546、以及微处理器510可以为包括在内核空间中执行的操作系统内核580的软件堆栈提供操作环境。例如，内核580可以表示Linux、Berkeley软件分布(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的NIC 530，NIC 530可以具有符合SR-IOV标准的数千个可用虚拟功能，但是，对于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进程而运行(此处，示出了位于用户空间545中的虚拟路由器506)。还可以在用户空间中运行虚拟路由器代理514。在示例性的计算设备500中，虚拟路由器506在用户空间内作为基于DPDK的虚拟路由器而运行，但是，虚拟路由器506可以通过各种实现方式在管理程序、主机操作系统、主机应用、或虚拟机内运行。虚拟路由器代理514使用信道连接到网络控制器24，信道用于下载配置和转发信息。虚拟路由器代理514将该转发状态编程为由虚拟路由器506表示的虚拟路由器数据(或“转发”)平面。虚拟路由器506与虚拟路由器代理514可以是进程。虚拟路由器506与虚拟路由器代理514被容器化/是云本地的。

虚拟路由器506可以是多线程的并且在一个或多个处理器核上运行。虚拟路由器506可以包括多个队列。虚拟路由器506可以实现封包处理管道。取决于对封包所应用的操作，虚拟路由器代理514以最简单的方式到最复杂的方式对管道进行缝合。虚拟路由器506可以维持转发基础的多个实例。虚拟路由器506可以使用RCU(读取复制更新)锁而访问并且更新表。

为了将封包发送至其他计算节点或交换机，虚拟路由器506使用工作负载，注入VM或容器池502。虚拟路由器506具有多个虚拟网络接口(例如，vifs)。这些接口可以包括与主机操作系统交换封包的内核接口vhost0、与虚拟路由器代理514交换封包的接口pkt0，以从网络控制器获得转发状态并且发送异常封包。可能存在与一个或多个物理网络接口532对应的一个或多个虚拟网络接口。虚拟路由器506的其他虚拟网络接口用于与工作负载交换封包。

在虚拟路由器506的基于内核的部署中(未示出)，将虚拟路由器506作为内核模块安装在操作系统内。虚拟路由器506通过TCP/IP堆栈注册其自身，以从其所希望的任意所需操作系统接口接收封包。接口可以被绑定、物理化、分接(用于VM)、veth(用于容器)等。在这种模式下，虚拟路由器506依赖于操作系统将封包发送至不同的接口并且从不同的接口接收封包。例如，操作系统可以暴露由vhost网络驱动器支持分接接口，以与VM进行通信。一旦虚拟路由器506注册来自该分接接口的封包，TCP/IP堆栈则将全部封包发送至虚拟路由器。虚拟路由器506经由操作系统发送封包。此外，由操作系统处理NIC队列(物理或虚拟)。封包处理可以在中断模式下操作，中断模式产生中断并且可能导致频繁的上下文切换。当存在较高的封包速率时，伴随频繁中断和上下文切换的总开销可能压垮操作系统并且导致性能不良。

在虚拟路由器506的基于DPDK的部署中(图5中未示出)，将虚拟路由器506安装为链接至DPDK库的用户空间545应用。具体地，在存在较高的封包速率时，这可能导致比基于内核的部署更快的性能。由DPDK的轮询模式驱动器(PMD)、而非内核的基于中断的驱动器，使用物理接口532。可以将物理接口532的寄存器暴露至用户空间545中，以使PMD可进行访问；通过这种方式被绑定的物理接口532不再由主机操作系统管理或对主机操作系统是不可见的，并且基于DPDK的虚拟路由器506管理物理接口532。这包括封包轮询、封包处理、以及封包转发。换言之，由虚拟路由器506的DPDK数据平面执行用户封包处理步骤。与中断模式相比较，当封包速率较高时，该“轮询模式”的性质使得虚拟路由器506的DPDK数据平面封包处理/转发更高效。与内核模式虚拟路由器506相比较，在封包I/O期间，存在相对较少的中断以及上下文切换，并且在一些情况下，可以一起避免在封包I/O期间出现中断及上下文切换。

通常，可以为容器池502A–502B中的每个容器池分配用于在相应的虚拟网络内使用的一个或多个虚拟网络地址，其中，每个虚拟网络可以与由虚拟路由器506所提供的不同虚拟子网相关联。例如，可以为容器池502B分配其自身的第三虚拟层(L3)IP地址来发送并且接收通信，但是，容器池502B可能不知道计算设备500的容器池502B运行的IP地址。由此，虚拟网络地址可能与底层物理计算机系统(例如，计算设备500)的逻辑地址不同。

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

在一个示例中，网络封包，例如，由位于虚拟网络域内的容器529A–529B所生成并且使用的第3层(L3)IP封包或第2层(L2)以太网封包，可以被封装在由物理网络传输的另一封包(例如，另一IP或以太网封包)中。在虚拟网络中进行传输的封包此处可以被称为“内部封包”，而物理网络封包此处可以被称为“外部封包”或“隧道封包”。可以由虚拟路由器506执行虚拟网络封包在物理网络封包内的封装和/或解封。此处，该功能被称为隧穿并且可以用于创建一个或多个覆盖网络。除IPinIP之外，可以使用的其他示例性隧穿协议，包括基于GRE的多协议标签交换(MPLS)、基于用户数据报协议(UDP)的MPLS等。虚拟路由器506对源自/被派往至容器池502的任意容器的封包执行隧道封装/解封，并且虚拟路由器506经由总线542和/或NIC 530的网桥与容器池502交换封包。

如上所述，网络控制器24可以提供便于一个或多个虚拟网络的操作的逻辑集中控制器。例如，网络控制器24可以维护路由信息库，例如，存储关于物理网络以及一个或多个覆盖网络的路由信息的一个或多个路由表。虚拟路由器506对其虚拟路由器506操作为相应的隧道端点的相应虚拟网络实施诸如VRF 222A的一个或多个虚拟路由和转发实例(VRF)。通常，每个VRF存储关于对应的虚拟网络的转发信息并且识别数据封包被转发到的位置以及封包是否被封装在隧道协议中，诸如，利用可以包括虚拟网络协议堆栈的不同层的一个或多个报头的隧道报头进行封装。每个VRF可以包括存储关于虚拟网络的路由和转发信息的网络转发表。

NIC 530可以接收隧道封包。虚拟路由器506对隧道封包进行处理，以从隧道封装报头确定内部封包的源端点与目的地端点的虚拟网络。虚拟路由器506可以剥去第2层报头和隧道封装报头，以仅在内部转发内部封包。隧道封装报头可以包括指示虚拟网络(例如，与VRF 222A对应的虚拟网络)的虚拟网络标识符，诸如VxLAN标记或MPLS标签。VRF 222A可以包括关于内部封包的转发信息。例如，VRF 222A可以将内部封包的目的地第3层地址映射到虚拟网络接口。相应地，VRF 222A经由容器池502A的虚拟网络接口而转发内部封包。

容器529A还可以发起内部封包作为源虚拟网络端点。例如，容器529A可以生成被派往由另一计算设备(即，非计算设备500)执行的目的地虚拟网络端点或被派往另一个容器的第3层内部封包。容器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则使用物理功能将具有新的第2层报头的隧道封包输出至NIC 530。NIC530在出站接口上输出该封包。如果目的地是在计算设备500上执行的另一虚拟网络端点，虚拟路由器506则将该封包路由至虚拟网络接口212、213中的一个适当的虚拟网络接口。

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

容器池502A包括一个或多个应用容器529A。容器池502B包括容器化路由协议守护进程(cRPD)560的实例。容器平台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还可以管理管理ip表，以捕捉到服务的虚拟IP地址和端口的流量并且使流量重新定向至代理备份容器池的代理端口。服务代理593可以表示Kubernetes集群的从节点的kube代理。在一些示例中，容器平台588并不包括服务代理593，或由CNI 570禁用服务代理593，以有利于虚拟路由器506和容器池502的配置。

编排代理592包括可由微处理器510执行的代码。编排代理592可以是一个或多个计算机进程。编排代理592可以表示Kubernetes集群的从节点的kubelet。编排代理592是接收容器的容器指定数据并且确保由计算设备500执行容器的编排器的代理，例如，图1中的编排器23。容器指定数据可以是从编排器23被发送至编排代理592或经由命令行接口、HTTP端点、或HTTP服务器间接地接收的清单文件形式。容器指定数据可以是容器的一个容器池502的容器池规范(例如，PodSpec-YAML(又一种标记语言)或描述容器池的JSON对象)。基于容器指定数据，编排代理592引导容器引擎590获得容器529的容器图像并且对容器图像进行实例化，以供计算设备500执行容器529。

编排代理592对CNI 570进行实例化并且通过其他方式调用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确定的配置状态而对虚拟网络接口进行配置，由此桥接编排控制平面与虚拟网络控制平面之间的间隙。此外，这能够使得CNI 570获得用于容器池的多个虚拟网络接口的接口配置数据并且配置多个虚拟网络接口，这可以减少调用用于配置各个虚拟网络接口的单独CNI 570所固有的通信与资源开销。

在于2022年2月1日提交的美国申请号17/649,632中描述了容器化路由协议守护进程，通过引用将其全部内容结合在此。

此外，CNI 570可能结合虚拟路由器代理514将虚拟路由器506配置为实现VNR 52。VNR 52可能产生经由一个或多个导入策略和/或一个或多个导出策略而配置的路由平面，以与VNR 52的共同路由目标交换路由信息。这些策略导致针对VN 50进行维护的路由信息与VNR 52的共同路由目标进行交换(或换言之，泄露)，其转而被解析成转发信息。CNI 570可以从网络控制器24获得用于安装该转发信息的配置数据，从而与虚拟路由器代理514进行对接，以对从VN 50转发封包的转发信息进行安装。

换言之，创建该共同的路由目标能够使得将路由信息从一个VN 50(例如，VN 50A)导入并且导出至通过一个或多个VNR 52所提供的共同路由目标并且将路由信息从共同的路由目标导入并且导出至另一VN 50(例如，VN 50N)。网络控制器24可以将该路由信息解析成上述所述转发信息并且安装在虚拟路由器506内，以实现封包在VN 50A与VN 50N之间的转发(在一些配置中，为诸如上述所述网状配置)。如此，虚拟路由器506可以建立用于在VN50之间导入和导出路由信息的方式，随后，VN 50可以使用该方式在VN 50彼此之间传送封包。

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

尽管被示出并且描述为由单一计算设备1300运行，然而，可以在构成计算系统或硬件/服务器集群的多个计算设备之间分配调度器1322、API服务器300A、控制器406A、自定义API服务器301A、自定义资源控制器302A、控制器管理器1326、SDN控制器管理器1325、控制节点232A、以及配置存储1328。换言之，多个计算设备中的每个计算设备可以为调度器1322、API服务器300A、控制器406A、自定义API服务器301A、自定义资源控制器302A、网络控制器管理器1326、网络控制器、SDN控制器管理器1325、控制节点232A、或配置存储1328中的任意一项或多项的一个或多个实例提供硬件操作环境。

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

微处理器1310可以包括一个或多个处理器，该一个或多个处理器各自包括执行与指令集架构、存储到存储介质的指令相符合的指令的独立执行单元。执行单元可以实现为独立的集成电路(IC)或可以在各自使用单一IC(即，芯片多处理器)实现的一个或多个多核处理器(或”多核“处理器)内进行组合。

盘1346表示计算机可读存储介质，包括在用于存储诸如处理器可读指令、数据结构、程序模块、或其他数据的信息的任意方法或技术中所实现的易失性和/或非易失性、可移除和/或不可移除介质。计算机可读存储介质包括、但不限于随机访问存储器(RAM)、只读存储器(ROM)、EEPROM、闪存存储器、CD-ROM、数字通用盘(DVD)、或其他光学存储器、磁盒、磁带、磁盘存储器、或其他磁性存储设备、或能够用于存储所需信息并且微处理器1310能够访问的任意其他介质。

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

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

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

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

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

API服务器300A、控制器406A、自定义API服务器301A、以及自定义资源控制器302A中的每个包括可由微处理器1310执行的代码。自定义API服务器301A验证并且配置关于SDN架构配置(诸如，VN 50和VNR 52)的自定义资源的数据。服务可以是定义容器池的逻辑集合和用于访问容器池的策略的抽象化。基于服务定义选择实现服务的容器池集。服务可以部分实现为负载平衡器或通过其他方式包括负载平衡器。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服务器300A，API服务器300可以将标识符写至与容器池相关联的配置存储1328。API服务器300可以调用用于所选择的从节点的编排代理，以致使用于所选择的从节点的容器引擎从存储服务器获得容器池并且在从节点上创建虚拟执行元件。用于所选择的从节点的编排代理可以向API服务器300A更新容器池的状况，API服务器300A使该新的状态持续到配置存储1328。如此，计算设备1300在计算基础设施8中对新的容器池进行实例化。

控制器管理器1326包括可由微处理器1310执行的代码。控制器管理器1326可以是一个或多个计算机进程。控制器管理器1326可以嵌入内核控制环路，以通过获得来自API服务器300A的通知而监测集群的共享状态。控制器管理器1326可以尝试使集群的状态朝向所需状态移动。可以由控制器管理器1326管理示例性的控制器406A与自定义资源控制器302A。其他控制器可以包括复制控制器、端点控制器、命名空间控制器、以及服务帐户控制器。控制器管理器1326可以执行生命周期功能，诸如，命名空间创建与生命周期、事件垃圾收集、终止容器池垃圾收集、级联删除垃圾收集、节点垃圾收集等。控制器管理器1326可以表示用于Kubernetes集群的Kubernetes控制器管理器。

用于此处所描述的SDN架构的网络控制器可以为在网络基础设施之上所操作的计算架构提供云网络。云网络可以包括用于企业或服务供应商的私有云、基础设施即服务(IaaS)、以及用于云服务供应商(CSP)的虚拟私有云(VPC)。私有云、VPC、以及IaaS用例可能涉及诸如参考图1所描述的多租户虚拟化数据中心。在这种情况下，位于数据中心内的多个租户共享相同的物理资源(物理服务器、物理存储、物理网络)。为每个租户分配其自身的逻辑资源(虚拟机、容器、或其他形式的虚拟执行元件；虚拟存储器；虚拟网络)。这些逻辑资源彼此隔离，除非安全策略明确允许。位于数据中心内的虚拟网络还可以与物理IP VPN或L2VPN互连。

网络控制器(或“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集群进行集成

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

与工作负载Kubernetes集群分离

由来自工作负载Kubernetes集群中的单独库博奈提斯集群执行网络控制器24的组件。

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可以创建注释中所列出的虚拟网络(上面实施例中的“红色-网络”、“蓝色-网络”、以及“默认/extns-网络”)并且利用来自虚拟网络的集群范围地址块(例如，10.0/16)的独特私有虚拟网络地址针对每个虚拟网络创建每个容器池副本(例如，容器池202A)的虚拟网络接口。

Contrail是示例性的网络控制器架构。Contrail CNI可以是针对Contrail所开发的CNI。云本地Contrail控制器可以是本公开中所描述的网络控制器的示例，诸如网络控制器24。

图7A是示出根据本公开的技术的使用SDN架构的底层网络与覆盖网络配置的控制/路由平面的框图。图7B是示出根据本公开的技术的使用底层网络中所配置的隧道连接容器池的已配置虚拟网络的框图。

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

就网络信令方面而言，路由平面能够根据分布式模型而工作，其中，cRPD在集群中的每个计算节点上运行。实质上，这就是指将智能构建到计算节点中并且智能涉及每个节点处的复杂配置。在该模型中，路由反射器(RR)可能不能做出智能的路由决策，但是，被用作反映节点之间的路由的中继器。分布式容器路由协议守护进程(cRPD)是可以使用的路由协议进程，其中，每个计算节点运行其自身的路由守护进程的实例。同时，集中cRPD主控实例可以用作在计算节点之间中继路由信息的RR。利用中心位置处的RR跨节点分配路由与配置智能。

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

集中控制平面提供如下：

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

·控制节点确实比路由多。控制节点构建在虚拟网络概念上并且能够使用路由复制和重新组织而生成新的路由(例如，支持类似其他用例的服务链接与内部-VM路由的特征)。

·为最优广播与多播转发构建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的编排能力的核心是使用基于虚拟网络(及有关对象)的抽象化(包括上述所述VNR)对网络虚拟化进行建模的能力。控制节点232与配置节点230对接，以将配置信息中继至控制平面和数据平面。控制节点232还有助于为多播第2层和第3层构建覆盖树。例如，控制节点可以构建其用于实现此目的的集群的虚拟拓扑。通常，cRPD不包括该编排能力。

高度可用性与水平扩展性

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

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

相应地，在一些示例中，SDN架构可以在如图7A至图7B中所示的计算节点上具有cRPD。图7A示出了可以表示示例性的实现方式SDN架构200或400的SDN架构700。在SDN架构700中，cRPD 324在计算节点上运行，并且在运行提供编排和覆盖服务的集中(和可水平扩展)的控制节点232集的同时，提供到转发平面的底层路由。在一些示例中，代替在计算节点上运行cRPD 324，可以使用默认网关。

计算节点上的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结构进行编程。在该示例中，可以由控制节点232对非默认的覆盖VRF进行编程。

在该上下文中，控制节点232可以获得定义VNR 52的自定义资源并且对单独的路由实例进行实例化(具有对应的共同路由目标)。控制节点232可以针对共同的路由目标创建导入和/或导出策略，以将路由从各个虚拟网络(例如，VN 50A和50N)导入和导出至共同的路由目标。控制节点232可以对共同的路由目标进行解析，以获得随后经由虚拟路由目标514被推送至虚拟路由器506的转发信息。使用该转发信息，虚拟路由器506可以在VN 50A与VN 50N之间转发封包(在一些互连方案中，诸如，上述所述网状互连方案)。

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

如图7B中所示，cRPD 324交换可用于通过VRF的底层网络702而创建隧道的路由信息。隧道710是示例并且使服务器12A与服务器12X的虚拟路由器506连接。隧道710可以表示分段路由(SR)或SRv6隧道、通用路由封装(GRE)隧道、以及IP-in-IP隧道、LSP、或其他隧道。控制节点232利用隧道710来创建虚拟网络712，虚拟网络712连接被附接至虚拟网络的VRF的服务器12A与服务器12X的容器池22。

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

因为可能存在在各个计算节点上运行的工作者，所以对于cRPD 324，gRPC模型表现良好，并且虚拟路由器代理316用作暴露客户端(cRPD 324)的服务的gRPC服务器，以用于对路由和配置信息(底层)进行编程。由此，当与XMPP进行比较时，gRPC是具有吸引力的解决方案。具体地，gRPC将数据作为二进制流进行传输并且在对通过gRPC进行发送的数据进行编码/解码时不增加开销。

在一些示例中，控制节点232可以使用XMPP与虚拟路由器代理514进行对接。由于虚拟路由器代理514用作gRPC服务器，cRPD 324用作gRPC客户端。这就是指客户端(cRPD)需要向服务器(vRouter代理)发起连接。在SDN架构700中，虚拟路由器代理514选择其所订阅的控制节点232集(因为存在多个控制节点)。在该方面，控制节点232用作服务器并且虚拟路由器代理514作为客户端而连接并且订阅进行更新。

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

控制节点232与其使用的额外增强如下。HA与水平扩展性具有三个控制节点。如同任意路由平台，仅具有两个控制节点232来满足HA需求已足以。在许多情况下，这是有利的。(然而，可以使用一个或多个控制节点232)。例如，其提供更加确定性的基础设施并且与标准路由的最佳实践符合。每个虚拟路由器代理514被附接至唯一的一对控制节点232，以避免随机性。利用两个控制节点232，调试可能更简单。此外，仅利用两个控制节点232，可以简化用于构建多播/广播树的边缘复制。当前，因为vRouter代理316仅连接至三个控制节点中的两个控制节点，所以全部控制节点在某一时间内可能不具有树的完整图片并且依赖BGP来同步控制节点之间的状态。因为虚拟路由器代理316可以随机地选择两个，所以三个控制节点232加剧了这种情况。如果仅存在两个控制节点232，每个虚拟路由器代理316则连接至相同的控制节点。这进而指控制节点232不需要依赖于BGP来同步状态并且具有多播树的相同图片。

SDN架构200可以提供入口复制作为边缘复制的可替代方案并且为用户提供选项。入口复制可以被视为是通用覆盖多播树的特殊退化情况。然而，实际上，入口复制树的信令比通用覆盖多播树的信令更简单。利用入口复制，每个虚拟路由器21以其自身作为根部并且每个其他vrouter作为叶部的树而结束。发生故障的虚拟路由器21理论上不应该导致对树进行重建。应注意，入口复制的性能由于集群较大而发生恶化。然而，入口复制对于较小的集群表现良好。进一步地，多播并不是许多客户的流行与普遍需求。其主要限于传输仅初始发生的广播BUM流量。

配置处理模块增强

在常规的SDN架构中，网络控制器对全部用例的编排进行处理。配置节点基于数据模型将意图转换成配置对象并且将配置对象写至数据库(例如，Cassandra)中。在一些情况下，例如，同时经由RabbitMQ将通知发送至等待配置的全部客户端。

控制节点不仅用作BGP扬声器，而且还具有通过下列方式从数据库中读取配置对象的配置处理模块。首先，当控制节点启动(或重启)时，其连接至数据库并且直接从数据库中读取全部配置。其次，控制节点还可以是消息客户端。当存在对配置对象的更新时，控制节点接收列出已被更新的对象的消息通知。这再次致使配置处理模块从数据库中读取对象。

配置处理模块读取控制平面(BGP有关配置)和vRouter转发平面的配置对象。可以将配置存储为以对象作为节点并且关系作为链路的图表。然后，能够将该图表下载到客户端(BGP/cRPD和/或vRouter代理)。

根据本公开的技术，在一些示例中，常规配置的API服务器与消息服务被kubeapi-服务器(API服务器300和自定义API服务器301)取代并且之前的Cassandra数据库被Kubernetes中的etcd取代。由于这种改变，对配置对象感兴趣的客户端能够直接在etcd数据库上制定监视，以获得更新，而非依赖于RabbitMQ通知。

CRPD的控制器编排

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

分布式配置处理

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

通过使虚拟路由器代理514直接在API服务器300中的etcd服务器上进行监视，可以避免作为中间模块的IFMAP以及存储依赖关系图的需求。在计算节点上运行的cRPD 324可以使用相同的模型。这将避免对IFMAP-XMPP配置信道的需求。Kubernetes配置客户端(用于控制节点232)可以用作该配置的一部分。虚拟路由器代理也可以使用该客户端。

然而，这能够增加从etcd服务器中读取配置的客户端的数量，尤其是在具有数百个计算节点的集群中。添加更多的监视器最终导致写入速率下降并且事件速率下降至达不到理想值。etcd的gRPC代理从一个服务器监视器向多个客户端监视器进行重播。gRPC代理将相同秘钥或范围内的多个客户端监视器(c-监视器)合并成连接至etcd服务器的单一监视器(s-监视器)。代理将全部事件从s-监视器广播至其c-监视器。假设N个客户端监视相同的秘钥，则一个gRPC代理能够将etcd服务器上的监视负载从N个减少至1个。用户能够将多个gRPC代理部署到进一步分配的服务器负载。这些客户端共享一个服务器监视器；代理从核心集群有效地卸载资源压力。通过增加代理，etcd每秒能够服务一百万个事件。

SDN架构中的DNS/命名

在之前的架构中，由联合工作的contrail-dns与contrail-命名进程提供DNS服务，以向网络中的VM提供DNS服务。命名用作提供BIND协议的实现方式的DNS服务器，contrail-dns从vrouter-代理接收更新并且将这些记录推送给命名。

系统中支持四种DNS模式，IPAM配置能够选择所需的DNS模式。

1.无-无支持VM的DNS。

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架构可以代替为使用任意DNS服务的核心DNS。

数据平面

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

代理514的责任可以包括：与控制节点232对接，以获得配置。将所接收的配置转换成该数据路径能够理解的形式(例如，将来自IFMAP的数据模型转换成数据路径所使用的数据模型)。与控制节点232对接，以对路由进行管理。并且从数据路径采集统计并且将统计输出至监测解决方案。

虚拟路由器506实现可以允许虚拟网络接口与VRF相关联的数据平面功能。每个VRF具有其自身的转发和流表，而MPLS和VXLAN表在虚拟路由器506内是全局的。转发表可以包含用于目的地的IP和MAC地址的路由并且IP到MAC关联被用于提供代理ARP能力。当VM/容器接口启动并且仅在本地对该vRouter较为重要时，由虚拟路由器506选择MPLS表中的标签值。VXLAN网络标识符跨域内的不同虚拟路由器506中的相同虚拟网络的全部VRF是全局的。

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

下面是由虚拟路由器506实现的封包流转发的示例。

相同子网中的VM/容器接口之间的封包流。

工作者节点可以是VM或容器接口。在一些示例中，封包处理进行如下：

·VMI/容器接口需要将封包发送至VM2，因此，虚拟路由器506首先查询其自身的DNS缓存获得IP地址，但是，因为这是第一个封包，所以不存在条目。

·当其接口启动时，VM1将DNS请求发送至DHCP响应中所供应的DNS服务器地址。

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

·控制器中的DNS服务器以VM2的IP地址做出响应。

·虚拟路由器506将DNS响应发送至VM1。

·VM1需要形成以太网帧，因此，需要VM2的MAC地址。VM1检查其自身的ARP缓存，但是，因为这是第一个封包，所以不存在条目。

·VM1发出ARP请求。

·虚拟路由器506截获ARP请求并且在其自身的转发表中查找IP-VM2的MAC地址并且在控制器针对VM2发送MAC地址的L2/L3路由中找出关联。

·虚拟路由器506利用VM2的MAC地址向VM1发送ARP应答。

·在VM1的网络堆栈中出现TCP超时。

·VM1的网络堆栈重新尝试发送封包，并且此时，在ARP缓存中找出VM2的MAC地址并且能够形成以太网帧并且将以太网帧发送出去。

·虚拟路由器506查询VM2的MAC地址并且找出封装路由。虚拟路由器506构建外部报头并且将生成的封包发送至服务器S2。

·位于服务器S2上的虚拟路由器506对封包进行解封并且查找MPLS标签来识别虚拟接口，以将初始以太网帧发送至该虚拟接口中。将以太网帧发送至接口中并且由VM2接收。

位于不同子网中的VM之间的封包流

在一些示例中，除虚拟路由器506作为默认网关做出响应之外，将封包发送至不同子网中的目的地的顺序是相同的。VM1在以太网帧中发送具有默认网关的MAC地址的封包，当VM1启动时，在虚拟路由器506所供应的DHCP响应中提供该默认网关的IP地址。当VM1关于网关IP地址做出ARP请求时，虚拟路由器506利用其自身的MAC地址做出响应。当VM1使用该网关MAC地址发送以太网帧时，虚拟路由器506使用该帧内的封包的目的地IP地址来查找VRF中的转发表，以找出经由封装隧道到目的地所运行的主机的路由。

图10是示出根据本公开中所描述的技术的各个方面的虚拟网络路由器可以被配置为实现虚拟网络之间的网状互连的第一实例的示图。在图10的实施例中，对虚拟网络(“VN”)1500A(也被示出为“VN 1”)和VN 1500B(也被示出为“VN 2”)进行定义并且在Kubernetes(或某一其他编排平台)内实现为自定义资源，然后，在诸如SDN架构700的SDN架构内实现为VN。VN 1500A、VN 1500B可以是自定义资源的实例并且具有对应的客户API服务器301和自定义资源控制器302。

网络控制器24可以允许管理员将VN 1500A定义成为容器池1502A(也被示出为“容器池-1”)提供网络连接的自定义资源，并且允许将VN1500B定义成为容器池1502B(也被示出为“容器池-2”)提供网络连接的自定义资源。

如图10的实施例中进一步示出的，在同一命名空间1504(也被示出为“命名空间-1”)内对VN 1500A和1500N(“VN 1500”)进行定义，这指示VN 1500存在于共同的网络命名空间内(并且由此彼此不隔离)。命名空间至少在Kubernetes的上下文中提供了用于使单个集群内的成组资源隔离的机制，例如，容器池1502A和1502B(“容器池1502”)以及VN 1500。如左上方所示，VN 1500并不互连并且并不提供由容器池-2(容器池1502A)的ping状态表示为“失败”并且由容器池-1(容器池1502B)的ping状态表示为“失败”的彼此之间的网络连接。

为了提供容器池1502之间的网络连接，管理员可以通过对同一命名空间1504(再次，示出为“命名空间-1”)内的VNR 1506进行实例化而使VN 1500彼此互连。如上所述，VNR1506可以表示管理员利用具有“mesh”的网络连接类型的“VNR-web”的示例性名称进行实例化的自定义资源。为了指定进行互连的VN，管理员可以将各个VN 1500的标签分配为“vn:web”并且然后指定具有“vn:web”的选择标签的VN 1500之间的网状连接。

网络控制器24(例如，自定义资源控制器302)可以对该自定义资源进行处理，以生成上述所述导出和导入策略，即，指示经由VNR 1506将VN 1500A的全部路由导出至VN1500B并且将VN 1500B的全部路由导出至VN 1500A，而经由VNR 1506将VN 1500B的全部路由导入至VN 1500A并且将VN 1500A的全部路由导入至VN 1500B。因为在每个VN之间交换每个VN的全部路由而创建网状，所以该导入/导出策略通常被称为对称的。

可以通过在共同的路由实例(RI，被示出为“vnr-RI”)的上下文中创建共同的路由目标(被示出为“vnr-RT”，其中，RT表示路由目标)而“安装”VNR 1506，其中，将导入/导出策略定义为将全部路由导入至vnrRT并且从各个VN 1500导出全部路由。一旦这些策略被定义并且安装在与VN 1500相关联的SDN架构700内(例如，路由平面中)，则导入路由并且导出至各个vnr-RT的VRF中并且进行解析，以生成转发信息。vnr-RI与vnr-RT的实例可以是用于SDN架构配置的自定义资源的实例。

控制节点232可以生成配置数据形式的转发信息并且与虚拟路由器代理514对接，以向虚拟路由器代理514提供配置数据，虚拟路由器代理514可以将转发信息安装到虚拟路由器506，以实现VN 1500(例如，图5的实施例中所示的VRF 222A)的对应VRF。一旦安装，转发信息则在具有VN 1500的容器池的其他计算节点中促使虚拟路由器506及其他虚拟路由器正确地用于VN间流量。如图10的实施例所示，通过容器池-2(容器池1502A)的ping“通过”和容器池-1(容器池1502B)ping“通过”的指示，容器池1502之间的这些虚拟路由器可以使用已泄露的路由信息对ping进行正确转发。

图11是示出根据本公开中所描述的技术的各个方面的虚拟网络路由器可以被配置为实现虚拟网络之间的网状互连的第二实例的示图。图11中所示的实施例从图10中所示的实施例构建，在于，VNR 1506提供VN 1500之间的网状互连，以允许同一命名空间1504中的容器池1502彼此对称地通信。

在图11的实施例中，在同一命名空间1504中对VN 1500C和1500D(也被分别示出为“VN 3”和“VN 4”)进行定义并且为相应的容器池1502C和1502D(也被示出为“容器池-3”和“容器池-4”)提供网络连接。为了将VN 1500C和1500D添加至由1506提供的网状，管理员可以将“vn:web”标签添加至VN 1500C和1500D。

在添加与网状VNR 1506对应的标签之后，网络控制器24可以通过生成导入和导出策略的方式而将VN1500C和VN 1500D添加至VNR 1506，以经由VNR共同的路由目标(“vnr-RT”)在VN 1500C与VN 1500A、VN 1500B、以及VN 1500D之间导出和导入全部的路由并且再次经由VNR共同的路由目标(“vnr-RT”)在VN 1500D与VN 1500A-1500C之间导出和导入全部的路由。即，控制节点232可能仅需要生成将路由从vnr-RT导入至VN 1500C和VN 1500D并且将路由从VN 1500C和VN 1500D导出至vnr-RT的策略。在一些情况下，通过使用VNR 1506的共同路由目标，可以在全部VN 1500A-1500D之间自动导出路由，而无需对任意已有的策略进行更新(诸如用于已有VN 1500A和VN 1500B的导入/导出策略)。

在任何情况下，控制节点232可以将路由解析成转发信息并且与虚拟路由器代理514对接，以通过与上面参考图10所描述的相似方式对转发信息进行安装。在对转发信息进行安装之后，如针对每一个其他的容器池1502A-1502D(例如，对于由“容器池-2、容器池-3、容器池-4”表示的各个容器池1502B-1502D等并且对于每一个其他的容器池1502B-1502D，表示为“容器池-1”的容器池1502A具有“通过”ping状态)的“通过”ping状态示出的，各个容器池1502A-1502D可以是每一个其他的容器池1502A-1502D具有网状网络连接。因此，图11示出了将额外的VN添加至使用VNR而互连的VN的网状，能够通过仅将适当的标签添加至VN实例(此处，“vn:web”)而实现。

图12A与图12B是示出根据本公开中所描述的技术的各个方面的虚拟网络路由器可以被配置为实现虚拟网络之间的网状连接的第三实例的示图。在该实施例中，不同于图11中的实施例，VN 1500C和VN 1500D耦合至图12A的实施例中的VNR 1506B，以提供VN1500C与VN 1500D(右侧)之间的网状网络连接，其中，图11的实施例中的VNR 1506被图12A的实施例中的相似VNR 1506A所替代，以提供VN 1500A与VN 1500B(左侧)之间的网状网络连接。

在与VNR 1506B的路由实例(被示出为“vnr-2-RI”)不同的命名空间1504的上下文中，VNR 1506A具有唯一的路由实例(“vnr-RI”)。VNR1506A提供vnr-RT，而VNR 1506B提供vnr-2-RT(尽管给定不同/唯一的路由实例，然而，RT可以相同)。进一步地，VNR 1506A具有选择VN 1500A和VN 1500B的“vn:web”标签选项，而VNR 1506B具有“vn:db”的标签选项，即，被分配给VN 1500C和VN 1500D的标签。因此，容器池1502A与1502DB并不具有与容器池1502C和1502D的网络连接(由“失败”ping状态表示)，而容器池1502C与1502D并不具有与容器池1502A和1502B的网络连接(由“失败”ping状态表示)。

为了使容器池1502A-1502D具有网状网络连接(由于VNR 1506A和VNR 1506B是类型“网状”)，管理员可以添加标签选择语句，以选择其他VNR 1506A和VNR 1506B的标签。接着，参考图12B中的实施例，VNR 1506A现包括“vnr:db”的标签选择语句，网络控制器24将该标签选择语句转换成vnr-db-RT的导入和导出策略，由此，将路由导入至VNR 1506B的vnr-db-RT并且从VNR 1506B的vnr-db-RT导出路由。同样，VNR 1506B现包括“vnr:web”的标签选择语句，网络控制器24可以将该标签选择语句转换成将路由导入至VNR 1506A的vnr-web-RT并且从VNR 1506A的vnr-web-RT导出路由。连接至VNR 1506A(“VNR-web”)和VNR 1506B(“VNR-db”)的VN的全部容器池能够通过致使VNR 1506A、1506B导入/导出彼此的路由而按照这种方式使用VNR和标签实现彼此的通信。

再次，网络控制器24(例如，自定义资源控制器302)可以将这些策略部署在路由平面内，然后，网络控制器可以执行路由信息交换。控制节点232可以将已交换的路由信息解析成转发信息并且与虚拟路由器代理514进行对接，以通过与上面参考图10所描述的相似方式而将转发信息安装在虚拟路由器506中。因此，如通过每一个其他容器池1502A-1502D的成功“通过”ping状态所证明的，建立容器池1502A-1502D之间的网状连接。

图13A与图13B是示出根据本公开中所描述的技术的各个方面的虚拟网络路由器可以被配置为实现虚拟网络之间的网状连接的第四实例的示图。在图13A的实施例中，整体网络结构与图12A中的实施例所示的结构相似，但VN 1500A和1500B、容器池1502A和1502B、以及VNR 1506A位于第一命名空间1504A(被示出为“命名空间-1”)中，而VN 1500C和1500D、容器池1502C和1502D、以及VNR 1506B位于第二个不同的命名空间1504B(被示出为“命名空间-2”)中。

假定命名空间1504A和1504B使VN 1500A/1500B、容器池1502A/1502B、以及VNR1506A与VN 1500C/1500D、容器池1502C/1502D、以及VNR 1506B隔离，则必须存在跨命名空间1504A和1504B导入路由信息的授权，因为由单独的分组管理每个命名空间1504A和1504B，而非跨两个命名空间1504A和1504B共享管理权限。因此，可以向两个命名空间1504A和1504B的管理员发送请求，以确认许可在VNR 1506A与VNR 1506B之间导入和导出路由信息。

此外，由于由命名空间1504A和1504B相对于其他命名空间所提供的隔离，仅许可VNR 1506A与VNR 1506B跨命名空间1504A和1504B导入和导出路由信息。对命名空间之间的路由信息的这种限制强制实施上述授权并且避免可能导致路由信息交换的错误配置，即，许可在命名空间1504A与1504B之间传送具有敏感或其他安全信息的封包(这可能导违反数据合规、合同义务无效、或其他导致违反由命名空间1504A与1504B所提供的隔离的恶意信息)。

因此，假设由两个命名空间1504A和1504B的管理员提供授权，则控制节点232可以将VNR 1506A和1506B转换成上面参考图12B的实施例所描述的导入和导出策略，即，便于生成转发信息，以提供容器池1502A-1502D之间的网状连接。图13B示出了该转换的结果与策略安装以及已交换路由信息到能够安装在虚拟路由器506中的转发信息的解析，以能够实现该命名空间之间的网状网络连接。

图14是示出根据本公开中所描述的技术的各个方面的虚拟网络路由器可以被配置为实现虚拟网络之间的轴辐式互连的虚拟网络路由器的第五实例的示图。在图14的实施例中，VN 1500A-1500C位于命名空间1504内并且为相应的容器池1502A-1502C提供网络连接。VN 1500A与VN 1500B各自被分配“vn:web”的VN标签并且VN 1500C被分配“vn:db”的VN标签。

此外，管理员可以与网络控制器24进行交互，以通过VNR 1516A和VNR 1516B的形式对自定义资源进行实例化。VNR 1516A是用作轴辐式网络配置中的中心的“中心”类型VNR。轴辐式网络配置是一种交换，其中，中心VNR 1516A从耦合至中心VNR 1516A的任意分支VNR导入全部路由信息并且耦合至中心VNR 1516A的分支VNR从中心VNR 1516A导入路由信息。VNR 1516B被配置成用作轴辐式网络配置中的分支的“分支”类型VNR。分支VNR 1516B可以将全部路由信息导出至中心VNR 1516A，但是从中心VNR 1516A导入全部路由信息。然而，分支VN并不从其他分支VN接收任意的路由信息。

管理员可以对中心VNR 1516A进行定义，以选择标签“vn:db”，并且管理员可以对分支VNR 1516B进行定义，以选择标签“vn:web”。如上所述，标签选择器可以指示VN 1500A-1500C哪一个耦合至中心VNR 1516A和分支VNR 1516B中的哪一个。

在图14的实施例中，控制节点232针对中心VNR 1516A(以及spoke-RI或vnr-spoke-RI)生成中心共同的路由目标(“hub-RT”或“vnr-hub-RT”)并且针对分支VNR 1516B(以及hub-RI或vnr-hub-RI)生成分支共同的路由目标(“spoke-RT”或“vnr-spoke-RT”)。接着，控制节点232可以针对中心VNR 1516A生成导出策略，以引导贴有标签“vn:db”的任意VN1500A-1500C(在该实施例中，是VN 1500C)将路由信息导出至vnr-hub-RT。

控制节点232还可以针对分支VNR 1516B生成导出策略，以指示分支VNR 1516B应将全部路由信息导出至vnr-hub-RT。控制节点232可以针对中心VNR 1516A生成导入策略，以指示中心VNR 1516A应从任意分支VNR导入全部路由信息，诸如分支VNR 1516B的vnr-spoke-RT。控制节点232还可以生成指示VN 1500A和VN 1500B应将全部路由信息导出至vnr-spoke-RT的导入和导出策略。

一旦策略被配置，控制节点232则可以根据策略对路由信息进行交换，从而对路由信息进行解析而生成转发信息。控制节点232可以经由虚拟路由器代理514将转发信息安装到虚拟路由器506中，以实现轴辐式连接，其中，各个容器池1502C能够与各个容器池1502A和1502B进行通信(由于连接容器池的中心能够到达任意分支容器池)并且容器池1502A和1502B能够与中心容器池1502C进行通信，但是，由于分支容器池1502A和1502B不能根据每个轴辐式网络连接而彼此进行通信，分支容器池1502A和1502B彼此之间并不进行通信。

图15是示出根据本公开中所描述的技术的各个方面的虚拟网络路由器可以被配置为实现虚拟网络之间的轴辐式互连的第六实例的示图。图15中所示的实施例与图14中所示的实施例相似的，但是，在该实例中，中心VNR 1516A、VN 1500C、以及容器池1502C位于不同的命名空间1504B(被示出为“命名空间-2”)中，而分支VNR 1516B、VN 1500A与VN 1500B、以及容器池1502A和1502B位于第一命名空间1504A(被示出为“命名空间-1”)中。

在该实例中，VN 1500A-1500C仅能够与同一命名空间中的VNR 1516A和VNR 1516B互连，并且仅分支VNR 1516B和中心VNR 1516A能够出于上述所述原因跨命名空间1504A和1504B进行通信。假设由两个命名空间1504A和1504B的管理员给出授权，则能够以与上面参考图14所描述的相似(如果非大致相似)的方式实现图15中的底部所示的轴辐式连接。

图16是示出根据本公开中所描述的技术的各个方面的虚拟网络路由器可以被配置为实现虚拟网络之间的轴辐式互连的第七实例的示图。图16中所示的实施例与图14中所示的实施例相似，但是，提供了额外的网状VNR 1506，以允许修改VN 1500A-1500D之间的轴辐式互连。

如上面更为详细描述的，在图16的实施例中，VN 1500A-1500D初始彼此不能进行通信(根据“失败”ping状态)，直至中心VNR 1516A和分支VNR 1516B被实例化、部署为策略、交换路由信息并且然后进行解析，并且将转发信息安装到虚拟路由器516中。这能够实现VN1500C和VN 1500D将路由信息导出至共同的hub-RT(“vnr-hub-RT”)，而VN 1500A和VN1500B将路由信息导出至共同的spoke-RT(“vnr-spoke-RT”)。分支VNR 1516B可以将全部路由信息导出至vnr-hub-RT，这能够使得中心容器池1502C和1502D与每一个其他的分支容器池1502A和1502B进行通信。分支容器池1502A和1502B能够与每个其他的中心容器池1502C和1502D进行通信，但不与每个其他的分支容器池1502A和1502B进行通信。

为了实现中心容器池1502C和1502D彼此直接进行通信，管理员可以对网状VNR1506进行实例化，以能够将路由信息导出至与上面参考图10的实施例所描述的相似单独网状VNR。如此，由于经由网状-RT在VN 1500C与VN 1500D之间交换全部路由信息，中心容器池1502C和1502D彼此可以直接进行通信。

图17A至图17D是示出根据本公开中所描述的技术的各个方面的当在SDN架构内建立一个或多个虚拟网络路由器时所执行的操作的流程图。首先，参考图17A的实施例，网络控制器24的VNR控制器(例如，一个自定义资源控制器302，诸如，图6的实施例中所示的自定义资源控制器302A)初始可以识别(或换言之，监视Ectd数据库进行识别)创建具有名称VN-1和vn＝web的标签的VN 50A以及具有名称VN-2和vn＝web的标签的VN 50N作为与网络控制器24相关联的Etcd数据库中的自定义资源(例如，图6的实施例中所示的配置存储1328)，其中，网络控制器24的控制器管理器(例如，控制器管理器1326)调用网络控制器24的调度器(例如，调度器1322)，以创建VN 50A和VN 50N(1700、1702、1704)。

经由网络控制器24的kube-api(再次，可以指图6的实施例中所示的API服务器300A和/或自定义API服务器301A)，管理员可以对VNR 52A进行实例化，以使VN 50A和VN50N互连，从而指定类型为网状以及标签为“vn:web”。Kube-api对Etcd数据库进行更新，以存储创建52A的新的自定义资源，并且陈述VNR 52A的创建在Etcd数据库内是悬而未决的(1706、1708、1710)。

接着，网络控制器24的调度器可以从已经定义新的自定义资源的Etcd数据库接收通知，然后，与控制器管理器进行对接，以将VNR创建请求通知给控制器管理器(1712、1714、1716)。控制器管理器可以对VNR控制器进行对接，以请求进行VNR协调，从而为VNR 52A创建RI，从而向kube-API提供新的RI(1718)，因此，kube-api能够对Etcd进行更新，以反映新的RI到VNR 52A的分配(1720)。

然后，Etcd数据库可以与调度器进行对接，以指示存在VNR-RI创建事件(1722)，其转而与控制器管理器进行对接，以将VNR-RI创建通知给控制器管理器(1724)。然后，控制器管理器与网络控制器24的RI控制器进行对接，以请求进行VNR-RI协调(1726)。

接着，参考图17B中的实施例，网络控制器24的RI控制器可以执行VNR-RI的协调，以为VNR-1-RI创建RT，从而将VNR-1-RI报告回至kube-api(1728)。kube-api可以对Etcd进行更新，以表明已创建VNR-1-RT，其可以向Kube-api报告VNR-1-RT处于悬而未决并且然后成功创建(1730、1732)。然后，Kube-api可以与VNR控制器进行对接，以指示已创建VNR-1-RI，其转而可以从RI获得VNR-1-RT(1736、1738)。

接着，VNR控制器可以与Kube-api进行对接，以识别具有标签vn＝web的VN 50的列表(1740)，其中，Kube-api可以将名称VN-1和VN-2返回VN 50A和VN 50N(1742)。再次，VNR控制器可以与Kube-api进行对接，以获得VN-1和VN-2的RI(1744)，其继续与Kube-api进行对接，以在VN-1-RI、VN-2-RI状态对VNR-1-RT进行修补(1746)。然后，Kube-api对VN-RI修补事件的Etcd进行更新(1748)。然后，Etcd将修补事件通知给调度器(1750)，从而将修补事件通知给控制器管理器(1752)。

参考图17C中的实施例，控制器管理器响应修补事件而请求RI控制器执行VN-RI协调(1754)，RI控制器在VN-1-RI、VN-2-RI状态请求Kube-api修补VNR-1-RT之前对VN-RI执行协调(1756)。响应修补请求，Kube-api将Etcd中的VN-1-RI更新为包括用于导入和导出至VNR-1-RT(VNR共同的路由目标)的策略，并且Kube-API将VN-2-RI更新为包括用于导入和导出至VNR-1-RT(VNR共同的路由目标)的策略(1758)。Etcd将修补的状态报告回至Kube-API(1760)。响应于VN-1-RI和VN-2-RI的修补状态，Kube-api与RI控制器进行对接，以在VNR-RI对VNR-1-RT进行修补(1762)，其中，RI控制器将修补状态报告回至Kube-api(1764)。

接着，参考图17D的实施例，Kube-api与Etcd进行对接，以针对修补事件对Etcd进行更新，Etcd与调度器进行对接，以将修补事件通知给调度器(1766、1768)。然后，调度器与控制器管理器进行对接，以将VNR-RI修补通知给控制器管理器，控制器管理器转而请求来自VNR控制器的VNR-RI协调(1770、1772)。RI控制器在VNR-RI处对VNR-1-RT进行修补，并且将修补通知给Kube-api(1774、1776)。Kube-api针对修补对Etcd进行更新(1778)并且与RI控制器进行对接，以将VNR-1状态设置成指示“成功”，因此，Kube-api在VNR-1状态成功时对Etcd进行更新(1780)。

下面提供VNR API方案的细节设计(如YAML文件)：

API Type(方案)

type VirtualNetworkRouterSpec struct{

//Common spec fields

CommonSpec`json:",inline"protobuf:"bytes,1,opt,name＝commonSpec"`

//Type of VirtualNetworkRouter.valid types-mesh,spoke,hub

Type VirtualNetworkRouterType`json:"type,omitempty"

protobuf:"bytes,2,opt,name＝type"`

//Select VirtualNetworks to which this VNR's RT be shared

VirtualNetworkSelector*metav1.LabelSelector

`json:"virtualNetworkSelector,omitempty"

protobuf:"bytes,3,opt,name＝virtualNetworkSelector"`

//Import Router targets from other virtualnetworkrouters

Import ImportVirtualNetworkRouter`json:"import,omitempty"

protobuf:"bytes,4,opt,name＝import"`

}

type ImportVirtualNetworkRouter struct{

VirtualNetworkRouters[]VirtualNetworkRouterEntry

`json:"virtualNetworkRouters,omitempty"

protobuf:"bytes,1,opt,name＝virtualNetworkRouters"`

}

type VirtualNetworkRouterEntry struct{

VirtualNetworkRouterSelector*metav1.LabelSelector

`json:"virtualNetworkRouterSelector,omitempty"

protobuf:"bytes,1,opt,name＝virtualNetworkRouterSelector"`

NamespaceSelector*metav1.LabelSelector

`json:"namespaceSelector,omitempty"

protobuf:"bytes,2,opt,name＝namespaceSelector"`

}

VirtualNetworkRouter Yamls-Mesh VNR

apiVersion:core.contrail.juniper.net/v1alpha1

kind:VirtualNetworkRouter

metadata:

namespace:frontend

name:vnr-1

annotations:

core.juniper.net/display-name:vnr-1

labels:

vnr:web

ns:frontend

spec:

type:mesh

virtualNetworkSelector:

matchLabels:

vn:web

import:

virtualNetworkRouters:

-virtualNetworkRouterSelector:

matchLabels:

vnr:db

namespaceSelector:

matchLabels:

ns:backend

VirtualNetworkRouter Yamls-Spoke VNR

apiVersion:core.contrail.juniper.net/v1alpha1

kind:VirtualNetworkRouter

metadata:

namespace:frontend

name:vnr-1

annotations:

core.juniper.net/display-name:vnr-1

labels:

vnrgroup:spokes

ns:frontend

spec:

type:spoke

virtualNetworkSelector:

matchLabels:

vngroup:spokes

import:

virtualNetworkRouters:

-virtualNetworkRouterSelector:

matchLabels:

vnrgroup:hubs

namespaceSelector:

matchLabels:

ns:backend

VirtualNetworkRouter Yaml-Hub VNR

apiVersion:core.contrail.juniper.net/v1alpha1

kind:VirtualNetworkRouter

metadata:

namespace:backend

name:vnr-2

annotations:

core.juniper.net/display-name:vnr-2

labels:

vnrgroup:hubs

ns:backend

spec:

type:hub

virtualNetworkSelector:

matchLabels:

vngroup:hubs

import:

virtualNetworkRouters:

-virtualNetworkRouterSelector:

matchLabels:

vnrgroup:spokes

namespaceSelector:

matchLabels:

ns:frontend

图18是示出执行此处所描述的技术的各个方面时的图1的实施例中所示的计算机架构的操作的另一流程图。网络控制器24可以被配置为使由数据中心10表示的SDN架构系统内操作的第一虚拟网络(例如，VN 50A)与第二虚拟网络(例如，VN 50N)互连。网络控制器24可以被配置为对一个或多个策略的逻辑抽象进行定义，以经由一个或多个VNR 52(例如，VNR 52A)执行该互连。

策略可以包括关于由虚拟路由器(在该实施例中，可以指VN 50A和VN 50N)维护的路由信息的导入和导出策略。即，可以经由表示VNR 52A的自定义资源对Kubernetes进行扩展，以将VNR 52A转换成相对于VN 50A和VN 50N所部署的一个或多个导入和导出策略，以经由VN 50A与VN 50N之间的路由信息分布而配置相互通信。一旦被配置，VN 50A则可以将路由信息(例如，表示VN 50A的路由)导出至VN 50N并且将路由信息(例如，表示VN 50N的路由)导入至VN 50A。同样，VN 50N可以将路由信息(例如，表示VN 50N的路由)导出至VN 50A并且将路由信息(例如，表示VN 50A的路由)导入至VN 50N。

抽象化可能隐藏底层路由配置，以实现该路由泄露，诸如定义用于实现VN 50A和VN 50N的路由实例的路由信息导入和导出的路由目标。替代地，网络控制器24可以将VNR52A转换成共同的路由目标并且经由用于实现VN 50A和VN 50N(在该实施例中)的路由实例的共同路由目标而配置路由信息的通信。

为了实现网状连接，网络控制器24可以将VN 50A、VN 50N、以及VNR 52A的路由实例的导入和导出配置有与VN 50A、VN 50N、以及VNR 52A相关联的路由目标。为了实现轴辐式连接，网络控制器24可以将与VN 50A和VN 50N相关联的路由实例的导出配置成将路由信息导出至与VNR 52A(用作中心)相关联的路由实例，并且将VNR 52A的路由实例配置成将路由信息导入至与VN 50A和VN 50N相关联的路由实例。在该轴辐式连接中，VN 50A和VN 50N彼此可能并不直接进行通信。

在该方面，网络控制器24可以对创建例如VNR 52A的请求进行处理，其中，VNR 52A表示一个或多个策略的逻辑抽象，该一个或多个策略致使发生在第一虚拟网络(例如，VN50A)与第二虚拟网络(例如，VN 50N)之间的路由信息的一个或多个导入和导出(1800)。接着，网络控制器24可以根据该一个或多个策略对VN 50A和VN 50N进行配置，以能够实现经由VNR 52A在VN 50A与VN 50N之间的路由信息的导入和导出的一项或多项(1802)。

同样，该技术的各个方面能够实现下列实例。

实例1.一种用于软件定义网络(SDN)架构系统的网络控制器，网络控制器包括：处理电路；配置节点，被配置为由处理电路执行；以及控制节点，被配置为由处理电路执行；其中，配置节点可执行为对创建虚拟网络路由器的请求进行处理，其中，虚拟网络路由器被配置为致使网络控制器使在SDN架构系统内操作的第一虚拟网络和第二虚拟网络互连，虚拟网络路由器表示一个或多个策略的逻辑抽象，该一个或多个策略致使发生在第一虚拟网络与第二虚拟网络之间的路由信息的导入和导出的一项或多项；并且其中，控制节点根据该一个或多个策略对第一虚拟网络和第二虚拟网络进行配置，以能够实现经由虚拟网络路由器在第一虚拟网络与第二虚拟网络之间的路由信息的导入和导出的一项或多项。

实例2.根据实例1所述的网络控制器，其中，请求包括与第一虚拟网络和第二虚拟网络相关联的标签；并且其中，配置节点基于标签对第一虚拟网络和第二虚拟网络进行识别，以根据该一个或多个策略而配置与虚拟网络路由器对应的路由实例，以致使在第一虚拟网络与第二虚拟网络之间导入和导出路由信息。

实例3.根据实例1和2中任一项所述的网络控制器，其中，请求指示虚拟网络路由器是网状虚拟网络路由器；并且其中，由网状虚拟网络路由器表示的该一个或多个策略包括对称的导入和导出策略，该对称的导入和导出策略致使在第一虚拟网络与第二虚拟网络之间导入和导出路由信息。

实例4.根据实例1至3中任一项所述的网络控制器，其中，请求指示虚拟网络路由器是中心虚拟网络路由器，第一虚拟网络是第一分支虚拟网络，并且第二虚拟网络是第二分支虚拟网络；并且其中，由中心虚拟网络路由器表示的该一个或多个策略包括非对称的导入和导出策略，该非对称的导入和导出策略致使将路由信息从第一分支虚拟网络和第二分支虚拟网络导出至虚拟网络路由器，但是不在第一分支虚拟网络与第二分支虚拟网络之间导入路由信息。

实例5.根据实例1至4中任一项所述的网络控制器，其中，第一虚拟网络与第一命名空间相关联；其中，第二虚拟网络与第二命名空间相关联；其中，虚拟网络路由器是第一虚拟网络路由器；其中，该一个或多个策略包括第一策略和第二策略；其中，第一虚拟网络路由器表示用于在第一虚拟网络与第二虚拟网络路由器之间导入和导出路由信息的第一策略；并且其中，第二虚拟网络路由器表示用于在第二虚拟网络与第一虚拟网络路由器之间导入和导出路由信息的第二策略。

实例6.根据实例5所述的网络控制器，其中，第一虚拟网络路由器在对第一策略进行部署之前必须获得使第一虚拟网络路由器与第二虚拟网络路由器互连的授权。

实例7.根据实例1至6中任一项所述的网络控制器，其中，网络控制器支持容器编排系统。

实例8.根据实例1至7中任一项所述的网络控制器，其中，虚拟网络路由器是用于SDN架构的SDN架构配置的自定义资源的实例；并且其中，配置节点包括将SDN架构的状态协调成虚拟网络路由器的预期状态的自定义资源控制器；并且其中，控制节点被配置为对虚拟网络路由器进行部署，以实现虚拟网络路由器的预期状态。

实例9.根据实例1至8中任一项所述的网络控制器，其中，使用共同的路由实例和共同的路由目标实现虚拟网络路由器；其中，使用第一路由实例和第一路由目标实现第一虚拟网络；其中，使用第二路由实例和第二路由目标实现第二虚拟网络；并且其中，控制节点被配置为将第一路由实例、第二路由实例、以及共同的路由实例的导入和导出配置有第一路由目标、第二路由目标、以及共同的路由目标，以实现网状连接。

实例10.根据实例1至9中任一项所述的网络控制器，其中，使用共同的路由实例和共同的路由目标实现虚拟网络路由器；其中，使用第一路由实例和第一路由目标实现第一虚拟网络；其中，使用第二路由实例和第二路由目标实现第二虚拟网络；其中，使用第三路由实例和第三路由目标实现第三虚拟网络；并且其中，控制节点被配置为将第一路由实例、第二路由实例、第三路由实例、以及共同的路由实例的导入和导出配置有第一路由目标、第二路由目标、第三路由目标、以及共同的路由目标，以实现轴辐式连接。

实例11.根据实例1至10中任一项所述的网络控制器，其中，使用第一多个计算节点中的一个或多个第一虚拟路由器实现第一虚拟网络；并且其中，使用第二多个计算节点中的一个或多个第二虚拟路由器实现第二虚拟网络。

实例12.根据实例11所述的网络控制器，其中，第一多个计算节点是第一Kubernetes集群；并且其中，第二多个计算节点是第二Kubernetes集群。

实例13.根据实例1至12中任一项所述的网络控制器，其中，控制节点将路由信息解析成用于第一虚拟网络和第二虚拟网络中的一个或多个虚拟网络的转发信息并且将转发信息安装在支持第一虚拟网络与第二虚拟网络之间的互连的虚拟路由器中。

实例14.一种方法，包括：由网络控制器对创建虚拟网络路由器的请求进行处理，其中，虚拟网络路由器被配置为致使网络控制器使在SDN架构系统内操作的第一虚拟网络和第二虚拟网络互连，虚拟网络路由器表示一个或多个策略的逻辑抽象，该一个或多个策略致使发生在第一虚拟网络与第二虚拟网络之间的路由信息的导入和导出的一项或多项；并且由网络控制器根据该一个或多个策略对第一虚拟网络和第二虚拟网络进行配置，以能够实现经由虚拟网络路由器在第一虚拟网络与第二虚拟网网络之间的路由信息的导入和导出的一项或多项。

实例15.根据实例14所述的方法，其中，请求包括与第一虚拟网络和第二虚拟网络相关联的标签；并且其中，对请求进行处理包括：基于标签对第一虚拟网络和第二虚拟网络进行识别，以根据该一个或多个策略而配置与虚拟网络路由器对应的路由实例，以致使在第一虚拟网络与第二虚拟网络之间导入和导出路由信息。

实例16.根据实例14和15中任一项所述的方法，其中，请求指示虚拟网络路由器是网状虚拟网络路由器；并且其中，由网状虚拟网络路由器表示的一个或多个策略包括对称的导入和导出策略，该对称的导入和导出策略致使在第一虚拟网络与第二虚拟网络之间的路由信息的导入和导出。

实例17.根据实例14和16中任一项所述的方法，其中，请求指示虚拟网络路由器是中心虚拟网络路由器，第一虚拟网络是第一分支虚拟网络，并且第二虚拟网络是第二分支虚拟网络；并且其中，由中心虚拟网络路由器表示的一个或多个策略包括非对称的导入和导出策略，该非对称的导入和导出策略致使将路由信息从第一分支虚拟网络和第二分支虚拟网络导出至虚拟网络路由器，但是不在第一分支虚拟网络与第二分支虚拟网络之间导入路由信息。

实例18.根据实例14至17中任一项所述的方法，其中，第一虚拟网络与第一命名空间相关联；其中，第二虚拟网络与第二命名空间相关联；其中，虚拟网络路由器是第一虚拟网络路由器；其中，该一个或多个策略包括第一策略和第二策略；其中，第一虚拟网络路由器表示用于在第一虚拟网络与第二虚拟网络路由器之间的路由信息的导入和导出的第一策略；并且其中，第二虚拟网络路由器表示用于在第二虚拟网络与第一虚拟网络路由器之间的路由信息的导入和导出的第二策略。

实例19.根据实例18所述的方法，其中，第一虚拟网络路由器在对部署第一策略之前必须获得使第一虚拟网络路由器与第二虚拟网络路由器互连的授权。

实例20.根据实例14至19中任一项所述的方法，其中，网络控制器支持容器编排系统。

实例21.根据实例14至20中任一项所述的方法，其中，虚拟网络路由器是用于SDN架构的SDN架构配置的自定义资源的实例；并且其中，对请求进行处理包括：将SDN架构的状态协调成虚拟网络路由器的预期状态；并且对虚拟网络路由器进行部署，以实现虚拟网络路由器的预期状态。

实例22.根据实例14至21中任一项所述的方法，其中，使用共同的路由实例和共同的路由目标实现虚拟网络路由器；其中，使用第一路由实例和第一路由目标实现第一虚拟网络；其中，使用第二路由实例和第二路由目标实现第二虚拟网络；并且其中，对请求进行处理包括：将第一路由实例、第二路由实例、以及共同的路由实例的导入和导出配置有第一路由目标、第二路由目标、以及共同的路由目标，以实现网状连接。

实例23.根据实例14至22中任一项所述的方法，其中，使用共同的路由实例和共同的路由目标实现虚拟网络路由器；其中，使用第一路由实例和第一路由目标实现第一虚拟网络；其中，使用第二路由实例和第二路由目标实现第二虚拟网络；其中，使用第三路由实例和第三路由目标实现第三虚拟网络；并且其中，对请求进行处理包括：将第一路由实例、第二路由实例、第三路由实例、以及共同的路由实例的导入和导出配置有第一路由目标、第二路由目标、第三路由目标、以及共同的路由目标，以实现轴辐式连接。

实例24.根据实例14至23中任一项所述的方法，其中，使用第一多个计算节点中的一个或多个第一虚拟路由器实现第一虚拟网络；并且其中，使用第二多个计算节点中的一个或多个第二虚拟路由器实现第二虚拟网络。

实例25.根据实例24所述的方法，其中，第一多个计算节点是第一Kubernetes集群；并且其中，第二多个计算节点是第二Kubernetes集群。

实例26.根据实例14至25中任一项所述的方法，进一步包括：将已交换的路由信息解析成用于第一虚拟网络和第二虚拟网络中的一个或多个虚拟网络的转发信息并且将转发信息安装在支持第一虚拟网络与第二虚拟网络之间的互连的虚拟路由器中。

实例27.一种包括指令的非暂时性计算机可读介质，指令用于致使网络控制器的处理电路：对创建虚拟网络路由器的请求进行处理，其中，虚拟网络路由器被配置为致使网络控制器使在SDN架构系统内操作的第一虚拟网络和第二虚拟网络互连，虚拟网络路由器表示一个或多个策略的逻辑抽象，该一个或多个策略致使在第一虚拟网络与第二虚拟网络之间的路由信息的导入和导出的一项或多项；并且根据一个或多个策略对第一虚拟网络和第二虚拟网络进行配置，以能够实现经由虚拟网络路由器在第一虚拟网络与第二虚拟网网络之间的路由信息的导入和导出的一项或多项。可以在硬件、软件、固件、或其任意组合中实现此处所描述的技术。可以在集成式逻辑设备中一起实现被描述为模块、单元、或组件的各个特征，或作为离散、但可相互操作或逻辑设备或其他硬件设备单独实现被描述为模块、单元、或组件的各个特征。在一些情况下，电子电路的各个特征可以实现为一个或多个集成电路设备，诸如集成电路芯片或芯片集。

如果在硬件中实现，则本公开可以面向诸如处理器的装置或诸如集成电路芯片或芯片集的集成电路设备。可替代地或此外，如果在软件或固件中实现，则可以至少部分通过计算机可读数据存储介质而实现技术，计算机可读数据存储介质包括指令，当执行指令时，致使处理器执行上面所描述的一种或多种方法。例如，计算机可读数据存储介质可以存储由处理器执行的该指令。

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

在一些示例中，计算机可读存储介质可以包括非易失性介质。术语“非易失性”可以指示不将存储介质包含到载波或传播信号中。在特定示例中，非易失性存储介质可以存储随着时间而改变的数据(例如，存储到RAM或缓存中)。

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

Claims

1.一种用于软件定义网络SDN架构系统的网络控制器，所述网络控制器包括：

处理电路；

配置节点，被配置为由所述处理电路执行；以及

控制节点，被配置为由所述处理电路执行；

其中，所述配置节点能执行为对创建虚拟网络路由器的请求进行处理，其中，所述虚拟网络路由器被配置为致使所述网络控制器使在所述SDN架构系统内操作的第一虚拟网络和第二虚拟网络互连，所述虚拟网络路由器表示一个或多个策略的逻辑抽象，所述一个或多个策略致使在所述第一虚拟网络与所述第二虚拟网络之间的路由信息的导入和导出的一项或多项；并且

其中，所述控制节点根据所述一个或多个策略对所述第一虚拟网络和所述第二虚拟网络进行配置，以能够实现经由所述虚拟网络路由器在所述第一虚拟网络与所述第二虚拟网络之间的所述路由信息的导入和导出的一项或多项。

2.根据权利要求1所述的网络控制器，

其中，所述请求包括与所述第一虚拟网络和所述第二虚拟网络相关联的标签；并且

其中，所述配置节点基于所述标签对所述第一虚拟网络和所述第二虚拟网络进行识别，以根据所述一个或多个策略配置与所述虚拟网络路由器对应的路由实例，以致使在所述第一虚拟网络与所述第二虚拟网络之间的所述路由信息的导入和导出。

3.根据权利要求1所述的网络控制器，

其中，所述请求指示所述虚拟网络路由器是网状虚拟网络路由器；并且

其中，由所述网状虚拟网络路由器表示的所述一个或多个策略包括对称的导入和导出策略，所述对称的导入和导出策略致使在所述第一虚拟网络与所述第二虚拟网络之间的所述路由信息的导入和导出。

4.根据权利要求1所述的网络控制器，

其中，所述请求指示所述虚拟网络路由器是中心虚拟网络路由器，所述第一虚拟网络是第一分支虚拟网络，并且所述第二虚拟网络是第二分支虚拟网络；并且

其中，由所述中心虚拟网络路由器表示的所述一个或多个策略包括非对称的导入和导出策略，所述非对称的导入和导出策略致使将来自所述第一分支虚拟网络和所述第二分支虚拟网络的所述路由信息导出至所述虚拟网络路由器，但是不在所述第一分支虚拟网络与所述第二分支虚拟网络之间导入所述路由信息。

5.根据权利要求1所述的网络控制器，

其中，所述第一虚拟网络与第一命名空间相关联；

其中，所述第二虚拟网络与第二命名空间相关联；

其中，所述虚拟网络路由器是第一虚拟网络路由器；

其中，所述一个或多个策略包括第一策略和第二策略；

其中，所述第一虚拟网络路由器表示用于在所述第一虚拟网络与第二虚拟网络路由器之间的所述路由信息的导入和导出的所述第一策略；并且

其中，所述第二虚拟网络路由器表示用于在所述第二虚拟网络与所述第一虚拟网络路由器之间的所述路由信息的导入和导出的所述第二策略。

6.根据权利要求5所述的网络控制器，其中，所述第一虚拟网络路由器在部署所述第一策略之前必须获得使所述第一虚拟网络路由器与所述第二虚拟网络路由器互连的授权。

7.根据权利要求1所述的网络控制器，其中，所述网络控制器支持容器编排系统。

8.根据权利要求1至7中任一项所述的网络控制器，

其中，所述虚拟网络路由器是用于所述SDN架构系统的SDN架构配置的自定义资源的实例；并且

其中，所述配置节点包括将所述SDN架构系统的状态协调成所述虚拟网络路由器的预期状态的自定义资源控制器；并且

其中，所述控制节点被配置为对所述虚拟网络路由器进行部署，以实现所述虚拟网络路由器的所述预期状态。

9.根据权利要求1至7中任一项所述的网络控制器，

其中，使用共同的路由实例和共同的路由目标实现所述虚拟网络路由器；

其中，使用第一路由实例和第一路由目标实现所述第一虚拟网络；

其中，使用第二路由实例和第二路由目标实现所述第二虚拟网络；并且

其中，所述控制节点被配置为将所述第一路由实例、所述第二路由实例、以及所述共同的路由实例的导入和导出配置有所述第一路由目标、所述第二路由目标、以及所述共同的路由目标，以实现网状连接。

10.根据权利要求1至7中任一项所述的网络控制器，

其中，使用第二路由实例和第二路由目标实现所述第二虚拟网络；

其中，使用第三路由实例和第三路由目标实现第三虚拟网络；并且

其中，所述控制节点被配置为将所述第一路由实例、所述第二路由实例、所述第三路由实例、以及所述共同的路由实例的导入和导出配置有所述第一路由目标、所述第二路由目标、所述第三路由目标、以及所述共同的路由目标，以实现轴辐式连接。

11.根据权利要求1至7中任一项所述的网络控制器，

其中，使用第一多个计算节点中的一个或多个第一虚拟路由器实现所述第一虚拟网络；并且

其中，使用第二多个计算节点中的一个或多个第二虚拟路由器实现所述第二虚拟网络。

12.根据权利要求11所述的网络控制器，

其中，所述第一多个计算节点是第一Kubernetes集群；并且

其中，所述第二多个计算节点是第二Kubernetes集群。

13.根据权利要求1至7中任一项所述的网络控制器，其中，所述控制节点将所述路由信息解析成用于所述第一虚拟网络和所述第二虚拟网络中的一个或多个虚拟网络的转发信息，并且将所述转发信息安装在支持所述第一虚拟网络与所述第二虚拟网络之间的互连的虚拟路由器中。

14.一种软件定义网络方法，包括：

由网络控制器对创建虚拟网络路由器的请求进行处理，其中，所述虚拟网络路由器被配置为致使所述网络控制器使在软件定义网络SDN架构系统内操作的第一虚拟网络和第二虚拟网络互连，所述虚拟网络路由器表示一个或多个策略的逻辑抽象，所述一个或多个策略致使在所述第一虚拟网络与所述第二虚拟网络之间的路由信息的导入和导出的一项或多项；并且

由所述网络控制器根据所述一个或多个策略对所述第一虚拟网络和所述第二虚拟网络进行配置，以能够实现经由所述虚拟网络路由器在所述第一虚拟网络与所述第二虚拟网络之间的所述路由信息的导入和导出的一项或多项。

15.根据权利要求14所述的方法，

其中，对所述请求进行处理包括：基于所述标签对所述第一虚拟网络和所述第二虚拟网络进行识别，以根据所述一个或多个策略配置与所述虚拟网络路由器对应的路由实例，以致使在所述第一虚拟网络与所述第二虚拟网络之间的所述路由信息的导入和导出。

16.根据权利要求14和15中任一项所述的方法，

17.根据权利要求14和15中任一项所述的方法，

其中，由所述中心虚拟网络路由器表示的所述一个或多个策略包括非对称的导入和导出策略，所述非对称的导入和导出策略致使将来自所述第一分支虚拟网络和所述第二分支虚拟网络的路由信息导出至所述虚拟网络路由器，但是不在所述第一分支虚拟网络与所述第二分支虚拟网络之间导入所述路由信息。

18.根据权利要求14和15中任一项所述的方法，

其中，所述第一虚拟网络与第一命名空间相关联；

其中，所述第二虚拟网络与第二命名空间相关联；

其中，所述虚拟网络路由器是第一虚拟网络路由器；

其中，所述一个或多个策略包括第一策略和第二策略；

19.根据权利要求18所述的方法，其中，所述第一虚拟网络路由器在部署所述第一策略之前必须获得使所述第一虚拟网络路由器与所述第二虚拟网络路由器互连的授权。

20.一种包括指令的非暂时性计算机可读介质，所述指令用于致使网络控制器的处理电路：

对创建虚拟网络路由器的请求进行处理，其中，所述虚拟网络路由器被配置为致使所述网络控制器使在软件定义网络SDN架构系统内操作的第一虚拟网络和第二虚拟网络互连，所述虚拟网络路由器表示一个或多个策略的逻辑抽象，所述一个或多个策略致使在所述第一虚拟网络与所述第二虚拟网络之间的路由信息的导入和导出的一项或多项；并且

根据所述一个或多个策略对所述第一虚拟网络和所述第二虚拟网络进行配置，以能够实现经由所述虚拟网络路由器在所述第一虚拟网络与所述第二虚拟网网络之间的所述路由信息的导入和导出的一项或多项。