CN118282881A

CN118282881A - 网络策略验证

Info

Publication number: CN118282881A
Application number: CN202310871836.8A
Authority: CN
Inventors: 普拉萨德·梅里亚拉; 纳迪姆·福努; 萨亚丽·马内; 安库尔·唐东; 萨杰施·马修; 帕纳夫·切鲁库帕利; 库什·维迪雅
Original assignee: Juniper Networks Inc
Current assignee: Juniper Networks Inc
Priority date: 2022-12-30
Filing date: 2023-07-14
Publication date: 2024-07-02

Abstract

提供了一种网络策略验证。在示例中，验证系统包括：处理电路，该处理电路可访问存储设备并且被配置为获得指示工作负载之间的分组流的流记录，该工作负载被部署至一个或多个计算设备的配置有网络策略的集群，其中，该流记录中的每个流记录指示对应分组流被集群允许或拒绝；接收更新的网络策略；确定流记录中的一个流记录的对应分组流与更新的网络策略是否具有差异；并且响应于确定出＝流记录中的一个流记录的对应分组流与更新的网络策略具有差异，输出错误指示。

Description

网络策略验证

相关申请

本申请要求于2023年5月5日提交的美国申请号18/313,131，以及于2022年12月30日提交的美国临时申请号63/478,089的权益，这些申请中的每个申请的全部内容通过引证结合于此。

技术领域

本公开涉及虚拟化的计算基础设施，并且更具体地，涉及用于虚拟化的计算基础设施的网络策略。

背景技术

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

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

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

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

利用容器的固有轻量级性质，相比传统虚拟机(VM)，单个主机通常可支持更多的容器示例。容器通常寿命较短，相比VM，容器可被更有效地创建和移动，并且容器还可被管理为逻辑相关元件的组(对于一些编排平台，例如，Kubernetes，该组有时被称为“豆荚(pods)”)。这些容器特性影响容器联网方案的要求：网络应灵活且可扩展。VM、容器和裸金属服务器可能需要共存于相同计算环境中，其中，在应用的不同部署之间使能通信。容器网络还应无限制地与用于部署容器化应用的多种类型的编排平台一起工作。

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

发明内容

总体上，描述用于验证网络策略并识别配置异常的技术。在一些示例中，用于SDN架构系统的验证系统可针对表示该系统中的预期分组流集合的“黄金流量”流记录来自动验证更新的网络策略。黄金流量是当系统在“第0天”配置有完全部署应用(包括工作负载和网络策略)时发生的分组流。策略控制器可收集与(允许和拒绝的)分组流对应的流元数据，并且将流元数据存储为流记录。通过使用算法将黄金流量流记录与更新的网络策略进行比较，验证系统可验证更新的网络策略。

在一些示例中，在配置更新的网络策略之后，验证系统可应用类似算法来识别更新的网络策略与对应于系统中的分组流的新的流记录之间的任何差异。通过识别差异，即，根据更新的网络策略应被拒绝的允许分组流或者根据更新的网络策略应被允许的拒绝分组流之间的差异，验证系统可确定与软件定义网络的部件相关联的配置异常存在于该系统中或者这些部件未按预期操作。

该技术可提供一个或多个技术优点以实现至少一个实际应用。例如，该技术可促进自动策略验证，以便促进相对于SDN架构的配置的连续部署和连续集成，由此支持分布式应用。以此方式，该技术可补充用于应用开发的现有DevOps最佳实践，并将其应用于用于分布式应用部署和配置的网络策略自动化。用于检验的现有方案涉及在提交之前手动检查网络策略，这尤其在大规模分布式应用的情景下是不实用且不可靠的，或者这些现有方案涉及分析在提交之后收集的流记录，以确定流量是否被无意允许/拒绝。因为直到网络策略被推送至系统，根据网络策略的表示在分布式应用的工作负载之间的通信的流记录才是可用的，所以涉及自动检验的先前方案需要将网络策略的改变推送至系统。相比之下，通过应用涉及先前获得的黄金流量流记录的算法，本公开的技术的一些方面使得能够在提交之前验证网络策略。总体上，该技术可减少验证人工网络策略及验证SDN架构系统配置的需求。

在示例中，一种方法包括：获得指示工作负载之间的分组流的流记录，该工作负载被部署至一个或多个计算设备的配置有网络策略的集群，其中，该流记录中的每个流记录指示对应分组流被集群允许或拒绝；接收更新的网络策略；确定流记录中的一个流记录的对应分组流与更新的网络策略是否具有差异；并且响应于确定出流记录中的一个流记录的对应分组流与更新的网络策略具有差异，输出错误指示。

在示例中，一种方法包括：获得指示工作负载之间的分组流的流记录，该工作负载被部署至一个或多个计算设备的配置有网络策略的集群，其中，该流记录中的每个流记录指示对应分组流被集群允许或拒绝；确定流记录中的一个流记录的对应分组流与更新的网络策略是否具有差异；并且响应于确定出流记录中的一个流记录的对应分组流与网络策略具有差异，输出错误指示。

在示例中，验证系统包括：处理电路，该处理电路可访问存储设备并且被配置为获得指示工作负载之间的分组流的流记录，该工作负载被部署至一个或多个计算设备的配置有网络策略的集群，其中，该流记录中的每个流记录指示对应分组流被集群允许或拒绝；接收更新的网络策略；确定流记录中的一个流记录的对应分组流与更新的网络策略是否具有差异；并且响应于确定出流记录中的一个流记录的对应分组流与更新的网络策略具有差异，输出错误指示。

在附图和以下描述中阐述了本发明的一个或多个实施方式的细节。从说明书和附图以及权利要求中，本发明的其他特征、目的和优点将是显而易见的。

附图说明

图1是示出可实现本文描述的技术的示例的示例性计算基础设施的框图。

图2是示出根据本公开的技术的用于云原生联网的云原生SDN架构系统的示例的框图。

图3是根据本公开的技术的更详细示出SDN架构系统的部件的另一视图的框图。

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

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

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

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

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

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

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

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

图11A至图11D描绘根据本公开的技术的用于SDN架构系统的示例性操作模式的流程图。

图12是示出根据本公开的技术的用于SDN架构系统的示例性操作的框图。

贯穿说明书和附图，相同的参考字符表示相同元素。

具体实施方式

图1是示出可实现本文描述的技术的示例的示例性计算基础设施8的框图。由于例如生命周期管理的复杂性、强制性高资源分析部件、配置模块中的规模限制以及无命令行接口(CLI)(类kubectl)的接口，用于虚拟网络的软件定义网络(SDN)架构的当前实现方式对于云原生(cloud-native)采用提出挑战。计算基础设施8包括本文描述的云原生SDN架构系统(或更简单地，“SDN架构”)，该系统解决了这些挑战并且使得电信云原生时代现代化。云原生SDN架构的示例性使用情况包括：5G移动网络以及云和企业云原生使用情况。SDN架构可包括在计算节点(例如，服务器12)和诸如路由器或交换机的网络设备中实现的数据平面元件，并且SDN架构还可包括用于创建和管理虚拟网络的SDN控制器(例如，网络控制器24)。SDN架构配置和控制平面设计为具有支持服务中升级的基于容器的微服务架构的扩展(scale-out)云原生软件。

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

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

