CN116467039A - 用于Kubernetes集群中的Operator容器组的分片管理方法、装置及系统 - Google Patents

Abstract

本说明书实施例提供用于Kubernetes集群中的Operator容器组的分片管理方法、装置及系统。中心管理组件将发生配置变更的分片配置信息发送给各个对应的Operator容器组中的代理容器。各个代理容器触发重启对应的控制器并拦截在控制器重启时发起的资源获取请求，对所拦截的资源获取请求进行生效资源对象范围信息注入，并且将经过生效资源对象范围信息注入后的资源获取请求发送给API服务器。API服务器根据所接收的资源获取请求中的生效资源范围信息而从资源存储系统中获取资源对象，并将所获取的资源对象返回给对应的代理容器。各个代理容器将所获取的资源对象加载到对应Operator主容器的缓存中。

Description

用于Kubernetes集群中的Operator容器组的分片管理方法、 装置及系统

技术领域

本说明书实施例通常涉及容器技术领域，尤其涉及用于Kubernetes集群中的Operator容器组的分片管理方法、装置及系统。

背景技术

随着云计算技术的发展，容器技术(比如，Docker)和基于容器技术的云资源编排调度系统得到广泛的应用，并成为行业标准。在云原生技术中，容器组(例如，Pod)是云资源编排系统的最小调度单元。一个容器组由一个或多个容器(Container)组成，并且在容器组上运行应用程序。

Kubernetes(也称为k8s)是一种面向容器技术的云资源编排调度系统，是云原生技术的基础标准。Kubernetes所提供的声明式API是云原生领域的核心能力。声明式API提供面向终态的描述，并且通过背后的Operator完成面向终态的资源或能力的交付。Operator是Kubernetes的扩展形式，其可以帮助用户以Kubernetes的声明式API风格自定义管理应用及服务。在生产实践中，Operator的运行一般采用社区的Leader-Election机制，即，实际处理k8s内资源的控制器实例只有一个。然而，单主运行的控制器无法实现负载均衡、水平扩展和版本升级直接切换，也无法实现灰度升级。随着Kubernetes规模的不断扩大，控制器的爆炸半径也跟着扩大，运行时和升级变更都面临着潜在风险。

发明内容

本说明书的实施例提供用于Kubernetes集群中的Operator容器组的分片管理方法、装置及系统。利用该分片管理方法、装置及系统，可以实现对Kubernetes集群资源的分片管理，并且在实现Operator负载均衡和水平扩展能力的同时，提高Operator的运行效率，降低Operator的启动时间和API服务器负载。

根据本说明书实施例的一个方面，提供一种用于Kubernetes集群中的Operator容器组的分片管理方法，所述分片管理办法由Operator容器组中的代理容器执行，所述分片管理办法包括：从Kubernetes集群的中心管理组件接收所述Operator容器组对应的分片配置信息，所述分片配置信息对应一个通过对Kubernetes集群中的资源对象进行划分得到的资源对象分片，并且所述分片配置信息至少包括分片配置信息的生效资源对象范围信息和应用分片配置信息的目标Operator容器组信息；重启所述Operator容器组中的Operator主容器的控制器；响应于拦截到在所述控制器重启时向API服务器发起的资源获取请求，将所述分片配置信息中的生效资源对象范围信息注入所述资源获取请求，并将经过信息注入后的资源获取请求发送给API服务器；从所述API服务器接收所述API服务器根据所接收的资源获取请求中的生效资源范围信息而从所述Kubernetes集群的资源存储系统中获取的资源对象；以及将所获取的资源对象加载到所述Operator主容器的缓存中。

可选地，在上述方面的一个示例中，所述资源对象分片以命名空间为最小资源对象单元进行划分，所述生效资源对象范围信息包括用于指示生效资源对象所在的命名空间的第一资源标签和/或用于指示基于生效资源对象所在的命名空间的命名字符串计算得到的哈希值的第二资源标签。

可选地，在上述方面的一个示例中，所述资源对象的资源标签经由所述中心管理组件注册的Webhook服务添加到所述资源对象的资源描述中。

可选地，在上述方面的一个示例中，所述Operator容器组通过下述过程创建：响应于拦截到Operator容器组创建请求，经由所述Webhook服务修改所述Operator容器组创建请求中的容器组描述文本，所述修改至少包括将代理容器注入Operator主容器以及对所述Operator主容器进行证书替换；经由所述Webhook服务将修改后的Operator容器组创建请求返回给所述API服务器；以及经由所述API服务器根据修改后的容器组描述文本创建修改后的Operator容器组，并将所创建的修改后的Operator容器组存储到所述资源存储系统中。

可选地，在上述方面的一个示例中，经由所述Webhook服务修改所述Operator容器组创建请求中的容器组描述文本包括：在所述Operator容器组中注入代理容器，并将所述Operator容器组创建请求中的初始证书挂载到所述代理容器下作为所述代理容器的授权证书；以及在所述Operator容器组的Operator主容器的对应命名空间下创建伪证书的ConfigMap，并将所述伪证书挂载到所述Operator主容器下作为所述Operator主容器的授权证书，所述伪证书的证书地址指向所述代理容器的特定端口。

可选地，在上述方面的一个示例中，所述分片管理方法还可以包括：从所述中心管理组件接收请求限流策略；以及根据所接收的请求限流策略对所述Operator容器组发起的请求进行限流处理。

可选地，在上述方面的一个示例中，所述请求限流策略可以包括：限流加熔断策略；仅限流策略；强制熔断策略；和/或强制放行策略。

可选地，在上述方面的一个示例中，所述请求限流策略可以包括：基于资源规则配置的请求限流策略；和基于请求动作和/或请求地址的请求限流策略。

根据本说明书的实施例的另一方面，提供一种用于Kubernetes集群中的Operator容器组的分片管理方法，包括：响应于资源配置中的分片配置信息发生配置变更，经由Kubernetes集群的中心管理组件将发生配置变更的分片配置信息发送给各个对应的Operator容器组中的代理容器，所述资源配置包括一个或多个分片配置信息，每个分片配置信息对应一个通过对Kubernetes集群中的资源对象进行划分得到的资源对象分片，并且所述分片配置信息至少包括分片配置信息的生效资源对象范围信息和应用分片配置信息的目标Operator容器组信息；在各个Operator容器组中的代理容器接收到分片配置信息后，经由各个代理容器重启该Operator容器组中的Operator主容器的控制器；响应于拦截到在控制器重启时向API服务器发起的资源获取请求，经由各个代理容器将所述分片配置信息中的生效资源对象范围信息注入各自拦截到的资源获取请求，并将经过信息注入后的资源获取请求发送给API服务器；经由所述API服务器根据所接收的各个资源获取请求中的生效资源范围信息而从所述Kubernetes集群的资源存储系统中获取的资源对象，并将所获取的资源对象返回给对应的代理容器；以及经由各个代理容器将所获取的资源对象加载到对应Operator主容器的缓存中。

