CN115941456A - 用于连续部署的网络策略生成 - Google Patents

Abstract

本公开涉及用于连续部署的网络策略生成。在示例中，方法包括：由策略控制器从第一SDN架构系统获得关于在被部署至该第一SDN架构系统的分布式应用的工作负载之间所交换的封包流的流元数据；使用关于该封包流中的一封包流的流元数据识别封包流的源端点工作负载和目的地端点工作负载；生成网络策略规则，以允许封包流从该封包流的源端点工作负载到目的地端点工作负载；并且当将分布式应用部署至第二SDN架构系统时，将网络策略规则作为第二SDN架构系统的配置数据添加至配置存储库，以致使部署系统将第二SDN架构系统配置成具有网络策略规则以允许封包流从源端点工作负载到目的地端点工作负载。

Description

用于连续部署的网络策略生成

相关申请的交叉引用

本申请要求于2022年3月31日提交的美国专利申请号17/657,613的权益，美国专利申请号17/657,613要求于2021年10月4日提交的印度临时专利申请号202141044924的权益，通过引用将其全部内容结合在此。

技术领域

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

背景技术

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

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

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

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

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

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

发明内容

整体上，描述了用于生成并且验证连续部署的网络策略的技术。在一些实施例中，策略控制器将网络策略的自动生成与配置数据的部署进行集成，包括关于软件定义网络架构的网络策略。策略控制器可以确定被部署至SDN架构的分布式应用的预期流量模式，其中，数据平面并不对分布式应用的工作负载之间的封包流应用防火墙策略。基于这些流量模式，策略控制器能够自动生成数据平面可使用的网络策略，以在拒绝其他流量模式时允许分布式应用的预期流量模式。策略控制器可以将网络策略作为配置数据提交至配置存储库，配置存储库促使部署系统将包括网络策略的配置数据应用于SDN架构。在一些情况下，在存储库中将配置数据与应用部署进行集成，从而能够实现应用工作负载和SDN架构配置到计算基础设施的一致性按钮部署。

该技术可以提供实现至少一种实际应用的一个或多个技术优点。例如，该技术可以允许策略控制器和部署系统与SDN架构系统一起提供集成策略生成和管理以及部署，以便于相对于SDN架构的配置进行连续部署和连续集成，以支持分布式应用。如此，该技术可以补充用于应用开发的现有DevOps(开发运营)最佳实践并且将其应用于分布式应用部署与配置的网络策略自动化。这可以减少对手动策略确定和配置的需求并且针对可能具有上百个不同工作负载的更大应用部署促进更具扩展性的基础设施配置。通过与配置存储库进行集成，该技术针对每个部署生成用于分布式应用的相同SDN架构环境。

在实施例中，策略控制器包括处理电路并且被配置为：从第一软件定义网络(SDN)架构系统获得关于在被部署至第一SDN架构系统的分布式应用的工作负载之间所交换的封包流的流元数据；使用关于该封包流中的一封包流的流元数据，识别该封包流的源端点工作负载和目的地端点工作负载；生成网络策略规则，以允许封包流从该封包流的源端点工作负载到目的地端点工作负载；并且当将分布式应用部署至第二SDN架构系统时，将网络策略规则作为第二SDN架构系统的配置数据添加至配置存储库，以致使部署系统将第二SDN架构系统配置成具有允许封包流从源端点工作负载到目的地端点工作负载的网络策略规则。

在实施例中，方法包括：由策略控制器从第一软件定义网络(SDN)架构系统获得关于在被部署至第一SDN架构系统的分布式应用的工作负载之间所交换的封包流的流元数据；由策略控制器使用关于该封包流中的一封包流的流元数据，识别该封包流的源端点工作负载和目的地端点工作负载；由策略控制器生成网络策略规则，以允许封包流从该封包流的源端点工作负载到目的地端点工作负载；并且当将分布式应用部署至第二SDN架构系统时，由策略控制器将网络策略规则作为第二SDN架构系统的配置数据添加至配置存储库，以致使部署系统将第二SDN架构系统配置成具有允许封包流从源端点工作负载到目的地端点工作负载的网络策略规则。

在实施例中，非易失性计算机可读介质包括指令，指令用于致使策略控制器的处理电路：从第一软件定义网络(SDN)架构系统获得关于在被部署至第一SDN架构系统的分布式应用的工作负载之间所交换的封包流的流元数据；使用关于该封包流中的一封包流的流元数据，识别该封包流的源端点工作负载和目的地端点工作负载；生成网络策略规则，以允许封包流从该封包流的源端点工作负载到目的地端点工作负载；并且当将分布式应用部署至第二SDN架构系统时，将网络策略规则作为第二SDN架构系统的配置数据添加至配置存储库，以致使部署系统将第二SDN架构系统配置成具有允许封包流从源端点工作负载到目的地端点工作负载的网络策略规则。

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

附图说明

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

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

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

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

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

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

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

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

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

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

图10是示出根据本公开的技术的被部署至SDN架构的数据平面的示例性分布式应用的框图。

图11是示出根据本公开的技术的SDN架构的操作的示例性模式的流程图。

图12是示出根据本公开的技术的SDN架构的操作的示例性模式的流程图。

图13是示出根据本公开的技术的SDN架构的操作的示例性模式的流程图。

贯穿描述与附图，类似参考字符表示类似元件。

具体实施方式

图1是示出可以实现此处所描述的技术的示例的示例性计算基础设施8的框图。用于虚拟网络的软件定义网络(SDN)架构的当前实现方式由于例如生命周期管理的复杂性、资源分析组件的强制性高、配置模块的扩展性限制、以及无基于命令行接口(CLI)的(如kubectl)接口而使得云本地采用面临挑战。计算基础设施8包括此处所描述的云本地SDN架构系统(或更简单地，称为“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)进行集成。

此处所描述的SDN架构实现了防火墙策略框架。防火墙策略框架支持使用标记来帮助简化并且抽象化容器工作负载，诸如Kubernetes容器池。在明显增强用户可见性和分析功能的同时，防火墙策略框架允许路由从安全策略解耦并且提供多维分割与策略移植性。防火墙策略框架使用标记，可以实现各个实体之间并且具有安全特征的多维流量分割。标记是与部署中的不同实体相关联的关键值配对。能够对标记进行预定义或自定义。

