CN115380514A - 为异构计算元件自动部署网络元件 - Google Patents

Abstract

公开了一种用于在一个或多个数据中心的集合中为机器集合部署网络元件的方法，其中数据中心集合是一个可用性区域的一部分。该方法包括：接收基于意图的API(应用编程接口)请求，并解析这些API请求以识别网络元件集合以连接该机器集合和/或为该机器集合执行服务。API是可以在计算和/或网络元件层次的不同级别指定多个不同的计算和/或网络元件的分层文档。该方法执行自动化过程来定义虚拟私有云(VPC)将机器集合连接到逻辑网络，该逻辑网络将机器集合与数据中心集合中的其它机器隔离开，其中机器集合包括虚拟机和容器，VPC使用主管集群命名空间定义，并且API请求作为YAML文件提供。

Description

为异构计算元件自动部署网络元件

背景技术

随着最近云原生应用(native application)的增加，如今对快速部署按需联网以连接部署在软件定义数据中心(SDDC)中的机器的需求比以往任何时候都多。由于许多计算集群管理员没有广泛的联网知识，因此期望提供自动部署的联网解决方案。但是，对于希望调整其系统联网的管理员来说，期望为这些管理员提供配置和定制其网络部署的能力。

发明内容

本发明的一些实施例提供了一种用于在一个或多个软件定义数据中心(SDDC)集合中为机器集合部署网络元件的方法。在一些实施例中，数据中心集合是一个可用性区域的一部分。该方法接收基于意图的API(应用编程接口)请求，并解析这些API请求以识别网络元件集合以连接该机器集合和/或为该机器集合执行服务。在一些实施例中，API是可以在计算和/或网络元件层次的不同级别指定多个不同的计算和/或网络元件的分层文档。

该方法执行自动化过程来定义虚拟私有云(VPC)以将机器集合连接到逻辑网络，该逻辑网络将机器集合与数据中心集合中的其它机器隔离开。在一些实施例中，机器集合包括虚拟机和容器Pod，VPC使用主管集群命名空间定义，并且API请求作为YAML文件提供。

在一些实施例中，自动化过程使用模板或预先配置的规则来识别和部署实现逻辑网络的网络元件，而无需管理员在接收到API请求之后执行任何动作来指导网络元件的识别和部署。在一些实施例中，部署的网络元件包括用于VPC的网关路由器(称为VPC网关路由器)，用于将VPC连接到数据中心集合的网络或连接到数据中心集合外部的网络。

在一些实施例中，该网关路由器由一个物理路由器实现。在其它实施例中，VPC网关路由器是由一个以上物理路由器实现的逻辑网关路由器。例如，在一些实施例中，逻辑路由器是用处于活动/活动或活动/备用配置中的两个物理路由器实现的。此外，在一些实施例中，逻辑路由器包括(1)由主机计算机和边缘装置上的几个路由器实例实现的分布式路由器，以及(2)各自由边缘装置实现的一个或多个中央路由器。

VPC网关路由器被配置为与数据中心网关路由器通信以将VPC网关连接到另一个VPC的另一个VPC网关，从而将两个VPC相互连接。在一些实施例中，两个VPC的VPC路由器可以被配置为直接相互通信。在一些实施例中，VPC网关路由器被配置为执行源网络地址转换(SNAT)操作以将在VPC内使用的内部网络地址转换成一个或多个外部源网络地址集合。在一些实施例中，外部源网络地址是数据中心集合内的地址，而在其它实施例中，外部源网络地址是数据中心集合外部网络的地址。在一些实施例中，VPC网关路由器不对在VPC和部署在数据中心集合中的另一个VPC之间交换的流量执行SNAT操作，而在其它实施例中它执行这样的SNAT操作。

VPC网关被配置为对进入和/或离开VPC的入口和/或出口流量执行负载平衡操作，或与一个或多个负载平衡器一起工作以执行负载平衡操作。在一些实施例中，负载平衡操作是第4层(L4)和/或第7层(L7)负载平衡操作。在一些实施例中，已部署机器的至少一个子集是通过Kubernetes部署的，并且L4/L7负载平衡操作实现Kubernetes的负载平衡和入口服务。

为了部署网络元件，一些实施例的方法使用一个或多个自定义资源定义(CRD)来定义由接收到的API请求引用的自定义指定网络资源的属性。当这些API请求是KubernetesAPI时，CRD定义了对Kubernetes联网要求的扩展。除了基于Kubernetes的容器Pod，一些实施例的方法还部署网络元件以连接非Kubernetes Pod和/或虚拟机(VM)。对于非Kubernetes Pod和VM，一些实施例的方法使用虚拟网络接口(VIF)CRD来指定虚拟接口，该虚拟接口用于将非Kubernetes Pod和VM连接到在其上执行非Kubernetes Pod和VM的主机计算机上执行的软件转发元件(例如，软件交换机)。

一些实施例的方法为VPC配置逻辑网络以将部署的机器集合相互连接。例如，在一些实施例中，逻辑网络包括一个或多个逻辑转发元件，诸如逻辑交换机、路由器、网关等。在一些实施例中，该方法通过配置几个物理转发元件(LFE)来定义逻辑转发元件(PFE)，其中一些或全部PFE在主机计算机上与部署的机器(例如，VM和Pod)一起执行。在一些实施例中，该方法将PFE被配置为实现两个或更多个LFE以连接两个或更多个不同的部署机器子集。

在一些实施例中，该方法通过为逻辑网络配置两个或更多个子网络来配置逻辑网络。在一些实施例中，每个子网络具有一个或多个段(每个段由逻辑交换机实现)、连接不同的部署机器子集，并提供满足该机器子集的唯一连接性要求集合的网络元件集合。例如，在一些实施例中，第一子网络(例如，第一逻辑交换机)连接Kubernetes Pod，而第二子网络(例如，第二逻辑交换机)连接VM和/或非Kubernetes Pod。另一个示例是为需要高带宽的机器(例如，VM、Pod等)设有一个子网络，并且为可以容忍较少带宽的机器设有另一个子网络。

为了部署独特子网络中的部分或全部，一些实施例的方法使用CRD来定义子网络的属性，使得这些子网络可以被该方法处理的API请求引用。这些CRD在下文中称为虚拟网络CRD。在一些实施例中，引用虚拟网络CRD的API包括可以用于定义不同类型的虚拟网络的网络类型值。

一些实施例具有以下四种网络类型(1)默认类型，包括逻辑子网络的一个或多个网段，每个网段连接到VPC网关路由器，(2)公共类型，包括连接到逻辑子网络的单独网关路由器的一个或多个网段，该单独网关路由器连接到VPC网关路由器并支持逻辑网络的单独路由表和服务，(3)高带宽类型，包括连接到单独网关路由器以直接连接到数据中心集合的路由器的一个或多个段，以及(4)私有类型，包括逻辑子网络的在VPC内部隔离的一个或多个段。

如上所述，一些实施例的方法使用VIF CRD来为非Kubernetes Pod和VM定义和部署VIF。在一些实施例中，VPC在具有相关联IP CIDR(无类域间路由)的单个路由域内操作。对于属于网段的VIF，本方法在一些实施例中自动从为该段自动分配的VPC IP CIDR的IP子网中分配IP地址，除非当前分配的IP子网中的IP地址全部被使用，在这种情况下，它会自动从VPC IP CIDR中分配新的IP子网，并从新分配的IP子网自动分配IP地址。

在一些实施例中，VIF连接到的(即，与VIF相关联的)PFE端口被配置有到一个或多个服务引擎的一个或多个钩子(hooks)，即，一个或多个功能调用，该一个或多个服务引擎在通过端口的数据消息(例如，报文)上执行服务操作。在一些实施例中，一个这样的服务引擎是负载平衡器，其在与网络地址或网络地址集合(例如，VIP地址或相关联IP地址集合)相关联的几个端点机器集合之间分配数据流量负载。

此负载平衡器将从VIF的相关联VM或Pod发送的数据消息分配给端点机器集合中的机器。此外，在一些实施例中，该负载平衡器实现分布式负载平衡器(即，逻辑负载平衡器)，其中几个其它负载平衡器在几个不同的主机计算机上操作。在一些实施例中，这种分布式负载平衡器实现由Kubernetes API调用指定的一个或多个ClusterIP服务。

一些实施例利用端点组CRD来将同质或异质机器集合的分组定义为一个或多个端点组。在一些实施例中，端点组的成员由一个或多个选择器指定，该选择器使用不同类型的网络构造来识别端点组的成员。在一些实施例中，选择器包括VIF选择器、Pod选择器、命名空间选择器和服务选择器。一些实施例使用端点组和VIF CRD来定义相同或不同类型机器的端点组，以提供由Kubernetes API调用指定的ClusterIP服务。

一些实施例利用安全CRD来定义附加的方式来指定VPC的安全策略。例如，一些实施例的方法使用安全策略CRD来定义控制VPC网络端点之间的流量的防火墙规则，这可以由引用端点组CRD的API来定义。在一些实施例中，端点组可以被指定为入口或出口安全规则(例如，防火墙规则)的源或目的地。此类规则由防火墙引擎强制执行，这些引擎在连接到VM和容器Pod的接口(例如，VIF)的端口中定义了钩子。

在一些实施例中，选择器(诸如VIF选择器、Pod选择器、服务选择器等)可以用于指定API中的AppliedTo字段，以指定应在何处强制执行通过安全策略CRD定义的安全策略。在一些实施例中，端点组还可以用于指定应用通过安全策略CRD定义的安全策略的位置。安全策略CRD提供了动态分组的便利性，因为现有解决方案需要手动将端点实例关联到安全组。在一些实施例中，安全策略CRD还支持跨(通过虚拟网络CRD定义的)不同虚拟网络和跨不同VPC的成员资格。因此，在一些实施例中，管理员可以使用安全策略CRD来定义两个VPC之间流量的入口/出口规则。

一些实施例使用管理策略CRD来定义另一种类型的安全策略。在一些实施例中，这些CRD允许为整个VPC定义更高优先级的安全策略(例如，比通过安全策略CRD定义的安全策略更高的优先级)。在一些实施例中，管理策略CRD控制VPC与外部网络之间(例如，来自另一个VPC、来自外部IP块或来自部署VPC的数据中心集合外部)的北/南流量。当逻辑网络的子网络具有其自己的网关时，一些实施例使用管理策略CRD来定义安全策略以供网关强制执行。

在一些实施例中，通过管理策略CRD定义的策略通过由VPC网关强制执行的防火墙规则或由VPC网关使用的一个或多个防火墙来实现。在一些实施例中，这与通过安全策略CRD定义的安全策略形成对比，安全策略CRD由在具有源或目的地VM和Pod的主机计算机上执行的分布式防火墙强制执行。

一些实施例使用虚拟服务对象(VSO)CRD将在VPC内部提供的服务(例如，中间盒服务或应用层，诸如Webserver、AppServer、数据库服务器)暴露给VPC外部的机器或VPC内部的机器。在一些实施例中，基于VSO CRD的VSO API将一个或多个L4端口集合和协议映射到用于提供服务的机器的端点组。在一些实施例中，VSO API还指定虚拟服务的内部范围和/或外部范围，其中内部范围指定虚拟服务可用于VPC内部的机器，而外部范围指定虚拟服务可用于VPC外部的机器。

在一些实施例中，该方法在指定内部范围时自动为虚拟服务分配内部VIP地址，而在外部范围为范围时自动为虚拟服务分配外部VIP地址。该方法还为一个或多个负载平衡器自动生成一个或多个负载平衡规则以实现虚拟服务。每个负载平衡规则包括(1)匹配标准集合，其包括VIP、端口集合和协议，以及(2)动作标准集合，其包括一个或多个标识符集合，这些标识符识别为与VSO CRD一起部署的虚拟服务指定的端点组中的机器。

对于外部范围，在一些实施例中，负载平衡规则由VPC网关路由器或由VPC网关路由器使用的负载平衡器集合来实现。对于内部范围，在一些实施例中，负载平衡规则由VPC网关路由或由VPC网关路由器使用的负载平衡器集合，和/或由与使用虚拟服务的客户端VM和Pod一起在主机计算机上执行的负载平衡引擎实现的分布式负载平衡器实现。在一些实施例中，VSO API指定一种或多种不同类型的负载平衡器，用于针对一种或多种不同类型的数据消息流量的虚拟服务执行负载平衡操作。在使用Kubernetes API的一些实施例中，VSOAPI可以用于将ClusterIP和负载平衡器服务类型定义为(一种或多种)指定的负载平衡类型。

前面的发明内容旨在用作对本发明的一些实施例的简要介绍。这并不意味着是对本文件中公开的所有创造性主题的介绍或概述。下面的具体实施方式和具体实施方式中参考的附图将进一步描述发明内容中描述的实施例以及其它实施例。因此，为了理解本文件所描述的所有实施例，需要对发明内容、具体实施方式、附图和权利要求进行全面审查。此外，要求保护的主题不受发明内容、具体实施方式和附图中的说明性细节的限制。

附图说明

本发明的新颖特征在所附权利要求中阐述。但是，为了解释的目的，本发明的几个实施例在以下图中阐述。

图1图示了本发明的一些实施例的网络控制系统。

图2图示了虚拟私有云的逻辑网络示例。

图3从概念上图示了为VPC部署网络的过程。

图4图示了VPC的逻辑网络的另一个示例。

图5图示了在一些实施例中控制系统可以为VPC的逻辑网络部署的不同子网络的示例。

图6图示了虚拟网络CRD和用于基于此CRD为访客(guest)集群创建虚拟网络的基于意图的API的示例。

图7图示了控制系统定义VIF并为其分配IP地址的过程示例。

图8图示了在一些实施例中控制系统为几个主机计算机上的几个VIF相关联机器定义的分布式负载平衡器的示例。

图9图示了在一些实施例中控制系统为几个主机计算机上的几个VIF相关联机器定义的分布式防火墙的示例。

图10图示了示例VIF CRD和引用此CRD的API。

图11从概念上图示了端点组的示例。

图12从概念上图示了创建端点组的过程。

图13图示了依据端点组定义的防火墙规则和负载平衡规则的示例。

图14图示了跨端点组的成员分发数据消息流量负载的分布式负载平衡器。

图15图示了端点组CRD和与此CRD相关的几个API的示例。

图16图示了一些实施例的虚拟服务对象(VSO)。

图17从概念上图示了定义和使用VSO的过程。

图18和19图示了VSO CRD和VSO API的示例。

图20和21图示了负载平衡器CRD和引用此CRD的API的示例。

图22图示了使用安全策略CRD的API示例。

图23图示了安全策略CRD的示例。

图24图示了基于引用安全策略CRD的API指定防火墙规则的过程。

图25和26图示了管理策略CRD和使用管理策略CRD的API的示例。

图27图示了基于引用管理策略CRD的API指定防火墙规则的过程。

图28图示了访客集群的示例。

图29和30图示了为VPC和访客集群定义基线规则集合的过程。

图31从概念上图示了实现本发明的一些实施例的计算机系统。

具体实施方式