可选地，在上述方面的一个示例中，所述分片管理方法还可以包括：响应于从API服务器获取到Operator容器组创建请求，经由所述中心管理组件注册的Webhook服务修改所述Operator容器组创建请求中的容器组描述文本，所述修改至少包括将代理容器注入Operator主容器以及对所述Operator主容器进行证书替换；经由所述Webhook服务器将修改后的Operator容器组创建请求返回给所述API服务器；以及经由所述API服务器根据修改后的容器组描述文本创建修改后的Operator容器组，并将所创建的修改后的Operator容器组存储到所述资源存储系统中。

可选地，在上述方面的一个示例中，经由所述Webhook服务修改所述Operator容器组创建请求中的容器组描述文本包括：在所述Operator容器组中注入代理容器，并将所述Operator容器组创建请求中的初始证书挂载到所述代理容器下作为所述代理容器的授权证书；以及在所述Operator容器组的Operator主容器的对应命名空间下创建伪证书的ConfigMap，并将所述伪证书挂载到所述Operator主容器下作为所述Operator主容器的授权证书，所述伪证书的证书地址指向所述代理容器的特定端口。

可选地，在上述方面的一个示例中，所述分片管理方法还可以包括：在创建Operator容器组后，经由所述中心管理组件按照下述容器组发布策略发布所创建的Operator容器组：基于资源对象分片的优先级顺序，依序发布每个资源对象分片所对应的Operator容器组；以及针对每个资源对象所对应的Operator容器组，优先升级非LeaderOperator容器组。

根据本说明书的实施例的另一方面，提供一种用于Kubernetes集群中的Operator容器组的分片管理装置，所述分片管理管理装置应用于Operator容器组中的代理容器，所述分片管理装置包括：分片配置信息接收单元，从Kubernetes集群的中心管理组件接收所述Operator容器组对应的分片配置信息，所述分片配置信息对应一个通过对Kubernetes集群中的资源对象进行划分得到的资源对象分片，并且所述分片配置信息至少包括分片配置信息的生效资源对象范围信息和应用分片配置信息的目标Operator容器组信息；控制器重启单元，重启所述Operator容器组中的Operator主容器的控制器；信息注入单元，响应于拦截到在所述控制器重启时向API服务器发起的资源获取请求，将所述分片配置信息中的生效资源对象范围信息注入所述资源获取请求，并将经过信息注入后的资源获取请求发送给API服务器；资源对象接收单元，从所述API服务器接收所述API服务器根据所接收的资源获取请求中的生效资源范围信息而从所述Kubernetes集群的资源存储系统中获取的资源对象；以及资源对象加载单元，将所获取的资源对象加载到所述Operator主容器的缓存中。

可选地，在上述方面的一个示例中，所述分片管理装置还可以包括：请求限流策略接收单元，从所述中心管理组件接收请求限流策略；以及请求限流处理单元，根据所接收的请求限流策略对所述Operator容器组发起的请求进行限流处理。

根据本说明书的实施例的另一方面，提供一种用于Kubernetes集群中的Operator容器组的分片管理系统，包括：中心管理组件，响应于资源配置文件中的分片配置信息发生配置变更，将发生配置变更的分片配置信息发送给各个对应的Operator容器组中的代理容器，所述资源配置文件包括一个或多个分片配置信息，每个分片配置信息对应一个通过对Kubernetes集群中的资源对象进行划分得到的资源对象分片，并且所述分片配置信息至少包括分片配置信息的生效资源对象范围信息和应用分片配置信息的目标Operator容器组信息；一个或多个Operator容器组，每个Operator容器组包括Operator主容器和代理容器，每个Operator主容器至少包括控制器，各个Operator容器组中的代理容器包括如上所述的分片管理装置；以及API服务器，根据所接收的各个资源获取请求中的生效资源范围信息而从所述Kubernetes集群的资源存储系统中获取的资源对象，并将所获取的资源对象返回给对应的代理容器。

可选地，在上述方面的一个示例中，所述中心管理组件注册Webhook服务。响应于拦截到Operator容器组创建请求，所述Webhook服务修改所述Operator容器组创建请求中的容器组描述文本，所述修改至少包括将代理容器注入Operator主容器以及对所述Operator主容器进行证书替换，并且将修改后的Operator容器组创建请求返回给所述API服务器，所述API服务器根据修改后的容器组描述文本创建修改后的Operator容器组，并将所创建的修改后的Operator容器组存储到所述资源存储系统中。

可选地，在上述方面的一个示例中，所述Webhook服务被配置为：在所述Operator容器组中注入代理容器，并将所述Operator容器组创建请求中的初始证书挂载到所述代理容器下作为所述代理容器的授权证书；以及在所述Operator容器组的Operator主容器的对应命名空间下创建伪证书的ConfigMap，并将所述伪证书挂载到所述Operator主容器下作为所述Operator主容器的授权证书，所述伪证书的证书地址指向所述代理容器的特定端口。

可选地，在上述方面的一个示例中，在Operator容器组创建完成后，所述中心管理组件按照下述容器组发布策略发布所创建的Operator容器组：基于资源对象分片的优先级顺序，依序发布每个资源对象分片所对应的Operator容器组；以及针对每个资源对象所对应的Operator容器组，优先升级非Leader Operator容器组。

根据本说明书的实施例的另一方面，提供一种用于Kubernetes集群中的Operator容器组的分片管理装置，包括：至少一个处理器，与所述至少一个处理器耦合的存储器，以及存储在所述存储器中的计算机程序，所述至少一个处理器执行所述计算机程序来实现如上所述的用于Kubernetes集群中的Operator容器组的分片管理方法。

根据本说明书的实施例的另一方面，提供一种用于Kubernetes集群中的Operator容器组的分片管理系统，包括：至少一个处理器，与所述至少一个处理器耦合的存储器，以及存储在所述存储器中的计算机程序，所述至少一个处理器执行所述计算机程序来实现如上所述的用于Kubernetes集群中的Operator容器组的分片管理方法。

根据本说明书的实施例的另一方面，提供一种计算机可读存储介质，其存储有可执行指令，所述指令当被执行时使得处理器执行上所述的用于Kubernetes集群中的Operator容器组的分片管理方法。

根据本说明书的实施例的另一方面，提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行来实现如上所述的用于Kubernetes集群中的Operator容器组的分片管理方法。

附图说明

通过参照下面的附图，可以实现对于本说明书内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。

图1示出了基于代理容器的Kubernetes集群架构的示例示意图。