在诸如Kubernetes的一些容器编排平台中，网络策略是容器池指定的并且应用于一个容器池或一组容器池。网络策略是允许成组的容器池如何彼此并且与其他网络端点工作负载进行通信的规范。网络策略资源使用标签来选择容器池并且定义规定允许什么流量到所选择的容器池的规则。在Kubernetes中：

·网络策略能够定义容器池在入口、出口、或两个方向上的流量规则。默认地，如果未明确规定方向，则对入口方向应用网络策略。

·当对容器池应用网络策略时，策略必须具有指定许可流量在入口和出口方向上的允许列表的明确规则。拒绝并且丢弃不与允许列表规则相匹配的全部流量。

·能够对任意容器池应用多种网络策略。必须允许与任意一种网络策略相匹配的流量。

·网络策略作用于连接、而非单个封包。例如，如果所配置的策略允许流量从容器池A到容器池B，则即使适当的策略并不允许容器池B发起到容器池A的连接，也允许从容器池B到容器池A的该连接的返回封包。

·入口策略：入口规则由源标识与协议：来自被允许转发给容器池的源的流量的端口类型，构成。源标识可以是下列类型：

ο非传统网络区域路由(CIDR)块-如果源IP地址来自CIDR块并且流量与协议：端口相匹配，则将流量转发给容器池。

οKubernetes命名空间-命名空间选择器识别命名空间，该命名空间的容器池能够将已定义的协议：端口流量发送至入口pod。

ο容器池-容器池选择器识别命名空间中与网络策略对应的容器池，该pod能够将匹配协议：端口流量发送至入口容器池。

ο出口策略：这指定了许可从网络策略针对的容器池到其具体协议：流量的端口类型的允许列表CIDR。目的地的标识可以是下列类型：

οCIDR块-如果目的地IP地址来自CIDR块并且流量与协议：端口相匹配，则将流量转发至目的地。

οKubernetes命名空间-命名空间选择器识别命名空间，该命名空间的容器池能够将已定义的协议：端口流量发送至出口容器池。

ο容器池-容器池选择器识别命名空间中与网络策略对应的容器池，该容器池能够从出口容器池接收相匹配的协议：端口流量。

上面相对于容器池所描述的技术可以应用于其他容器编排平台的其他类型的工作负载以及工作负载部署结构。

就每个语义规定网络策略的语义方面而言，Kubernetes网络策略与SDN架构可以不同。通过SDN架构防火墙策略有效地实现Kubernetes网络策略的关键在于：在这两个实体之间映射出对应的配置构造，其示例如下：

·标签→自定义标记(tag)(每个标签一个标记)

·命名空间→自定义标记(每个命名空间一个标记)

·网络策略→防火墙策略(每种网络策略一个防火墙策略)

·规则防火墙规则→(每个网络策略规则一个防火墙规则)

·CIDR规则→地址组

·集群默认→应用策略集。

对Kubernetes网络策略标签的解析是简单明了的。pod在防火墙策略中的表示与在对应的Kubernetes网络策略中的表示完全相同。防火墙策略对SDN架构中的术语的标签或标记进行处理。其并不将标签扩展到IP地址。例如，在默认的命名空间中，如果网络策略podSelectorspecifies:role＝db，则对应的防火墙规则将容器池规定为(role＝db&&namespace＝default)。并不进行到容器池IP地址或其他地址的其他转换。

如果相同的网络策略还具有如namespace＝myproject的namespaceSelector，则对应的防火墙规则将该命名空间表示为(namespace＝myproject)。并不在“myproject”命名空间中进行表示容器池的其他转换或规则。

同样，每个CIDR由一种规则表示。实际上，将Kubernetes网络策略以1:1转换成防火墙策略。仅存在针对每种Kubernetes网络策略所创建的一个额外防火墙规则。该规则的目的是实现网络策略的隐式拒绝需求，并且并不创建其他规则。

由此处所描述的SDN架构实现的基于云的部署和配置可以促进自动生成并且验证用于连续部署的网络策略。该网络策略可以是Kubernetes资源和/或可以是由本公开中所描述的SDN架构实现的防火墙策略框架所指定的防火墙策略。

通常，一个或多个数据中心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”)提供的这些容器。如同虚拟机，每个容器被虚拟化并且可以保持与主机及其他容器隔离。然而，不同于虚拟机，每个容器可以省去独立的操作系统并且反而提供应用套件和应用特定的库。通常，容器由主机运行作为隔离的用户-空间实例并且容器可以与在主机上运行的其他容器共享操作系统和共同的库。由此，容器可能需要比虚拟机更低的处理能力、存储、以及网络资源。一组一个或多个容器可以被配置为共享用于在对应的虚拟网络上进行通信的一个或多个虚拟网络接口。

在一些示例中，由其主机内核管理容器，以允许在一些情况下使用命名空间隔离功能对资源(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。这包括封包轮询、封包处理、以及封包转发。可以由虚拟路由器21 DPDK数据平面执行用户封包处理步骤，内核(在图1中未示出内核)参与有限或不参与。与中断模式相比较，具体当封包速率较高时，该“轮询模式”的性质使得虚拟路由器21 DPDK数据平面封包处理/转发更高效。在封包I/O期间存在有限的中断或不存在中断、并且存在上下文切换。

在瞻博网络公司的Kiran KN等人于2021年发表的“DAY ONE:CONTRAIL DPDKvROUTER”中找到了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年5月26日提交并且题为“Tunneled Packet Aggregation for Virtual Networks”的美国专利申请号14/226,509中找到了关于结合数据中心10的其他设备或其他软件定义网络进行操作的网络控制器24的示例性操作的额外信息，如此处进行全面阐述的，通过引用结合各个申请。

通常，编排器23跨服务器12的集群控制容器的部署、扩展、以及操作并且提供计算基础设施，计算基础设施可以包括以容器为中心的计算基础设施。编排器23，并且在一些情况下，网络控制器24可以针对一个或多个Kubernetes集群实现相应的集群主控。作为示例，Kubernetes是跨公共云和私有云提供便携性的容器管理平台，其中每个云可以向容器管理平台提供虚拟化基础设施。下面参考图3对Kubernetes编排系统的示例性组件进行描述。

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

命名空间能够使得多个用户、用户团队、或具有多个应用的单一用户使用一个Kubernetes集群。此外，每个用户、用户团队、或应用可以在命名空间内与集群的每个其他用户隔离。因此，在命名空间内Kubernetes集群的每个用户操作为如同其是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中配置)被称为虚拟网络策略(VNP)并且可替代地此处被称为虚拟网络路由器或虚拟网络拓扑的网络策略。VNP定义了虚拟网络之间的连接策略。单一网络控制器24可以支持多个Kubernetes集群，并且由此，VNP允许在命名空间、Kubernetes集群中、并且跨Kubernetes集群连接多个虚拟网络。VNP还可以扩展为支持跨网络控制器24的多个实例的虚拟网络连接。