在本发明的以下详细描述中，阐述和描述了本发明的许多细节、示例和实施例。但是，对于本领域技术人员来说将清楚和明显的，本发明不限于所阐述的实施例并且可以在没有讨论的一些具体细节和示例的情况下实践本发明。

本发明的一些实施例提供了一种用于在一个或多个软件定义数据中心(SDDC)集合中为相关机器集合部署和管理网络元件的网络控制系统。在一些实施例中，数据中心集合是一个可用性区域的一部分。该网络控制系统接收基于意图的API(应用编程接口)请求，并解析这些API请求(API调用)以识别要为该机器集合部署的网络元件。在一些实施例中，API是可以在计算和/或网络元件层次的不同级别指定多个不同的计算和/或网络元件的分层文档。

网络控制系统执行自动化过程来定义虚拟私有云(VPC)以将机器集合连接到逻辑网络，该逻辑网络将这些机器与数据中心集合中的其它机器隔离开。在一些实施例中，机器集合包括虚拟机(VM)和容器Pod，VPC被定义有主管集群命名空间，并且API请求作为YAML文件提供。

为了部署网络元件，一些实施例的网络控制系统处理一个或多个自定义资源定义(CRD)，该CRD定义了由接收到的API请求引用的自定义指定网络资源的属性。当这些API请求是Kubernetes API请求时，CRD定义了对Kubernetes联网要求的扩展。一些实施例使用以下CRD：虚拟网络接口(VIF)CRD、虚拟网络CRD、端点组CRD、安全CRD、虚拟服务对象(VSO)CRD和负载平衡器CRD。

在一些实施例中，VIF CRD用于定义虚拟接口以将非Kubernetes容器Pod或VM连接到在其上执行非Kubernetes Pod和VM的主机计算机上执行的软件转发元件(例如，软件交换机)。在一些实施例中，虚拟网络CRD用于定义逻辑子网络的属性，该逻辑子网络将连接已部署机器的子集。端点组CRD用于定义用于对异质或同质机器集合(即，相同或不同类型的机器)进行分组的属性。端点组CRD提供了一种简单的机制，用于定义一组机器来访问服务或计算操作和/或提供服务或计算操作。

安全CRD用于指定VPC的安全策略。例如，一些实施例使用安全策略CRD来为VPC网络端点之间的流量定义安全策略，这可以用端点组CRD来定义。在一些实施例中，另一个安全CRD是管理策略CRD，它可以用于定义VPC与外部网络之间(例如，来自另一个VPC、来自外部IP块或来自部署VPC的数据中心集合外部)的北/南流量的安全策略。

VSO CRD用于将VPC内部提供的服务(例如，中间盒服务或应用层，诸如Webserver、AppServer、数据库服务器)暴露给VPC外部的机器或VPC内部的机器。在一些实施例中，引用VSO CRD的API将一个或多个L4端口集合和协议映射到用于提供服务的机器的端点组。一些实施例使用负载平衡器CRD来定义负载平衡器服务的配置。在一些实施例中，引用VSO CRD的API还使用负载平衡器CRD来指定用于在机器的端点组之间分配流量负载的负载平衡器服务。

现在将描述一些实施例的几个更详细的示例。在这些示例中，几个已部署的逻辑网络是基于Kubernetes的逻辑网络，它们为一个或多个数据中心中的企业实体定义虚拟私有云(VPC)。在一些实施例中，VPC是具有为实体提供租赁边界的命名空间的“主管”Kubernetes集群。这些实施例使用CRD来定义补充Kubernetes原生资源的附加联网构造和策略。

普通技术人员将认识到，其它实施例为其它类型的实体(诸如其它商业实体、非营利组织、教育实体等)定义了其它类型的网络。在这些其它实施例中的一些实施例中，Kubernetes和基于Kubernetes的Pod都没有被使用。例如，一些实施例用于仅为VM和/或非Kubernetes容器/Pod部署网络。

如本文档中所使用的，数据消息是指跨网络发送的特定格式的比特集合。本领域的普通技术人员将认识到，在本文档中使用术语数据消息来指代跨网络发送的各种格式化的比特集合。这些比特的格式化可以由标准化协议或非标准化协议指定。遵循标准化协议的数据消息的示例包括以太网帧、IP报文、TCP段、UDP数据报等。此外，如本文档中所使用的，对L2、L3、L4和L7层(或第2层、第3层、第4层和第7层)的引用分别是对OSI(开放系统互连)层模型的第二数据链路层、第三网络层、第四传输层和第七应用层的引用。

图1图示了本发明的一些实施例的控制系统100的示例。该系统100处理API，这些API使用基于Kubernetes的声明性模型来描述(1)要部署的机器，以及(2)要为已部署的机器执行的连接性、安全性和服务操作(例如，私有和公共IP地址连接、负载平衡、安全策略等)的期望状态。为了处理这些API，控制系统100使用一个或多个CRD来定义API中引用的一些资源。系统100执行自动化过程来部署逻辑网络，该逻辑网络连接已部署的机器并将这些机器与数据中心集合中的其它机器隔离开。在一些实施例中，机器连接到VPC的已部署的逻辑网络。

如图所示，控制系统100包括API处理集群105、软件定义网络(SDN)管理器集群110、SDN控制器集群115以及计算管理器和控制器117。API处理集群105包括两个或更多个API处理节点135，其中每个节点包括API处理服务器140和网络控制器插件(NCP)145。API处理服务器接收基于意图的API调用并解析这些调用。在一些实施例中，接收到的API调用是声明性的、分层的Kubernetes格式，并且可以包含多个不同的请求。

API处理服务器140将每个接收到的基于意图的API请求解析成一个或多个单独的请求。当请求涉及机器的部署时，API服务器将这些请求直接提供给计算管理器和控制器117，或者通过运行在Kubernetes主节点135上的代理将这些请求间接提供给计算管理器和控制器117。计算管理器和控制器117然后在可用性区域中的主机计算机上部署VM和/或Pod。

API调用还可以包括需要部署网络元件的请求。在一些实施例中，这些请求明确识别要部署的网络元件，而在其它实施例中，这些请求还可以通过请求部署必须为其默认定义网络元件的计算构造(例如，计算集群、容器等)来隐含地识别这些网络元件。如下文进一步描述的，控制系统100使用NCP 145来识别需要部署的网络元件，并指导这些网络元件的部署。

在一些实施例中，API调用是指本身不是由Kubernetes定义的扩展资源。对于这些引用，API处理服务器140使用一个或多个CRD120来解释API调用中对扩展资源的引用。如上所述，在一些实施例中，CRD包括VIF、虚拟网络、端点组、安全策略、管理策略以及负载平衡器和VSO CRD。在一些实施例中，CRD在具有API调用的一个流中被提供给API处理服务器。

NCP 145是API服务器140和SDN管理器集群110之间的接口，它管理在可用性区域中用作转发元件(例如，交换机、路由器、网桥等)和服务元件(例如，防火墙、负载平衡器等)的网络元件。SDN管理器集群110指导SDN控制器集群115配置网络元件以实现一个或多个逻辑网络的期望转发元件和/或服务元件(例如，逻辑转发元件和逻辑服务元件)。如下文进一步描述的，在一些实施例中，SDN控制器集群与主机计算机和边缘网关上的本地控制器交互以配置网络元件。

在一些实施例中，NCP 145向API服务器140注册事件通知，例如，建立与API服务器的长拉(long-pull)会话以接收为联网定义的各种CRD的所有CRUD(创建、读取、更新和删除)事件。在一些实施例中，API服务器140是Kubernetes主VM，并且NCP 145作为Pod在该VM中运行。在一些实施例中，NCP 145从用于CRD的SDN资源收集实现数据，并在该实现数据与CRD状态相关时提供该实现数据。

在一些实施例中，NCP 145处理解析的与VIF、虚拟网络、负载平衡器、端点组、安全策略和VSO相关的API请求，以指导SDN管理器集群110实现(1)将VM和Pod连接到主机计算机上的转发元件所需的VIF，(2)用于实现VPC的逻辑网络的不同段的虚拟网络，(3)用于将流量负载分配到端点机器的负载平衡器，(4)用于实现安全和管理策略的防火墙，以及(5)用于访问由VPC中的机器集合向VPC内外的机器提供的服务的暴露端口。

API服务器将已为这些扩展网络构造定义的CRD提供给NCP，以便NCP处理引用对应网络构造的API。API服务器还将配置数据从配置存储装置125提供给NCP 145。在一些实施例中，配置数据包括调整NCP遵循以执行其自动化过程的预定义模板规则的参数。NCP执行这些自动化过程以执行接收到的API请求，以便指导SDN管理器集群110为VPC部署网络元件。对于接收到的API，控制系统100执行一个或多个自动化过程以识别和部署用于实现VPC的逻辑网络的一个或多个网络元件。控制系统执行这些自动化过程，而无需管理员在接收到API请求之后执行任何动作来指导网络元件的识别和部署。

SDN管理器110和控制器115可以是当今可用的任何SDN管理器和控制器。在一些实施例中，这些管理器和控制器是由VMware公司许可的NSX-T管理器和控制器。在这样的实施例中，NCP 145通过处理由其对应的API服务器140提供的数据来检测网络事件，并使用NSX-TAPI来指导NSX-T管理器110部署和/或修改实现API调用所表达的网络状态所需的NSX-T网络构造。NCP和NST-T管理器110之间的通信是异步通信，其中NCP向NSX-T管理器提供期望状态，然后NSX-T管理器将期望状态中继到NSX-T控制器以异步计算和传播状态给可用性区域中的主机计算机、转发元件和服务节点(即，到由控制器115控制的SDDC集合)。

在从NCP 145接收到API之后，SDN管理器110在一些实施例中指导SDN控制器115配置网络元件以实现由API调用表达的网络状态。在一些实施例中，SDN控制器用作控制系统100的中央控制平面(CCP)。图2描绘了充当CCP计算高级配置数据(例如，端口配置、策略、转发表、服务表等)的SDN控制器115。在这样的能力中，SDN控制器115将高级配置数据推送到主机计算机205上的本地控制平面(LCP)代理220、边缘装置210上的LCP代理225和TOR(架顶式)交换机215的TOR代理230。

基于接收到的配置数据，主机计算机205上的LCP代理220配置一个或多个软件交换机250和软件路由器255以实现一个或多个逻辑网络的分布式逻辑交换机、路由器、网桥和/或服务节点(例如，服务VM或管理程序服务引擎)以及其它主机计算机205、边缘装置210和TOR交换机215上的对应交换机和路由器。在边缘装置上，LCP代理225配置这些装置备的报文处理阶段270以实现一个或多个逻辑网络的逻辑交换机、路由器、网桥和/或服务节点以及其它主机计算机205，边缘装置210和TOR交换机215上的对应交换机和路由器。

对于TOR 215，TOR代理230通过OVSdb服务器240配置TOR交换机215的一个或多个配置表275。然后使用配置表中的数据来配置硬件ASIC报文处理流水线280以执行期望的转发操作来实现期望的逻辑交换、路由、桥接和服务操作。美国专利(USP)10,554,484、USP10,250,553、USP 9,847,938和USP 9,178,833更详细地描述了CCP、LCP和TOR代理，并通过引用并入本文。

在主机计算机205与边缘装置210和/或TOR交换机215一起被配置之后，它们可以实现一个或多个逻辑网络，其中每个逻辑网络将为其部署的实体的机器和网络流量与在同一可用性区域中的其它实体的机器和网络流量分离开。图2图示了为一个实体(诸如多租户公共数据中心中的一个公司，或私有数据中心中一个公司的一个部门)定义VPC的逻辑网络295的示例。

如图所示，逻辑网络295包括多个逻辑交换机284，其中每个逻辑交换机连接不同的机器集合并用作不同的网段。每个逻辑交换机具有端口252，该端口与机器260的虚拟接口265连接(即，相关联)。在一些实施例中，机器265包括VM和Pod，其中每个Pod具有一个或多个容器。

逻辑网络295还包括连接由不同逻辑交换机284定义的不同网段的逻辑路由器282。在一些实施例中，逻辑路由器282用作图2中部署的VPC的网关。在一些实施例中，逻辑路由器282包括分布式路由组件296和集中式路由组件297。在一些实施例中，分布式路由组件由在主机计算机和边缘装置上执行的路由实例实现，而中央路由组件297由边缘装置210实现。每个集中式路由组件执行一个或多个服务291或与执行一个或多个服务的一个或多个中间盒服务节点相关联。由此，在一些实施例中，集中式路由组件被称为服务路由器。

在一些实施例中，集中式和分布式路由组件通过在主机计算机205和边缘装置210上定义的逻辑交换机294连接。此外，在一些实施例中，逻辑路由器由一对逻辑节点299实现，其中每个节点具有集中式和分布式组件。在一些实施例中，这对节点可以被配置为以主动/主动或主动/备用模式执行。美国专利9,787,605更详细地描述了一些实施例的网关实现，并且通过引用并入本文。

图3从概念上图示了用于为实体部署VPC的过程300。在一些实施例中，NCP 145指导SDN管理器和控制器执行该过程。在一些实施例中，过程300在NCP 145接收到需要部署新VPC的API请求时开始。在一些实施例中，这样的API请求可以是为可用性区域中的新实体或现有实体创建新逻辑网络的请求。

如图所示，过程300最初为VPC分配(在305处)IP子网。在一些实施例中，VPC是主管集群的一部分，该主管集群是具有指定可用性区域内部的IP地址范围的对应IP CIDR(无类域间路由)的单个路由域。在一些实施例中，分配的IP子网是该IP CIDR中的子网。结合分配的IP地址，在一些实施例中，过程为VPC的虚拟接口分配MAC地址。

接下来，在310处，该过程为VPC定义网关路由器，并将该网关路由器与一个或多个分配的内部IP地址相关联。这些相关联地址是VPC交换机和路由器用于到达该网关的地址。图4图示了具有网关路由器282的VPC 400的示例。在一些实施例中，网关路由器282是具有分布式和集中式组件的逻辑路由器，和/或被实现为一对主动/主动或主动/备用路由器，如上所述。

在一些实施例中，VPC网关路由器282被配置为将VPC与可用性区域的(即，包含VPC的SDDC集合的)一个或多个网关路由器405连接，以便连接到可用性区域外部的网络。此外，在一些实施例中，VPC网关路由器282被配置为与数据中心网关路由器405通信以将VPC网关282连接到另一个VPC的另一个VPC网关，从而将两个VPC相互连接。在一些实施例中，VPC网关路由器282被配置为将报文直接转发到其它VPC的网关路由器(未示出)。

在315处，该过程定义了它为VPC定义的逻辑网络的段，并将IP地址范围分配给这个段。在一些实施例中，这个分配的范围是连续的范围，而在其它实施例中不是连续的范围(即，在这些实施例中分配的IP地址不一定是连续的)。在一些实施例中，所定义的逻辑网段包括被定义为连接特定机器集合(例如，VM和/或Pod)的逻辑交换机。图4图示了属于一个逻辑网段的逻辑交换机284的示例。