图2示出了基于代理容器的请求处理过程的示例流程示意图。

图3示出了根据本说明书的实施例的用于Kubernetes集群中的Operator容器组的分片管理系统的示例架构图。

图4示出了根据本说明书的实施例的资源变更操作过程的示例示意图。

图5示出了根据本说明书的实施例的分片配置信息的示例示意图。

图6示出了根据本说明书的实施例的用于Kubernetes集群中的Operator容器组的分片管理过程的示例流程图。

图7示出了根据本说明书的实施例的请求注入过程的示例示意图。

图8示出了根据本说明书的实施例的Operator Pod创建过程的示例示意图。

图9示出了根据本说明书的实施例的基于请求限流策略的通信过程的示例示意图。

图10示出了根据本说明书的实施例的基于资源配置规则的请求限流配置的示例示意图。

图11示出了根据本说明书的实施例的基于请求动作和/或请求地址的请求限流配置的示例示意图。

图12示出了根据本说明书的实施例的请求限流策略配置模板的示例。

图13示出了根据本说明书的实施例的请求限流策略的示例。

图14示出了根据本说明书的实施例的Operator容器组发布过程的示例示意图。

图15示出了根据本说明书的实施例的应用于代理容器中的分片管理装置的示例方框图。

图16示出了根据本说明书的实施例的基于计算机实现的应用于代理容器中的分片管理装置的示例方框图。

图17示出了根据本说明书的实施例的基于计算机系统实现的分片管理系统的示例示意图。

具体实施方式

现在将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本说明书内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。例如，所描述的方法可以按照与所描述的顺序不同的顺序来执行，以及各个步骤可以被添加、省略或者组合。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。

如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。

本说明书中使用的流程图示出了根据本说明书中的一些实施例的系统实现的操作。应该清楚地理解，流程图的操作可以不按顺序实现。相反，操作可以以反转顺序或同时实现。此外，可以向流程图添加一个或多个其他操作，和/或可以从流程图中移除一个或多个操作。

鉴于单主运行的控制器无法实现负载均衡、水平扩展，版本升级直接切换，也无法实现灰度升级，提出了一种基于代理容器的operator管理方案。

图1示出了基于代理容器的Kubernetes集群架构100的示例示意图。

如图1所示，Kubernetes集群架构100包括至少一个Operator容器组110-1和110-2、中心管理组件120和API服务器。每个Operator容器组包括Operator主容器和代理容器。Operator主容器也可以称为Operator或Operator实例，是Kubernetes的扩展形式，可以帮助用户以Kubernetes的声明式API风格自定义来管理应用及服务。在一些实施例中，Operator主容器可以被实现为Kubernetes中面向终态处理资源的控制器(或控制器实例)。在一些实施例中，Operator主容器可以被实现为控制器和Webhook服务器。Webhook是Kubernetes中资源对象在向API服务器提交创建/更新/删除请求时的Hook钩子。Webhook也可以称为动态准入服务，是一种Kubernetes用于接收准入请求并对其进行处理的HTTP回调机制。中心管理组件120是中心化管理组件，用于实现对Operator容器组进行中心化管理。

在图1示出的Kubernetes集群架构100中，在数据平面中，通过给每个Operator实例配置一个代理容器(例如，sidecar容器)，利用代理容器，可以对Operator实例中的控制器到例如API服务器的get/list/watch/create/update/patch/delete等请求以及从API服务器到Operator所注册的Webhook服务的请求做透明代理，并经由代理容器执行规则路由、过滤、熔断、监控等工作。这些代理容器共同构成一个网络，可以拦截Operator与API服务器之间的网络通信。

在控制平面，中心管理组件120负责管理和配置代理容器112来控制Operator容器组中的控制器与API服务器(或其它服务器)之间的通信流量/数据。下面以控制器向API服务器发送List-Watch请求为例进行说明。

如图1所示，中心管理组件120将流量匹配规则下发给各个Operator容器组中的代理容器。在从API服务器接收到响应于控制器所发送的List-Watch请求而得到的List-Watch响应(包含资源对象)后，代理容器根据流量匹配规则对所接收的List-Watch响应进行过滤，只将符合流量匹配规则的资源对象返回给控制器进行处理，并不返回不符合流量匹配规则的资源对象。同时，针对不符合流量匹配规则的资源对象所执行的例如get/create/update/patch/delete等操作，控制器会返回例如NotFound的处理结果。这种流量控制策略类似于多租的隔离，控制器只能看到/操作符合流量匹配规则的资源对象。

图2示出了在上述架构下基于代理容器的请求处理过程的示例流程示意图。

如图2所示，在Operator的控制器向API服务器(或其它服务器)触发请求之后，通过防火墙iptable拦截控制器所发出的请求。请求例如可以是用于请求数据的数据处理请求，比如，用于请求数据查询、数据读写的数据处理请求等等，或者是用于获取资源对象的List-Watch请求。然后，iptable将所拦截的请求指令转发至控制器对应的代理容器。代理容器将请求指令转发至API服务器(或其它服务器)，并接收API服务器(或其它服务器)返回的请求响应。代理容器可以基于流量配置规则对所接收到的请求响应进行过滤处理得到过滤后的请求响应；然后将过滤后的请求响应发送至代理容器对应的控制器。另外，代理容器还可以基于流量配置规则执行路由、熔断、限流、监控等工作。

在API服务器(或其它服务器)向Operator中的Webhook服务发送请求之后，通过防火墙iptable拦截API服务器(或其它服务器)发出的请求。然后，iptable将所拦截的请求转发至控制器对应的代理容器。代理容器将该请求发送至对应的Webhook服务来进行处理。

在上述方案中，流量控制在代理容器侧执行，从而需要代理容器接收到响应于正常Http请求而获取的请求响应后，对请求响应内容进行过滤来实现流量控制，并没有实现彻底的请求隔离。而且，每个控制器向API服务器发起的请求依然是针对Kubernetes集群中的全量资源对象的全量List-Watch请求，从而没有减少API服务器处的负载。更严重地，在对Kubernetes集群的资源对象进行分片管理时，API服务器处的负载会加倍增加。此外，在集群资源规模庞大时，全量List-Watch请求耗时久，会导致Operator容器组的启动时间拉长。

此外，在上述方案中，只能在防火墙iptable允许编辑的情况下才能实现请求的路由转发。而在防火墙Iptable被禁用时，会导致请求无法转发到代理容器。