网络控制器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。

根据本公开的技术，系统8包括用于动态生成并且验证网络策略的开发系统52、策略控制器54、以及配置存储库50。配置存储库50可以实现诸如Git存储库的一个或多个存储库，以将用于应用部署的配置数据存储至SDN架构200并且进行管理。配置存储库50可以包括用于存储配置数据的一个或多个存储系统。配置存储库50可以包括用于跟踪配置数据的创建和修改的软件，以便于协作地更新并且开发使用配置存储库50所部署的应用的配置。用于配置存储库50的软件可以实现版本控制并开发分支，其中，具有所提交的配置数据的存储库可以被分支，以使用包括之前提交的配置数据的更新的后续提交，在另一“分支”中创建可替代的配置数据。因此，配置存储库50可以存储相同应用的多个配置数据集，每个配置数据集表示不同的配置并且导致SDN架构200中的应用的操作不同。用于应用的给定配置数据集可以被视为是用于限定该应用的所需应用状态的真实来源。应用可以是可部署至计算基础设施的工作负载集，并且可以使用网络控制器24配置SDN架构200，以实现应用的工作负载之间的网络通信。例如，用于应用的配置数据能够包括Kubernetes清单、网络策略(无论是Kubernetes清单中所包括的、还是其他地方所定义的)、容器池描述、网络配置、以及用于限定支持应用的SDN架构200的操作的其他配置数据，具体地，用于支持应用的工作负载之间的网络通信。

部署系统52利用配置存储库对被部署至计算基础设施8并且更具体地被部署至SDN架构200的应用进行配置。部署系统52可以便于连续交付(CD)可部署至SDN架构200的应用。例如，部署系统52可以自动部署来自配置存储库50的应用的配置数据。部署系统52可以跟踪配置存储库50中的配置数据的更新，并且响应于更新，可以获得所更新的配置数据并且将所更新的配置数据提供至网络控制器24的配置节点30，以配置该应用的SDN架构200。在一些示例中，将部署系统52与编排器23进行集成。

在一些情况下，将配置存储库50中的配置数据与应用部署进行集成，从而能够实现应用工作负载和SDN架构200配置到计算基础设施8的一致性按钮部署。由此，在该情况下，配置存储库操作为完整的应用部署存储库。

图10是示出根据本公开的技术的被部署至SDN架构200的数据平面的示例性分布式应用1050的框图。应用1050包括使用容器池22被部署至服务器12的各种微服务组件，例如，“EmailService”和“AdService”。微服务组件旨在通过所示出的方式彼此通信。例如，CartService从CheckoutService和Frontend接收服务请求，并且CartService向Cache发出服务请求。用于应用1050的网络策略允许所部署的容器池以这样的方式进行通信，即，便于这些容器池中所包括的微服务组件之间进行预期的通信。例如，服务器12A上的容器池22可以包括CheckoutService的容器并且应被允许与服务器12X上包括CartService的容器的容器池22进行通信。应用能够包括使用容器池、虚拟机、裸金属服务器进程、或使用其组合所部署的组件。

现返回图1，如下面进一步详细描述的，虚拟路由器21应用所配置的策略1000。例如，可以使用通过控制节点32而下载至虚拟路由器21的一个或多个防火墙规则而实现策略1000。

一旦由编排器23部署并且由网络控制器24配置应用(例如，应用1050)，应用则在SDN架构200的数据平面中作为由服务器12执行的工作负载(例如，容器池22)而运行。根据本公开的技术，策略控制器54动态地生成用于包括工作负载的分布式应用的网络策略1010。图11是示出SDN架构的操作1100的示例性模式的流程图。在该示例中，策略控制器54可以从配置存储库50获得第一配置数据集(1102)。第一配置数据集可以包括网络策略。策略控制器54可以将第一配置数据集应用于被部署到SDN架构200的应用，SDN架构200可以调用配置节点30的接口，以利用第一配置数据集的网络策略对SDN架构200进行编程(1104)。由于策略控制器54可以生成新的网络策略，而不存在现有网络策略被编程到SDN架构200中，所以步骤1102与步骤1104是可选的。在一些示例中，策略控制器54从配置节点30获得当前网络策略，配置节点30可以将当前网络策略存储在配置存储器中。

然后，策略控制器54开启SDN架构200的数据平面中的封包流上的监视(1106)。为了开启监视，策略控制器54可以向配置节点30发送禁用虚拟路由器21中所配置的防火墙策略1000的请求。因此，虚拟路由器21允许所部署的应用的工作负载之间的全部流量。(这可能与默认的Kubernetes网络策略相符合)。

策略控制器54可以接收指示用于动态生成网络策略的测试参数的用户输入(1108)。测试参数可以沿着应用执行的一个或多个维度而缩小分析范围。例如，应用可以具有不同的层(例如，应用、网络、数据库等)、在不同的站点执行、根据不同的角色执行。该应用可以表示多个不同的应用，并且测试参数可以仅指定对不同应用的子集的分析。测试参数可以包括时间范围。在一些情况下，可以通过测试参数约束在步骤1106开启的监视，以使得虚拟路由器21仅停止应用影响测试参数所涵盖的工作负载的这些防火墙策略1000，例如，仅具体应用或位于具体站点的工作负载。