如上所述，在一些实施例中，VPC逻辑网络包括一个或多个逻辑转发元件，诸如逻辑交换机、路由器、网关等。在一些实施例中，SDN控制器115通过在主机计算机、边缘装置和TOR交换机上配置几个物理转发元件(诸如软件和硬件交换机、路由器、网桥等)以实现一个或多个逻辑转发元件(LFE)来实现逻辑网络。

如下文进一步描述的，在一些实施例中，控制系统配置PFE以实现两个或更多个LFE以连接在逻辑网络的两个或更多个子网络中已部署机器的两个或更多个不同子集。在一些实施例中，每个子网络可以具有一个或多个段(其中每个段由逻辑交换机实现)、连接已部署机器的不同子集，并提供满足该机器子集的独特连接性要求集合的网络元件集合。例如，在一些实施例中，第一子网络(例如，第一逻辑交换机)连接Kubernetes Pod，而第二子网络(例如，第二逻辑交换机)连接VM。在其它实施例中，一个子网络用于需要高带宽的VM，而另一个子网络用于常规VM。下面提供了附加示例。

在一些实施例中，VPC的逻辑网络的一些子网络可以具有它们自己的子网络网关路由器。如果在315处定义的段的子网络具有这样的子网络路由器，那么过程300定义(在320处)逻辑网段的子网络路由器。如下文进一步描述的，在一些实施例中，子网络路由器可以被配置为将报文转发到VPC网关路由器(例如，路由器282)或可用性区域路由器(例如，路由器405)。

图4图示了逻辑交换机284和VPC网关路由器282被配置为与之通信的子网络路由器410的示例。在一些实施例中，子网络路由器410是由在主机计算机上执行的软件路由器255实现的分布式路由器。图4使用虚线来图示子网络路由器410及其到逻辑交换机284和VPC网关282的连接，以便表明子网络路由器410可能不被部署用于VPC逻辑网络的每个子网络。下面将通过参考图5进一步描述这一点，图5图示了基于虚拟网络CRD部署的虚拟网络的几个示例。在一些实施例中，当子网络路由器用于子网络时，子网络内的所有逻辑交换机都连接到子网络路由器(例如，路由器410)而不是VPC路由器(例如，路由器282)。

在325处，过程300将VPC网关配置为连接到可用性区域网关并执行源网络地址转换(SNAT)操作。例如，在一些实施例中，该过程为VPC网关282配置转发规则以供网关使用以将某些数据消息流转发到可用性区域网关405。此外，在一些实施例中，VPC网关路由器282被配置为执行SNAT操作以将在VPC内使用的内部网络地址转换成一个或多个外部源网络地址集合，并执行反向SNAT操作。在一些实施例中，外部源网络地址是可用性区域内的地址和/或到可用性区域外部的网络的地址。在一些实施例中，VPC网关路由器282不对在其VPC和部署在同一可用性区域中的另一个VPC之间交换的流量执行SNAT操作，而在其它实施例中，它对一些或所有其它VPC执行这样的SNAT操作.

在一些实施例中，VPC网关282被配置为执行其它服务操作或使用服务引擎/装置来执行这样的其它服务操作。对于这样的实施例，过程300配置(在330处)VPC网关以执行其它服务操作(例如，负载平衡操作)或将数据消息转发到服务引擎/装置来执行这样的其它服务操作。在一些实施例中，VPC网关被配置为执行服务操作和/或将数据消息转发到服务引擎/装置以执行这样的服务操作，但是当部署VPC网关时，该配置不是过程300的一部分，而是随后(例如，在VPC中部署执行某些服务或应用的机器时)执行的另一个过程的一部分。

在图4中，VPC网关282被配置为将数据消息流转发到一个或多个负载平衡器415的集群，以对进入和/或离开VPC的入口和/或出口流量执行负载平衡操作。在一些实施例中，负载平衡操作是L4和/或L7负载平衡操作。在一些实施例中，已部署机器的至少一个子集通过Kubernetes部署，并且L4/L7负载平衡操作实现Kubernetes的负载平衡和入口服务。在一些实施例中，VPC网关自己执行一些或所有这样的负载平衡操作。具有负载平衡能力的网关的示例在美国专利9,787,605和10,084,726中进行了描述，这些专利通过引用并入本文。过程300在330之后结束。

图5图示了在一些实施例中控制系统100可以为VPC 500的逻辑网络部署的不同子网络的示例。VPC 500是部署在可用性区域550中的几个VPC之一。在图5中所示的示例中，为VPC 500部署了五种不同类型的已部署子网络502-510，其中一个是为Kubernetes Pod部署的默认网络502，另外四个504-510是基于通过虚拟网络CRD定义的四种虚拟网络类型之一部署的。

控制系统502在其必须部署Kubernetes Pod时部署默认网络502。对于默认网络502，控制系统502配置网络元件(例如，实现默认网络的逻辑交换机和路由器，以及由该网络使用的VPC网关和服务节点)以满足Kubernetes联网要求。例如，控制系统从默认网络的VPC的IP CIDR中的一个子网开始，为每个Kubernetes Pod的网络接口分配来自该子网的IP地址，并将该网络接口与用于实现默认网络502的逻辑交换机相关联。随着更多的Pod被添加，当现有子网用尽时，控制系统会自动从VPC的IP CIDR中分配额外的子网，并创建新的逻辑交换机来为新子网实现默认网络的新段。

此外，除了上述VPC网关282上的SNAT操作之外，控制系统还在VPC网关282上定义了防火墙操作，以确保满足Kubernetes联网假设，例如，允许在一个路由域内的VPC上的流量通过并且不进行源网络地址转换。此外，在一些实施例中，VPC网关282被配置为丢弃从可用性区域外部到达网关的流量，以便隔离VPC。在一些实施例中，VPC管理员可以定义安全规则以改变这些默认设置中的一些或全部。

对于Kubernetes负载平衡器类型和入口类型服务，控制系统配置VPC网关282的负载平衡器415以为默认网络502以及其它子网络提供这些服务。此外，在一些实施例中，控制系统100在主机计算机上配置分布式负载平衡引擎以实现Kubernetes指定的ClusterIP服务，并在主机计算机上配置分布式防火墙引擎以实现Kubernetes指定的网络策略，同样针对默认网络502以及其它子网络。

控制系统100部署基于通过虚拟网络CRD定义的四种虚拟网络类型的子网络504-510。为了部署独特子网络中的一些或全部，一些实施例的网络控制系统接收并处理引用虚拟网络CRD的API以定义这些子网络的属性。如上所述，在一些实施例中，虚拟网络CRD包括网络类型值，该值定义使用这些CRD部署的虚拟网络的网络类型。

图5图示了一些实施例的四种虚拟网络类型504-510。这些虚拟网络中的每一个都是VPC 500的逻辑网络的单独子网络。第一虚拟网络是默认类型的虚拟网络504，其包括VPC逻辑网络中的一个或多个网段，其中每个网段连接到VPC网关路由器282。第二虚拟网络是公共类型虚拟网络506，其包括用于虚拟网络连接到VPC网关路由器282的单独网关路由器520。这个单独的网关路由器520支持用于公共虚拟网络506的单独路由表和服务。

高带宽型虚拟网络508是图5中的第三个虚拟网络。该虚拟网络508具有连接到单独网关路由器525的一个或多个网段，该单独网关路由器525直接连接到可用性区域550的网关路由器555。这种直接连接为高带宽虚拟网络508提供到可用性区域之外的网络以及到VPC500之外的可用性区域中的其它资源的更高速连接。

最后一个虚拟网络是私有类型的虚拟网络510。它包括逻辑网络的在VPC内部隔离并连接到其自己的网关路由器530的一个或多个段。图5中的每个子网络502-510可以具有不止一个段，因为当分配给子网络中的(一个或多个)现有网段的IP范围中的所有IP地址都被使用时，网络控制系统在一些实施例为子网络部署新段，并为该新段分配新IP范围。在一些实施例中，子网络的每一段由一个逻辑交换机实现，该逻辑交换机跨越一个或多个主机计算机，该一个或多个主机计算机执行连接到由逻辑交换机实现的子网络段的机器。

从四个示例504-510可以明显看出，在一些实施例中，每个虚拟网络CRD为共享相同联网和连接性要求的一组工作负载定义网络和连接性。虚拟网络是有利的，因为部署在VPC中的工作负载可能对联网配置具有不同的需求。前端服务，诸如网站和流传输服务，始终是面向公众的。但是，机密服务(例如，某些数据库)始终与互联网隔离。因此，对于此类不同类型的工作负载，期望基于不同的联网连接性要求来隔离工作负载。为了向VPC提供这种子网划分功能，一些实施例使用新的VirtualNetwork(VNet)抽象。

引用虚拟网络CRD的示例API如下：

这个API指定它与虚拟网络CRD相关，因为它在其Kind(类型)字段中引用VirtualNetwork(虚拟网络)。在其metadata(元数据)字段中，它提供了正在部署的虚拟网络的name(名称)(vnet-1)，以及正在为其部署的VPC(vvpc-1)。在其connectivity(连接性)字段中，该API描述了应该部署的虚拟网络的类型。在这个示例中，vnet-1被指定为私有虚拟网络(如虚拟网络510)。

在VNet创建事件时，NCP将基于VirtualNetwork规范中的连接性字段实现对应的网络资源和路由配置，并指导SDN管理器/控制器部署具有期望网络元件(例如，交换机、路由器、和/或网关)的此类虚拟网络。如上面通过参考图5所提到的，一些实施例支持具有四种不同类型的连接性的4种类型的虚拟网络。

在一些实施例中，管理员可以通过在请求部署(一个或多个)VM的API调用中指定虚拟网络的名称来将一个或多个VM放置到已部署的虚拟网络上。在一些实施例中，虚拟网络的底层网络资源包括一个或多个NSX-T段，其连接到VPC网关路由器(其在NSX-T中是第1层路由器)或为虚拟网络部署的单独的虚拟网络路由器(例如，单独的NSX-T第一层路由器)(如网关路由器520、525和530)。放置在已部署虚拟网络上的工作负载(例如，VM、Pod等)映射到段上的端口。每个段都分配有来自私有IP块的子网。在一些实施例中，个别虚拟网络不限于固定的CIDR。在一些实施例中，当当前段用尽时，会自动创建更多段。

一些实施例的虚拟网络设计相对于现有公共云解决方案具有以下优点。它们简化了路由配置，因为与云VPC不同，一些实施例的VPC不需要用户深入了解路由配置的复杂性。NCP 145还自动配置路由表以满足基本连接性要求。一些实施例的虚拟网络设计还灵活且容易地支持各种联网拓扑。除了最常见子网的模式，公有和私有之外，这种虚拟网络设计使用户能够基于性能考虑选择不同的底层资源布局，如上所述。

这种设计还提供了更好的用户体验和子网使用效率。普通云VPC因子网规划不便而备受批评。例如，在AWS中，子网必须使用固定的CIDR创建，并且在以后应用放大时无法扩展。一些实施例的VPC设计具有子网自动缩放机制，该机制可以通过跨不同虚拟网络稳健地重新分配IPAM资源来实现IPAM利用的最高效率。

一些实施例使用虚拟网络CRD不仅为VPC指定虚拟网络，而且为与VPC联合工作的访客集群指定虚拟网络。在一些实施例中，一个或多个访客集群被定义在与VPC相同的命名空间内。在一些实施例中，此类访客集群(GC)具有在其上执行工作负载Kubernetes Pod的几个主机计算机，而VPC具有在其上执行工作负载非Kubernetes Pod和VM的几个主机计算机。

一些实施例的网络控制系统是使用NSX-T作为Kubernetes Pod的网络和安全解决方案的工作负载控制平面(WCP)的一部分。Kubernetes需要Node网络和Pod网络能够相互到达。因此，在一些实施例中，主管集群中的主VM需要附接到NSX网络。同时，访客集群节点也附接到同一NSX网络，使得主管集群也可以管理访客集群节点。

在一些实施例中，部署在主VM上的NCP 145为WCP提供NSX联网。在一些实施例中，NCP 145监听WCP API服务器事件，然后指导NSX-T管理器/控制器创建NSX资源。在一些实施例中，主管集群中的主VM和访客集群中的节点VM在Kubernetes中没有现有的对象定义。因此，为了允许NCP 145为这些VM创建网络资源并提供关于有关已配置VM网络的网络状态的WCP信息，网络控制系统使用Kubernetes资源CRD以允许针对不同部署的不同管理员定义其自己的资源。在一些实施例中，网络控制系统为VM和非Kubernetes Pod定义了用于WCP联网的虚拟网络CRD集合。

在主管集群上，在一些实施例中WCP为每个主VM创建VIF对象。对于访客集群创建，在一些实施例中WCP为每个集群创建VNet并且为每个节点VM创建VIF对象。NCP 145监视这些虚拟网络事件，并为VIF对象分配NSX网络资源，然后将关于VIF的状态报告回网络控制系统。然后通过CRD状态更新通知WCP联网实现结果。

为了使用虚拟网络CRD为访客集群定义虚拟网络，为访客集群使用Vnet CRD的API包括命名空间范围。对于每个虚拟网络CRD，NCP 145让SDN管理器/控制器部署GC网关路由器(例如，T1路由器)、用于访客集群的全局SNAT IP，并在部署的GC网关路由器下分配子网。NCP还提供回SNAT IP作为CRD状态的一部分。在一些实施例中，主管集群中的主VM使用VIF附接到NSX网络，而访客集群使用虚拟网络来定义集群路由器和子网。在一些实施例中，访客集群中的节点使用VIF CRD来创建附接到虚拟网络的网络资源。

图6图示了虚拟网络CRD 605和用于基于该CRD 605为访客集群创建虚拟网络的基于意图的API 610的示例。如下文进一步描述的，在一些实施例中访客集群是特定的工作负载集群，其被定义为包括执行特定任务或为为其定义VPC的实体的特定子实体操作的工作负载机器。

CRD 605在规范部分中定义虚拟网络的名称、组和版本属性。它还在元数据部分定义了名称属性。虚拟网络API 610在元数据部分中定义访客集群的虚拟网络名称。它还指定访客集群默认SNAT IP属性，并在状态部分中指定几个条件属性。默认SNAT IP指定必须为访客集群分配一个IP地址。在一些实施例中，SNAT操作由为访客集群部署的网关执行，如下文进一步描述的。

如上所述，一些实施例的网络控制系统使用VIF CRD来为非Kubernetes Pod和VM定义和部署VIF。在一些实施例中，VPC在具有相关联IP CIDR的单个路由域内操作。与主管集群的私有IP CIDR不同，在一些实施例中，VPC拥有公共IP地址范围。在一些实施例中，控制系统100使用Kubernetes Pod列表部署Pod，并且使用VM CRD部署VM。对于Pod工作负载，将为Pod分配私有IP。管理员还可以通过在Pod或VM的规范中指定公共IP地址来请求它。