本文描述的SDN架构实现防火墙策略框架。防火墙策略框架支持使用标牌来辅助简化并抽象化容器工作负载，诸如Kubernetes豆荚。防火墙策略框架允许路由与安全策略解耦，并且提供多维分段和策略便携性，同时显著增强用户可见性和分析功能。由防火墙策略框架使用的标牌可实现各种实体之间的多维流量分段并且具有安全特征。标牌是与部署中的不同实体相关联的键-值对。标牌可以是预定义的或自定义的。

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

·网络策略可在入口方向、出口方向或这两个方向上为豆荚定义流量规则。默认地，如果没有明确指定方向，则将网络策略应用于入口方向。

·当网络策略应用于豆荚时，策略必须具有显式规则以指定入口方向和出口方向上的许可流量的白名单(allowlist)。与白名单规则不匹配的所有流量被拒绝并丢弃。

·可在任何豆荚上应用多个网络策略。必须许可与网络策略中的任一个匹配的流量。

·网络策略作用于连接，而不是单个分组。例如，如果配置策略允许从豆荚A到豆荚B的流量，那么即使现行策略不允许豆荚B

发起到豆荚A的连接，也允许从豆荚B到豆荚A的该连接的返回分组。

·入口策略：入口规则由源的标识以及来自源的、允许转发至豆荚的流量的协议:端口类型组成。源的标识可以是以下类型：

ο无类别域间路由(CIDR)块——如果源IP地址来自CIDR块并且流量与协议:端口匹配，则将流量转发至豆荚。

οKubernetes命名空间——命名空间选择器识别命名空间，这可以将定义的协议:端口流量发送至入口豆荚。

ο豆荚(Pod)-豆荚选择器识别命名空间中对应于网络策略的豆荚，其可将匹配的协议:端口流量发送至入口豆荚。

·出口策略：从网络策略所针对的豆荚中，指定流量的特定协议:端口类型所许可的白名单CIDR。目的地的标识可以是以下类型：

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

οKubernetes命名空间——命名空间选择器识别命名空间，其豆荚能够将定义的协议:端口流量发送至出口豆荚。

ο豆荚(Pod)-豆荚选择器识别命名空间中对应于网络策略的豆荚，其可从出口豆荚接收匹配的协议:端口流量。

相对于豆荚描述的上述技术可应用于其他类型的工作负载和用于其他容器编排平台的工作负载部署结构。

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

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

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

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

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

·CIDR规则→地址组

·集群默认→应用策略集

解析Kubernetes网络策略标签是简单易懂的。防火墙策略中的豆荚的表示与对应Kubernetes网络策略完全相同。防火墙策略处理SDN架构的术语中的标签或标牌。它不将标签扩展至IP地址。例如，在默认命名空间中，如果网络策略podSelector指定：角色＝db，则对应防火墙规则将豆荚指定为(角色＝db&&命名空间＝默认)。不进行到豆荚IP地址或其他地址的其他转换。

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

类似地，每个CIDR由一个规则表示。本质上，Kubernetes网络策略被1:1转换为防火墙策略。针对每个Kubernetes网络策略，只创建一个额外防火墙规则。该规则的目的是实现网络策略的隐式拒绝要求，并且不创建其他规则。

由本文描述的SDN架构实现的云基部署和配置可促进用于连续部署的网络策略的自动验证。这种网络策略可以是Kubernetes资源和/或可以是特定于由本公开描述的SDN架构实现的防火墙策略框架的防火墙策略。

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

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

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

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

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

所示示例中的交换结构14包括互连架顶(TOR)(或其他“叶片式”)交换机16A至16N(被统称为“TOR交换机16”)，其耦接至机框(或“脊柱”或“核心”)交换机18A-18M(统称为“机框交换机18”)的分布层。尽管未示出，但是数据中心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，该结构可执行第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)网络并且跨这些网络扩展。虚拟网络还可用于实现网络功能虚拟化(NFV)和服务链。

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

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

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

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

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

服务器12托管一个或多个虚拟网络的虚拟网络端点，这些虚拟网络在这里由IP结构20和交换结构14表示的物理网络上操作。虽然主要关于基于数据中心的交换网络来描述，但是其他物理网络(诸如服务提供商网络7)可覆盖一个或多个虚拟网络。

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

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

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

一个或多个服务器12可各自包括虚拟路由器21，其执行数据中心10内的对应虚拟网络的一个或多个路由实例，以提供虚拟网络接口并在虚拟网络端点之间路由分组。每个路由实例可与网络转发表相关联。每个路由实例可表示用于互联网协议-虚拟专用网络(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驱动程序时，它从Linux内核空间移动到用户空间，因此不再由LinuxOS管理或可见。因此，DPDK应用(即，本示例中的虚拟路由器21A)完全管理NIC 13。这包括分组轮询、分组处理和分组转发。用户分组处理步骤可由虚拟路由器21DPDK数据平面执行，内核参与有限或不参与(内核未在图1中示出)。该“轮询模式”的性质使得虚拟路由器21DPDK数据平面分组处理/转发与中断模式相比更加高效，尤其是当分组速率高时。在分组I/O期间存在有限的中断和上下文切换，或没有中断和上下文切换。

DPDK v路由器的示例的附加细节可参见于2021的瞻博网络公司的Kiran KN等人的“第一天：凝结DPDK v路由器”(“DAY ONE:CONTRAIL DPDK vROUTER,”2021,Kiran KN etal.,Juniper Networks,Inc.)，其全部内容通过引用并入本文。

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

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

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

总体上，网络控制器24控制数据中心10结构的网络配置以例如在虚拟网络端点之间建立用于分组通信的一个或多个虚拟网络。网络控制器24提供逻辑上并且在一些情况下物理上集中的控制器，用于促进数据中心10内的一个或多个虚拟网络的操作。在一些示例中，网络控制器24可响应于从编排器23和/或管理员/操作员接收的配置输入来操作。在于2013年6月5日提交的名称为“PHYSICAL PATH DETERMINATION FOR VIRTUAL NETWORKPACKET 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编排系统的示例性部件。

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

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

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

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

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

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

CNI 17可由编排器23调用。出于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实现为tap接口、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)、豆荚接口、容器网络接口、(分接头)tap接口、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，并可将同一veth对的另一端附接到豆荚22，豆荚可使用virtio用户来实现它。

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

[{

//virtual network interface 26

"id":"fe4bab62-a716-11e8-abd5-0cc47a698428",

"instance-id":"fe3edca5-a716-11e8-822c-0cc47a698428",

"ip-address":"10.47.255.250",

"plen":12,

"vn-id":"56dda39c-5e99-4a28-855e-6ce378982888",

"vm-project-id":"00000000-0000-0000-0000-000000000000",

"mac-address":"02:fe:4b:ab:62:a7",

"system-name":"tapeth0fe3edca",

"rx-vlan-id":65535,

"tx-vlan-id":65535,

"vhostuser-mode":0,

“v6-ip-address”:“::“,

“v6-plen”:,

“v6-dns-server”:“::”,

“v6-gateway”:“::”,

"dns-server":"10.47.255.253",

"gateway":"10.47.255.254",

"author":"/usr/bin/contrail-vrouter-agent",

"time":"426404:56:19.863169"

}]

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

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

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