分布式应用在SDN架构200中运行并且生成虚拟路由器21在服务器12之间进行路由的封包流(1110)。虚拟路由器21还可以经由服务供应商网络7从外部源接收用于转发至应用工作负载的封包流，并且虚拟路由器21还可以经由服务供应商网络7将由应用工作负载生成的封包流发送至外部目的地。虚拟路由器21生成并且存储封包流的会话记录。

策略控制器54从SDN架构200获得遥测数据，遥测数据包括关于分布式应用的工作负载之间的封包流的流元数据(1114)。在一些示例中，流元数据可以是由虚拟路由器21处理的封包流(例如，用于在工作负载之间转发)的流量统计的会话记录。策略控制器54将封包流的流量统计的会话记录关联到工作负载的流量统计的会话记录中。流元数据指示从工作负载到其他工作负载的流。

在一个示例中，为了将封包流的会话记录关联到工作负载的会话记录中，策略控制器54经由用户接口设备将封包流的流量统计的会话记录提供给用户或管理员。进一步地，策略控制器54经由用户接口设备接收指定哪些封包流与给定的工作负载对应的输入并且基于该输入将封包流的会话记录聚合到工作负载的会话记录中。

在另一示例中，策略控制器54基于由封包流的会话记录所指定的一个或多个标记，而将封包流的会话记录关联到工作负载的会话记录中。例如，封包流的会话记录可以指定与工作负载被标记的标记对应的一个或多个标记。策略控制器54可以使用该标记使工作负载匹配到封包流的一些具体的会话记录并且基于匹配标记将封包流的会话记录聚合到工作负载的会话记录中。

如此处所描述的，在另一示例中，策略控制器54将封包流的会话记录关联到工作负载的会话记录中。进一步地，策略控制器54可以从封包流的会话记录生成与工作负载被标记的标记对应的一个或多个标记并且将所生成的标记应用于会话记录。例如，策略控制器54可以使用会话记录中的元数据来生成与工作负载被标记的标记对应的一个或多个标记并且将所生成的标记应用于会话记录。策略控制器54可以基于标记将封包流的会话记录聚合到工作负载的会话记录中。进一步地，如下面更为详细描述的，策略控制器54可以使用所生成的标记来生成一个或多个应用策略，以应用于工作负载的实例之间的封包流。

在另一示例中，策略控制器54通过对封包流的会话记录应用聚类算法，而将封包流的会话记录关联到工作负载的会话记录中。例如，策略控制器54可以使用聚类算法来识别封包流与指定工作负载的会话记录之间的关系，并且基于该关系将封包流的会话记录聚合到工作负载的会话记录中。在一些示例中，聚类算法是K-均值聚类算法、Mean-Shift聚类算法、基于密度的有噪声的空间聚类应用(DBSCAN)聚类算法、可以使用高斯混合模型(GMM)的期望最大化(EM)聚类算法、和聚合层次聚类算法中的一种。

在获得或生成流元数据的上述示例中，可以将流元数据约束至与在测试步骤1108所获得的测试参数相匹配的封包流。例如，流元数据可以仅用于被部署在特定站点、或符合具体的一个或多个角色、或位于具体时间范围内的工作负载之间的封包流。

策略控制器54基于在监视开启时所交换的封包流的流元数据的分析而动态地生成SDN架构200的策略1010(1116)。为了生成策略，可以将流元数据中的流记录的端点关联至端点工作负载，其中，例如，端点工作负载可以实现具体的微服务组件或进程。可以将流记录的端点表示为虚拟网络地址。例如，具体的流记录可以指示实现工作负载A的容器池A(第一端点)与实现工作负载B的容器池B(第二端点)之间的封包流。因此，策略控制器54可以生成新的网络策略规则，以允许流量从工作负载A到工作负载B。可以使用工作负载的任意特征来表达新的网络策略规则，诸如标签、命名空间、网络地址/子网、集群、站点、角色等。策略控制器54可以对策略规则进行组合并且可以根据一个或多个网络策略1010对网络策略规则进行合并。

在一些示例中，策略控制器54可以可选地基于用户输入而确定是否应用新的网络策略(1118)。策略控制器54输出新网络策略1010的指示，以在用户接口设备显示器处进行显示。如果用户不批准新的网络策略1010(1120中否分支)，策略控制器54则可以结束操作(1126)。在一些情况下，策略控制器54可以接收用户输入，以代替为修改新的网络策略1010。

如果用户批准(经过修改或不修改)网络策略1010或者策略控制器54在不需要用户批准的情况下应用新的网络策略1010(1120中，是分支)，策略控制器54则使用新的网络策略1010对第一配置数据集进行修改，以生成第二配置数据集，并且策略控制器54将第二配置数据集作为项目的新分支提交至配置存储库50(1122)。可替代地，策略控制器54可以在不修改第一配置数据集的情况下而创建第二配置数据集作为新的配置数据。

部署系统52可以检测对配置存储库50进行的修改，并且响应于该修改，将包括网络策略1010的第二配置数据集发送至网络控制器24的配置节点30，并且网络控制器24将虚拟路由器21中的策略1000配置为实现该应用部署的网络策略1010(1124)。

在一些示例中，相比于用于生成网络策略1010的SDN架构，该应用部署可能是不同的SDN架构。例如，测试台SDN架构可以用于生成网络策略1010，而产品SDN架构可以运行产品应用并且配置有网络策略1010。

在一些情况下，网络策略1010表示编排器23的网络策略。例如，网络策略1010可以是Kubernetes本地资源，即，Kubernetes网络策略。配置节点30可以将表示编排器23的本地资源的网络策略1010转换成SDN架构配置的自定义资源。例如，该自定义资源可以是虚拟路由器21所理解的防火墙策略。下面对该过程进行了进一步详细的描述。在该示例中，策略1000可以表示在虚拟路由器21中被实例化并且与自定义资源对应的SDN架构配置对象。在不同的服务器12上操作的不同虚拟路由器21可以实现不同的策略集，根据不同的策略集，工作负载在虚拟路由器所在的服务器上进行操作。

策略控制器54与部署系统52各自可以表示与SDN架构200分离的计算系统。策略控制器54与部署系统52中的每个可以包括由服务器或专用设备的处理电路执行的一个或多个应用。在一些示例中，策略控制器54可以包括由服务器12的处理电路执行的一个或多个应用。在一些示例中，部署系统52与策略控制器54可以被组合成策略控制器。策略控制器54与部署系统52可以在公共云或私有云中实现。