对于VM，在一些实施例中，管理员可以在VM CRD规范中创建并指定N个虚拟接口。VIF CRD定义虚拟接口，在一些实施例中，虚拟接口将被实现为连接到VPC段的NSX-T逻辑端口。在一些实施例中，NSX-T还实现VM的VNIC。下面示出了示例VIF API。类型字段定义为接口分配的IP地址。如果类型被设置为私有，那么它将只被分配私有IP。如果类型被设置为公共，那么除了私有地址之外，还将给这个接口分配公共IP地址。

这个API中的虚拟网络字段将部署的VIF关联到特定的虚拟网络。换句话说，VIFAPI中的虚拟网络字段引用了与VIF相关联的特定虚拟网络。当VIF API未指定虚拟网络时，VIF连接到默认网络504。在WCP使用的一些实施例中，默认网络是共享命名空间网络。

对于属于网段的VIF，在一些实施例中，网络控制系统自动从为该段自动分配的VPC IP CIDR的IP子网中分配IP地址，除非当前分配的IP子网中的IP地址被全部使用，在这种情况下，它会自动从VPC IP CIDR分配新的IP子网，并从新分配的IP子网自动分配IP地址。除了将IP地址分配给VIF之外，在一些实施例中，NCP还指导SDN管理器/控制器将MAC地址分配给VIF，如下文进一步描述的。

图7图示了控制系统100执行以自动缩放VPC逻辑网络的段，同时定义VIF并为其分配私有IP地址(即，VPC中的IP地址)的过程700的示例。在一些实施例中，NCP 145每次检测到新的VIF创建事件时执行过程700。例如，每次API服务器140接收到需要创建新VIF的API时，NCP都会检测到这样的事件。在一些实施例中，这样的API是指VIF CRD。如上所述，一些实施例定义了新的VIF以将VM或非Kubernetes Pod连接到VPC的逻辑网络。因此，在这些实施例中，VIF创建伴随着配置在主机计算机上部署以加入逻辑网络的VM。

如图所示，过程700最初定义(在705处)新的VIF(例如，定义新的VIF对象)。然后确定VIF所属的(例如，VPC逻辑网络的子网络的)段是否有空闲IP地址可以分配。在一些实施例中，VIF API包括指定VIF所属的Vnet的虚拟网络标识符。当API不提供此值或提供默认值时，该过程将VIF分配给默认网络504。在一些实施例中，为VIF识别(在710处)的虚拟网络是VIF所属的子网络。一旦该过程识别了VIF的子网络，然后它就确定(在710处)该子网络是否仍然有空闲的IP地址从已分配给识别出的子网络的当前段的当前IP地址范围分配给VIF。

如果没有，那么该过程转换到715，在此它为VIF的虚拟网络定义新段并为该新段分配新的IP范围。在一些实施例中，虚拟网络的每个新段是不同的逻辑交换机。从715，该过程转换到720。当它确定(在710处)已分配给VIF的虚拟段的当前IP范围尚未用尽(即，仍有一些未分配的IP地址)时，该过程也转换到720。

在720处，该过程从当前IP范围(当IP范围尚未用尽时)或从新IP范围(当IP范围用尽并且为VIF定义了新IP范围时)将IP地址分配给VIF。接下来，在725处，该过程将VIF与在VIF的相关联VM在其上执行的主机计算机上执行的软件交换机的端口相关联(即，在VIF和端口之间创建逻辑连接)。在一些实施例中，软件交换机实现了定义VIF所属的虚拟网络的段的逻辑交换机。在720之后，该过程结束。

如上所述，当引用该VIF的API请求此类IP地址时，NCP还可以请求SDN管理器/控制器为VIF分配公共IP地址。在一些实施例中，过程700将MAC地址连同它分配给VIF的(一个或多个)IP地址一起分配给VIF。每当控制系统100为逻辑网络的子网络(例如，默认网络502或Vnet 504-510)分配新段时，控制系统不仅分配IP地址和MAC地址，而且还配置逻辑网络路由器的路由表，以允许将数据消息转发到段和从段转发数据消息。

例如，每次在创建逻辑子网络的第一段之后创建该子网络的新段时，SDN管理器/控制器在具有属于该子网络的机器的主机上使用允许虚拟路由器255在一个子网络的不同段之间转发数据消息的路由记录(例如，下一跳转发记录)配置这些虚拟路由器。这些虚拟路由器执行用于子网络的网关的分布式路由器296。

如上所述，一些实施例使用VPC网关282作为子网络的网关，而其它实施例使用其自己的网关520、525或530。在一些实施例中，SDN管理器/控制器还配置每个子网络的集中式和分布式路由组件以将流量从子网络转发到网关和从网关转发到子网络，以便允许在子网络之间以及在子网络与VPC逻辑网络之外的其它网络之间交换数据消息流。

但是，在这些实施例中的一些实施例中，私有虚拟网络510与其它子网络和VPC外部的网络保持隔离。总之，每次创建新段时(例如，在715处)，SDN管理器/控制器在多个主机、边缘设备和/或TOR交换机上配置多个路由记录，以确保将数据消息流正确地转发到网段和从网段转发。下面将进一步描述为VPC和访客集群定义的基线转发和安全策略。

在一些实施例中，NCP 145可以定义服务规则以执行服务操作，其中VIF相关联机器(例如，VIF相关联VM和/或非Kube Pod)在这些服务操作和/或服务器操作的客户端或服务器端。例如，当VIF相关联机器位于此类操作的客户端时，在一些实施例中，NCP 145在连接到VIF的软件交换机端口定义钩子(即，函数调用)，使得分布式负载平衡操作可以由在与VIF相同的主机计算机上执行的负载平衡引擎执行，以便在执行服务操作的几个服务节点之间分发从VIF相关联机器出口的数据消息流。

在一些实施例中，NCP 145定义这样的钩子以实现在Kubernetes API中定义的ClusterIP服务(例如，在几个服务引擎、装置和/或机器之间分发来自一个或多个VIF相关联的客户端机器的数据消息流)，以及与本文档中描述的其它分布式负载平衡服务。此外，在一些实施例中，NCP 145定义了这样的钩子，以在执行相同的分布式计算操作(例如，执行相同的服务器层，诸如Webserver层、appserver层、数据库服务器层等)的几个不同计算节点(例如，VM、Pod等)之间分发来自一个或多个VIF相关联的客户端机器(例如，Pod和/或VM)的数据消息流。因此，钩住(hooked-in)的负载平衡器在其间分发数据消息流的端节点可以是服务节点或计算节点。

图8图示了在一些实施例中NCP为几个主机计算机850上的几个VIF相关联机器830定义的分布式负载平衡器800的示例。在NCP145的要求下，SDN管理器/控制器在一些实施例中配置VIF 805与到与VIF在相同主机计算机上执行的负载平衡器815的钩子连接到的(即，与VIF相关联的)软件交换机端口810。在一些实施例中，为需要关联的客户端负载平衡操作的每个VIF实例化一个负载平衡器815。在一些实施例中，每个负载平衡器是由在与机器830相同的计算机上执行的管理程序提供的服务引擎。

这些钩子被配置为将进入或离开VIF相关联机器(由VIF相关联机器提供或提供给VIF相关联机器)的入口和/或出口流量引导到它们各自的负载平衡器。每个负载平衡器815使用负载平衡规则集合(存储在LB规则存储装置820中)来识别应该处理进入或离开机器830的数据消息流的端节点集合825。在一些实施例中，负载平衡器然后使用负载平衡标准(例如，用于端节点的循环选择的权重值)来为每个数据消息流选择端节点，然后将流的一个或多个数据消息转发到为该流选择的端节点。如图所示，在一些实施例中，负载平衡规则和标准被存储在LB规则存储装置820中。

在一些实施例中，为数据消息流进行的负载平衡器的这种选择可以是有状态的，使得一个流的所有数据消息都被发送到不同的一个端节点825。可替代地，在一些实施例中，该选择可以是无状态的，使得将同一流的不同数据消息发送到不同的端节点。此外，在一些实施例中，负载平衡器可以被配置为仅将流的第一数据消息或前几个数据消息发送到端节点机器。

在一些实施例中，端节点825在入口或出口流量的情况下可以是服务节点，或者在出口流量的情况下可以是目的地计算节点。端节点可以是与客户端VIF相关联机器和负载平衡器在同一主机计算机850上的引擎/机器、可以是不同主机计算机上的引擎/机器，或者可以是独立装置。在一些实施例中，端节点与虚拟网络地址(例如，VIP地址)或相关联的网络地址集合(例如，相关联的IP地址集合)相关联。在一些实施例中，端节点机器是Pod、VM和/或在Pod/VM上执行的容器。

在一些实施例中，当将数据消息转发到驻留在同一主机计算机上的端节点机器时，负载平衡器815通过其主机计算机850上的软件交换机855转发数据消息。可替代地，当向不在同一主机计算机上驻留的端节点机器转发数据消息时，负载平衡器815通过其主机的软件交换机855和/或软件路由器(未示出)和中间网络架构转发数据消息。

在一些实施例中，NCP 145指导SDN管理器/控制器在VIF相关联端口810中配置钩子以用于其它中间盒服务操作，诸如防火墙、入侵检测、入侵预防、深度报文检查、加密等。图9图示了其中端口钩子被配置为将来自/到VIF相关联机器830的入口/出口数据消息流引导到对这些流执行防火墙操作的同一主机计算机850上的防火墙引擎915。在一些实施例中，防火墙操作确定数据消息流是否应该被允许通过机器或软件交换机、应该被丢弃，或者应该被重定向到另一个服务机器或装置。

如图所示，几个主机计算机上的几个防火墙引擎915实现分布式防火墙900。在一些实施例中，多个这样的防火墙引擎在同一主机计算机上为为其配置分布式防火墙操作的多个不同的VIF相关联机器执行。为了执行它们的防火墙操作，防火墙引擎使用存储在防火墙规则存储装置920中的防火墙规则。在一些实施例中，防火墙规则由SDN管理器/控制器在NCP 145的要求下定义。在一些实施例中，NCP 145定义分布式防火墙操作以实现在Kubernetes API中定义的网络策略服务，以及本文档中描述的其它防火墙操作。

如上所述，在一些实施例中，控制系统100可以配置服务和转发规则以使VIF相关联机器执行服务端或服务器端操作。为了便于将VIF相关联机器用作服务机器或服务器机器，一些实施例使用端点组CRD。为了简化在端点组中包含VIF，在一些实施例中，为VIF归档的元数据包括标签字段，该字段可以用于为VIF指定一个或多个标签。在一些实施例中，标签字段可以包括一个或多个键值对，其中每一对指定标签和标签的值。

为了进一步图示此类标签，图10图示了示例VIF CRD 1000和引用此CRD的API1005。如图所示，VIF CRD 1000指定VIF具有一个或多个元数据字段。它还将VIF定义为具有规范，该规范包括VIF所属的组、VIF的一个或多个版本属性、VIF的范围以及VIF的一个或多个名称。

API 1005具有将guest-cluster-network1识别为与VIF相关联的虚拟网络的虚拟网络字段。此虚拟网络是VIF及其相关联机器(例如，Pod)所属的网络。虚拟网络字段是可选的。未提供时，NCP会将VIF与默认网络504相关联。对于API指定的每个VIF，NCP将创建具有分配的IP地址和分配的MAC地址的端口。NCP会将实现结果作为CRD状态报告回来，计算管理器(例如，WCP)接收到该状态，然后相应地配置相关联的机器(例如，VM或Pod)。

VIF API具有interfaceID字段，用于定义VIF标识符(VIF_ID)。它还具有指定VIF具有相关联的IP地址、网关、子网掩码和MAC地址的字段。它进一步指定VIF具有带有逻辑交换机ID的逻辑交换机。在一些实施例中，这些参数由SDN管理器/控制器110/115在NCP 145的要求下提供，如上所述。VIF API具有包括标签的元数据字段集合。在图10的示例中，标签是两个键值对，一个将VIF定义为属于计算组件，另一个将VIF的机器定义为生产型机器。如下面通过参考端点组CRD和API进一步描述的，标签可以用作定义一组VIF的选择器。

由于VIF可以与非Kubernetes Pod和VM相关联，因此标签允许定义端点组以包含可以用作数据消息的服务器节点或服务节点的异构类型的机器组。端点组是在一些实施例中可以通过使用端点组CRD和API创建的动态分组对象。在一些实施例中，可以通过端点组相关联的机器可以是相同类型或不同类型。例如，在一些实施例中，端点组可以通过与VIF和Pod相关联的标签定义为包括VIF和Pod。更具体而言，在一些实施例中，管理员可以通过指定IP地址CIDR或选择器列表来指定端点组(即，可以定义组的成员)。在一些实施例中，选择器与不同类型的网络元件相关。例如，在一些实施例中，选择器包括VIF选择器、Pod选择器、命名空间选择器和服务选择器。

图11从概念上图示了包括两个VM 1105、非Kubernetes Pod1110和KubernetesPod 1115的端点组1100的示例。如本例所示，端点组通过这些机器的其VIF 1107和1112与VM和非Kubernetes Pod相关联，而它直接与Kubernetes Pod 1110相关联。在这个示例中，VM 1105和非Kubernetes Pod 1110部署在两个虚拟网络1120和1122(在一些实施例中其可以是网络504-510中的任何一个)上，而Kubernetes Pod部署在默认网络1124(其在一些实施例中是默认网络502)上。

在一些实施例中，选择器可以根据网络元件的一个或多个属性来识别一组网络元件(VIF、Pod、命名空间、服务)，包括已经为网络元件指定的任何标签。选择器提供了一种用于为各种工作负载形成具有动态成员资格的端点组的简单方法，因为选择器可以根据与可以动态更改的网络元件集合相关联的属性(例如，标签)来定义。

然后，此类组可以用于执行服务、安全和计算操作。例如，如上所述，端点组和VIF可以用于定义相同类型或不同类型的机器集合，以提供API请求指定的服务或计算操作(例如，ClusterIP服务)。

图11从概念上图示了端点组1100被用来定义虚拟服务对象1130、安全策略1132、管理策略1134和负载平衡对象1136。

下面是引用端点组的示例API调用。

在上述YAML代码中，端点组foo被定义为包括vvpc-1命名空间内、虚拟网络vnet-1上并与标签“app＝frontTier”相关联的所有VIF。在一些实施例中，管理员还可以指定资源的名称(例如，VIF的名称)来执行精确匹配。这种分组方法提供了最大的配置灵活性。它支持在同一组中拥有不同类型的Kubernetes资源，以及跨不同虚拟网络(例如，网络504-510)甚至不同VPC的组。

图12从概念上图示了用于创建和使用端点组的过程1200。如图所示，该过程由管理员基于定义端点组成员的选择器集合指定(在1205处)端点组API开始。接下来，在1210处，API服务器140接收该API，并且NCP 145检测创建端点组事件。在一些实施例中，通过SDN管理器，NCP引导(在1215处)NSX-T SDN管理器110(其然后引导SDN控制器115)为端点组创建NSX-T组(例如，NSX安全组)，并将组成员定义为映射到具有匹配属性的资源(例如，Kubernetes资源)的对应NSX-T资源(例如，VNIC、Pod接口等)。