作为图1中所示的SDN架构的一部分的网络控制器24可以是多租户感知的并且支持编排平台的多租户。例如，网络控制器24可支持基于Kubernetes角色的访问控制(RBAC)构造、本地身份访问管理(IAM)和外部IAM集成。网络控制器24也可支持Kubernetes定义的联网构造和高级联网特征，如虚拟联网、BGPaaS、联网策略、服务链和其他telco特征。网络控制器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是用于支持支持多个Kubernetes集群的网络控制器24的单个示例的可选部件。

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

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

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

同样地，5GNC内的用户平面功能(UPF)将是超高性能的应用。它可作为一组高度分布的高性能豆荚来交付。本文所述的SDN架构可能能够提供非常高的吞吐量数据平面(就每节位数(bps)和每秒分组(pps)而言)。与具有最近性能增强的DPDK虚拟路由器、eBPF和SmartNIC的集成将有助于实现所需的吞吐量。基于DPDK的虚拟路由器更详细地描述于2022年2月1日提交的名称为“CONTAINERIZED ROUTER WITH VIRTUAL NETWORKING”的美国申请号17/649,632，通过引用将其全文并入本文。

随着工作负载从更传统的虚拟化工作负载迁移到容器化微服务，高性能处理可能在GiLAN中也是相关的。在UPF和GiLAN服务的数据平面中，诸如GiLAN防火墙、入侵检测和预防、虚拟IP多媒体子系统(vIMS)语音/视频等，吞吐量将保持在bps和pps方面很高且持续。对于5GNC功能的控制平面，诸如接入和移动性管理功能(AMF)、会话管理功能(SMF)等，以及对于一些GiLAN服务(例如，IMS)，虽然绝对流量在bps方面可能不大，但小分组占主导地位意味着pps将保持较高水平。在一些示例中，SDN控制器和数据平面为每个虚拟路由器21提供每秒数百万个分组，如在服务器12上实现的。在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、SmartNIC等)。还可能存在需要SR-IOV的工作负载。因此，SDN架构还可支持在ToR处创建VTEP并将其作为VXLAN链接回到覆盖层。

期望存在完全分布式Kubernetes微集群的混合，其中每个站点运行其自己的主节点(多个主节点)，并且SDN架构可支持类似远程计算的场景。

对于涉及企业Kubernetes平台的使用情况，高性能云原生应用为金融服务平台、在线游戏服务、以及托管的应用服务提供商提供支持。提供这些应用的云平台必须提供高性能、故障恢复能力、以及高安全性和可见性。托管在这些平台上的应用趋向于在内部开发。应用开发者和平台所有者与基础设施团队一起工作以部署和操作组织的应用的示例。这些应用往往需要高吞吐量(每台服务器>20Gbps)和低延迟。一些应用还可以使用组播来用于信令或有效负载流量。可以利用附加硬件和网络基础设施来确保可用性。应用和微服务将利用集群内的命名空间来进行分区。在高安全性环境中，命名空间之间的隔离至关重要。虽然默认拒绝策略是零信任应用部署环境中的标准状态，但是使用虚拟路由和转发示例(VRF)的附加网络分段增加了附加的安全层并且允许使用重叠的网络范围。重叠的网络范围是管理应用托管环境的关键要求，并且往往会对所有管理客户的一组可达端点进行标准化。

复杂的基于微服务的应用往往会利用复杂的网络过滤器。本文描述的SDN架构可以大规模地提供高性能的防火墙过滤。这样的过滤可表现出一致的转发性能，具有较少的延迟降级，不管规则集长度或顺序如何。一些客户在应用的分离方面可能也面临着与电信公司相同的监管压力，不仅在网络层，而且在内核中。金融行业以及其他行业都需要数据平面加密，尤其是在公共云上运行时。在一些示例中，本文所述的SDN架构可包括用于满足这些要求的特征。

在一些示例中，当SDN架构通过应用开发/测试/阶段/生产持续集成/持续开发(CI/CD)流水线被自动化时，SDN架构可以提供GitOps友好的UX，用于严格的变更管理控制、审计以及在生产环境中每天多次甚至数百次进行更改的可靠性。

根据本公开的技术，系统8包括部署系统52、策略控制器54、配置储存库50和用于验证网络策略的验证系统60。配置储存库50可以实现诸如Git储存库的一个或多个储存库，以存储和管理用于向SDN架构200的应用部署的配置数据。配置储存库50可以包括用于存储配置数据的一个或多个存储系统。配置储存库50可以包括用于跟踪配置数据的创建和修改的软件，以促进使用配置储存库50部署的应用的配置的协作更新和开发。用于配置储存库50的软件可以实现版本控制和开发分支，其中，具有已提交的配置数据的储存库可以被分支以使用包括对较早提交的配置数据的更新的后续提交在另一“分支”中创建替代性配置数据。因此，配置储存库50可以存储同一应用的多组配置数据，每组配置数据表示不同的配置并且导致SDN架构200中的应用的不同操作。应用的一组给定配置数据可以被认为是用于定义应用的期望应用状态的真实来源。应用可以是可部署到计算基础设施的一组工作负载，并且SDN架构200可以使用网络控制器24来配置以实现应用的工作负载之间的网络通信。应用的配置数据可以包括例如Kubernetes清单、网络策略(无论是包括在Kubernetes清单中的还是在别处定义的)、豆荚描述、网络配置、以及用于定义SDN架构200的操作的其他配置数据，以支持应用，尤其是支持应用的工作负载之间的网络通信。

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

在一些情况下，配置数据与配置储存库50中的应用部署集成，使得应用工作负载和SDN架构200配置两者能够一致地按键部署到计算基础设施8。在这种情况下，配置储存库50由此作为完整的应用部署储存库进行操作。

图10是示出根据本公开的技术的部署到SDN架构200的数据平面的示例分布式应用1050的框图。应用1050包括使用豆荚22部署到服务器12的各种微服务部件，例如，“邮件服务(EmailService)”和“广告服务(AdService)”。微服务部件旨在以所示的方式彼此通信。例如，购物车服务(CartService)接收来自结账服务(CheckoutService)和前台(Frontend)的服务请求，并且购物车服务向缓存(Cache)发出服务请求。用于应用1050的网络策略允许部署的豆荚以这样的方式通信，即促进包括在那些豆荚中的微服务部件之间的预期通信。例如，服务器12A上的豆荚22可以包括结账服务的容器，并且该豆荚22应该被允许与服务器12X上的包括购物车服务的容器的豆荚22通信。应用可包括使用豆荚、虚拟机、裸金属服务器处理或使用其组合部署的部件，所有这些部件可使用通用术语“工作负载”来指代。

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

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