图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)接口248来支持SDN架构200的意图驱动配置。用于将意图推送至配置节点230的示例性平台与应用包括虚拟机编排器240(例如，Openstack)、容器编排器242(例如，Kubernetes)、用户接口244、或者其他一个或多个应用246。在一些示例中，SDN架构200将Kubernetes作为其基础平台。

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

在高层级，配置节点230使用配置存储224来管理SDN架构200的配置资源状态。通常，配置资源(或更简单地“资源”)是包括描述自定义资源的数据和/或方法的命名对象模式，并且定义了用于通过API服务器创建并且操纵数据的应用编程接口(API)。种类是对象模式的名称。配置资源可以包括Kubernetes本地资源，诸如容器池、入口、配置图、服务、角色、命名空间、节点、网络策略、或负载平衡。根据本公开的技术，配置资源还包括自定义资源，该自定义资源用于通过定义Kubernetes平台的默认安装中不可用的应用编程接口(API)而扩展Kubernetes平台。在SDN架构200的示例中，自定义资源可以描述SDN架构200的物理基础设施、虚拟基础设施、配置、和/或其他资源。作为配置与操作SDN架构200的一部分，可以对各种自定义资源进行实例化。被实例化的资源(无论本地还是自定义)可以被称为资源的对象或实例，即，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。如上面参考图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的节点的自动扩展。

图4是示出根据本公开的技术的SDN架构的示例性组件的框图。在该示例中，SDN架构400对用于网络配置对象的Kubernetes API服务器进行扩展和使用，以实现该网络配置的用户意图。在Kubernetes术语中，该配置对象被称为自定义资源，并且当在SDN架构中存留时，被简称为对象。配置对象主要是用户意图(例如，虚拟网络、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-api服务器)可以接收Kubernetes配置对象、本地对象(容器池、服务)、以及自定义资源。用于SDN架构400的自定义资源可以包括配置对象，当在SDN架构400中实现配置对象的预期状态时，该配对对象实现SDN架构400的预期网络配置。自定义资源可以与针对网络配置进行传统限定、但符合本公开的技术的配置方案对应，自定义资源被扩展为通过聚合API 402进行操纵。可替代地，该自定义资源可以被命名并且此处被称为“用于SDN架构配置的自定义资源”。用于SDN架构配置的每种自定义资源可以与通常由SDN控制器暴露、但符合此处所描述的技术的配置对象类型对应，使用自定义资源暴露配置对象并且使配置对象与Kubernetes本地/内置资源进行合并。这些配置对象可以包括虚拟网络、bgp即服务(BGPaaS)、子网、虚拟路由器、服务实例、项目、物理接口、逻辑接口、节点、网络ipam、浮动ip、警报、别名ip、接入控制列表、防火墙策略、防火墙规则、网络策略、路由目标、路由实例等。因此，SDN架构系统400支持由聚合API 402暴露的统一意图模型，即，通过Kubernetes控制器406A-406N并且通过自定义资源控制器302(在图4中被示出为组件微服务302A-302L)实现该统一意图模型，Kubernetes控制器406A-406N与自定义资源控制器302致力于使包括网络元件的计算基础设施的实际状态与预期状态一致。

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。

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

默认地，自定义资源控制器302运行主动-被动模式并且使用主控选举实现一致性。当控制器容器池开始时，其尝试使用指定的秘钥在Kubernetes中创建ConfigMap资源。如果创建成功，该容器池则变成主控并且开始处理协调请求；否则，该容器池阻挡尝试创建死循环的ConfigMap。

自定义资源控制器302可以跟踪其所创建的自定义资源的状况。例如，虚拟网络(VN)创建路由实例(RI)，路由实例(RI)创建路由目标(RT)。如果创建路由目标失败，路由实例状况则发生退化，并且由此，虚拟网络状况也发生退化。因此，自定义资源控制器302可以输出指示这些自定义资源的状况的自定义消息，来排除故障。图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。NIC 530在出站接口上输出该封包。如果目的地是在计算设备500上执行的另一虚拟网络端点，虚拟路由器506则将该封包路由至虚拟网络接口中的一个适当的虚拟网络接口。

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

容器池502A包括一个或多个应用容器529A。容器池502B包括容器化路由协议守护进程(cRPD)560的实例。容器平台588包括容器引擎590、编排代理592、服务代理593、以及CNI 570。

容器引擎590包括由微处理器510执行的代码。容器引擎590可以是一个或多个计算机进程。容器引擎590运行容器529A-529B的形式的容器化应用。容器引擎590可以表示Docker、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中描述了容器化路由协议守护进程，通过引用将其全部内容结合在此。

虚拟路由器506基于由配置节点30接收的网络策略而实现由控制节点32配置的策略1000。策略1000可以包括一个或多个应用防火墙策略规则，并且一个或多个应用防火墙策略规则中的每个应用防火墙策略规则限定一个虚拟路由器21是否应该允许或拒绝相应工作负载的封包流。例如，策略控制器54可以使用工作负载的会话记录的5元组来定义应用防火墙策略规则的5元组。进一步地，策略控制器54可以基于会话记录定义防火墙策略规则的规则(例如，允许、阻挡、记录、或报告与规则对应的流量)。在一些示例中，每个防火墙策略规则规定了允许对应的网络流量的默认规则，并且阻挡不与所生成的防火墙策略规则匹配的全部其他网络流量。

在示例中，策略控制器54使用SDN架构配置对象来实现网络策略1010。作为一个示例，策略控制器54应用全局级的第一配置对象集。第一配置对象集包括跨多个级和/或类别的全局应用策略集、全局防火墙策略、全局防火墙规则、以及全局标记。例如，策略控制器54将全局级的第一配置对象集分配给虚拟路由器。策略控制器54使与全局应用策略集、全局防火墙策略、以及全局防火墙规则相关联的全局标记匹配到标记有全局标记的对象。基于全局应用策略集、全局防火墙策略、以及全局防火墙规则，策略控制器54允许或阻挡标记有全局标记的对象的虚拟网络接口之间的网络流量。例如，接口可以是虚拟机接口(VMI)。