在1220处，端点组的定义(即，端点组的成员列表)被分发到使用该定义来解析根据端点组定义的服务和转发规则的主机计算机和边缘装置。对于包括VIF和KubernetesPod的端点组，在一些实施例中端点组定义包括端点组标识符加上作为组的成员的VIF和Pod接口的IP地址列表。每次添加具有与端点组的(一个或多个)选择器的属性匹配的属性的新网络元件时，都会将更新后的成员列表分发到主机计算机和边缘装置。

图13图示了根据端点组定义的防火墙规则1305和负载平衡规则1310的示例。这些规则由在主机计算机和/或边缘装置上执行的防火墙引擎1320和负载平衡引擎1325处理。在这个示例中，端点组用于定义一些或所有防火墙规则1305的一个或多个匹配分类属性(例如，防火墙规则的目的地IP字段)。

如下面进一步描述的，一些实施例根据端口地址以及IP地址来定义端点组的每个成员。在这样的实施例中，端点组的相关联IP和端口地址可以用于定义由中间盒服务引擎处理以执行中间盒服务操作的服务规则(例如，防火墙规则或其它中间盒服务规则)的源和/或目的地IP和端口值。

在一些实施例中，图13中所示的端点组是由SDN控制器部署的NSX安全组。这些安全组等效于由Kubernetes API指定并由处理这些API的NCP识别的端点组。类似地，Pod和VIF(以及其它数据平面部署的网络构造)是由API和NCP定义的等效构造。从一些网络元件来看，SDN部署的元件与API定义的元件之间存在1对1的映射，而对于其它网络元件，不存在1对1的映射。

当防火墙引擎1320接收到数据消息时，防火墙引擎确定消息的流标识符是否匹配其防火墙规则之一的匹配分类属性，如果匹配，那么它执行最高优先级匹配规则的动作。当防火墙规则的匹配分类包括端点组标识符时，防火墙引擎使用端点组列表1350将端点组标识符解析为成员IP地址列表，然后确定接收到的消息的流标识符是否具有落入该成员IP列表中的报头值。如图所示，端点组列表1350包括几个端点组标识符1352，以及作为该端点组成员的VIF和Pod的IP地址集合1354。

当端点组标识符用于识别防火墙规则的目的地IP字段时，防火墙引擎确定接收到的消息的报头(在其流标识符中)中的目的地IP地址是否是端点组列表中的端点组定义中的IP地址。如果是，并且如果数据消息的其余流标识符与防火墙规则的其余匹配分类属性匹配，那么防火墙引擎1320确定防火墙规则与数据消息匹配，然后基于匹配的防火墙规则的动作属性对流执行防火墙操作(例如，允许、丢弃等)。

在一些实施例中，端点组由IP地址和端口地址识别。在一些这样的实施例中，防火墙引擎1320使用端点组列表来将防火墙规则的匹配分类属性集合中的端点组标识符解析为IP和端口地址(例如，目的地IP和端口地址)。然后将解析的IP和端口地址与接收到的数据消息的对应IP和端口地址进行比较，以确定数据消息是否匹配防火墙规则的匹配分类属性。

在图13中，负载平衡规则1310使用端点组来定义匹配流的目的地。负载平衡引擎1325将接收到的数据消息的流标识符(例如，五元组标识符)与一个或多个负载平衡规则的匹配分类属性进行比较，以确定数据消息是否匹配这些规则之一。如果是，那么负载平衡规则识别由匹配规则指定的端点组标识符。

在一些实施例中，端点组标识符识别端点组列表1360中识别的端点组。如图所示，端点组列表1360具有多行，每行由不同的端点组标识符索引，表示不同的端点组并指定组中端点机器的属性。在此列表中，每个端点机器都与VIF或Pod接口相关联，并且当VIF与VM或非Kubernetes Pod相关联时由IP地址和端口值指定，或者当接口与Kubernetes Pod相关联时由IP地址和协议指定。

负载平衡引擎使用端点组列表1360将端点组标识符解析为(1)作为端点组成员的成员VIF和Pod的IP地址列表，以及(2)列表中的IP地址的负载平衡标准(例如，权重值)集合。对于VM和非Kubernetes Pod，在一些实施例中，端点组列表提供每个VIF的IP地址，用于访问由与VIF相关联的端点机器提供的服务或计算的端口。对于Kubernetes Pod，在一些实施例中，端点组列表1360提供VIF IP以及用于访问由与VIF相关联的端点机器提供的服务或计算操作的协议(例如，http)。

基于负载平衡标准，负载平衡引擎然后从列表中选择一个端点机器(例如，列表中的一个IP地址)、用所选择的IP地址替换数据消息的目的地IP地址、用与所选择的IP地址相关联的目的地端口(如果适用)替换目的地IP端口，然后将数据消息提供给转发元件(例如，其主机计算机上的软件交换机)以转发到新指定的目的地IP地址。这些是对VM和非Kubernetes Pod执行的操作。

对于Kubernetes Pod，负载平衡引擎不会替换目的地IP端口，而是使用由端点组列表为所选择的端点机器指定的协议。此外，对于VM和非Kubernetes Pod，在一些实施例中，接收到的数据消息的目的地端口对应于由所有端点机器用于提供服务或计算操作的目的地端口。在这样的实施例中，负载平衡器在将数据消息转发到所选择的端点机器之前不需要替换目的端口地址。

图14图示了跨端点组的成员分发用于特定服务操作或计算操作的数据消息流量负载的分布式负载平衡器(例如，由几个主机计算机850上的负载平衡器815实现)。在这个示例中，实现分布式负载平衡器(DLB)1405的负载平衡器将来自客户端机器集合1410的数据消息流匹配到指定端点组标识符的负载平衡规则1310。在一些实施例中，匹配流的目的地IP地址根据目的地VIP地址来指定。因此，在这些实施例中，在匹配的负载平衡规则中包含端点组标识符表示寻址到目的地VIP地址的消息应该被分发到与端点组标识符对应的端点组。在这个示例中，端点组是包括Pod 1424和与Pod 1422和两个VM 1420相关联的三个VIF 1450的组。

对于接收到的数据消息流，DLB 1405在一些实施例中通过使用端点组列表来识别端点组的成员。然后，它使用在已识别端点组的端点组列表中指定的负载平衡标准(例如，基于成员机器的轮询选择的权重值)，以便从端点组中为流选择一个机器。DLB 1405然后将接收到的数据消息流中的目的VIP地址和目的端口地址替换为为流选择的端点机器的解析IP和端口地址，然后将数据消息流转发给该端点机器。

在图13和14所示的示例中，防火墙和负载平衡规则以端点组标识符表示。在这些示例中，数据平面中的防火墙和负载平衡引擎解析端点组标识符以找到匹配规则或执行匹配规则的负载平衡操作。在其它实施例中，控制平面(例如，主机计算机和边缘装置上的本地控制代理)解析组成员资格，以便根据成员IP地址而不是根据端点组标识符来表达规则。此外，一些实施例还使用端点组来指定转发规则。当用于指定转发规则时，端点组用于在转发规则(例如，基于策略的路由规则)的匹配分类属性中指定源和/或目的地地址。

对于Kubernetes部署，一些实施例使用以下工作流来为端点组部署ClusterIP服务。最初，管理员创建端点组来描述选择器。图15图示了端点组CRD 1502和引用此CRD的API1504的示例。如图所示，API 1504具有几个规范属性，其中包括指定端点组包括VIF的vifSelector属性，这些VIF(1)是虚拟网络vnet_name的一部分，并且(2)对于labelX具有valueX。

在一些实施例中，端点组不仅根据VIF定义，而且还根据端口/协议定义。这是因为一个VM或Pod可以有多个容器，并且需要端口/协议属性来区分在VM或Pod上执行的不同容器(例如，不同的服务或计算)操作。还需要端口来在端点组上执行L4负载平衡。当端点组定义不提供端口时，在一些实施例中将默认端口指派给端点组。在图15中，端点组的规范属性定义了用于访问端点组的端口/协议。在本示例中，可以通过https TCP端口6443和DNS UDP端口5353访问端点组。

端点组的创建触发工作负载控制器在没有选择器的情况下创建KubernetesClusterIP服务。图15图示了在没有选择器的情况下API1506生成ClusterIP服务的示例。基于端点组API 1504中指定的名称和端口属性，服务创建API 1506指定服务的名称和端口属性。它还将服务类型指定为ClusterIP类型的服务。

在没有选择器的情况下创建CluserIP服务之后，工作负载控制器然后根据端点组中的选择器填写相关的Kubernetes端点信息。图15图示了提供相关Kubernetes端点信息的API 1508的示例。在这个示例中，API 1508在端点组中提供VIF的IP地址。然后管理员创建虚拟服务对象并使用端点组作为虚拟服务对象的目的地。下面将进一步描述虚拟服务对象。

该工作流可以与其它Kubernetes服务一起使用，诸如Ingress、IngressRoute、OpenShift Route、IstioVirtualService和其它负载平衡解决方案。大多数第三方解决方案允许使用服务作为目的地，并且它们可以理解Kubernetes端点。但是，除了工作负载控制器，其它现有的服务部署模块不知道选择器，也没有办法经由Kubernetes API获得选择器条件。这个问题是通过最初定义端点组来解决的。这种方法还为NSX-T提供了通过虚拟服务对象暴露更好的负载平衡体验的机会，并且还允许WCP与第三方负载平衡器集成。

VIF提供了一种将单个VM或非Kubernetes Pod暴露给外部或内部网络的方法。虚拟服务对象通过将负载重新分配到VPC网络内部或VPC网络外部的机器来暴露多个工作负载。具体而言，一些实施例使用虚拟服务对象(VSO)CRD将由VPC内部的两个或更多个机器提供的负载平衡服务或其它工作负载(例如，中间盒服务或应用层，诸如Webserver、AppServer、数据库服务器)暴露给VPC外部的机器或VPC内部的机器。由于端点组可以拥有不同类型的机器，因此VSO用于以负载平衡的方式暴露执行相同服务或计算操作的不同类型的机器。

图16图示了在一些实施例中如何使用VSO。具体而言，该图图示了当NCP 145检测到创建VSO事件时(例如，当API服务器140通知它已经接收到创建VSO的API时)NCP 145创建的VSO 1605。在一些实施例中，VSO将一个或多个L4端口集合(例如，端口范围)和/或协议映射到用于提供服务的机器的端点组。在一些实施例中，VSO API提供这种映射。图16示出了具有映射属性集合的VSO 1605，该映射属性集合将端口映射到特定端点组。

以下YAML代码中提供了VSO API指定的映射示例。

在这个示例中，VSO被称为service-1，识别暴露的端点组epp-1，并指定此端点组在TCP端口80上可达。

在一些实施例中，VSO与一个或多个负载平衡器相关联。在一些实施例中，VSO API可以指定与VSO相关联的负载平衡器集合，但是当VSO API没有指定任何负载平衡器时，控制系统100在为VPC中的端点组指定VSO时将VPC网关282的(一个或多个)负载平衡器415指定为VSO的负载平衡器，或者在为访客集群中的端点组指定VSO时将访客集群网关的(一个或多个)负载平衡器指定为VSO的负载平衡器。在图16中，VSO 1605包括负载平衡器标识符，该标识符识别负载平衡器对象1610，该负载平衡器对象1610表示VPC中的负载平衡构造1620。

NCP 145创建负载平衡对象1610来表示负载平衡元件1620，其可以是一个或多个集中式负载平衡器集合(诸如，VPC网关的负载平衡器415)或一个或多个分布式负载平衡引擎集合(诸如，负载平衡引擎815)。NCP还在VSO 1605和负载平衡对象1610之间创建关联(例如，引用)。它还在定义端点机器组1630时创建端点组对象1615，并在创建VSO 1605时在VSO1605和端点组对象1615之间创建关联(例如，引用)。

在一些实施例中，VSO API还指定虚拟服务的内部范围和/或外部范围。内部范围指定虚拟服务可用于VPC内部的机器，而外部范围指定虚拟服务可用于VPC外部的机器。在一些实施例中，网络控制系统在指定内部范围时自动为虚拟服务分配内部VIP地址，而在外部范围被定义为VSO的范围时自动为虚拟服务分配外部VIP地址。如以下通过参考图19讨论的示例性API中所指示的，当外部范围为空或指代负载平衡器时，外部VIP与由VSO或网关负载平衡器指定的负载平衡器相关联。

如图16中所示，NCP 145使用VSO 1605、负载平衡对象1610和端点组对象1615为服务分配内部VIP和/或外部VIP，并为负载平衡器集合1620生成一个或多个负载平衡规则来实现虚拟服务。每个负载平衡规则1655包括(1)匹配标准集合，其包括用于将暴露的服务映射到端点组的VIP和端口/协议集合，以及(2)动作标准集合，其包括识别由引用VSO CRD的API为虚拟服务指定的机器的端点组中的机器的一个或多个标识符(例如，端点组标识符)的集合。如图所示，负载平衡器然后使用负载平衡规则在端点组中的机器1630当中分发来自客户端机器1625的沿着与VSO 1605相关联的端口/协议寻址到VIP地址(以VIP作为其目的地IP地址)的数据消息。

对于外部范围，在一些实施例中，负载平衡规则由网关路由器(例如，VPC或GC网关路由器)或网关路由器使用的负载平衡器集合来实现。对于内部范围，在一些实施例中，负载平衡规则可以由网关路由器(例如，VPC或GC网关路由器)，或网关路由器使用的负载平衡器集合，和/或由在主机计算机上执行的负载平衡引擎以及使用虚拟服务的客户端VM和Pod实现的分布式负载平衡器来实现。在一些实施例中，VSO API指定一种或多种不同类型的负载平衡器，用于针对一种或多种不同类型的数据消息流量的虚拟服务执行负载平衡操作。在使用Kubernetes API的一些实施例中，VSO API可以使用ClusterIP和负载平衡器类型作为其指定的(一个或多个)负载平衡类型，或通过负载平衡CRD定义的负载平衡器。

图17从概念上图示了NCP 145在一些实施例中执行以部署和使用VSO的过程1700。在一些实施例中，NCP 145指导SDN控制器115(通过SDN管理器110)执行一个或多个操作以实现图17中所示的一些操作。如图所示，当API服务器140接收API以创建VSO时，过程1700开始(在1705处)。接下来，在1710处，NCP创建具有映射属性集合的VSO对象，该映射属性集合根据接收到的API中表达的映射参数集合、将一个或多个L4端口(例如，端口或端口范围)和/或协议的集合映射到提供服务的机器的端点组。

在1715处，该过程在VSO和由VSO暴露的端点组之间创建关联。在一些实施例中，该端点组在接收到的API中指定。在一些实施例中，当NCP 145接收到定义端点组的API时，它创建表示端点组的对象。由于端点组可以具有不同类型的机器，因此在一些实施例中可以使用VSO以负载平衡的方式暴露执行相同服务或计算操作的不同类型的机器。为了创建VSO和端点组之间的关联，在一些实施例中过程1700在VSO中定义了对端点组的引用。