在一些情况下，网络策略1010表示用于编排器23的网络策略。例如，网络策略1010可以是Kubernetes原生资源，即，Kubernetes网络策略。配置节点30可将网络策略1010(其可表示编排器23的原生资源)转换为SDN架构配置的自定义资源。这样的自定义资源可以是例如由虚拟路由器21理解的防火墙策略。该过程在下面进一步详细描述。在这样的示例中，策略1000可以表示在虚拟路由器21中示例化且对应于自定义资源的SDN架构配置对象。在不同服务器12上操作的不同虚拟路由器21可实现一组不同的策略，这取决于哪些工作负载在虚拟路由器所位于的服务器上操作。

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

返回图1，根据本公开的技术，系统8包括验证系统60、策略控制器54和用于网络策略的自动验证的流记录56。流记录56可以包括表示流过数据中心10的所有流量的多个流记录(例如，发送的字节和分组的总数、数据流的开始和结束时间等)。策略控制器54可以利用遥测数据从SDN架构200获得流元数据，并将多个流元数据作为流记录存储在流记录56中。关于策略控制器24获得流元数据的示例操作的其他信息可见于在2022年3月31日提交的、标题为“用于持续部署的网络策略生成(Network Policy Generation for ContinuousDeployment)”的美国专利申请号17/657,613中的对图11的步骤1102至步骤1114的描述中找到，该专利申请通过引用通过引用并入本文，如同在本文中全面阐述一样。

流元数据用于分布式应用的工作负载之间的分组流。在一些示例中，流元数据可以是由虚拟路由器21处理(例如，在工作负载之间转发)的分组流的流量统计的会话记录。策略控制器54可以将分组流的流量统计的会话记录关联到工作负载的流量统计的会话记录。流元数据指示从工作负载到其他工作负载的分组流。策略控制器54可以将流元数据存储为流记录，该流记录包括指示在流元数据中指定的分组流被允许还是被拒绝的标牌(tag)或标签(label)。每个流记录56可包括用于标识在系统200内发起的分组流的分组流标识信息和指示该分组流是否被v路由器21允许或拒绝的数据。如上所述，指示分组流是否被允许或拒绝的数据可以是标牌或标记(例如，“允许”)、整数、布尔值或一些其他数据。分组流标识信息可以包括覆盖层和/或底层源或目的地网络地址、源/目的地端口、协议信息、其他分组报头字段数据、标牌、应用ID、或用于识别由所部署的工作负载中的一个发起的分组流的其他数据。

验证系统60包括一个或多个计算设备的处理电路70并且可访问存储用于验证算法的可执行指令的一个或多个存储设备(未示出)。

在一些情况下，验证系统60利用流记录56基于在包括所配置的网络策略的初始部署期间所收集的流记录来生成流量概况(traffic profile)(本文中也被称为“黄金流量”或“黄金流量概况”)。流量概况是“黄金”的指的是任何旨在被允许的流都被允许，而任何旨在被拒绝的流都被拒绝。验证系统60可以使用黄金流量来识别由网络策略1010的改变或集群的改变(例如，添加服务器12或更新v路由器21代码)引起的流中的后续差异。

在初始部署期间收集的流记录可以是在由用户建立的时间段或自动设置以产生流量概况的时间段(例如，一天的操作的，或一周的操作、或某个其他时间段)内收集的流记录。用户还可以选择在指定时间段内收集的流记录以生成流量概况(例如，生成包括在周一从上午8：00到下午6：00收集的流记录的流量概况)。

使用策略控制器54的用户可以随后通过修改任何网络策略1010、创建用于网络策略1010的新策略、或删除任何网络策略1010来更新网络策略1010。更新的网络策略1010可能不经意地或无意地致使系统200中的网络流量偏离黄金流量概况。例如，更新的网络策略1010可能导致根据初始部署期间设置的网络策略1010被拒绝(允许)的分组流在系统200中改为被允许(拒绝)。系统200对分组流的处理的这种改变可能是用户想要的，也可能不是想要的。

在部署更新的网络策略1010之前或在部署之后，验证系统60可以对照从流记录56生成的黄金流量概况来验证更新的网络策略1010。验证系统60可处理流量概况的流记录，以确定更新的网络策略是否会使系统200允许或拒绝流量。验证系统60将更新的网络策略应用于流量概况并且标记任何不一致。验证系统60根据更新的网络策略的规则，通过比较黄金色流量概况中的指示端点之间的流被允许(拒绝)的流记录是否被替换为被拒绝(允许)来标记不一致。例如，验证系统60可响应于确定流量概况的流记录被标记为允许但应用更新的网络策略的规则将导致流量概况的流记录的端点之间的流改为被拒绝，来标记不一致。验证系统60可以输出或存储该不一致的指示以供用户检查。

在一些情况下，响应于验证系统60通过确定与黄金流量概况没有不一致来验证网络策略1010，验证系统60可向策略控制器54发送验证的指示。在一些情况下，响应于验证系统60输出不一致的指示，用户可检查该不一致性并确定其是想要的。换言之，网络策略1010的更新导致(或将导致)系统200的操作相对于用户想要的已部署应用的分组流的改变。对系统200的操作的示例改变可包括拒绝(允许)作为初始部署的一部分而被允许(拒绝)的分组流。用户可向验证系统60提供批准不一致的用户输入，并且验证系统60可响应地向策略控制器54发送验证的指示。基于验证的指示，策略控制器54可以将更新的网络策略1010推送到配置储存库50以供部署系统52在系统200中进行配置。以此方式，鉴于对网络策略1010的更新，验证系统60可促进提高用户对系统200的操作的信任。

图11A、图11C和图11D描述了示出用于SDN架构的示例操作模式1100的流程图。在该示例中，验证系统60开始验证一个或多个更新的网络策略(1102)，验证系统60可从策略控制器54中获得该一个或多个更新的网络策略。策略控制器54可以获得流元数据并且将流元数据作为流记录存储在流记录56中(1104)。如以上所讨论的，所获得的流记录可以被称为流量概况并且包括关于特定时间段的流记录。验证系统60可将流量概况的流记录分成“允许”组和“阻止”、或者拒绝组并单独处理每组。

验证系统60可以通过编译指示分组流已被允许的流量概况的流记录来生成被允许的流记录集合(1106)。对于允许集合中的每个流记录，解析一个或多个更新的网络策略(1108)。验证系统60可迭代地确定(图11C的1110)更新的网络策略的至少一个规则是否允许在允许集合的流记录中表示的流量(即，分组流)(1112)。响应于验证系统60确定没有更新的网络策略的规则允许在允许集合的流记录中表示的流量(1112的否分支)，验证系统60标记流记录和更新的网络策略(1116)并返回步骤1110。响应于验证系统60确定更新策略的至少一个规则确实允许在允许集合的流记录中表示的流量(1112的是分支)，验证系统60可使计数器递增以跟踪允许集合的流记录和更新的网络策略一致的示例(1114)并返回到步骤1110。在已经检查了一个或多个更新的策略的所有策略的差异之后，验证系统60可通过确定计数器的值是否等于允许集合中的流记录的数量，来相对于流记录的允许集合将一个或多个更新的网络策略作为整体进行验证(1118)。如果验证系统60确定计数器的值等于允许集合中的流记录的数量(1118的是分支)，则验证系统60可相对于流记录的被允许集合来验证一个或多个更新的策略(1122)并移至步骤1144。如果验证系统60确定计数器的值不等于流记录的数量(1118的否分支)，则验证系统60可输出标记的流量和策略(1120)并随后输出差异指示(1146)。