进一步地，在该示例中，策略控制器54应用项目级的第二配置对象集。第二配置对象集可以包括跨多个级的项目指定应用策略集、防火墙策略、防火墙规则、以及标记。策略控制器54分配项目级的第二配置对象集。策略控制器54使与项目指定应用策略集、防火墙策略、以及防火墙规则相关联的项目标记匹配到标记有项目标记的对象。基于项目指定的应用策略集、防火墙策略、以及防火墙规则，策略控制器54允许或阻挡标记有项目标记的对象接口之间的网络流量。

在进一步的示例中，策略控制器54可以指定低级配置对象，诸如，虚拟网络特定级别、虚拟机特定级别、和/或接口特定级别所定义的应用策略集、防火墙策略、防火墙规则、以及标记。由此，策略控制器54可以对一个或多个数据中心10内的多个对象应用分级策略集。由此，本公开的技术允许分配跨多种不同类型的部署和执行环境进行扩展并且鲁棒的简化流量策略。在于2017年11月22日提交并且题为“Scalable Policy Management forVirtual Networks”的美国专利申请号15/819,522以及于2020年4月2日公布并且题为“Intent-based Policy Generation for Virtual Networks”的美国公开号US 2020/0106744中找到了额外的描述，通过引用将其全部内容结合在此。

在一些示例中，图1中的网络策略1000可以是Kubernetes网络策略。示例性的Kubernetes网络策略“test-network-policy”如下：

如上所述，SDN控制器管理器303将编排器与SDN架构绑定在一起。作为该绑定的一方面，SDN控制器管理器303收听网络策略1010的更新作为编排平台的本地资源并且将这些网络策略事件转换成SDN架构配置对象。这可以包括SDN控制器管理器303调用自定义API服务器301来创建与网络策略对应的防火墙策略形式的自定义资源。

在对网络策略执行该转换的示例性操作集中，SDN控制器管理器303可以为每个Kubernetes标签创建标记、创建地址组、为每个Kubernetes网络策略创建防火墙策略、并且创建应用策略集(APS)来表示集群(在该集群中所创建的全部防火墙策略被附接至该应用策略集)。对现有Kubernetes网络策略的修改导致SDN控制器管理器303对对应的防火墙策略进行更新。标记、防火墙策略、以及APS是根据本公开的技术的全部自定义资源。

对于上面示例性的Kubernetes网络策略“test-network-policy”，如果其还不存在，SDN控制器管理器303则可以创建下列标记：{role:db,namespace:default}；如果其还不存在(名称：前缀)，则可以创建下列地址组：{17x.xx.1.0/24:17x.xx.1.0/24,17x.xx.0.0/16:17x.xx.0.0/16,10.0.0.0/24:10.0.0.0/24}；并且如果其还不存在，则可以创建下列防火墙规则：(Rule name,action,services,endpoint1,direction,endpoint2){default-ingress-test-network-policy-0-ipBlock-0-17x.xx.1.0/24-0,deny,tcp:6379,Address Group:17x.xx.1.0/24,>,role＝db&&namespace＝default；；default-ingress-test-network-policy-0-ipBlock-0-cidr-17x.xx.0.0/16-0,pass,tcp:6379,Address Group:17x.xx.0.0/16,>,role＝db&&namespace＝default；；default-ingress-test-network-policy-0-namespaceSelector-1-0,pass,tcp:6379,project＝myproject,>,role＝db&&namespace＝default；；default-ingress-test-network-policy-0-podSelector-2-0,pass,tcp:6379,namespace＝default&&role＝frontend,>,role＝db&&namespace＝default；；default-egress-test-network-policy-ipBlock-0-cidr-10.0.0.0/24-0,pass,tcp:5978,role＝db&&namespace＝default,>,Address10.0.0.0/24}。标志符“pass”指允许。该上下文中的Endpoint是与针对端点所列出的标准相匹配的端点工作负载，例如，前缀范围内的地址或标记有所列出的标记的工作负载。相反，Kubernetes端点是容器池的IP地址和端口的资源。

SDN控制器管理器303可以再次使用自定义API服务器301而创建包括上面规则的防火墙安全策略。控制节点232可以经由虚拟路由器代理获得防火墙规则并且将其编程到虚拟路由器中，虚拟路由器代理将防火墙策略规则实现为策略1000。

由于上述技术，策略控制器54、部署系统52、配置存储库50、以及网络控制器24提供集成式策略生成和管理以及部署，以便于相对于支持分布式应用的SDN架构的配置而进行连续部署和连续集成。

图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架构配置的自定义资源的数据。服务可以是定义容器池的逻辑集合和用于访问容器池的策略的抽象化。基于服务定义选择实现服务的容器池集。服务可以部分实现为负载平衡器或通过其他方式包括负载平衡器。API服务器300A与自定义API服务器301A可以实现表述性状态转移(REST)接口，以对REST操作进行处理并且将前端作为SDN架构的配置平面的一部分提供给存储到配置存储1328的对应集群共享状态。API服务器300A可以表示KubernetesAPI服务器。

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

调度器1322包括可由微处理器1310执行的代码。调度器1322可以是一个或多个计算机进程。调度器1322监测新创建或已请求的虚拟执行元件(例如，容器中的容器池)并且选择虚拟执行元件运行的从节点。调度器1322可以基于资源需求、硬件约束、软件约束、策略约束、局部性等而选择从节点。调度器1322可以表示Kubernetes调度器。

通常，API服务器300可以调用调度器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的编排能力的核心是使用基于虚拟网络(及有关对象)的抽象化对网络虚拟化进行建模的能力。控制节点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进行编程。