接下来，在1720处，过程1700识别与VSO相关联的一个或多个负载平衡器集合。如上所述，在一些实施例中，VSO API指定与VSO相关联的负载平衡器集合，但是当VSO API未指定任何负载平衡器时，NCP指定(一个或多个)网关负载平衡器(例如，VPC或GC网关负载平衡器)作为VSO的负载平衡器。在1725处，该过程在VSO对象与NCP先前创建的一个或多个对象之间创建关联，以表示它识别为与VSO相关的一个或多个负载平衡器。

在1730处，过程1700取决于VSO是否具有内部范围、外部范围或两者来分配内部VIP地址和/或外部VIP地址。在一些实施例中，VSO的范围由VSO API指定。分配的VIP地址被提供给VPC的管理员和/或自动化过程，以分发给将使用VIP地址访问由VSO暴露的端点组提供的服务或计算操作的客户端侧计算机。

在分配(一个或多个)VIP地址之后，过程1700定义(在1735处)一个或多个负载平衡规则的集合，用于在相关联的端点组的成员当中分发寻址到分配的(一个或多个)VIP地址的内部和/或外部数据消息流。在一些实施例中，使用负载平衡标准集合来生成负载平衡规则，该负载平衡标准集合控制数据消息流如何在端点组当中分发。接下来，在1740处，过程1700将该负载平衡规则集合分发到在1720处识别出的负载平衡器集合，然后结束。在一些实施例中，SDN控制器周期性地收集关于端点组机器上的负载的统计数据，并且基于收集到的统计数据，不时地修改负载平衡标准，并将修改后的负载平衡标准分发给负载平衡器。

图18和19图示了VSO CRD 1800和VSO API 1900的示例。VSO CRD定义了元数据和规范部分，其中元数据属性包括名称字段，并且规范部分包括组、版本、范围、名称和子资源属性。VSO API1900指定VSO的外部范围。因为它指定特定的负载平衡器(lb-1)，因此为VSO分配的VIP附接到指定的负载平衡器。当范围未指定特定负载平衡器时，分配的VIP与集群(例如，VPC或GC)网关路由器相关联。

VSO API还指定三个不同的端口/协议集合来暴露三种不同的服务，称为serviceX、serviceY和serviceZ。所有这三种服务都可使用相同的VIP地址访问，但沿着不同的端口/协议集合。ServiceX沿着TCP端口8080暴露，serviceY沿着UDP端口5353暴露，serviceZ沿着TCP端口80、443、8000-10000暴露。

在VSO API中，(1)serviceX与Kubernetes定义的端点组相关联，该端点组通过对Kubernetes定义对象的引用来识别，(2)serviceY与称为EPA的端点组相关联，以及(3)serviceZ与称为epgB的端点组相关联。如代码中的注释中所述，在一些实施例中，端点组可以通过端点组的唯一标识符(uid)来识别；否则，它在为端点组指定的命名空间中由其名称来识别。此外，当端点组的命名空间被省略时，端点组的命名空间被假定为与VSO相同的命名空间。

一些实施例使用负载平衡器CRD来定义负载平衡器服务的配置。在一些实施例中，通过负载平衡器CRD定义的设置作为默认值应用于绑定在特定负载平衡器服务上的L4/L7路由。在一些实施例中，虚拟网络定义负载平衡器服务和网关路由器(例如，VPC网关路由器)之间的绑定。默认情况下，负载平衡器服务在一些实施例中被放置在网关路由器集群(例如，VPC网关路由器集群或GC网关路由器)上。

在一些实施例中，引用负载平衡器CRD以创建负载平衡器服务的API也可以引用虚拟网络CRD以指定负载平衡器用于该虚拟网络。如上所述，在一些实施例中，虚拟服务对象用作负载平衡器对象和端点对象之间的链接对象。在一些实施例中，负载平衡器对象可以将虚拟网络对象(例如，虚拟网络)与虚拟服务对象和端点组对象链接。

图20图示了负载平衡器CRD的示例，而图21图示了引用此类CRD以创建负载平衡器集群的API示例。此API在其元数据部分命名负载平衡集群，并在其规范部分指定许多可选属性。其中包括(1)支持http/http路由的httpConfig，(2)可以被自动分配的virtualIP，(3)用于定义与负载平衡器相关联的一个或多个端口的端口属性，以及(4)虚拟网络名称。与基于CRD创建其它扩展资源的其它API一样，负载平衡API具有定义要作为状态返回的参数的状态部分。在这个示例中，返回的状态值是与负载平衡器相关联的外部VIP。

一些实施例利用安全CRD来提供附加的方式来指定VPC或GC的安全策略。例如，一些实施例的网络控制系统使用安全策略CRD来定义用于过滤VPC网络端点之间的流量的安全规则，该安全规则可以用由引用端点组CRD的API创建的端点组来定义。在一些实施例中，端点组可以被指定为入口或出口安全规则(例如，防火墙规则)的源或目的地。在一些实施例中，此类规则由在主机计算机(例如，防火墙引擎915)和/或边缘装置上执行的分布式防火墙引擎强制执行。

在一些实施例中，端点组还可以用于指定应用通过安全策略CRD定义的安全策略的位置。图22图示了使用安全策略CRD的API的YAML示例。在这个示例中，端点组epp-2由applyToGroup字段指定为应用安全策略(称为policy-1)的位置。该策略适用于源端点组src-epp沿着TCP端口80发送到目的端点组dst-epp的数据消息。图23图示了本发明在一些实施例中的安全策略CRD。

在一些实施例中，可以通过使用选择器来定义安全策略API的applyToGroup。在一些实施例中，此类选择器的示例包括VIF选择器、Pod选择器、服务选择器等。安全策略CRD提供了动态分组的便利，因为现有解决方案需要手动将端点实例关联到安全组。在一些实施例中，安全策略CRD还支持跨通过虚拟网络CRD定义的不同虚拟网络的成员资格。在一些实施例中，安全策略CRD还支持跨不同VPC或不同GC的成员资格。因此，在一些实施例中，管理员可以使用安全策略CRD来定义两个VPC或两个GC之间的流量的入口/出口规则。在这些实施例中的一些实施例中，通过安全策略CRD创建的入口/出口防火墙规则是由分布式防火墙引擎强制执行的防火墙规则，如上所述。

图24图示了NCP 145和SDN管理器/控制器在一些实施例中执行以处理引用安全策略CRD的API的过程2400。如图所示，当API服务器140接收API并且NCP 145被通知创建安全策略事件时，过程2400开始(在2405处)。从该API中，过程2400提取(在2410和2415处)解释安全策略应用到的流的源端点和目的地端点的参数。可以根据IP和端口地址指定源端点和目的地端点。还可以根据先前指定的端点组来指定其中一个或两个端点。

如果API指定了appliedTo字段，那么过程2400识别(在2420处)安全策略的强制执行位置。接下来，在2025处，该过程用在2410和2415处识别出的源和目的地参数来制定防火墙规则。该防火墙规则具有设置为在2420处识别出的(一个或多个)强制执行位置的(一个或多个)标识符的applyTo字段(如果识别出任何这样的位置)。过程2400将指定的防火墙规则分发(在2430处)到将强制执行该规则的分布式防火墙引擎。当applyTo参数由接收到的安全策略API指定时，防火墙规则的分发是分发给落入由applyTo字段识别的强制执行位置内的更有限的分布式防火墙引擎集合。在分发防火墙规则之后，该过程然后结束。

上述图13提供了通过引用端点组标识符指定的防火墙规则的示例。具体而言，该示例示出了在防火墙规则的五元组匹配分类属性中用作目的地IP值的端点组EPGj。在一些实施例中，这样的防火墙规则将由过程2400响应于将EPGj识别为定义安全策略的目的地端点的属性的API而创建和分发。如果API指定端点组来定义安全策略的源端点属性，那么在一些实施例中生成的防火墙规则将使用该端点组作为防火墙规则的五元组匹配分类组件中的源IP字段的值。

一些实施例提供管理策略CRD作为用于定义另一种类型的安全策略的机制。在一些实施例中，这些CRD允许为整个VPC或GC定义高优先级安全策略。在一些实施例中，通过管理策略CRD定义的安全策略控制VPC和外部网络之间(例如，来自另一个VPC、来自外部IP块或来自部署VPC的可用性区域外部)的北/南流量。当集群的子网络(例如，子网络504-510)具有其自己的网关时，一些实施例使用管理策略CRD来定义应用网关强制执行的安全策略。类似地，在一些实施例中，管理策略API控制GC和GC外部机器之间的北/南流量。

在一些实施例中，通过管理策略CRD定义的策略是通过由VPC或GC网关或VPC或GC网关使用的一个或多个防火墙强制执行的防火墙规则来实现的。在一些实施例中，这与通过安全策略CRD定义的安全策略形成对比，安全策略CRD由在具有源或目的地VM和Pod的主机计算机上执行的分布式防火墙强制执行。

在一些实施例中，通过管理策略API定义的安全规则比通过Kubernetes网络策略和安全策略CRD定义的安全规则具有更高的优先级。使用管理策略CRD，VPC管理员可以为VPC显式定义来自/到另一个VPC或外部IP块的入站/出站流量，或者为GC定义来自/到另一个GC或外部IP块的入站/出站流量。一些实施例的网络控制系统利用Kubernetes RBAC(基于角色的认证控制)来确保只有VPC管理员用户可以创建、更新或删除VPC的管理策略CRD，并且只有GC管理员用户可以创建、更新、或删除GC的管理策略CRD。

图25图示了管理策略CRD的示例，而图26图示了使用管理策略CRD的API示例。如图所示，该API创建称为admin-policy-1的策略，并具有指定与称为vvpc-1的VPC相关联的appiedTo字段。在一些实施例中，applyTo值可以通过允许选择相同命名空间或不同命名空间中的构造的选择器构造(例如，vifSelector、podSelector、namespaceSelector和serviceSelector)来定义。图26中的API定义了两个安全规则，一个在进入VPC的入口路径(南侧流量)上，一个在来自VPC的出口路径(北侧流量)上。入口端安全规则指定应允许来自特定IP地址子网的所有流量，而出口安全规则规定应丢弃来自特定VPC(vvpc-2)的所有流量。

图27图示了NCP 145和SDN管理器/控制器在一些实施例中执行以处理引用管理策略CRD的API的过程2700。如图所示，当API服务器140接收到API并且NCP 145被通知创建管理策略事件时，过程2700开始(在2705处)。从该API中，过程2700提取(在2710处)与由API定义的一个安全规则相关联的参数。接下来，在2715处，该过程从这些提取的参数制定防火墙规则(例如，定义指定在图26中所示的示例中应允许来自172.168.0.1/24的所有数据消息的防火墙规则)。该策略规则用于在为其定义管理策略的VPC或GC的网关路由器处强制执行。

在2720处，过程2700确定它是否已经处理由API定义的所有安全规则。如图26中的YAML示例所示，管理策略API可以指定多个安全规则。当过程2700确定它没有处理所有安全规则时，它返回到2710以选择和处理另一个安全规则。否则，它转换到2725，在此它将(一个或多个)指定的防火墙规则分发到为其定义(一个或多个)防火墙规则的网关路由器，然后结束。

图28图示了与VPC 2810联合工作的访客集群2805的示例。在这个示例中，访客集群2805是为VPC定义的三个访客集群之一。就像可以为可用性区域中的同一实体或不同实体(不同租户)定义不同的VPC一样，可以为VPC定义不同的访客集群。在一些实施例中，不同的访客集群包括不同类型的工作负载。此外，在一些实施例中，一个或多个访客集群被定义在与对应的VPC相同的命名空间内。

如图所示，访客集群2805包括在作为访客集群的一部分的几个主机计算机上执行的几个工作负载Kubernetes Pod。在这个示例中，访客集群2805包括具有由逻辑交换机定义的多个网段的逻辑网络。访客集群2805具有主VM集群2820，其中Kubernetes API服务器在每个主VM上执行以在访客集群中部署Pod。它还具有连接到可用性区域的逻辑网关路由器2850的逻辑网关路由器2822。

在一些实施例中，这些逻辑网关路由器中的每一个以及VPC2810的逻辑网关路由器2840类似于图2的网关路由器282。由此，它们包括分布式和集中式路由组件，具有至少两对冗余的集中式路由组件。在一些实施例中，访客集群路由器2822和VPC路由器2840通过它们各自的分布式路由组件连接。VPC 2810包括具有一个或多个逻辑子网络的逻辑网络，每个逻辑子网络具有一个或多个网段，每个网段由逻辑交换机定义。在一些实施例中，GC逻辑网络是VPC逻辑网络的子网络。

VPC 2810还包括主VM集群2842，每个都类似于图1的Kubernetes主VM 135。在一些实施例中，主VM 2842通过其VNIC之一连接到管理网络2860以与SDN管理器2862通信，SDN管理器2862又与SDN控制器2864通信。SDN管理器/控制器用于为VPC部署和配置转发和服务元件。计算元件(例如，VM和非Kubernetes Pod)通过计算管理器/控制器2866进行部署。

一些实施例使用基线规则集合自动配置访客集群2805和VPC的网络元件以实现几个不同目的。这些规则可以由VPC和/或访客集群的管理员修改，但要确保所有VPC和GC的共同策略起点。例如，这些基线策略确保没有两个VPC可以交换数据消息，因为每个VPC最初都被定义为其自己的隔离租户命名空间/网络。类似地，这些策略确保没有两个GC可以交换数据消息，因为每个GC最初都被定义为其自己的隔离命名空间/网络。

图29和30图示了用于用基线规则集合配置VPC和GC网络元件的过程2900和3000。如图29中所示，过程2900最初为VPC 2810中的每个VM和非Kubernetes Pod的DFW引擎定义(在2905处)默认的包罗万象的规则，以拒绝到VM或Pod的所有入口流量。接下来，在2910处，该过程为VPC 2810中的每个VM和非Kubernetes Pod的DFW引擎定义规则以允许来自同一命名空间和VM或非Kubernetes Pod内部的数据消息。在一些实施例中，每个特定VM或非Kubernetes Pod的相同命名空间包括与特定VM或Pod相同的逻辑子网络中的机器(VM或Pod)。

在图5中所示的示例中，虚拟网络504-510每一个是一个逻辑子网络。因此，在2910处，过程2900为这些虚拟网络之一中的特定VM的特定DFW定义防火墙规则以允许来自同一虚拟网络中的其它VM或Pod的数据消息。由于在2905处定义的默认的包罗万象的规则，来自不同逻辑子网络中的Pod或VM的数据消息将默认被丢弃。与大多数其它默认规则一样，管理员可以定义规则以允许来自一个VPC逻辑子网络(例如，一个虚拟网络)的数据消息到达另一个VPC逻辑子网络(例如，另一个虚拟网络)。

在2915处，过程2900为每个主VM 2842定义DFW规则以允许入口流量允许来自所有VPC和GC机器(VM、非Kubernetes Pod和Kubernetes Pod)的流量到达主VM。这是为了允许所有机器访问主VM服务(例如，对主VM的DNS请求用于核心DNS服务2880执行)。