验证系统60可通过编译指示分组流已被拒绝或阻止的流量概况的流记录，生成被阻止的流记录集合(1126)。对于阻止集合中的每个流记录，解析一个或多个更新的网络策略(1128)。验证系统60可迭代地确定(图11D的1130)更新的网络策略的规则是否没有规则允许在阻止集合的流记录中表示的流量(即，分组流)(1132)。响应于验证系统60确定更新的网络策略的至少一个规则允许在阻止集合的流记录中表示的流量(1132的否分支)，标记流记录和更新的网络策略(1136)并返回步骤1130。标记的更新的网络策略可以是允许流量的网络策略。响应于验证系统60确定没有更新的策略的规则确实允许在阻止集合的流记录中表示的流量(1132的是分支)，验证系统60可使计数器递增以跟踪阻止集合的流记录和更新的网络策略一致的示例(1134)并返回到步骤1130。在检查了一个或多个更新的策略中的所有策略的差异之后，验证系统60可通过确定计数器的值是否等于阻止集合中的流记录的数量，相对于流记录的被阻止集合将所述一个或多个更新的网络策略作为整体进行验证(1138)。如果验证系统60确定计数器的值等于阻止集合中的流记录的数量(1138的是分支)，则验证系统60可相对于流记录的阻止集合来验证一个或多个更新的策略(1142)并移至步骤1144。如果验证系统60确定计数器的值不等于流记录的数量(1138的否分支)，则验证系统60可输出标记的流量和策略(1140)并随后输出错误指示(1146)。

如果验证系统60已验证流记录的允许集合和阻止集合两者(1144的是分支)，则验证系统60可将更新的网络策略视为已验证，并输出验证的指示，该指示使网络控制器24将更新的网络策略推送至v路由器21(1148)。步骤1106和步骤1126可以组合。步骤1108和1128可以组合。

本文描述的技术提供了在网络策略由集群实现之前自动验证网络策略的优点。传统的网络策略验证方案涉及在将网络策略提交给集群之前手动检查网络策略，或者在将网络策略提交给集群之后分析流记录。本文中的技术可允许网络管理员建立流量概况或黄金流量来自动地验证经更新的网络策略。将不再需要网络管理员手动验证网络策略。网络管理员还将不再必须在任何自动网络策略验证方案之前将网络策略提交给集群，从而实现更快的网络策略验证过程，该过程避免了与将尚未被验证的网络策略提交给集群相关联的潜在安全风险。

在其他示例中，验证系统60可验证网络部件(节点、虚拟路由器或控制器)是否被适当地配置来实施与流量概况相关联的网络策略。验证系统60可通过利用网络策略1010连续地或周期性地确认流记录来识别网络部件的配置异常。验证系统60可利用策略控制器54获得特定时间段(例如，每天)的流记录，并且将获得的流记录存储在流记录56中。验证系统60可响应于添加到数据中心10的新服务器或作为监视数据中心10的所有服务器的策略执行的一部分而获得流记录。

图11B、图11C、图11D描绘了示出用于SDN架构的示例操作模式1150的流程图。在此示例中，验证系统60可通过基于策略控制器54周期性地获得或在指定的时间段内获得的流记录来验证流量(即，分组流)来识别配置异常(1152)。验证系统60可将获得的流记录分成一组允许的流记录和一组阻止的流记录，并单独地验证每组。

验证系统60可通过编译指示指定的分组流已被允许的所获得的流记录来生成被允许的流记录集合(1154)。验证系统60可获得应用于与被允许的流记录集合相关联的豆荚的策略(例如，网络策略1010)(1156)。在网络策略是Kubernetes资源的示例中，验证系统60可以使用网络策略资源从Kubernetes API服务器获得网络策略1010。然后，验证系统60可解析获得的策略(1158)并且执行如上所述的图11C的步骤1110至步骤1122。步骤1156和步骤1166可以组合。步骤1158和步骤1168可以组合。

验证系统60可通过编译指示指定的分组流被拒绝或阻止的所获得的流记录来生成一组阻止的流记录(1164)。然后，验证系统60可获得应用于与被阻止的流记录集合相关联的豆荚的策略(1166)。然后，验证系统60可解析所获得的策略(1168)并且执行如上所述的图11D的步骤1130至步骤1142。

图12是示出根据本公开的技术的SDN架构的示例操作的框图。在图12的示例中，单个策略可以包括规则的列表，该列表包括入口规则1202和出口规则1204。入口规则1202是指定与分组流的源相对应的参数(例如，被阻止的源IP地址、被允许的源IP地址、被允许的协议、被允许的端口等)的允许的入口规则的列表。出口规则1204是指定与分组流的目的地相对应的参数(例如，被阻止的目的地IP地址、被允许的目的地IP地址、被允许的协议、被允许的端口等)的允许的出口规则的列表。在验证系统60基于流记录中的允许或拒绝指示生成被允许的流记录1206的集合和被阻止的流记录1208的集合之后，验证系统60可分析策略的规则(例如，入口规则1202或出口规则1204)是否遵守流记录。例如，验证系统60可确定入口规则1202是否具有与被允许的流记录1206中的每个流记录的源地址、源端口、协议等匹配的对应规则(例如，IP阻止例外、端口等)，并且该对应规则允许流记录。响应于验证系统60确定入口规则1202匹配被允许的流记录1206的流记录，验证系统60可如前所述使计数器递增。验证系统60可类似地分析入口规则1202是否具有允许被阻止的流记录1208的流记录的规则，或被阻止的流记录1208的每个流记录的源地址、源端口、协议等是否被入口规则1202明确地阻止(例如，基于IP阻止CIDR范围)。此外，验证系统60可对出口规则1204进行类似分析以确定与出口规则1204相关联的网络策略是否将允许或阻止分别对应于被允许的流记录1206和被阻止的流记录1208的流记录(例如，基于目的地地址、目的地端口、协议等)。

在一些示例中，验证系统60可允许手动创建被允许的流量流的白名单和被阻止的流量流的黑名单。验证系统60可应用允许的流量流的白名单和阻止的流量流的黑名单来验证策略，类似于如上所述如何应用允许的流记录1206和阻止的流记录1208。例如，为了验证更新的网络策略，验证系统60可迭代地确定更新的网络策略中的至少一个规则(例如，入口规则1202或出口规则1204)是否允许在允许的流记录的用户生成的白名单中表示的流量(即，分组流)并且阻止在阻止的流记录的用户生成的黑名单中表示的流量。响应于验证系统60确定更新的网络策略的至少一个规则允许在允许的流记录的白名单中表示的流量并且阻止在阻止的流记录的黑名单中表示的流量，验证系统60可验证更新的网络策略。在另一示例中，验证系统60可获得应用于与允许的流量流的用户生成的白名单和/或阻止的流量流的用户生成的黑名单相关联的豆荚的策略(例如，网络策略1010)。然后，验证系统60可解析所获得的策略。响应于验证系统60解析所获得的策略，验证系统60可相对于允许的流记录的白名单执行图11C的步骤1110至步骤1122，并且相对于阻止的流记录的黑名单执行图11D的步骤1130至步骤1142。