此外，在上述方案中，针对Http请求的请求响应的过滤依赖流量匹配规则(例如，命名空间(Namespace)列表，即，一个分片下的所有具体的Namespace)。由于流量匹配规则依赖于中心管理组件120的分发，从而使得在Kubernetes集群内的Namespace发生变更时，流量匹配规则可能还未分发到代理容器。在这种情况下，由于新的命名空间已经创建，而代理容器依然使用旧的流量规则，由此会过滤掉新的命名空间下的资源变更事件，从而导致事件丢失或者事件的重复调和，引起预期外的故障。鉴于上述，本说明书的实施例提供一种用于Kubernetes集群中的Operator容器组的分片管理方法、装置及系统。利用该分片管理方法、装置及系统，通过对Kubernetes集群中的资源对象进行资源划分，将资源划分结果按需写入资源配置文件中的分片配置信息，并将分片配置信息应用到对应Operator的控制器中，可以实现对Kubernetes集群资源的分片管理，并且在实现Operator负载均衡和水平扩展能力的同时，提高Operator的运行效率，降低Operator的启动时间和API服务器负载。

下面参照附图描述根据本说明书的实施例的用于Kubernetes集群中的Operator容器组的分片管理方法、装置及系统。

图3示出了根据本说明书的实施例的用于Kubernetes集群中的Operator容器组的分片管理系统300的示例架构图。

如图3所示，分片管理系统300包括中心管理组件310、一个或多个Operator容器组320和API服务器330。每个Operator容器组320包括Operator主容器和代理容器。Operator主容器也可以称为Operator或Operator实例。Operator主容器至少包括控制器(k8s控制器)。在一些实施例中，Operator主容器可以包括控制器和Webhook服务。

中心管理组件310用于监测资源配置中的分片配置信息是否发生配置变更。如图3所示，资源配置(VirtualAPP)可以包括一个或多个分片配置信息，每个分片配置信息对应一个资源分片。资源分片通过对Kubernetes集群中的资源对象进行划分得到。资源对象可以包括所有Kubernetes原生资源(比如，Pod、Service、Deployment、ConfigMap等)以及用户自定义资源。

在一些实施例中，在对Kubernetes集群内的资源对象进行资源划分时，以每个Namespace为最小资源对象单元来进行分组，从而确保对Kubernetes集群内的资源对象进行均匀划分。对于Kubernetes内任意Namespace维度的资源对象，如果对该资源对象执行任意变更操作，例如，集群资源(yaml)被Kubernetes集群内的各种控制方管理和修改，则会访问中心管理组件所注册的Webhook服务，并由Webhook服务在资源对象的资源标签中添加以下两种资源标签：(1)

ctrlmesh.cafe.cloud.alipay.com/namespace＝${namespace} ， 和 (2)ctrlmesh.cafe.cloud.alipay.com/origin-sharding＝${hashID}。其中，${namespace}表示资源的当前命名空间；以及${hashID}为根据命名空间的命名字符串计算得到的哈希值，例如，通过DJBX33A算法计算得到的哈希值，其类型可以为整数(0,31)。

图4示出了根据本说明书的实施例的资源变更操作过程的示例示意图。

如图4所示，在资源对象的变更请求(Create/Update/Patch)发送给API服务器后，API服务器会访问中心管理组件预先注册的修改性质的Webhook(Mutating Webhook)服务来修改变更资源对象。变更资源对象的修改内容例如可以包括但不限于添加新的资源标签或者替换原有资源标签。Webhook服务是一种用于接收准入请求并对其进行处理的HTTP回调机制。可以定义两种类型的准入Webhook，即验证性质的准入Webhook和修改性质的准入Webhook。修改性质的准入Webhook会先被调用。它们可以更改发送到API服务器的对象以执行自定义的设置默认值操作。

例如，API服务器向Webhook服务发送修改性质的准入请求。在接收到修改性质的准入请求后，Webhook服务解析请求内容，并根据解析结果修改资源描述中的资源标签，例如，添加新的资源标签或者替换原有资源标签。随后，Webhook服务将修改后的资源描述返回给API服务器。API服务器将修改后的资源描述保存到资源存储系统中，由此完成资源变更操作。资源存储系统例如可以被实现为ETCD。ETCD是采用Go语言编写的一个分布式key-value存储系统。它通过Raft协议进行leader选举和数据备份，对外提供高可用的数据存储，能有效应对网络问题和机器故障带来的数据丢失问题。同时，ETCD还可以提供服务发现、分布式锁、分布式数据队列、分布式通知和协调、集群选举等功能。在Kubernetes集群中，ETCD用于存储Kubernetes集群中的资源对象，比如，Kubernetes集群配置、容器组描述、网络服务、Kubernetes集群中运行的工作负载的状态信息等。

此外，为了规避特殊命名空间(比如kube-system、default等)，可以通过配置的方式避免Webhook服务拦截从而进行隔离。

分片配置信息至少包括分片配置信息的生效资源范围信息和应用分片配置信息的目标Operator容器组信息。分片配置信息的生效资源范围信息用于指示该分片配置信息所涉及的资源对象。在一些实施例中，生效资源范围信息可以利用资源标签选择条件(LabelSelector)来表征。应用分片配置信息的目标Operator容器组信息是指分片配置信息被应用于哪些目标Operator容器组。此外，可选地，分片配置信息还可以包括分片配置信息所关联的资源对象类型。

图5示出了根据本说明书的实施例的分片配置信息的示例示意图。

在图5的分片配置信息示例中，包括三种Selector信息，即，与分片配置所关联的资源对象类型对应的资源类型Selector信息(ObjectSelector)、与分片配置信息的生效资源范围信息对应的资源对象范围Selector信息以及与应用分片配置信息的目标operator容器组信息对应的目标Operator容器组Selector。

响应于监测到资源配置中的分片配置信息发生配置变更，中心管理组件310将发生配置变更的分片配置信息发送给各个对应的Operator容器组320中的代理容器。各个代理容器与API服务器330协作来从Kubernetes集群的ETCD中获取各自Operator容器组对应的资源对象，并将所获取的资源对象加载到各个Operator容器组中的Operator主容器的缓存中。

图6示出了根据本说明书的实施例的用于Kubernetes集群中的Operator容器组的分片管理过程600的示例流程图。

如图6所示，在601，中心管理组件310监测资源配置中的分片配置信息是否发生配置变更。响应于监测到资源配置中的分片配置信息发生配置变更，在602，中心管理组件310将发生配置变更的分片配置信息发送给各个对应的Operator容器组320中的代理容器。在一些实施例中，中心管理组件310可以对所监测到的发生配置变更的分片配置信息进行转换操作，以将分片配置信息转换为轻量信息，然后将轻量信息发送给代理容器。利用上述处理，发送给代理容器的分片配置信息可以仅仅包括资源标签信息(LabelSelector)，而无需发送详细的Namespace列表。在这种情况下，由于资源标签已经预定义，从而在namesapce发生增删时，无需进行不必要的分片配置信息重传，由此减少中心管理组件310与代理容器之间的传输流量。