接下来，在2920处，定义一个或多个防火墙规则以允许来自VPC外部(例如，来自可用性区域外部)的流量从LB源IP(即网关路由器下行链路端口的IP)到达负载平衡服务。在一些实施例中，过程2900定义了允许在VPC网关路由器处的这种流量的一个规则，以及用于提供服务的负载平衡机器的DFW的DFW规则。在一些实施例中，负载平衡服务的VIP地址在VPC之外(例如，在可用性区域之外)被通告，而大多数其它内部VPC IP地址没有被通告。

在2925处，过程2900在可用性区域网关路由器(图28中的路由器2850)上配置过滤器，以防止网关路由器向其路由邻居(例如，BGP邻居)发布VPC IP子网地址。这是因为外部网络不应该知道VPC网络，除非通过VIP地址和端口公开一个或多个服务作为提供给外部机器的内部服务。

在一些实施例中，VPC 2810的网关路由器2840和GC 2805的网关路由器2822对离开可用性区域的VPC和GC的出口数据消息执行SNAT操作。如图30中所示，过程3000配置(在3005处)VPC和GC网关路由器2840和2822以将它们的路由通告给AZ网关路由器2850，以允许它们各自集群中的机器访问另一个集群中的机器。例如，在一些实施例中，VPC机器(例如，VM或Pod)通过SSH与GC机器(例如，Kube Pod)连接，用于调试目的或引导操作。在一些实施例中，VPC主VM还将管理平面数据推送到GC主VM。

在3010处，过程3000定义默认规则以拒绝访客集群2805的网关路由器2822处的所有入口流量。设置此默认规则以确保默认情况下不能在访客集群之间交换流量。但是，为了允许来自VPC机器的流量，(在3015处)定义了允许在GC网关路由器2822处来自VPC SNAT IP的入口流量的规则。此外，在3020处，该过程定义允许与GC负载平衡服务相关的GC网关路由器2822处的入口流量(例如，允许具有与GC的负载平衡服务IP匹配的目的地IP地址的数据消息)的规则。在一些实施例中，没有定义用于阻止同一访客集群中的机器(例如，Kubernetes Pod)之间的数据消息交换的默认规则。

在一些实施例中，GC可以通过该服务的VIP访问VPC负载平衡服务。在一些这样的情况下，GC的网关路由器2822对出口GC进入VPC的流量执行SNAT。但是，相反，一些实施例不对来自访问GC的负载平衡服务(例如，LB类型服务或入口)的VPC的流量执行SNAT操作。为了防止这种SNAT操作，没有将SNAT规则添加到VPC的网关路由器2840进行这种服务访问。

许多上述特征和应用被实现为被指定为记录在计算机可读存储介质(也称为计算机可读介质)上的指令集合的软件过程。当这些指令由一个或多个处理单元(例如，一个或多个处理器、处理器的核心或其它处理单元)执行时，它们使(一个或多个)处理单元执行指令中指示的动作。计算机可读介质的示例包括但不限于CD-ROM、闪存驱动器、RAM芯片、硬盘驱动器、EPROM等。计算机可读介质不包括通过无线或有线连接传递的载波和电子信号。

在本说明书中，术语“软件”意味着包括驻留在只读存储器中的固件或存储在磁存储装置中的应用，它们可以被读入到存储器中以供处理器处理。此外，在一些实施例中，多个软件发明可以被实现为更大程序的子部分，同时保留不同的软件发明。在一些实施例中，多个软件发明也可以被实现为单独的程序。最后，共同实现这里描述的软件发明的单独程序的任何组合都在本发明的范围内。在一些实施例中，当软件程序被安装以在一个或多个电子系统上操作时，定义一个或多个执行和执行软件程序的操作的特定机器实现。

图31从概念上图示了实现本发明的一些实施例的计算机系统3100。计算机系统3100可以用于实现任何上述主机、控制器和管理器。由此，它可以用于执行任何上述过程。该计算机系统包括各种类型的非暂态机器可读介质和用于各种其它类型的机器可读介质的接口。计算机系统3100包括总线3105、(一个或多个)处理单元3110、系统存储器3125、只读存储器3130、永久存储设备3135、输入设备3140和输出设备3145。

总线3105共同表示通信连接计算机系统3100的多种内部设备的所有系统、外围设备和芯片组总线。例如，总线3105将(一个或多个)处理单元3110与只读存储器3130、系统存储器3125和永久存储设备3135通信连接。

从这些各种存储器单元中，(一个或多个)处理单元3110检索要执行的指令和要处理的数据，以便执行本发明的过程。在不同的实施例中，(一个或多个)处理单元可以是单个处理器或多核处理器。只读存储器(ROM)3130存储(一个或多个)处理单元3110和计算机系统的其它模块所需的静态数据和指令。另一方面，永久存储设备3135是读写存储器设备。该设备是即使在计算机系统3100关闭时也存储指令和数据的非易失性存储器单元。本发明的一些实施例使用大容量存储设备(诸如磁盘或光盘及其对应的盘驱动器)作为永久存储设备3135。

其它实施例使用可移动存储设备(诸如软盘、闪存驱动器等)作为永久存储设备。与永久存储设备3135一样，系统存储器3125是读写存储器设备。但是，与存储设备3135不同，系统存储器是易失性读写存储器，诸如随机存取存储器。系统存储器存储处理器在运行时需要的一些指令和数据。在一些实施例中，本发明的过程存储在系统存储器3125、永久存储设备3135和/或只读存储器3130中。从这些各种存储器单元中，(一个或多个)处理单元3110检索要执行的指令和要处理的数据，以便执行一些实施例的过程。

总线3105还连接到输入和输出设备3140和3145。输入设备使用户能够向计算机系统传达信息和选择请求。输入设备3140包括字母数字键盘和定点设备(也称为“光标控制设备”)。输出设备3145显示由计算机系统生成的图像。输出设备包括打印机和显示设备，诸如阴极射线管(CRT)或液晶显示器(LCD)。一些实施例包括用作输入和输出设备的设备，诸如触摸屏。

最后，如图31中所示，总线3105还通过网络适配器(未示出)将计算机系统3100耦合到网络3165。以这种方式，计算机可以是计算机网络(诸如局域网(“LAN”)、广域网(“WAN”)或内联网)或网络的网络(诸如互联网)的一部分。计算机系统3100的任何或所有组件都可以与本发明结合使用。

一些实施例包括将计算机程序指令存储在机器可读或计算机可读介质(可替代地称为计算机可读存储介质、机器可读介质或机器可读存储介质)中的电子组件，诸如微处理器。这种计算机可读介质的一些示例包括RAM、ROM、只读紧凑盘(CD-ROM)、可记录紧凑盘(CD-R)、可重写紧凑盘(CD-RW)、只读数字多功能盘(例如，DVD-ROM、双层DVD-ROM)、各种可刻录/可重写DVD(例如，DVD-RAM、DVD-RW、DVD+RW等)、闪存(例如，SD卡、mini-SD卡、micro-SD卡等)、磁性和/或固态硬盘驱动器，只读和可记录

盘、超密度光盘、任何其它光或磁介质以及软盘。计算机可读介质可以存储可由至少一个处理单元执行并且包括用于执行各种操作的指令集合的计算机程序。计算机程序或计算机代码的示例包括机器代码，诸如由编译器产生的机器代码，以及包括由计算机、电子组件或微处理器使用解释器执行的高级代码的文件。

虽然以上讨论主要涉及执行软件的微处理器或多核处理器，但一些实施例由一个或多个集成电路执行，诸如专用集成电路(ASIC)或现场可编程门阵列(FPGA)。在一些实施例中，这样的集成电路执行存储在电路本身上的指令。

如本说明书中使用的，术语“计算机”、“服务器”、“处理器”和“存储器”均指电子或其它技术设备。这些术语不包括人或人群。出于本说明书的目的，术语“显示(display)”或“显示(displaying)”是指在电子设备上显示。如在本说明书中使用的，术语“计算机可读介质”、“计算机可读介质”和“机器可读介质”完全限于以计算机可读形式存储信息的有形物理对象。这些术语不包括任何无线信号、有线下载信号和任何其它短暂或暂时的信号。

虽然本发明已参考许多具体细节进行了描述，但本领域普通技术人员将认识到，本发明可以以其它具体形式实施而不背离本发明的精神。上面描述了几个使用某些CRD的实施例。普通技术人员将意识到其它实施例使用其它类型的CRD。例如，一些实施例使用LB监视器CRD，使得可以通过引用这种CRD的API创建负载平衡监视器。在一些实施例中，LB监视器提供统计以反映负载平衡器的使用和整体健康状况。此外，虽然上面的几个示例涉及容器Pod，但其它实施例使用Pod之外的容器。因此，本领域的普通技术人员将理解本发明不受前述说明性细节的限制，而是由所附权利要求限定。

Claims (92)

1.一种为一个或多个数据中心的集合中的机器集合部署网络元件的方法，所述方法包括

接收基于意图的API(应用编程接口)请求；

解析API请求以识别要部署的多个网络元件；

执行自动化过程以部署网络元件来定义虚拟私有云(VPC)连接逻辑网络中的多个机器，该逻辑网络将所述多个机器与数据中心集合中的其它机器隔离开，所述多个机器包括虚拟机和容器。

2.如权利要求1所述的方法，其中执行自动化过程包括使用模板来识别和部署多个网络元件以实现逻辑网络，而无需管理员在接收到API请求之后执行任何动作来指导网络元件的识别和部署。

3.如权利要求1所述的方法，其中执行自动化过程包括为VPC部署和配置网关路由器以将VPC连接到数据中心集合的网络。

4.如权利要求3所述的方法，其中配置VPC网关路由器包括将VPC网关路由器配置为与数据中心网关路由器通信以将VPC连接到数据中心集合外部的网络。

5.如权利要求3所述的方法，其中配置VPC网关路由器还包括配置VPC网关路由器与数据中心网关路由器通信，以将VPC网关连接到另一个VPC的另一个VPC网关以便将两个VPC相互连接。

6.如权利要求3所述的方法，其中配置VPC网关包括配置将由VPC网关执行的源网络地址转换(SNAT)操作，以将在VPC内使用的内部网络地址转换成一个或多个外部源网络地址的集合。

7.如权利要求6所述的方法，其中外部源网络地址是数据中心集合内的地址。

8.如权利要求6所述的方法，其中外部源网络地址是到数据中心集合外部的网络的地址。

9.如权利要求6所述的方法，其中VPC不被配置为对在VPC和部署在数据中心集合中的另一个VPC之间交换的流量执行SNAT操作。

10.如权利要求3所述的方法，其中配置VPC网关包括配置将由VPC网关对进入VPC的流量执行的负载平衡操作。

11.如权利要求10所述的方法，其中负载平衡操作执行第4层Kubernetes LB操作。

12.如权利要求10所述的方法，其中负载平衡操作执行第7层Kubernetes LB操作。

13.如权利要求1所述的方法，其中

要部署的机器的至少一个子集包括通过Kubernetes定义的容器；以及

执行自动化过程包括处理定义对Kubernetes联网要求的扩展的自定义资源定义(CRD)。

14.如权利要求1所述的方法，还包括部署机器集合以在数据中心集合中的主机计算机集合上执行。

15.如权利要求1所述的方法，其中执行自动化过程包括为VPC配置逻辑网络以将机器集合相互连接。

16.如权利要求15所述的方法，其中逻辑网络包括逻辑转发元件，并且配置逻辑网络包括配置多个物理转发元件来实现逻辑转发元件。

17.如权利要求1所述的方法，其中执行自动化过程包括配置多个物理转发元件(PFE)以实现至少第一和第二逻辑转发元件(LFE)以分别连接机器集合中的第一和第二机器子集。

18.如权利要求1所述的方法，其中执行自动化过程包括配置多个物理转发元件(PFE)以实现至少第一和第二逻辑子网络以分别连接机器集合中的第一和第二机器子集。

19.如权利要求18所述的方法，其中

第一和第二机器子集具有两种不同类型的连接性要求，并且

第一和第二逻辑子网络满足第一和第二机器子集的两种不同类型的连接性要求。

20.如权利要求19所述的方法，其中

要部署的至少一个机器子集包括通过Kubernetes定义的容器；以及

配置PFE包括处理为第一和第二逻辑子网络指定第一和第二类型的第一和第二Kubernetes自定义资源定义(CRD)。

21.如权利要求20所述的方法，其中

执行自动化过程包括为VPC部署和配置网关路由器以将VPC连接到数据中心集合的网关路由器；

第一逻辑子网络包括连接到数据中心集合的网关路由器的网关路由器，而第二逻辑子网络没有网关路由器并且连接到VPC的网关路由器。

22.如权利要求19所述的方法，其中第一机器子集的连接性要求包括要由VPC外部的机器访问的可用性，而第二机器子集的连接性要求包括与VPC外部的机器的隔离。

23.如权利要求1所述的方法，其中

API是Kubernetes API，并且机器集合包括多个容器；

接收API包括接收Kubernetes自定义资源定义(CRD)，其指定第一逻辑子网络的属性集合以连接至少一个机器子集。

24.如权利要求23所述的方法，其中Kubernetes API将机器子集与识别第一逻辑子网络的标识符相关联。

25.如权利要求23所述的方法，其中CRD包括定义第一逻辑子网络的网络类型的第一网络类型值，网络类型具有用于识别至少三个不同逻辑子网络的至少三个不同网络类型值。

26.如权利要求25所述的方法，其中逻辑子网络中的至少两个具有至少一种不同类型的网络转发元件。

27.如权利要求25所述的方法，其中网络类型包括以下中的至少三种：

默认类型，包括逻辑子网络的一个或多个网段，每个网段连接到VPC的网关路由器；

公共类型，包括逻辑子网络的单独网关路由器，该单独网关路由器连接到VPC的网关路由器并支持逻辑网络的单独路由表和服务；

高带宽类型，包括单独网关路由器，以直接连接到数据中心集合的路由器；以及

私有类型，包括逻辑子网络的在VPC内部隔离的一个或多个段。

28.一种暴露由一个或多个数据中心的集合中的机器集合提供的虚拟服务的方法，所述方法包括

通过指定用于访问虚拟服务的第4层端口集合和协议并将端口集合和协议映射到一组动态的端点机器，指定定义虚拟服务的基于意图的API(应用编程接口)请求；

为虚拟服务分配VIP(虚拟互联网协议)地址；

将一个或多个负载平衡规则的集合分发到一个或多个负载平衡器，每个分布式负载平衡规则包括(i)匹配标准集合，包括VIP、端口集合和协议，以及(ii)动作标准集合，包括识别所述一组动态的端点机器中的机器的一个或多个标识符的集合。

29.如权利要求28所述的方法，其中动作标准中的标识符集合包括识别所述一组动态的端点机器的标识符，所述负载平衡器集合将该标识符转换成端点机器的网络地址。

30.如权利要求28所述的方法，其中动作标准中的标识符集合包括识别所述一组动态的端点机器的标识符，所述负载平衡器集合将该标识符转换成端点机器的IP地址和端口地址。