本文描述的技术提供了网络流量的快速确认和配置异常的自动识别的优点。传统的网络策略验证方案涉及对流记录的人工检查以确定网络流量是否被无意地允许或拒绝。本文的技术提供用于网络流量的分组流的自动验证。以这种方式，本文的技术通过确认集群的配置和操作来确保集群根据所建立的网络策略来操作。例如，如果在获得的流记录与建立的网络策略之间自动标识差异，则网络管理员可能能够通过修复虚拟路由器代码内的编码问题或解决网络控制器与虚拟路由器之间的连接性问题(阻止网络控制器将建立的网络策略推送至虚拟路由器)来校正差异。

图2是示出根据本公开的技术的用于云原生联网的云原生SDN架构的示例的框图。SDN架构200以抽象的不同部件之间的底层连接的方式示出。在该示例中，SDN架构200的网络控制器24包括配置节点230A至230N(“配置节点(configuration nodes)”或“配置节点(config nodes)”并且被统称为“配置节点230”)和控制节点232A至232K(被统称为“控制节点232”)。配置节点230和控制节点232可分别表示图1的配置节点30和控制节点32的示例实现方式。配置节点230和控制节点232虽然示出为与服务器12分离，但是可以作为服务器12上的一个或多个工作负载来执行。

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

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

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

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

通过作为Kubernetes的容器编排器242，SDN架构200用作Kubernetes CNI。如上所述，可以支持Kubernetes原生资源(豆荚、服务、进入、外部负载平衡器等)，并且SDN架构200可支持Kubernetes的自定义资源以用于SDN架构200的高级联网和安全性。

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

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

豆荚250和虚拟机252是可以由虚拟机编排器240或容器编排器242部署到计算节点并且由SDN架构200使用一个或多个虚拟网络互连的工作负载的示例。

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

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

配置节点230可包括部件微服务API服务器300(或“Kubernetes API服务器300”-图3中未示出的对应控制器406)、自定义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。控制器320执行配置分发和路由学习和分发，如以上关于图2所描述的。

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