在接收到发生配置变更的分片配置信息后，在603，各个代理容器触发对应Operator主容器中的控制器重启。随后，在604，各个控制器执行重启操作，并且在重启时发起List-Watch请求。List/Watch请求用于List和Watch自身所关注的资源对象，即，缓存和同步自身所关注的资源对象。控制器所发起的List/Watch请求默认是访问Kubernetes集群中的所有当前资源对象。

在605，各个代理容器拦截对应的控制器重启时发起的List/Watch请求。然后，在606，各个代理容器对所拦截的List/Watch请求执行生效资源对象范围信息信息注入，即，将分片配置信息中的生效资源对象范围信息注入资源获取请求中。例如，将图5中的与分片配置信息的生效资源范围信息对应的资源对象范围Selector信息注入到List-Watch请求中，从而使得经过信息注入后的List-Watch请求具有特定资源对象标签。在一些实施例中，生效资源对象范围Selector信息可以利用资源标签选择条件(LabelSelector)信息表示。在这种情况下，生效资源范围信息注入也可以称为LabelSelector信息注入。资源对象范围Selector信息注入可以是将整个资源对象范围Selector信息完整地注入到List-Watch请求中，或者将资源对象范围Selector信息中的关键字注入到List-Watch请求中。图7示出了根据本说明书的实施例的请求注入过程的示例示意图。

在606，各个代理容器将经过信息注入后的List-Watch请求发送给API服务器。在接收到经过信息注入后的List-Watch请求后，在607，API服务器根据经过信息注入后的List-Watch请求，向ETCD系统发起资源对象获取请求，所述资源对象获取请求具有所注入的特定资源对象标签信息。

在接收到资源对象获取请求后，在609，ETCD根据特定资源对象标签信息进行资源对象查询，从而从ETCD中检索出与特定资源对象标签信息匹配的局部资源对象，即，符合资源标签选择条件(LabelSelector)的局部资源对象。

在610，ETCD将所检索出的局部资源对象返回给API服务器。在接收到所检索出的局部资源对象后，在611，API服务器将所获取的资源对象返回给对应的代理容器。

在接收到资源对象后，612，各个代理容器将所接收的资源对象加载到对应Operator主容器的缓存中。

按照上述分片管理方案，首先对全集群资源对象进行划分，并对每个Namespace下的所有资源标记了特定资源对象标签；然后通过代理容器将资源标签选择条件LabelSelector注入到Operator发往API服务器的List/Watch请求中，从而使得API服务器从各个代理容器接收的List-Watch请求中具备该代理容器所在Operator容器组的Operator所对应的特定LabelSelector选项，由此API服务器可以从ETCD中检索出符合LabelSelector选项的局部资源对象，进而使得缓存到各个Operator的缓存中的资源对象仅仅是该Operator所关注的资源对象，由此实现对Kubernetes集群中的资源对象的分片管理。按照这种方式，API服务器所接收到的来自不同资源对象分片的请求具有不同的LabelSelector，所有分片请求的加和是整个集群的所有资源对象，从而实现了真正意义上的资源对象分片隔离。

要说明的是，在图6的示例中，以List-Watch请求作为资源获取请求的示例来说明分片管理过程。在其它实施例中，可以使用其它合适的资源获取请求。

利用这种分片管理方案，不仅可以降低Operator启动耗时，提高了运行效率，而且也可以减轻API服务器的负载。而且，由于在请求发送时已经实现了分片，从而无需再对请求响应进行过滤，由此解决了Namespace变更动态生效的问题。

此外，鉴于Operator Pod所访问的API服务器地址可以从Kubeconfig证书获取，且Kubeconfig证书的使用优先级大于ServiceAccount，所以可以通过主容器证书替换的方式来改变API服务器的访问地址。即，创建一个指向代理容器特定端口的伪证书，并将其挂载到主容器上，实现主容器与API服务器之间的请求的代理。

图8示出了根据本说明书的实施例的Operator Pod创建过程800的示例流程图。

如图8所示，在创建Operator Pod时，Kubernetes根据Statefulset服务中的Pod模板创建Pod描述，所创建的Pod描述包含在Pod创建请求中。在API服务器接收到Pod创建请求后，访问由中心管理组件注册的修改性质的Webhook服务。Webhook服务对Pod创建请求中的Pod描述进行修改。具体地，在Pod中注入代理容器，所注入的代理容器使用Pod描述中的初始授权证书来为代理容器授权。同时，在Operator主容器的对应命名空间下创建伪证书的ConfigMap，并将所创建的伪证书挂载到Operator主容器下，从而使得Operator主容器使用伪证书作为授权证书。伪证书的目标地址指向代理容器的特定端口。可选地，在进行Operator容器组创建时，还可以修改主容器KUBECONFIG环境变量和kubeconfig启动参数。

在完成上述Pod描述修改后，Webhook服务将修改后的Pod描述返回给API服务器。API服务器根据修改后的Pod描述创建修改后的Operator Pod，并将所创建的Operator Pod存储到ETCD中，由此完成Operator Pod创建过程。

在如上完成Operator Pod创建后，由于所创建的Operator主容器的授权证书地址指向代理容器的特定端口，而代理容器的授权证书地址指向目标服务器，从而使得Operator主容器所发起的请求会先发送给代理容器，然后经由代理容器转发给目标服务器。由此，即使在防火墙Iptable被禁用的情况下，也可以实现请求的无感知转发。

可选地，在一些实施例中，中心管理组件310还可以向各个Operator容器组320中的代理容器发送请求限流策略。然后，各个代理容器根据所接收的请求限流策略，对所在Operator容器组的控制器所发起的请求进行限流处理。图9示出了根据本说明书的实施例的基于请求限流策略的通信过程的示例示意图。

在一些实施例中，请求限流策略可以包括：限流加熔断策略(Norm)；仅限流策略(LimiterOnly)；强制熔断策略(ForceOpened)；和/或强制放行策略(ForceClosed)。限流加熔断策略可以是默认策略。在限流加熔断策略下，当请求达到限流值阈值后会触发熔断，拒绝后续的请求，恢复手段依赖请求恢复策略的配置。在仅限流策略下，当请求达到限流值阈值后会拒绝后续请求，待流量正常后自动恢复。在强制熔断策略下，拒绝所有请求。在强制放行策略下，放行所有请求。请求恢复策略可以包括人工恢复策略(Manual)和自动恢复策略(SleepingWindow)。在人工恢复策略下，触发熔断后，用户排查完熔断根因，自行决策恢复。在自动恢复策略下，触发熔断后，经过设定的时间窗口自动恢复，并清空历史流量状态。

在一些实施例中，针对不同类型的请求，可以存在不同的请求限流策略。请求限流策略例如可以包括：基于资源规则配置的请求限流策略；和基于请求动作和/或请求地址的请求限流策略。