31.如权利要求28所述的方法，其中动作标准中的标识符集合包括作为所述一组动态的端点机器的成员的多个机器的网络地址。

32.一种暴露由一个或多个数据中心的集合中的机器集合提供的服务的方法，所述方法包括

接收将虚拟服务定义为数据中心中的资源的自定义资源定义(CRD)；

接收引用CRD并定义由机器集合提供的虚拟服务的基于意图的API(应用编程接口)请求，该API将一个或多个端口的集合映射到机器集合；

执行自动化过程来解析API请求并处理CRD以在数据中心集合中部署虚拟服务。

33.如权利要求32所述的方法，其中执行自动化过程包括配置一个或多个负载平衡器的集合以跨机器集合分发数据消息。

34.如权利要求33所述的方法，其中

CRD进一步指定用于为虚拟服务提供负载平衡服务的负载平衡资源，

执行自动化过程还包括配置负载平衡器集合以实现用于提供负载平衡服务的负载平衡资源。

35.如权利要求34所述的方法，其中

虚拟服务由网络执行，

所述负载平衡器集合被部署在网络的北/南边缘处。

36.如权利要求33所述的方法，其中执行自动化过程还包括

为虚拟服务分配VIP(虚拟互联网协议)地址；

创建负载平衡规则，该负载平衡规则包括(i)包括VIP和端口集合的匹配标准集合，以及(ii)包括识别机器集合的一个或多个标识符的集合的动作标准集合；

向负载平衡器集合提供负载平衡规则。

37.如权利要求33所述的方法，其中CRD还将要提供虚拟服务的机器集合指定为端点组，该端点组是具有动态可调整的成员集合的一组机器。

38.如权利要求37所述的方法，其中端点组包括不同类型的机器，其包括虚拟机和容器。

39.如权利要求32所述的方法，其中CRD通过将端口集合和协议映射到机器集合来将端口集合映射到机器集合。

40.如权利要求32所述的方法，其中机器集合是工作负载机器集合，并且虚拟服务是由工作负载机器集合中的每个工作负载机器执行的一个操作。

41.如权利要求32所述的方法，其中虚拟服务是虚拟中间盒服务操作。

42.一种在一个或多个数据中心的集合中部署机器集合的方法，所述方法包括

将所述多个机器部署在执行多个转发元件的主机计算机集合上；

执行自动化过程以：

解析基于意图的API(应用编程接口)请求以配置所述多个转发元件以定义逻辑网络的逻辑转发元件(LFE)将机器集合相互连接；

部署网关路由器以将LFE连接到逻辑网络外部的网络；

配置网关路由器以执行逻辑网络的防火墙操作。

43.如权利要求42所述的方法，其中所述API是Kubernetes API，并且所述机器集合包括多个容器，所述方法包括：

接收定义对Kubernetes的安全策略扩展的属性的Kubernetes自定义资源定义(CRD)，所述API通过引用CRD来指定两个或更多个安全策略，每个安全策略将在逻辑网络元件的入口/出口节点处强制执行。

44.如权利要求42所述的方法，其中网关路由器被配置为通过接收网关路由器强制执行的防火墙规则集合来执行防火墙操作。

45.如权利要求42所述的方法，其中网关路由器被配置为通过接收将与逻辑网络相关联的流量集合重定向到一个或多个防火墙设备的集合以执行防火墙操作的规则集合来执行防火墙操作。

46.如权利要求42所述的方法，其中执行自动化过程包括在已经解析API请求之后使用模板来配置所述多个机器和转发元件，而无需管理员执行任何动作来指导配置。

47.一种为一个或多个数据中心的集合中的机器集合部署网络元件的方法，所述方法包括

接收将虚拟网络定义为数据中心中的资源的自定义资源定义(CRD)；

接收引用CRD的基于意图的API(应用编程接口)；

执行自动化过程来解析API请求并处理CRD以部署虚拟网络以连接多个机器。

48.如权利要求47所述的方法，其中自动化过程将虚拟网络部署为已经为所述多个机器定义的逻辑网络的段，所述逻辑网络将所述多个机器与数据中心集合中位于所述逻辑网络外部的其它机器隔离开。

49.如权利要求47所述的方法，其中所述多个机器包括虚拟机。

50.如权利要求47所述的方法，其中所述多个机器包括容器。

51.如权利要求47所述的方法，其中接收到的API请求是指定要部署的所述多个机器的YAML文件。

52.如权利要求47所述的方法，其中所述CRD是第一CRD，所述虚拟网络是第一网络类型的第一虚拟网络，并且所述多个机器是第一多个机器，所述方法还包括：

接收将第二虚拟网络指定为数据中心中的另一个资源的第二CRD，所述API引用第二虚拟网络资源作为用于连接第二多个机器的虚拟网络；

其中执行自动化过程包括：

部署所述第二多个机器；

配置多个物理转发元件(PFE)，在部署第一和第二多个机器的多个主机计算机上执行，以实现分别连接第一和第二多个机器的第一和第二虚拟网络，第一和第二虚拟网络用作逻辑网络的两个段。

53.如权利要求52所述的方法，其中自动化过程部署配置所述多个PFE以分别为所述第一和第二虚拟网络实现第一和第二LFE，每个LFE将一个虚拟网络实现为包括所述第一和第二虚拟网络的逻辑网络的段。

54.如权利要求52所述的方法，其中

所述第一和第二多个机器具有两种不同类型的连接性要求，以及

所述第一和第二虚拟网络满足第一和第二机器子集的所述两种不同类型的连接性要求。

55.如权利要求54所述的方法，其中所述第一和第二CRD为所述第一和第二虚拟网络指定第一和第二类型。

56.如权利要求54所述的方法，其中

执行自动化过程包括部署和配置网关路由器以将逻辑网络连接到数据中心集合的网关路由器；

所述第一虚拟网络包括连接到数据中心集合的网关路由器的网关路由器，而所述第二虚拟网络没有网关路由器并且连接到逻辑网络的网关路由器。

57.如权利要求54所述的方法，其中所述第一多个机器的连接性要求包括VPC外部的机器访问的可用性，而所述第二多个机器的连接性要求包括与VPC外部的机器的隔离。

58.如权利要求47所述的方法，其中所述CRD包括定义虚拟网络的网络类型的第一网络类型值，所述网络类型具有用于识别至少三个不同虚拟网络的至少三个不同网络类型值。

59.如权利要求58所述的方法，其中虚拟网络中的至少两个虚拟网络具有至少一种不同类型的网络转发元件。

60.如权利要求58所述的方法，其中网络类型包括以下中的至少三种：

默认类型，包括虚拟网络的一个或多个网段，每个网段连接到VPC的网关路由器；

公共类型，包括虚拟网络的单独网关路由器，该单独网关路由器连接到VPC的网关路由器并支持逻辑网络的单独路由表和服务；

高带宽类型，包括单独网关路由器，以直接连接到数据中心集合的路由器；以及

私有类型，包括虚拟网络的在VPC内部隔离的一个或多个段。

61.如权利要求47所述的方法，其中所述API是第一API，所述CRD是第一CRD，所述虚拟网络是第一网络类型的第一虚拟网络，并且所述多个机器是第一多个机器，所述方法还包括：

接收第二基于意图的分层API请求；

接收将第二虚拟网络指定为数据中心中的另一个资源的第二CRD，所述API引用第二虚拟网络资源作为用于连接第二多个机器的虚拟网络；

其中执行自动化过程包括：

部署第二多个机器；

配置多个物理转发元件(PFE)，在部署第一和第二多个机器的多个主机计算机上执行，以实现分别连接第一和第二多个机器的第一和第二虚拟网络，第一和第二虚拟网络用作逻辑网络的两个段。

62.一种在一个或多个数据中心的集合中部署机器集合的方法，所述方法包括

在执行多个转发元件的主机计算机集合上部署所述多个虚拟机(VM)；

执行一个或多个自动化过程的集合以：

解析基于意图的API(应用编程接口)请求，以为每个VM定义虚拟网络接口(VIF)；

分配多个网络地址；

将分配的多个网络地址指派给多个VIF；以及

将所述多个VIF与所述多个PFE相关联。

63.如权利要求62所述的方法，其中所述多个PFE实现逻辑网络并且分配的网络地址被分配给所述逻辑网络，所述逻辑网络将所述多个VM与数据中心集合中的不是所述逻辑网络的一部分的其它机器隔离开。

64.如权利要求63所述的方法，其中所述PFE实现跨越两个或更多个主机计算机的至少一个逻辑转发元件(LFE)。

65.如权利要求62所述的方法，其中执行自动化过程集合包括执行将两个或更多个VIF的集合中的每一个VIF与分布式负载平衡操作相关联的自动化过程，所述分布式负载平衡操作将由执行VIF的相关联VM的主机计算机上的负载平衡引擎执行。

66.如权利要求65所述的方法，其中两个或更多个主机计算机上的负载平衡引擎实现分布式逻辑负载平衡器。

67.如权利要求62所述的方法，其中

解析识别多个第一和第二类型的Pod，每个Pod包含容器；

执行自动化过程集合包括执行自动化过程的子集以：

将所述多个Pod部署在执行多个转发元件(PFE)的主机计算机集合上；

为每个第一类型的Pod定义虚拟网络接口(VIF)，每个第二类型的Pod具有一个预定义接口；

为每个第一类型的Pod的VIF指派一个分配的网络地址，并且为每个预定义接口指派一个分配的网络地址；以及

将所述多个第一类型的Pod VIF和第二类型的Pod的预定义接口与所述多个PFE相关联。

68.如权利要求62所述的方法，其中定义VIF包括处理将VIF指定为数据中心中的资源的自定义资源定义(CRD)，所述API引用所述VIF。

69.如权利要求63所述的方法，其中

所述API是为执行服务操作的多个服务机器指定要执行的ClusterIP服务的Kubernetes API；

执行自动化过程集合包括执行将两个或更多个VIF的集合中的每一个VIF与分布式负载平衡操作相关联的自动化过程，该分布式负载平衡操作将由执行VIF的相关联VM的主机计算机上的负载平衡引擎执行；

负载平衡引擎执行分布式负载平衡操作以实现所述多个服务机器的ClusterIP服务，以便将来自所述VIF集合的VM的负载分发在所述多个服务机器上。

70.如权利要求63所述的方法，其中所述逻辑网络是为虚拟私有云(VPC)定义的网络，并且分配给所述逻辑网络的网络地址是分配给VPC的地址或者是由数据中心集合使用的内部网络地址。

71.如权利要求62所述的方法，其中数据中心集合包括与由软件定义的数据中心(SDDC)接口识别的可用性区域相关联的一个或多个数据中心。

72.如权利要求62所述的方法，其中所述API请求是第一API请求，并且分配的多个网络地址来自第一子网，所述方法包括：

解析第二基于意图的分层API请求以识别要部署的新VM；

执行一个或多个自动化过程的另一个集合以：

确定没有剩余的网络地址从第一子网分配；

分配网络地址的第二子网；

在特定的主机计算机上部署新VM；

为新VM定义新虚拟网络接口(VIF)，并将新分配的第二子网中的网络地址指派给新VM的新VIF；以及

将新VIF与在所述特定主机计算机上执行的转发元件相关联。

73.如权利要求72所述的方法，其中所述转发元件包括端口，并且通过在所述VIF和所述转发元件的端口之间创建关联来将所述VIF与所述转发元件相关联。

74.如权利要求72所述的方法，其中所述多个转发元件实现逻辑网络，并且所述第一和第二子网是所述逻辑网络的第一和第二子网络。

75.如权利要求74所述的方法，其中自动化过程集合配置多个转发元件以实现建立所述第一和第二逻辑子网络的第一和第二逻辑转发元件(LFE)。

76.如权利要求75所述的方法，其中自动化过程集合配置多个转发元件以将所述第一和第二LFE连接到为所述逻辑网络部署的网关路由器。

77.如权利要求76所述的方法，其中所述网关路由器是包括多个分布式路由转发元件和集中式路由转发元件的逻辑路由器。

78.如权利要求62所述的方法，其中执行自动化过程集合包括在已经解析API请求之后使用模板来执行自动化过程而无需管理员执行任何动作。

79.一种为一个或多个数据中心的集合中的机器集合部署逻辑元件的方法，所述方法包括

接收引用自定义资源定义(CRD)的基于意图的API(应用编程接口)请求，该自定义资源定义(CRD)将端点组的定义提供为数据中心中的资源；

解析API以定义端点组包括不同类型的网络元件作为成员；

通过使用端点组的定义，执行自动化过程来解析API请求并处理CRD以定义中间盒服务操作。

80.如权利要求79所述的方法，其中所述不同类型的网络元件包括与中间盒服务操作相关联的不同类型的机器。

81.如权利要求80所述的方法，其中所述不同类型的机器是作为由一个或多个中间盒服务引擎的集合处理的数据消息的目的地的机器。

82.如权利要求81所述的方法，其中所述中间盒服务操作是负载平衡操作。

83.如权利要求81所述的方法，其中所述中间盒服务操作是防火墙操作。

84.如权利要求80所述的方法，其中所述不同类型的机器是作为由一个或多个中间盒服务引擎的集合处理的数据消息的源的机器。

85.如权利要求80所述的方法，其中所述不同类型的机器包括容器和虚拟机。

86.如权利要求80所述的方法，其中所述不同类型的机器包括由Kubernetes部署的Pod和由除Kubernetes之外的计算控制器部署的Pod。

87.如权利要求79所述的方法，其中所述不同类型的网络元件包括与和端点组相关联的虚拟网络相关联的两个或更多个网络元件类型。

88.如权利要求79所述的方法，其中所述端点组是通过选择所述不同类型的网络元件的一个或多个选择器定义的，所述选择器包括虚拟接口选择器、机器选择器、命名空间选择器和服务选择器中的一个或多个。

89.如权利要求79所述的方法，其中所述不同类型的网络元件包括与IP(互联网协议)CIDR(无类别域间路由)地址相关联的两种或更多种网络元件类型。

90.一种在一个或多个数据中心的集合中部署机器集合的方法，所述方法包括

将所述多个机器部署在执行多个转发元件的主机计算机集合上；

执行自动化过程以：

解析基于意图的API(应用编程接口)请求以配置所述多个转发元件以定义逻辑网络的逻辑转发元件(LFE)将机器集合相互连接；

配置在主机计算机集合上执行的防火墙引擎集合，以执行逻辑网络的防火墙操作。

91.如权利要求90所述的方法，其中所述API是Kubernetes API，并且所述机器集合包括多个容器，所述方法包括接收指定用于Kubernetes部署的安全网络策略的Kubernetes自定义资源定义(CRD)。

92.如权利要求90所述的方法，其中所述API是Kubernetes API，并且所述机器集合包括多个容器，所述方法包括：

接收指定要对机器集合中的机器之间交换的数据消息强制执行的安全策略的Kubernetes自定义资源定义(CRD)；

其中执行自动化过程包括处理CRD以配置防火墙引擎集合来执行防火墙操作集合。

Images