图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模型表现良好。并且虚拟路由器代理514用作暴露客户端(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代理514仅连接至三个控制节点中的两个控制节点，所以全部控制节点在某一时间内可能不具有树的完整图片并且依赖BGP来同步控制节点之间的状态。因为虚拟路由器代理514可以随机地选择两个，所以三个控制节点232加剧了这种情况。如果仅存在两个控制节点232，每个虚拟路由器代理514则连接至相同的控制节点。这进而指控制节点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中的转发表，以找出经由封装隧道到目的地所运行的主机的路由。

图12是示出SDN架构的操作的示例性模式的流程图。在该示例中，网络控制器24可以接收新的网络策略(1202)。网络控制器使SDN架构200配置有当前网络策略，但是，对当前网络策略进行修改，以整合新的网络策略(1204)。例如，新的网络策略可以对现有的策略规则进行修改、创建新的策略规则、或删除现有的策略规则。一旦SDN架构200配置有由新的网络策略进行修改的网络策略，分布式应用则运行并且工作负载交换封包流。

策略控制器54从SDN架构200获得遥测数据，遥测数据包括关于分布式应用的工作负载之间的封包流的流元数据(1206)。上面参考图11对用于获得流元数据的示例性技术进行了描述。策略控制器54可以获SDN架构200中的当前网络策略，即，不添加新的网络策略的网络策略(1208)。

然后，策略控制器54可以将流元数据与当前网络策略进行比较，以确定任意封包流是否违反了当前网络策略(1210)。封包流可能出于各种原因而违反网络策略：虚拟路由器可能被错误配置、SND架构的组件代码中可能存在漏洞、网络策略可能不可调和等。然而，对于操作1200，因为流元数据基于整合了新的网络策略的已配置网络策略，所以封包流可能由于新的网络策略重写了当前网络策略的某一方面而故意违反当前网络策略。这被称为不一致(discrepancy)。例如，作为虚拟路由器21中的防火墙策略而实现的网络策略可以规定允许app→数据库，即，允许流量从应用的应用层到数据库层。在该示例中，以层信息对工作负载进行标记，并且虚拟路由器应用策略，以强制实施防火墙策略。新的网络策略可以规定拒绝app→数据库，即，不允许流量从应用的应用层到数据库层。因此，流元数据并不指示任意封包流从标记有app标签的工作负载到标记有数据库标签的工作负载。这就是与当前网络策略的不一致(尽管不是新的网络策略)。

策略控制器54可以将不一致的指示输出到用户输入设备显示器。该指示可以包括关于违反当前网络策略的封包流的流元数据的标记。不一致的指示还可以指示被违反的当前网络策略的网络策略。用户可以查看不一致的指示并且向策略控制器54提供用户输入。策略控制器54可以接收用户输入的指示，以指示用户是否希望应用新的网络策略。如果否(1214中，否分支)，策略控制器54则可以结束操作(1216)。

如果是(1214中，是分支)，策略控制器54则可以利用新的网络策略对当前网络策略进行更新，以创建所更新的网络策略(1218)。因此，策略控制器54可以将配置存储库50中的配置数据修改为该项目的新分支。

部署系统52可以检测对配置存储库50的修改，并且响应于该修改，将包括网络策略1010的已修改配置数据发送至网络控制器24的配置节点30，并且网络控制器24将虚拟路由器21中的策略1000配置为实现应用部署的已更新网络策略1010(1220)。分布式应用在配置有网络策略1000的SDN架构200中运行。

图13是示出根据本公开的技术的执行配置验证的SDN架构的操作的示例性模式的流程图。在该示例中，网络控制器24将SDN架构200配置有网络策略(1404)。一旦SDN架构200配置有网络策略，分布式应用则运行并且工作负载交换封包流。

策略控制器54从SDN架构200获得遥测数据，遥测数据包括关于分布式应用的工作负载之间的封包流的流元数据(1406)。上面参考图11对用于获得流元数据的示例性技术进行了描述。策略控制器54可以获得SDN架构200中所配置的网络策略(1408)。所获得的网络策略应该是SDN架构200中所配置的网络策略，而通过SDN架构收集器收集用于生成在步骤1406中所获得的流元数据的封包统计。

然后，策略控制器54可以将流元数据与当前网络策略进行比较，以确定任意封包流是否违反了网络策略(1410)。封包流可能出于各种原因而违反网络策略：虚拟路由器可能被错误配置、SND架构的组件代码中可能存在漏洞、底层可能被错误配置等。将下列情形称为配置违反：其中，存在违反拒绝封包流的网络策略的该封包流，或缺少网络策略允许封包流的该封包流。例如，作为虚拟路由器21中的防火墙策略而实现的网络策略可以规定拒绝app→数据库，即，不允许流量从应用的应用层到数据库层。在该示例中，以层信息对工作负载进行标记，并且虚拟路由器应用策略，以强制实施防火墙策略。如果流元数据指示封包流从标记有app标签的工作负载到标记有数据库标签的工作负载，则因为其违反了网络策略，所以这就是配置违反。

如果策略控制器54未检测到配置违反(1412中，否分支)，则操作结束。如果策略控制器检测到配置违反(1412中，是分支)，策略控制器54则可以将配置违反的指示输出到用户输入设备显示器。该指示可以包括关于违反网络策略的封包流的流元数据的标记和缺少封包流的标记。该不一致的指示还可以指示被违反的网络策略中的网络策略。用户可以查看配置违反的指示，这可以帮助用户识别底层问题。因此，用户可以采取补救措施(1418)。

补救措施可以包括：用户解决底层网络的错误配置，这可能是错误配置的电缆、错误配置的网络交换机、或其他问题。补救措施可以包括：修改SDN架构200中的一个或多个组件的代码，诸如网络控制器24的组件(例如，配置节点230或控制节点232)或虚拟路由器组件。可以将该代码或已修改的编译组件提交给配置存储库50。因此，部署系统52将根据连续部署的原理检测改变并已更新的软件部署到计算基础设施8。

策略控制器54可以周期性地运行操作1400的模式。以对SDN架构200的配置进行验证。如果步骤1418中的补救措施成功，则不再在操作1400的下一次运行中检测配置违反(1412中，否分支)，并且操作可以结束(1414)，直至其再次执行。

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

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

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

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

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

Claims (20)

1.一种网络策略控制器，所述策略控制器包括处理电路并且被配置为：

从第一软件定义网络SDN架构系统获得关于在被部署至第一SDN架构系统的分布式应用的工作负载之间所交换的封包流的流元数据；

使用关于所述封包流中的一个封包流的流元数据，识别所述封包流的源端点工作负载和目的地端点工作负载；

生成允许封包流从所述封包流的所述源端点工作负载到所述目的地端点工作负载的网络策略规则；并且

当将所述分布式应用部署至第二SDN架构系统时，将所述网络策略规则作为所述第二SDN架构系统的配置数据添加至配置存储库，以致使部署系统将所述第二SDN架构系统配置成具有允许封包流从所述源端点工作负载到所述目的地端点工作负载的所述网络策略规则。

2.根据权利要求1所述的策略控制器，其中，所述第一SDN架构系统是所述第二SDN架构系统。

3.根据权利要求1所述的策略控制器，其中，所述配置存储库存储关于所述分布式应用的所述工作负载。

4.根据权利要求1所述的策略控制器，其中，所述策略控制器被配置为：

将所述第一SDN架构系统配置为打开监视，以禁用应用于所述分布式应用的所述工作负载的全部防火墙策略；

其中，当所述监视开启时，所述流元数据是关于在所述分布式应用的所述工作负载之间所交换的所述封包流的流元数据。

5.根据权利要求4所述的策略控制器，其中，所述策略控制器被配置为：

将所述第一SDN架构系统配置为关闭所述监视，以启用应用于所述分布式应用的所述工作负载的全部防火墙策略。

6.根据权利要求4所述的策略控制器，其中，所述策略控制器被配置为：

仅禁用应用于所述分布式应用的所述工作负载的防火墙策略。

7.根据权利要求1至6中任一项所述的策略控制器，其中，为了将所述网络策略规则添加至所述配置存储库，所述策略控制器被配置为将新的分支添加至存储所述第二SDN架构系统的配置数据集的所述配置存储库，其中，所述配置数据集包括所述网络策略规则。

8.根据权利要求1至6中任一项所述的策略控制器，

其中，所述策略控制器被配置为从用户接收所述用户对所述网络策略规则的批准指示；并且

其中，所述策略控制器被配置为响应于所述用户对所述网络策略规则的所述批准指示而将所述网络策略规则添加至所述配置存储库。

9.根据权利要求1至6中任一项所述的策略控制器，其中，所述策略控制器被配置为：

从用户接收测试参数，所述测试参数将所述流元数据约束到与所述测试参数相匹配的封包流。

10.根据权利要求9所述的策略控制器，其中，所述测试参数包括应用标识符、时间范围、角色、站点、或应用层。

11.根据权利要求1至6中任一项所述的策略控制器，其中，所述第二SDN架构系统包括网络控制器，所述网络控制器包括用于配置所述第二SDN架构系统的配置节点，通过包括所述第二SDN架构系统的计算节点的集群，实现所述网络控制器。

12.根据权利要求1至6中任一项所述的策略控制器，其中，所述策略控制器被配置为：

接收新的网络策略规则；

配置所述第一SDN架构系统具有当前网络策略和所述新的网络策略规则；

当在所述第一SDN架构系统中配置所述新的网络策略规则时，从所述第一SDN架构系统获得关于在被部署至所述第一SDN架构系统的所述分布式应用的所述工作负载之间所交换的封包流的额外流元数据；

当在所述第一SDN架构系统中配置所述新的网络策略规则时，识别所述额外流元数据与所述当前网络策略之间的差异，所述差异指示在被部署至所述第一SDN架构系统的所述分布式应用的所述工作负载之间所交换的所述封包流违反了所述当前网络策略中的一个网络策略；并且

输出所述差异的指示，以在显示设备处进行显示。

13.一种配置网络的方法，所述方法包括：

由策略控制器从第一软件定义网络SDN架构系统，获得关于在被部署至第一SDN架构系统的分布式应用的工作负载之间所交换的封包流的流元数据；

由所述策略控制器使用关于所述封包流中的一个封包流的流元数据，识别所述封包流的源端点工作负载和目的地端点工作负载；

由所述策略控制器生成允许封包流从所述封包流的所述源端点工作负载到所述目的地端点工作负载的网络策略规则；并且

当将所述分布式应用部署至第二SDN架构系统时，由所述策略控制器将所述网络策略规则作为所述第二SDN架构系统的配置数据添加至配置存储库，以致使部署系统将所述第二SDN架构系统配置成具有允许封包流从所述源端点工作负载到所述目的地端点工作负载的所述网络策略规则。

14.根据权利要求13所述的方法，其中，所述配置存储库存储用于所述分布式应用的所述工作负载。

15.根据权利要求13所述的方法，还包括：

由所述策略控制器将所述第一SDN架构系统配置为开启监视，以禁用应用于所述分布式应用的所述工作负载的全部防火墙策略；

其中，当所述监视开启时，所述流元数据是关于在所述分布式应用的所述工作负载之间所交换的所述封包流的流元数据。

16.根据权利要求15所述的方法，还包括：

由所述策略控制器将所述第一SDN架构系统配置为关闭所述监视，以启用应用于所述分布式应用的所述工作负载的全部防火墙策略。

17.根据权利要求15所述的方法，还包括：

所述策略控制器仅禁用应用于所述分布式应用的所述工作负载的防火墙策略。

18.根据权利要求13至17中任一项所述的方法，其中，将所述网络策略规则添加至所述配置存储库包括：将新的分支添加至存储所述第二SDN架构系统的配置数据集的所述配置存储库，其中，所述配置数据集包括所述网络策略规则。

19.根据权利要求13至17中任一项所述的方法，还包括：

由所述策略控制器接收新的网络策略规则；

由所述策略控制器配置所述第一SDN架构系统具有当前网络策略和所述新的网络策略规则；

当在所述第一SDN架构系统中配置所述新的网络策略规则时，由所述策略控制器从所述第一SDN架构系统获得关于在被部署至所述第一SDN架构系统的所述分布式应用的所述工作负载之间所交换的所述封包流的额外流元数据；

当在所述第一SDN架构系统中配置所述新的网络策略规则时，由所述策略控制器识别所述额外流元数据与所述当前网络策略之间的差异，所述差异指示在被部署至所述第一SDN架构系统的所述分布式应用的所述工作负载之间所交换的所述封包流违反了所述当前网络策略中的一个网络策略；并且

由所述策略控制器输出所述差异的指示，以在显示设备处进行显示。

20.一种计算机可读存储介质，利用指令进行编码，所述指令用于致使一个或多个可编程处理器执行权利要求13至19中任一项所述的方法。

Images