对于Operator发往API服务器的请求，可以利用基于资源规则配置的请求限流策略来进行限流处理。通过资源规则配置来决定哪些具体的资源在做哪些变更时需要应用请求限流策略。资源描述可以具体到资源组、命名空间和具体资源。图10示出了根据本说明书的实施例的基于资源配置规则的请求限流配置的示例示意图。

对于Operator发往其他服务器的http请求，可以根据基于请求动作和/或请求地址的请求限流策略进行限流处理。图11示出了根据本说明书的实施例的基于请求动作和/或请求地址的请求限流配置的示例示意图。

此外，针对Operator发起的请求或动作，可以使用域名拦截策略来进行拦截。例如，可以支持黑白名单的配置方式，对特定域名以及特定访问API服务器的动作进行拦截。域名的匹配可使用精准匹配或正则匹配，从而实现对外部域名访问的精准管控。

在一些实施例中，可以使用请求限流策略配置模板来配置请求限流策略。图12示出了根据本说明书的实施例的请求限流策略配置模板的示例。

请求限流策略可以根据上述请求限流策略配置模板来配置出。图13示出了根据本说明书的实施例的请求限流策略的示例。

此外，在完成Operator容器组创建后，针对所创建的Operator容器组，中心管理组件可以基于分片情况下的容器组发布策略来进行Operator容器组发布。

具体地，在完成Operator容器组创建后，中心管理组件可以按照下述容器组发布策略发布所创建的Operaor容器组：基于资源对象分片的优先级顺序，依序发布每个资源对象分片所对应的Operator容器组；以及针对每个资源对象所对应的Operator容器组，优先升级非Leader Operator容器组。在确定资源对象分片的优先级时，灰度资源对象分片的优先级优先于常规资源对象分片。对于不同常规资源对象分片，根据资源对象分片编号确定优先级。

在一些实施例中，容器组发布策略可以是针对全资源对象分片的默认容器组发布策略，或者是针对指定资源对象分片的指定容器组发布策略。在按照容器组发布策略进行容器组发布时，通过标记的方式来指定待发布的资源对象分片，在容器组部署服务器上标记特定资源对象分片标签后，会发布具有对应标签的特定资源对象分片，在该特定资源对象分片内，依然首先基于优先级来依序发布每个指定资源对象分片所对应的Operator容器组，在每个资源对象分片内，优先发布非leader pod。在完成容器组发布后，自动清除容器组部署服务器上的特定资源对象分片标签。图14示出了根据本说明书的实施例的Operator容器组发布过程的示例示意图。

按照上述容器组发布方式，在完成Operator容器组创建后，会根据资源对象分片顺序依次发布所创建的Operator容器组，并且会自动识别当前资源对象分片内的leader容器组，由此在每个资源对象分片内，优先发布非leader容器组，从而使得在leader容器组发布后只会进行一次主备切换，由此在保证稳定性的同时提高了发布效率。

图15示出了根据本说明书的实施例的应用于代理容器中的分片管理装置1500的示例方框图。如图15所示，分片管理装置1500可以包括分片配置信息接收单元1510、控制器重启单元1520、信息注入单元1530、资源对象接收单元1540和资源对象加载单元1550。

分片配置信息接收单元1510被配置为从Kubernetes集群的中心管理组件接收Operator容器组对应的分片配置信息，所接收的分片配置信息对应一个通过对Kubernetes集群中的资源对象进行划分得到的资源对象分片，并且该分片配置信息至少包括分片配置信息的生效资源对象范围信息和应用分片配置信息的目标Operator容器组信息。

控制器重启单元1520被配置为重启对应Operator容器组中的Operator主容器的控制器。在控制器重启时会向API服务器发起资源获取请求。

信息注入单元1530被配置为响应于拦截到在控制器重启时向API服务器发起的资源获取请求，将对应分片配置信息中的生效资源对象范围信息注入资源获取请求，并将经过信息注入后的资源获取请求发送给API服务器。API服务器根据所接收的资源获取请求，向资源存储系统发起资源对象获取请求，该资源对象获取请求包括生效资源对象范围信息，由此，资源存储系统可以根据生效资源对象范围信息来获取对应的资源对象，并将所获取的资源对象返回给API服务器。API服务器将所获取的资源对象发送给代理容器的分片管理装置。

资源对象接收单元1540被配置为从API服务器接收API服务器根据所接收的资源获取请求中的生效资源范围信息而从Kubernetes集群的资源存储系统中获取的资源对象。然后，资源对象加载单元1550将所获取的资源对象加载到Operator主容器的缓存中。

可选地，分片管理装置1500还可以包括请求限流策略接收单元1560和请求限流处理单元1570。请求限流策略接收单元1560被配置为从中心管理组件接收请求限流策略。请求限流处理单元1570根据所接收的请求限流策略对Operator容器组所发起的请求进行限流处理。

如上参照图1到图15，对根据本说明书实施例的用于Kubernetes集群中的Operator容器组的分片管理方法、装置及系统进行了描述。上面的分片管理装置和分片管理系统可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。

图16示出了根据本说明书的实施例的基于计算机系统实现的分片管理装置1600的示例示意图。如图16所示，分片管理装置1600可以包括至少一个处理器1610、存储器(例如，非易失性存储器)1620、内存1630和通信接口1640，并且至少一个处理器1610、存储器1620、内存1630和通信接口1640经由总线1660连接在一起。至少一个处理器1610执行在存储器中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。

在一个实施例中，在存储器中存储计算机可执行指令，其当执行时使得至少一个处理器1610：从Kubernetes集群的中心管理组件接收Operator容器组对应的分片配置信息，分片配置信息对应一个通过对Kubernetes集群中的资源对象进行划分得到的资源对象分片，并且分片配置信息至少包括分片配置信息的生效资源对象范围信息和应用分片配置信息的目标Operator容器组信息；重启Operator容器组中的Operator主容器的控制器；响应于拦截到在控制器重启时向API服务器发起的资源获取请求，将分片配置信息中的生效资源对象范围信息注入资源获取请求，并将经过信息注入后的资源获取请求发送给API服务器；从API服务器接收API服务器根据所接收的List-Watch请求中的生效资源范围信息而从Kubernetes集群的资源存储系统中获取的资源对象；以及将所获取的资源对象加载到Operator主容器的缓存中。

应该理解，在存储器中存储的计算机可执行指令当执行时使得至少一个处理器1610进行本说明书的各个实施例中以上结合图1-图15描述的各种操作和功能。