一个或多个可选遥测节点260提供度量、警报、记录和流分析。SDN架构200遥测利用云原生监控服务，诸如Prometheus、Elastic、Fluentd、Kinaba栈(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服务器充当代理实体。该布置被称为API聚合(AA)。对于用户，简单地说，Kubernetes API被扩展。CRD允许用户在不添加另一API服务器的情况下创建新类型的资源。不管它们如何被安装，新资源被称为自定义资源(CR)以将它们与本地Kubernetes资源(例如，豆荚)区分开来。在初始配置原型中使用CRD。该架构可以使用API服务器构建器Alpha库来实现聚合的API。API服务器构建器是用于构建本地Kubernetes聚合扩展的库和工具的集合。

通常，Kubernetes API中的每个资源需要处理REST请求并管理对象的持久存储的代码。主Kubernetes API服务器300(用API服务器微服务300A至300J实现的)处理本地资源并且还可以通过CRD一般性地处理自定义资源。聚合API 402表示扩展Kubernetes API服务器300以通过写入和部署自定义API服务器301(使用自定义API服务器微服务301A至301M)来允许自定义资源的专门实现的聚合层。主API服务器300将对自定义资源的请求委托给自定义API服务器301，从而使这样的资源可用于它的所有客户端。

以此方式，API服务器300(例如，kube-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)实现，该自定义资源控制器工作以将包括网络元件的计算基础设施的实际状态与预期状态进行调和。

API服务器300聚合层将API自定义资源发送到其对应的注册的自定义API服务器300。可以有多个自定义API服务器/自定义资源控制器以支持不同种类的自定义资源。自定义API服务器300处理用于SDN架构配置的自定义资源以及对配置存储部304的写入，该配置存储部可以是etcd。自定义API服务器300可以是主机，并暴露自定义资源控制器302可能需要的SDN控制器标识符分配服务。

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

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

默认情况下，自定义资源控制器302运行主动-被动模式，并且使用主选举实现一致性。当控制器pod开始时，控制器试图使用指定的键在Kubernetes中创建ConfigMap资源。如果创建成功，则该pod变成主pod并开始处理调和请求；否则，其阻止试图在无限循环中创建ConfigMap。

自定义资源控制器302可跟踪其创建的自定义资源的状态。例如，虚拟网络(VN)创建路由实例(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控制器管理器303示例化还是通过自定义API服务器301示例化，控制节点232获取自定义资源的示例的配置数据并配置SDN架构400中的配置对象的对应示例。

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

作为示例，基于观察，控制节点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以及一个或多个微处理器210(在下文中为“微处理器510”)。NIC 530可能具备SR-IOV能力。在一些情况下，前侧总线可以耦接微处理器510和存储器设备524。在一些示例中，总线542可以耦接存储器设备524、微处理器510和NIC 530。总线542可以表示外围部件接口(PCI)高速(PCIe)总线。在一些示例中，直接内存访问(DMA)控制器可以控制耦接到总线542的部件之间的DMA传输。在一些示例中，耦接到总线542的部件控制耦接到总线542的部件之间的DMA传输。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NIC 530可接收隧道分组。虚拟路由器506处理隧道分组，以由隧道封装报头确定内部分组的源端点和目的地端点的虚拟网络。虚拟路由器506可剥离第2层报头和隧道封装报头以在内部仅转发内部分组。隧道封装报头可以包括指示虚拟网络(例如，与VRF 222A相对应的虚拟网络)的虚拟网络标识符，诸如，VxLAN标牌或MPLS标签。VRF 222A可以包括内部分组的转发信息。例如，VRF 222A可以将内部分组的目的第3层地址映射到虚拟网络接口212。作为响应，VRF 222A经由虚拟网络接口212将内部分组转发到豆荚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使用物理功能221将具有新的第2层报头的隧道分组输出到NIC 530。NIC 530在出站接口上输出分组。如果目的地是在计算设备500上执行的另一虚拟网络端点，则虚拟路由器506将分组路由到虚拟网络接口212、213中的合适的一个。

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

豆荚502A包括一个或多个应用容器529A。豆荚502B包括容器化的路由协议守护进程(cRPD)560的示例。容器平台588包括容器运行时590、编排代理(orchestration agent)592、服务代理实体(service proxy)593和CNI 570。

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

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

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

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

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

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

虚拟路由器506实施策略1000，该策略1000由控制节点32基于由配置节点30接收的网络策略来配置。策略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 PolicyManagement for Virtual Networks(虚拟网络的可扩展策略管理)”的美国专利申请号15/819,522和于2020年4月2日公开的题为“Intent-based Policy Generation for VirtualNetworks(虚拟网络的基于意图的策略生成)”的美国公开号US 2020/0106744，其各自通过引证全文并入本文。

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

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

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

对于上述示例Kubernetes网络策略“test-network-policy”，SDN控制器管理器303可以创建以下标牌(如果它们尚未存在)：{role:db,namespace:default}，创建以下地址组(如果它们尚未存在)(name:prefix):{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,AddressGroup: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,>,Address 10.0.0.0/24}。标志符“pass”意味着允许。该上下文中的端点是与针对端点列出的标准相匹配的端点工作负载，例如，前缀范围内的地址或用所列出的标牌标记的工作负载。相比之下，Kubernetes端点是用于豆荚的IP地址和端口的资源。

SDN控制器管理器303可以再次使用自定义API服务器301来创建包括上述规则的防火墙安全策略。控制节点232可获得防火墙规则并且经由虚拟路由器代理将这些防火墙规则编程到虚拟路由器中，虚拟路由器代理将防火墙策略规则实现为策略1000。策略1000由系统200中的各种虚拟路由器21(虚拟路由器506是该系统的示例)强制执行(enforce)，并且以这种方式使用策略1000来实现网络策略1010。

作为上述技术的结果，策略控制器54、验证系统60、流记录56和网络控制器24提供自动策略验证，以促进相对于SDN架构的配置的连续部署和连续集成，来支持分布式应用。

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

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

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

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

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

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

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

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

计算设备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架构配置的自定义资源的数据。服务可以是定义豆荚的逻辑集的抽象概念(abstraction)并且可以是用于访问豆荚的策略。基于服务定义选择实现服务的豆荚集。服务可以部分地实现为负载平衡器，或者以其他方式包括负载平衡器。API服务器300A和自定义API服务器301A可以实现表述性状态传输(REST)接口以处理REST操作，并且将前端作为SDN架构的配置平面的一部分提供给存储到配置存储1328的对应的集群的共享状态。API服务器300A可以表示Kubernetes API服务器。

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

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

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

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

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

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

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

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

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

与工作负载Kubernetes集群集成

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

与工作负载Kubernetes集群分离

网络控制器24的部件将由来自工作负载Kubernetes集群的单独的Kubernetes集群执行。

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

SDN控制器管理器1325可以使用由聚合API402提供的REST接口来为应用创建网络解决方案以定义网络对象(诸如虚拟网络、虚拟网络接口以及访问控制策略)。网络控制器24部件可以通过例如配置虚拟路由器中的一个或多个虚拟网络和虚拟网络接口来在计算基础设施中实现网络解决方案。(这仅是SDN配置的一个示例。)

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

元数据信息可以复制到由控制器管理器1326创建的每个豆荚副本。当SDN控制器管理器1325收到这些豆荚的通知时，SDN控制器管理器1325可以创建在注释(在以上示例中，“红色网络”、“蓝色网络”以及“默认/extns-网络”)中列示的虚拟网络，并且为每个虚拟网络创建每豆荚副本(例如，容器202A)虚拟网络接口，该虚拟网络接口具有来自用于虚拟网络的集群范围地址块(例如，10.0/16)的唯一私有虚拟网络地址。

以下描述根据本发明的额外技术。Contrail是示例性网络控制器架构。ContrailCNI可能是为Contail开发的CNI。云原生Contrail控制器可以是本公开所描述的网络控制器的示例，诸如网络控制器24。

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

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

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

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

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

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

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

·构建BUM(广播、未知单播、组播)树以用于最佳广播和组播转发。

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

于是，从工具角度考虑控制平面设计并且在它们最适合的地方适当地使用合适的工具。考虑contrail-bgp和cRPD的优缺点。

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

路由守护进程/处理

控制节点和cRPD均能够充当路由守护进程，实现不同协议，并且具有在转发平面中编程路由信息的能力。

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

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

网络编排/自动化

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

高可用性和水平可扩展性

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

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

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

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

cRPD 324提供的增强底层路由可以替换转发平面处的默认网关，并且为能够支持的使用情况提供丰富的路由栈。在不使用cRPD 324的一些示例中，虚拟路由器506将依赖于用于底层路由的默认网关。在一些示例中，作为底层路由处理的cRPD 324将限于仅编程具有控制平面路由信息的默认inet(6).0结构。在这样的示例中，非默认覆盖VRF可以由控制节点232编程。

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

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

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

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

在一些示例中，控制节点232可以使用XMPP与虚拟路由器代理514交互。在虚拟路由器代理514充当gRPC服务器的情况下，cRPD 324充当gRPC客户端。这将意味着客户端(cRPD)需要向服务器(虚拟路由器代理)发起连接。在SDN架构700中，虚拟路由器代理514选择虚拟路由器代理514将订阅的控制节点232集(因为存在多个控制节点)。在该方面，控制节点232充当服务器，并且虚拟路由器代理514作为客户端连接并订阅更新。

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

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

SDN架构200可以提供入口复制作为边缘复制的替代，并且为用户提供选项。入口复制能够视为一般覆盖组播树的特殊退化情况。然而，实际上，入口复制树的信令比一般覆盖组播树的信令更简单。利用入口复制，每个虚拟路由器21最终会形成以自身为根并且以每个其他虚拟路由器为叶的树。发生故障的虚拟路由器21理论上不应当导致对树进行重建。注意，入口复制的性能随着集群增加而降低。然而，它对于较小的集群效果良好。此外，组播对于许多客户不是流行且普遍的需求。它主要限于传输广播BUM流量，其仅在最初发生。

配置处理模块增强

在常规SDN架构中，网络控制器处理所有使用情况的编排。配置节点将意图转换成基于数据模型的配置对象，并且将其写入数据库(例如，Cassandra)中。在一些情况下，同时，例如经由RabbitMQ(消息队列中间件)向所有等待配置的客户端发送通知。

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

配置处理模块读取用于控制平面(BGP相关配置)和虚拟路由器转发平面两者的配置对象。配置可以存储为具有作为节点的对象和作为链路的关系的图形。然后，能够将该图形下载到客户端(BGP/cRPD和/或虚拟路由器代理)。

根据本公开的技术，在一些示例中，常规的配置API服务器和消息传递服务由Kubeapi服务器(API服务器300和自定义API服务器301)替换，并且先前的Cassandra数据库由Kubernetes中的etcd替换。利用该改变，对配置对象感兴趣的客户端能够直接在etcd数据库上进行观察以得到更新，而不是依赖于RabbitMQ通知。

用于CRPD的控制器编排

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

分布式配置处理

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

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

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

SDN架构中的DNS/Named

在先前的架构中，DNS服务由轨迹-dns(contrail-dns)和轨迹-named(contrail-named)处理结合工作提供，以为网络中的VM提供DNS服务。Named充当提供BIND协议的实现的DNS服务器。轨迹-dns从虚拟路由器代理接收更新并且将这些记录推送到named。

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

1.无-没有DNS支持VM。

2.默认DNS服务器-用于VM的DNS解析基于服务器基础设施中的名称服务器配置来完成。当VM得到DHCP(动态主机配置协议)响应时，子网默认网关配置为用于VM的DNS服务器。经由配置在相应的计算节点上的(结构)名称服务器来解析VM发送到该默认网关的DNS请求并且该响应被发送回VM。

3.租户DNS服务器-使用该模式，租户能够使用其自身的DNS服务器。服务器列表能够配置在IPAM中，然后在DHCP响应中作为DNS服务器被发送到VM。VM发送的DNS请求与任何其他数据分组一样基于可用路由信息进行路由。

4.虚拟DNS服务器-在该模式下，系统支持虚拟DNS服务器，提供解析来自VM的DNS请求的DNS服务器。我们能够在系统的每个域下定义多个虚拟域名服务器。每个虚拟域名服务器是配置的DNS域的权威服务器。

本文描述的SDN架构在它提供的DNS服务中是有效的。云原生世界中的客户受益于各种DNS服务。然而，随着移动到下一代基于Kubernetes的架构，SDN架构可以替代地使用用于任何DNS服务的核心DNS。

数据平面

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

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

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

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

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

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

工作节点能够是VM或容器接口。在一些示例中，分组处理如以下进行：

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

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

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

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

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

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

·VM1发送出ARP请求。

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1.一种计算机联网方法，包括：

获得指示工作负载之间的分组流的流记录，所述工作负载被部署至一个或多个计算设备的配置有网络策略的集群，其中，所述流记录中的每个流记录指示对应分组流被所述集群允许或拒绝；

接收更新的网络策略；

确定所述流记录中的一个流记录的对应分组流与所述更新的网络策略是否具有差异；并且

响应于确定出所述流记录中的所述一个流记录的所述对应分组流与所述更新的网络策略具有差异，输出错误指示。

2.根据权利要求1所述的计算机联网方法，还包括：

生成允许分组流集合，所述允许分组流集合包括所述流记录中的指示所述对应分组流被允许的流记录，

其中，确定出所述流记录中的所述一个流记录的所述对应分组流与所述更新的网络策略具有差异包括：确定出没有所述更新的网络策略的规则允许所述对应分组流。

3.根据权利要求2所述的计算机联网方法，还包括：

确定出所述更新的网络策略的至少一个规则允许所述对应分组流；

响应于确定出所述更新的网络策略的至少一个规则允许所述对应分组流，使计数器递增；并且

在阻止分组流集合中的所有流记录已被处理之后，如果所述计数器的值等于所述允许分组流集合中的流记录的数量，则相对于被允许的网络流量来验证所述更新的网络策略。

4.根据权利要求1所述的计算机联网方法，还包括：

生成阻止分组流集合，所述阻止分组流集合包括所述流记录中的指示所述对应分组流被拒绝的流记录，

其中，确定出所述流记录中的所述一个流记录的所述对应分组流与所述更新的网络策略具有差异包括：确定出所述更新的网络策略的规则允许所述对应分组流。

5.根据权利要求4所述的计算机联网方法，还包括：

确定出没有所述更新的网络策略的规则允许所述对应分组流；

响应于确定出没有所述更新的网络策略的规则允许所述对应分组流，使计数器递增；并且

在所述阻止分组流集合中的所有流记录已被处理之后，如果所述计数器的值等于所述阻止分组流集合中的流记录的数量，则相对于被阻止的网络流量来验证所述更新的网络策略。

6.根据权利要求1至5中任一项所述的计算机联网方法，还包括：

标记所述更新的网络策略，并且使所述对应分组流与所标记的更新的网络策略相关联以用于检查。

7.根据权利要求1至5中任一项所述的计算机联网方法，其中，所述差异包括以下中的一项：

(1)所述更新的网络策略将拒绝所述对应分组流，并且所述流记录指示所述对应分组流被允许；或者

(2)所述更新的网络策略将允许所述对应分组流，并且所述流记录指示所述对应分组流被拒绝。

8.根据权利要求1至5中任一项所述的计算机联网方法，还包括：

响应于确定出所述流记录中的所述一个流记录的所述对应分组流与所述更新的网络策略没有差异，输出针对所述更新的网络策略的验证的指示，以使所述更新的网络策略被配置在所述集群中。

9.一种计算机联网方法，包括：

确定所述流记录中的一个流记录的对应分组流与更新的网络策略是否具有差异；并且

响应于确定出所述流记录中的所述一个流记录的所述对应分组流与所述网络策略具有差异，输出错误指示。

10.根据权利要求9所述的计算机联网方法，还包括：

其中，确定出所述流记录中的所述一个流记录的所述对应分组流与所述网络策略具有差异包括：确定出没有所述网络策略的规则允许所述对应分组流。

11.根据权利要求10所述的计算机联网方法，还包括：

确定出所述网络策略的至少一个规则允许所述对应分组流；

响应于确定出所述网络策略的至少一个规则允许所述对应分组流，使计数器递增；并且

在所述允许分组流集合中的所有流记录已被处理之后，如果所述计数器的值等于所述允许分组流集合中的流记录的数量，则验证所述允许分组流集合。

12.根据权利要求9所述的计算机联网方法，还包括：

生成阻止分组流集合，所述阻止分组流集合包括所述流记录中的指示所述对应分组被拒绝的流记录，

其中，确定出所述流记录中的所述一个流记录的所述对应分组流与所述网络策略具有差异包括：确定出所述网络策略的规则允许所述对应分组流。

13.根据权利要求12所述的计算机联网方法，还包括：

确定出没有所述网络策略的规则允许所述对应分组流；

响应于确定出没有所述网络策略的规则允许所述对应分组流，使计数器递增；并且

在所述阻止分组流集合中的所有流记录已被处理之后，如果所述计数器的值等于所述阻止分组流集合中的流记录的数量，则验证所述阻止分组流集合。

14.根据权利要求9至13中任一项所述的计算机联网方法，还包括：

标记所述网络策略，并且使所述对应分组流与所标记的网络策略相关联以用于检查。

15.根据权利要求9至13中任一项所述的计算机联网方法，还包括：

将所述差异的原因识别为编码问题或连接性问题。

16.根据权利要求9至13中任一项所述的计算机联网方法，其中，所述差异包括以下中的一项：

(1)所述网络策略将拒绝所述对应分组流，并且所述流记录指示所述对应分组流被允许；或者

(2)所述网络策略将允许所述对应分组流，并且所述流记录指示所述对应分组流被拒绝。

17.根据权利要求9至13中任一项所述的计算机联网方法，还包括：

响应于确定出所述流记录中的所述一个流记录的所述对应分组流与所述网络策略没有差异，输出针对所获得的流记录的验证的指示。

18.一种验证系统，包括：处理电路，所述处理电路能够访问存储设备，所述处理电路被配置为：

接收更新的网络策略；

19.根据权利要求18所述的验证系统，其中，所述处理电路被进一步配置为：

生成允许分组流集合，所述允许分组流集合包括所述流记录中的指示所述对应分组流被允许的流记录，其中，确定出所述流记录中的所述一个流记录的所述对应分组流与所述更新的网络策略具有差异包括：确定出没有所述更新的网络策略的规则允许所述对应分组流；

如果所述计数器的值等于所述允许分组流集合中的流记录的数量，则相对于被允许的网络流量来验证所述更新的网络策略。

20.根据权利要求18至19中任一项所述的验证系统，其中，所述处理电路被进一步配置为：

生成阻止分组流集合，所述阻止分组流集合包括所述流记录中的指示所述对应分组流被拒绝的流记录，其中，确定出所述流记录中的所述一个流记录的所述对应分组流与所述更新的网络策略具有差异包括：确定出所述更新的网络策略的规则允许所述对应分组流；

如果所述计数器的值等于所述阻止分组流集合中的流记录的数量，则相对于被阻止的网络流量来验证所述更新的网络策略。