图17示出了根据本说明书的实施例的基于计算机系统实现的分片管理系统1700的示例示意图。如图17所示，分片管理系统1700可以包括至少一个处理器1710、存储器(例如，非易失性存储器)1720、内存1730和通信接口1740，并且至少一个处理器1710、存储器1720、内存1730和通信接口1740经由总线1760连接在一起。至少一个处理器1710执行在存储器中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。

在一个实施例中，在存储器中存储计算机可执行指令，其当执行时使得至少一个处理器1710：响应于资源配置中的分片配置信息发生配置变更，经由Kubernetes集群的中心管理组件将发生配置变更的分片配置信息发送给各个对应的Operator容器组中的代理容器，资源配置包括一个或多个分片配置信息，每个分片配置信息对应一个通过对Kubernetes集群中的资源对象进行划分得到的资源对象分片，并且分片配置信息至少包括分片配置信息的生效资源对象范围信息和应用分片配置信息的目标Operator容器组信息；在各个Operator容器组中的代理容器接收到分片配置信息后，经由各个代理容器重启该Operator容器组中的Operator主容器的控制器；响应于拦截到在控制器重启时向API服务器发起的资源获取请求，经由各个代理容器将分片配置信息中的生效资源对象范围信息注入各自拦截到的资源获取请求，并将经过信息注入后的资源获取请求发送给API服务器；经由API服务器根据所接收的各个资源获取请求中的生效资源范围信息而从Kubernetes集群的资源存储系统中获取的资源对象，并将所获取的资源对象返回给对应的代理容器；以及经由各个代理容器将所获取的资源对象加载到对应Operator主容器的缓存中。

应该理解，在存储器中存储的计算机可执行指令当执行时使得至少一个处理器1710进行本说明书的各个实施例中以上结合图1-图15描述的各种操作和功能。

根据一个实施例，提供了一种比如机器可读介质(例如，非暂时性机器可读介质)的程序产品。机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本说明书的各个实施例中以上结合图1-图15描述的各种操作和功能。具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。

在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。

可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。

根据一个实施例，提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序当被处理器执行时，使得处理器执行本说明书的各个实施例中以上结合图1-图15描述的各种操作和功能。

本领域技术人员应当理解，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种变形和修改。因此，本发明的保护范围应当由所附的权利要求书来限定。

需要说明的是，上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。

以上各实施例中，硬件单元或模块可以通过机械方式或电气方式实现。例如，一个硬件单元、模块或处理器可以包括永久性专用的电路或逻辑(如专门的处理器，FPGA或ASIC)来完成相应操作。硬件单元或处理器还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体的实现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。

上面结合附图阐述的具体实施方式描述了示例性实施例，但并不表示可以实现的或者落入权利要求书的保护范围的所有实施例。在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。

本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (22)

1.一种用于Kubernetes集群中的Operator容器组的分片管理方法，所述分片管理办法由Operator容器组中的代理容器执行，所述分片管理办法包括：

从Kubernetes集群的中心管理组件接收所述Operator容器组对应的分片配置信息，所述分片配置信息对应一个通过对Kubernetes集群中的资源对象进行划分得到的资源对象分片，并且所述分片配置信息至少包括分片配置信息的生效资源对象范围信息和应用分片配置信息的目标Operator容器组信息；

重启所述Operator容器组中的Operator主容器的控制器；

响应于拦截到在所述控制器重启时向API服务器发起的资源获取请求，将所述分片配置信息中的生效资源对象范围信息注入所述资源获取请求，并将经过信息注入后的资源获取请求发送给API服务器；

从所述API服务器接收所述API服务器根据所接收的资源获取请求中的生效资源范围信息而从所述Kubernetes集群的资源存储系统中获取的资源对象；以及

将所获取的资源对象加载到所述Operator主容器的缓存中。

2.如权利要求1所述的分片管理方法，其中，所述资源对象分片以命名空间为最小资源对象单元进行划分，所述生效资源对象范围信息包括用于指示生效资源对象所在的命名空间的第一资源标签和/或用于指示基于生效资源对象所在的命名空间的命名字符串计算得到的哈希值的第二资源标签。

3.如权利要求2所述的分片管理方法，其中，所述资源对象的资源标签经由所述中心管理组件注册的Webhook服务添加到所述资源对象的资源描述中。

4.如权利要求1所述的分片管理方法，其中，所述Operator容器组通过下述过程创建：

响应于拦截到Operator容器组创建请求，经由所述Webhook服务修改所述Operator容器组创建请求中的容器组描述文本，所述修改至少包括将代理容器注入Operator主容器以及对所述Operator主容器进行证书替换；

经由所述Webhook服务将修改后的Operator容器组创建请求返回给所述API服务器；以及

经由所述API服务器根据修改后的容器组描述文本创建修改后的Operator容器组，并将所创建的修改后的Operator容器组存储到所述资源存储系统中。

5.如权利要求4所述的分片管理方法，其中，经由所述Webhook服务修改所述Operator容器组创建请求中的容器组描述文本包括：

在所述Operator容器组中注入代理容器，并将所述Operator容器组创建请求中的初始证书挂载到所述代理容器下作为所述代理容器的授权证书；以及

在所述Operator容器组的Operator主容器的对应命名空间下创建伪证书的ConfigMap，并将所述伪证书挂载到所述Operator主容器下作为所述Operator主容器的授权证书，所述伪证书的证书地址指向所述代理容器的特定端口。

6.如权利要求1所述的分片管理方法，还包括：

从所述中心管理组件接收请求限流策略；以及

根据所接收的请求限流策略对所述Operator容器组发起的请求进行限流处理。

7.如权利要求6所述的分片管理方法，其中，所述请求限流策略包括：

限流加熔断策略；

仅限流策略；

强制熔断策略；和/或

强制放行策略。

8.如权利要求6所述的分片管理方法，其中，所述请求限流策略包括：

基于资源规则配置的请求限流策略；和

基于请求动作和/或请求地址的请求限流策略。

9.一种用于Kubernetes集群中的Operator容器组的分片管理方法，包括：

响应于资源配置中的分片配置信息发生配置变更，经由Kubernetes集群的中心管理组件将发生配置变更的分片配置信息发送给各个对应的Operator容器组中的代理容器，所述资源配置包括一个或多个分片配置信息，每个分片配置信息对应一个通过对Kubernetes集群中的资源对象进行划分得到的资源对象分片，并且所述分片配置信息至少包括分片配置信息的生效资源对象范围信息和应用分片配置信息的目标Operator容器组信息；

在各个Operator容器组中的代理容器接收到分片配置信息后，经由各个代理容器重启该Operator容器组中的Operator主容器的控制器；

响应于拦截到在控制器重启时向API服务器发起的资源获取请求，经由各个代理容器将所述分片配置信息中的生效资源对象范围信息注入各自拦截到的资源获取请求，并将经过信息注入后的资源获取请求发送给API服务器；

经由所述API服务器根据所接收的各个资源获取请求中的生效资源范围信息而从所述Kubernetes集群的资源存储系统中获取的资源对象，并将所获取的资源对象返回给对应的代理容器；以及

经由各个代理容器将所获取的资源对象加载到对应Operator主容器的缓存中。

10.如权利要求9所述的分片管理方法，还包括：

响应于拦截到Operator容器组创建请求，经由所述中心管理组件注册的Webhook服务修改所述Operator容器组创建请求中的容器组描述文本，所述修改至少包括将代理容器注入Operator主容器以及对所述Operator主容器进行证书替换；

经由所述Webhook服务将修改后的Operator容器组创建请求返回给所述API服务器；以及

经由所述API服务器根据修改后的容器组描述文本创建修改后的Operator容器组，并将所创建的修改后的Operator容器组存储到所述资源存储系统中。

11.如权利要求10所述的分片管理方法，其中，经由所述Webhook服务修改所述Operator容器组创建请求中的容器组描述文本包括：

在所述Operator容器组中注入代理容器，并将所述Operator容器组创建请求中的初始证书挂载到所述代理容器下作为所述代理容器的授权证书；以及

在所述Operator容器组的Operator主容器的对应命名空间下创建伪证书的ConfigMap，并将所述伪证书挂载到所述Operator主容器下作为所述Operator主容器的授权证书，所述伪证书的证书地址指向所述代理容器的特定端口。

12.如权利要求9所述的分片管理方法，还包括：

在创建Operator容器组后，经由所述中心管理组件按照下述容器组发布策略发布所创建的Operator容器组：

基于资源对象分片的优先级顺序，依序发布每个资源对象分片所对应的Operator容器组；以及

针对每个资源对象所对应的Operator容器组，优先升级非Leader Operator容器组。

13.一种用于Kubernetes集群中的Operator容器组的分片管理装置，所述分片管理管理装置应用于Operator容器组中的代理容器，所述分片管理装置包括：

分片配置信息接收单元，从Kubernetes集群的中心管理组件接收所述Operator容器组对应的分片配置信息，所述分片配置信息对应一个通过对Kubernetes集群中的资源对象进行划分得到的资源对象分片，并且所述分片配置信息至少包括分片配置信息的生效资源对象范围信息和应用分片配置信息的目标Operator容器组信息；

控制器重启单元，重启所述Operator容器组中的Operator主容器的控制器；

信息注入单元，响应于拦截到在所述控制器重启时向API服务器发起的资源获取请求，将所述分片配置信息中的生效资源对象范围信息注入所述资源获取请求，并将经过信息注入后的资源获取请求发送给API服务器；

资源对象接收单元，从所述API服务器接收所述API服务器根据所接收的资源获取请求中的生效资源范围信息而从所述Kubernetes集群的资源存储系统中获取的资源对象；以及

资源对象加载单元，将所获取的资源对象加载到所述Operator主容器的缓存中。

14.如权利要求13所述的分片管理装置，还包括：

请求限流策略接收单元，从所述中心管理组件接收请求限流策略；以及

请求限流处理单元，根据所接收的请求限流策略对所述Operator容器组发起的请求进行限流处理。

15.一种用于Kubernetes集群中的Operator容器组的分片管理系统，包括：

中心管理组件，响应于资源配置中的分片配置信息发生配置变更，将发生配置变更的分片配置信息发送给各个对应的Operator容器组中的代理容器，所述资源配置包括一个或多个分片配置信息，每个分片配置信息对应一个通过对Kubernetes集群中的资源对象进行划分得到的资源对象分片，并且所述分片配置信息至少包括分片配置信息的生效资源对象范围信息和应用分片配置信息的目标Operator容器组信息；

一个或多个Operator容器组，每个Operator容器组包括Operator主容器和代理容器，每个Operator主容器至少包括控制器，各个Operator容器组中的代理容器包括如权利要求13或14所述的分片管理装置；以及

API服务器，根据所接收的各个资源获取请求中的生效资源范围信息而从所述Kubernetes集群的资源存储系统中获取的资源对象，并将所获取的资源对象返回给对应的代理容器。

16.如权利要求15所述的分片管理系统，其中，所述中心管理组件注册Webhook服务，响应于拦截到Operator容器组创建请求，所述Webhook服务修改所述Operator容器组创建请求中的容器组描述文本，所述修改至少包括将代理容器注入Operator主容器以及对所述Operator主容器进行证书替换，并且将修改后的Operator容器组创建请求返回给所述API服务器，

所述API服务器根据修改后的容器组描述文本创建修改后的Operator容器组，并将所创建的修改后的Operator容器组存储到所述资源存储系统中。

17.如权利要求16所述的分片管理系统，其中，所述Webhook服务被配置为：

在所述Operator容器组中注入代理容器，并将所述Operator容器组创建请求中的初始证书挂载到所述代理容器下作为所述代理容器的授权证书；以及

在所述Operator容器组的Operator主容器的对应命名空间下创建伪证书的ConfigMap，并将所述伪证书挂载到所述Operator主容器下作为所述Operator主容器的授权证书，所述伪证书的证书地址指向所述代理容器的特定端口。

18.如权利要求15所述的分片管理系统，其中，在Operator容器组创建完成后，所述中心管理组件按照下述容器组发布策略发布所创建的Operator容器组：基于资源对象分片的优先级顺序，依序发布每个资源对象分片所对应的Operator容器组；以及针对每个资源对象所对应的Operator容器组，优先升级非Leader Operator容器组。

19.一种用于Kubernetes集群中的Operator容器组的分片管理装置，包括：

至少一个处理器，

与所述至少一个处理器耦合的存储器，以及

存储在所述存储器中的计算机程序，所述至少一个处理器执行所述计算机程序来实现如权利要求1到8中任一所述的用于Kubernetes集群中的Operator容器组的分片管理方法。

20.一种用于Kubernetes集群中的Operator容器组的分片管理系统，包括：

至少一个处理器，

与所述至少一个处理器耦合的存储器，以及

存储在所述存储器中的计算机程序，所述至少一个处理器执行所述计算机程序来实现如权利要求9到12中任一所述的用于Kubernetes集群中的Operator容器组的分片管理方法。

21.一种计算机可读存储介质，其存储有可执行指令，所述指令当被执行时使得处理器执行如权利要求1到8中任一所述的用于Kubernetes集群中的Operator容器组的分片管理方法或者如权利要求9到12中任一所述的用于Kubernetes集群中的Operator容器组的分片管理方法。

22.一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行来实现如权利要求1到8中任一所述的用于Kubernetes集群中的Operator容器组的分片管理方法或者如权利要求9到12中任一所述的用于Kubernetes集群中的Operator容器组的分片管理方法。