CN117909028A - 层级式容器编排系统及容器编排方法 - Google Patents

Abstract

本说明书实施例提供一种层级式容器编排系统和容器编排方法。在该层级式容器编排系统中，从通用不可信容器编排集群中移除调度器并增加准入控制器和定制控制器来生成定制化容器编排集群，并将该定制化容器编排集群置于可信执行环境中来得到可信容器编排集群，并且对通用不可信容器编排集群中的容器运行时管理器进行功能修改来得到不可信容器编排集群，并将可信容器编排集群叠加在不可信容器编排集群之上来构建出层级式容器编排系统。在进行容器编排时，不可信容器编排集群和可信容器编排集群协作工作来实现针对容器组的安全编排，并且在进行协作工作时，对不可信容器编排集群和可信容器编排集群之间的交互信息进行隐私保护。

Description

层级式容器编排系统及容器编排方法

技术领域

本说明书实施例通常涉及云计算领域，尤其涉及层级式容器编排系统及容器编排方法。

背景技术

作为轻量级虚拟化机制，容器已经被广泛地应用于云计算系统来在共享计算集群上有效地部署计算任务。为了对容器进行灵活和高效的管理，需要沿着容器的整个生命周期进行高效的容器编排，比如，在崩溃后自动重启，软件更新滚出，可扩展调度，资源分配等。Kubernetes(K8s)集群是用于容器部署和管理的流行容器编排系统，尤其适用于多个客户同时租用的多租户场景。然而，由于通用容器编排系统通常不可信，在使用容器编排系统对具有敏感数据的容器进行容器编排时，可能会导致数据安全问题。

发明内容

本说明书实施例提供一种层级式容器编排系统及容器编排方法。在该层级式容器编排系统中，通过从通用不可信容器编排集群中移除调度器并增加准入控制器和定制控制器来生成定制化容器编排集群，并将该定制化容器编排集群置于可信执行环境中来得到可信容器编排集群，对通用不可信容器编排集群中的容器运行时管理器进行功能修改来得到不可信容器编排集群，随后将可信容器编排集群叠加在不可信容器编排集群之上来构建出层级式容器编排系统，所构建出的不可信容器编排集群和可信容器编排集群协作工作来实现针对容器组的安全编排。此外，在进行协作工作时，对不可信容器编排集群和可信容器编排集群之间的交互信息进行隐私保护。利用上述层级式容器编排系统，可以最大程度地保留不可信容器编排集群和可信容器编排集群的工作流程，并且在确保可信容器组的容器组配置信息得到隐私保护的情况下实现容器组的安全编排，同时在不可信容器编排集群实现统一资源管理。

根据本说明书的实施例的一个方面，提供一种层级式容器编排系统，包括：可信容器编排集群，包括可信控制平面节点和可信数据平面节点，所述可信控制平面节点包括可信API服务器、可信准入控制器和可信数据存储系统，所述可信数据平面节点包括可信容器组管理器、可信容器运行时管理器和可信容器运行时；以及不可信容器编排集群，包括不可信控制平面节点和不可信数据平面节点，所述不可信控制平面节点包括不可信API服务器和容器组调度器，所述不可信数据平面节点包括不可信容器组管理器、不可信容器运行时管理器和不可信容器运行时，其中，在拦截到所述可信API服务器响应于所接收的API对象部署请求而生成的第一可信容器组后，所述可信准入控制器对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组，并将所述影子容器组转发给所述不可信API服务器来经由所述调度器进行容器组调度，在所述不可信容器组管理器从所述不可信API服务器拉起所述影子容器组并分配资源后，所述不可信容器运行时管理器将调度后的影子容器组的容器组规范转发给所述可信容器组管理器，所述容器组规范包括容器组配置信息和资源分配信息，所述可信容器组管理器根据所述影子容器组的容器组配置信息从所述可信API服务器拉起所述第一可信容器组，并使用基于所接收的资源分配信息分配的资源来在所述可信容器运行时中运行所述第一可信容器组。

可选地，在上述方面的一个示例中，所述可信准入控制器对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组包括：所述可信准入控制器基于隐私保护策略来对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组。

可选地，在上述方面的一个示例中，所述可信准入控制器基于隐私保护策略来对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组包括：针对所述第一可信容器组的容器配置信息中的每个字段，所述可信准入控制器：确定该字段是否是隐私字段；响应于确定该字段是隐私字段，判断移除该字段是否会影响所述不可信容器编排集群中的不可信执行；如果判断为不影响所述不可信容器编排集群中的不可信执行，则从所述容器组配置信息中移除该字段来进行字段信息遮蔽，如果判断为影响所述不可信容器编排集群中的不可信执行，则利用不敏感数据替换该字段的字段信息来进行字段信息遮蔽。

可选地，在上述方面的一个示例中，所述可信准入控制器对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组还包括：如果确定该字段不是隐私字段，则确定该字段是否要求其他被遮蔽的API对象；如果不要求其它被遮蔽的API对象，则保留该字段；如果要求其它被遮蔽的API对象，则判断该字段的保留或移除是否会触发所述不可信容器编排集群和/或所述可信容器编排集群中的执行错误，如果判断为该字段的移除会触发所述可信容器编排集群中的执行错误，并且该字段的保留不会触发所述不可信容器编排集群中的执行错误，则保留或修改该字段的字段信息，如果判断为该字段的移除不会触发所述可信容器编排集群中的执行错误，和/或该字段的保留会触发所述不可信容器编排集群中的执行错误，则从所述容器配置信息中移除该字段。

可选地，在上述方面的一个示例中，所述可信控制平面节点还包括可信定制控制器，所述可信容器组管理器将所述影子容器组的容器组配置信息发送给所述可信API服务器，以由所述可信定制控制器根据所述影子容器组的容器组配置信息和所述可信数据存储系统中存储的所述第一可信容器组的容器组配置信息进行容器组完整性验证，并且在容器组完整性验证成功后，所述可信容器组管理器根据所接收的容器组配置信息从所述可信API服务器拉起所述第一可信容器组。

可选地，在上述方面的一个示例中，所述可信控制平面节点还包括可信定制控制器，以及所述可信准入控制器创建用于指示调度约束的容器组模板，并将所述容器组模板持久化到所述可信数据存储系统。所述不可信容器运行时管理器进一步将所述第一可信容器组的调度信息转发给所述可信容器组管理器，并且所述可信容器组管理器将所述调度信息发送给所述可信API服务器来经由所述可信定制控制器根据所述调度约束进行调度约束验证。在所述容器组完整性验证和所述调度约束验证成功后，所述可信容器组管理器根据所述影子容器组的容器组配置信息从所述可信API服务器拉起所述第一可信容器组，并使用基于所接收的资源分配信息分配的资源来在所述可信容器运行时中启动所述第一可信容器组。

可选地，在上述方面的一个示例中，在所述可信容器组管理器从所述可信API服务器拉起所述第一可信容器组之前，为所述第一可信容器组创建无限期租约。

可选地，在上述方面的一个示例中，在接收到所述API对象部署请求后，所述API服务器将所述API对象部署请求转换为API对象并生成对应的第一可信容器组，响应于所述API对象具有数据敏感性，将所述API对象和所述第一可信容器组存储到所述可信数据存储系统，或者响应于所述API对象不具有数据敏感性，将所述API对象经过加密后存储到不可信数据存储系统并且将所述第一可信容器组存储到所述可信数据存储系统。

可选地，在上述方面的一个示例中，响应于接收到用于删除第一可信容器组的第一容器组删除请求，所述可信准入控制器向所述不可信API服务器发送第二容器组删除请求，并且所述可信容器组管理器停止运行所述第一可信容器组，响应于所述第一可信容器组停止运行，所述可信API服务器删除所述第一可信容器组，响应于接收到所述第二容器组删除请求，所述不可信API服务器删除所述影子容器组，并且响应于所述影子容器组被删除，所述不可信容器组管理器针对分配给所述影子容器组的资源进行资源重声明。

根据本说明书的实施例的另一方面，提供一种多租户容器编排系统，包括：至少两个租户容器编排集群，每个租户容器编排集群包括租户可信容器编排集群，所述租户可信容器编排集群包括可信控制平面节点和可信数据平面节点，所述可信控制平面节点包括可信API服务器、可信准入控制器和可信数据存储系统，所述可信数据平面节点包括可信容器组管理器、可信容器运行时管理器和可信容器运行时；以及服务端容器编排集群，包括第一不可信控制平面节点和第一不可信数据平面节点，所述第一不可信控制平面节点包括第一不可信API服务器和容器组调度器，所述不可信数据平面节点包括第一不可信容器组管理器、不可信容器运行时管理器和不可信容器运行时，其中，在拦截到所述可信API服务器响应于租户经由安全通信信道发起的API对象部署请求而生成的第一可信容器组后，所述可信准入控制器对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组，并将所述影子容器组转发给所述不可信API服务器来经由所述调度器进行容器组调度，在所述不可信容器组管理器从所述不可信API服务器拉起所述影子容器组并分配资源后，所述不可信容器运行时管理器将调度后的影子容器组的容器组规范转发给所述可信容器组管理器，所述容器组规范包括容器组配置信息和资源分配信息，所述可信容器组管理器从所述可信API服务器拉起所述第一可信容器组，并使用基于所接收的资源分配信息分配的资源来在所述可信容器运行时中运行所述第一可信容器组。

可选地，在上述方面的一个示例中，所述第一不可信控制平面节点还包括同步器，所述不可信API服务器经由所述同步器来与所述可信准入控制器进行通信。

可选地，在上述方面的一个示例中，所述租户容器编排集群还包括位于租户可信容器编排集群和服务端容器编排集群之间的租户不可信容器编排集群，所述租户不可信容器编排集群包括第二不可信控制平面节点和第二不可信数据平面节点，所述第二不可信控制平面节点包括第二不可信API服务器，所述第二不可信数据平面节点包括第二不可信容器组管理器。所述可信准入控制器和所述第一不可信API服务器经由所述第二不可信API服务器进行通信，以及所述不可信容器运行时管理器经由所述第二不可信容器组管理器将所述调度后的第一可信容器组的容器组规范和资源分配信息发送给所述可信容器组管理器。

根据本说明书的实施例的另一方面，提供一种容器编排方法，包括：响应于可信容器编排集群中的可信API服务器接收到API对象部署请求，经由所述可信API服务器将所述API对象部署请求转换为所请求的API对象并生成对应的第一可信容器组，并将所述第一可信容器组存储到所述可信容器编排集群中的可信数据存储系统；响应于所述可信容器编排集群中的可信准入控制器拦截到所述第一可信容器组，经由所述可信准入控制器对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组，并将所述影子容器组转发给所述不可信API服务器来经由所述调度器进行容器组调度；在所述不可信容器组管理器从所述不可信API服务器拉起所述影子容器组并分配资源后，经由所述不可信容器运行时管理器将调度后的影子容器组的容器组规范转发给所述可信容器组管理器，所述容器组规范包括容器组配置信息和资源分配信息；；经由所述可信容器组管理器从所述可信API服务器拉起所述第一可信容器组，并使用基于所接收的资源分配信息分配的资源来在所述可信容器运行时中运行所述第一可信容器组。

可选地，在上述方面的一个示例中，所述容器编排方法还可以包括：响应于接收到用于删除第一可信容器组的第一容器组删除请求，经由所述可信准入控制器向所述不可信API服务器发送第二容器组删除请求，并且经由所述可信容器组管理器停止运行所述第一可信容器组；响应于所述第一可信容器组停止运行，经由所述可信API服务器删除所述第一可信容器组；响应于接收到所述第二容器组删除请求，经由所述不可信API服务器删除所述影子容器组，并且响应于所述影子容器组被删除，经由所述不可信容器组管理器针对分配给所述影子容器组的资源进行资源重声明。

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

根据本说明书的实施例的另一方面，提供一种计算机可读存储介质，其存储有计算机程序，所述计算机程序被处理器执行来实现如上所述的容器编排方法。

根据本说明书的实施例的另一方面，提供一种计算机程序产品，包括计算机程序指令，所述计算机程序指令被处理器执行来实现如上所述的容器编排方法。

附图说明

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

图1示出了通用K8s集群的示例示意图。

图2示出了根据本说明书的实施例的层级式容器编排系统的示例架构示意图。

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

图4示出了根据本说明书的实施例的可信Pod的字段遮蔽处理过程的示例流程图。

图5示出了根据本说明书的实施例的可信Pod的示例示意图。

图6示出了根据本说明书的实施例的影子Pod的示例示意图。

图7示出了根据本说明书的实施例的调度约束验证过程的示例示意图。

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

图9示出了根据本说明书的实施例的多租户容器编排系统的示例架构示意图。

图10示出了根据本说明书的实施例的多租户容器编排系统的另一示例架构示意图。

图11示出了根据本说明书的实施例的基于计算机系统实现的层级式容器编排系统的示例示意图。

具体实施方式

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

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

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

容器(Container)是与主机系统的剩余进程相隔离的一组进程。Linux内核支持利用命名空间(namespace)来实现这种隔离，并且利用控制组(Control Group，例如，cgoups)来限制该进程组所使用的资源。对于不同主机之间的容器移植性，开放容器计划(OCI，OpenContainer Initiative)创建开放标准，该开放标准包括runtime-spec(用于定义容器的行为)、image-spec(用于定义图像的格式)和distribution-spec(用于定义对注册处的推送)。高阶容器运行时(例如，Docker，containerd，CRIO)实现image-spec和distribution-spec，用于管理整个容器生命周期。例如，它们从注册处拉取OCI镜像(image)，随后将该镜像解包为OCI运行时文件系统束，包括容器的根文件系统和被称为config.json的配置文件。接着，它们调用低阶容器运行时(例如，RunC和Kata)来使用该文件系统束创建进程，低阶容器运行时用于实现runtime-spec。与基于Linux命名空间和组的RunC不同，可以使用硬件虚拟化技术进行容器隔离，由此提供更强的工作负载隔离。

随着容器规模增加，人工管理容器将不再方便，从而需要容器编排系统来进行容器编排，比如，崩溃容器的自愈，容器更新的自动滚出和回滚，节点之间的容器自动调度等。K8s集群(K8s架构)是用于部署和管理容器的主流框架，并且已经成为容器编排标准。

取代容器，k8s集群中的最小部署单元是Pod。Pod是共享网络命名空间(相同的IP地址和端口空间)、IPC命名空间和存储卷的容器集合(容器组)。Pod可以包含一个或多个容器，这些容器通常是紧密协作的应用程序组件，共享相同的生命周期和资源。K8s集群将Pod作为一个整体来进行调度和管理，这意味着Pod中的容器始终在同一个节点上运行，并且它们可以在本地进行高效通信。

K8s API是基于资源的API(RESTful API)，并且Pod是基本的API资源类型。通过利用被称为kubectl的k8s命令行工具创建Pod对象来直接部署Pod，这通常难以管理。为此，可以通过kubectl部署高级工作负载资源，比如，Deployments，StatefulSets和Jobs，这些高级工作负载资源通常代表一组异构Pod。K8s集群自动管理这些Pod，比如，针对崩溃恢复而创建新Pod等。此外，K8s集群还可以提供许多其他资源，比如，ConfigMaps和Secrets，这些资源包含Pod所使用的配置信息和敏感元数据。在本说明书中，API资源也可以称为API对象。

图1示出了通用K8s集群的示例示意图。

如图1所示，通用K8s集群包括控制平面节点和一个或多个数据平面节点。控制平面节点和数据平面节点分别可以由一个或多个数据处理设备或数据处理装置组成。控制平面节点包括API服务器、状态控制器、调度器和数据存储系统Etcd。数据平面节点包括容器组管理器Kubelet、容器运行时管理器CRI shim、容器运行时Container Runtime和网络代理Kube-proxy，并且在容器运行时中运行所启动的Pod。在一些实施例中，容器运行时管理器CRI shim也可以与容器运行时Container Runtime集成在一起。

API服务器(API Server)是K8s集群的主要接口，针对Pod的所有操作和管理都通过API服务器进行。API服务器暴露了一组RESTful API，并且允许用户通过该组API与K8s集群中的其他组件进行交互。在接收到用户经由客户端(例如，使用命令行工具kubectl)输入的API请求后，API服务器将所接收的API请求转换为内部API对象，并将API对象转发到对应的K8s组件进行处理。API服务器也负责进行认证、授权和身份验证，以确保只有经过授权的用户和组件可以访问和操作K8s集群。

状态控制器代表用于持续监测K8s集群的当前状态的控制环路，用于管理和控制K8s集群中的各种资源的状态。状态控制器通过不断地监控K8s集群中的资源状态变化，确保所期望的状态与当前状态一致。状态控制器的示例例如可以包括但不限于Deployment控制器、ReplicaSet控制器、StatefulSet控制器等。Deployment控制器用于管理应用的部署，ReplicaSet控制器用于确保指定数量的Pod副本在运行，StatefulSet控制器用于管理有状态应用的部署等。例如，在API服务器接收到StatefulSet对象并存储到数据存储系统Etcd后，监测数据存储系统Etcd的StatefulSet控制器发现创建了新的StatefulSet对象，StatefulSet控制器就通过API服务器创建对应的Pod(Pod对象)。

调度器(Scheduler)负责将Pod分配到K8s集群中的节点上运行。调度器可以基于一系列的调度策略和Pod的资源需求，选择最合适的节点来运行Pod，例如，将Pod与所选择的节点绑定。调度器监控K8s集群中的节点资源利用率和负载情况，并根据预定义的策略进行智能的调度决策。

数据存储系统Etcd是K8s集群中的分布式键值存储系统，用于存储K8s集群的状态和元数据。Etcd是非易失性数据存储系统，提供了高可用性、一致性和持久性的存储，并能够快速响应读写请求。K8s集群中的各个组件和控制器使用Etcd来存储和读取K8s集群的配置信息、状态信息和事件通知等，比如，Pod配置信息、Pod调度约束等。Etcd可以部署在控制平面节点上，或者被部署为单独的集群。在被部署为单独集群的方式下，即使整个K8s集群重启，也不会发生元数据丢失。

容器组管理器Kubelet包括Pod的整个生命周期的各种管理器，用于监测Pod的创建或删除，并且相应地运行或停止该Pod。Pod的运行或停止依赖于经由容器运行时接口(CRI)进行的与容器运行时之间的通信。CRI是插件接口，其允许容器管理器Kubelet与各种容器运行时交互而无需重新编译。在容器管理器Kubelet和容器运行时之间存在CRI shim层，例如，Contained的CRI Containerd。网络代理Kube-proxy用于维护K8s集群的外部和内部与Pod之间的通信的网络规则。

在云计算系统中，上述通用K8s集群虽然部署容易并且具有灵活扩展性，但是由于通用K8s集群通常不可信，在敏感数据必须外包给第三方公共云平台来进行处理时，存在数据隐私问题。为了在K8s集群中实现可信计算，提出了将可信执行环境(TEE，trustedexecution environments)与K8s集群结合的实现方案。

可信执行环境可以在不可信服务器中提供可信区域，并且可信区域与不可信区域利用硬件机制隔离。可信区域可以是进程(比如，Intel SGX中的可信边界(enclave))或虚拟机(比如，Intel TDX中的可信域(TD))。TEE为客户提供验证机制来验证期望代码已经被加载到可信区域。比如主机操作系统(OS)或VM管理器的潜在恶意特权软件不能损害可信区域内的数据和代码的机密性和完整性。在可信区域中，仅仅(CPU或存储器中的)易失性状态可以被保护，而非易失性存储信息通常不进行保护。支持TEE的商用CPU的示例例如可以包括但限于：ARM TrustZone，Intel SGX，AMD SEV，ARM CCA，Intel TDX等。

可信执行环境例如可以包括基于进程的可信执行环境和基于虚拟机(VM)的可信执行环境。在基于进程的可信执行环境中，将应用移植到可信执行环境中。在基于VM的可信执行环境中，对整个VM进行隔离保护，从而可以在VM中直接运行未经修改的应用。相较于基于进程的可信执行环境，基于VM的可信执行环境构建可信I/O更容易，从而更利于异构计算，由此基于VM的可信执行环境在云计算中更为优选，尤其是针对使用容器的云原生应用。

基于VM的TEE允许应用在无需修改的情况下运行。当将基于VM的TEE应用于K8s集群时，存在一体式保护方案和最小化保护方案。在比如Constellation的一体式保护方案中，使用VM TEE来封装运行敏感工作负载的每个K8s集群。按照这种保护方案，在多租户场景下，针对不同租户会发起不同的Constellation实例。对于每个租户集群，控制平面和数据平面都被封装在VM TEE中。不同的K8s集群使用不同的VM TEE，并且由此将彼此不能容易通信的控制平面分开，这会导致次优的资源调度。由于节点是这种租赁架构中的租赁硬件资源粒度，租户需要为将来的工作负载租赁较大的节点，从而使得云提供商只能将自己的有限资源出售给较少的租户，从而导致云提供商的资源欠用以及租户的不必要费用。

在比如机密容器(CoCo)的最小化保护方案中，仅仅将Pod驻存在它们自有的VMTTE中来进行保护。由于Pod运行涉及敏感数据的工作负载，而K8s框架不会直接处理该敏感数据，从而最小化保护方案被认为足够安全。然而，最小化保护方案会遭受各种攻击，比如，替换VM镜像、篡改容器镜像、修改客户代理等，从而使得难以在不对K8s架构进行重大修改的情况下解决上述问题。

鉴于上述，本说明书的实施例提供一种层级式容器编排系统(容器编排框架)。在该层级式容器编排系统中，通过从通用不可信容器编排集群中移除调度器并增加准入控制器和定制控制器来生成定制化容器编排集群，并将该定制化容器编排集群置于可信执行环境中来得到可信容器编排集群，随后将可信容器编排集群叠加在通用不可信容器编排集群之上来构建出层级式容器编排系统，并且不可信容器编排集群和可信容器编排集群协作工作来实现对容器组的安全编排。此外，在进行协作工作时，对不可信容器编排集群和可信容器编排集群之间的交互信息进行隐私保护。利用上述层级式容器编排系统，可以最大程度地保留不可信容器编排集群和可信容器编排集群的工作流程，并且在确保可信容器组的容器组配置信息得到隐私保护的情况下实现容器组的安全编排，同时在不可信容器编排集群实现统一资源管理。

下面以K8s框架为例描述根据本说明书的实施例的层级式容器编排系统以及容器编排方法。要说明的是，在其它实施例中，也可以采用其它容器编排框架来实现本说明书中描述的层级式容器编排系统。

图2示出了根据本说明书的实施例的层级式容器编排系统的示例架构示意图。

如图2所示，层级式容器编排系统包括不可信K8s集群和可信K8s集群，并且可信K8集群叠加在不可信K8s集群之上。

不可信k8集群包括不可信控制平面节点和不可信数据平面节点。不可信控制平面节点包括不可信API服务器和容器组调度器，以及不可信数据平面节点包括不可信容器组管理器Kubelet和不可信容器运行时Container Runtime。在不可信容器组管理器Kubelet和不可信容器运行时Container Runtime之间存在不可信容器运行时管理器CRI Shim，例如，Contained的CRI Containerd。在本说明书中，CRI shim可以通过对通用K8s集群中的CRI Shim进行修改得到。除了保留原有功能之外，修改后的CRI Shim还可以基于Pod配置信息进行可信Pod识别，并且在识别出可信Pod后，将所接收的Pod配置信息和资源分配信息转发给可信K8集群中的可信容器管理器delegated Kubelet。

此外，不可信K8s集群也可以包括不可信数据存储系统Etcd(不可信Etcd)。不可信Etcd用于存储不可信K8s集群的状态和元数据，比如，调度器所调度的Pod的Pod配置信息等。

在一些实施例中，不可信K8s集群可以通过对通用K8s集群进行修改得到。例如，通过对通用K8s集群中的CRI Shim进行上述修改同时保持通用K8s集群的其它组件不变来实现上述不可K8s集群。

可信K8s集群包括可信控制平面节点和可信数据平面节点。可信控制平面节点包括可信API服务器、可信准入控制器、可信定制控制器和可信数据存储系统Etcd，以及可信数据平面节点包括可信容器组管理器Kubelet、可信容器运行时管理器和可信容器运行时。在一些实施例中，可信K8s集群可以通过在通用K8s集群的控制平面节点中增加准入控制器和定制控制器并且去除调度器，随后将修改后的K8s集群置于可信执行环境中来实现。在一个示例中，例如，可以通过终止运行调度器的二进制文件来移除K8s集群中的调度器。

在如上完成针对通用K8s集群的组件修改后，为了引导可信k8s集群，可以启动一组VM TEE来充当master节点和worker节点，并且通过提供可信区域构建过程的测量值以及可信区域的初始内容(包括OS内核和K8s组件)来由用户进行验证。在用户完成验证后，可以在用户的客户端设备与所有VM TEE之间建立起安全通道，并随后将整数和密码分发给可信K8s集群中的组件来进行组件内TLS连接，由此完成可信K8s集群的创建和启动。

可信准入控制器用于拦截来自客户端设备的API请求，验证它的行为，并且基于一些规则来修改API请求中的API对象，比如，向API对象中的缺失字段填充缺省值。此外，在可信准入控制器中，还可以创建用于验证和修改的规则，比如，调度约束等。在K8s框架中，可信准入控制器可以利用Admission Webhook实现。

可信定制控制器用于实现针对API请求处理结果的验证处理，比如，Pod创建请求时的Pod完整性验证、Pod调度约束验证等。可信Etcd用于持久化经由API服务器创建的API对象和Pod对象。要说明的是，在一些实施例中，可信控制平面节点也可以不包括可信定制控制器，从而在进行Pod创建时不进行Pod完整性验证和Pod调度约束验证。

可信容器组管理器Kubelet用于从可信API服务器拉起可信Pod，并在可信容器运行中运行所拉起的可信Pod。

在可信API服务器与用户的客户端设备之间建立安全通信通道后，用户可以使用客户端设备(例如，使用命令行工具Kubectl)来经由安全通信通道向可信API服务器发送各种API请求，比如，API对象部署请求、Pod删除请求等。随后，不可信K8s集群和可信K8s集群可以协作工作来进行API请求处理，由此实现容器编排，比如，Pod创建、Pod删除等。

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

如图3所示，在接收到用户使用命令行工具Kubectl发送的API对象部署请求后，可信API服务器将所接收的API对象部署请求转换为所请求的API对象并生成对应的第一可信Pod(也可以称为Pod对象)。API对象是用于描述和操作K8s集群中的不同资源的抽象化实体，并且是通过K8s API进行的创建、更新和删除操作的基本单元。API对象定义了资源的规范、状态和元数据。通过与API对象交互，可以实现资源的自动化管理、扩展和故障恢复等操作，从而提高容器应用的可靠性和可管理性。

在一些实施例中，如果所请求的API对象是低级API对象(低级工作资源)，比如，ConfigMap等，则可信API服务器可以按照内部规则将所接收的API请求转化为内部低级API对象，并且对于会生成Pod的API对象，按照内置逻辑生成对应的第一可信Pod。如果所请求的API对象是高级API对象(高级工作资源)，比如，StatefulSet等，则可信API服务器可以按照内部规则将所接收的API请求转化为内部高级API对象，并且对于会生成Pod的API对象，经由对应的状态控制器(比如，StatefulSet控制器)按照内置逻辑生成对应的第一可信Pod。在一些实施例中，可以将所生成的API对象和Pod持久化到可信Etcd。在一些实施例中，可以基于对象分流策略，响应于所转换的API对象具有数据敏感性，将API对象和第一可信Pod持久化到可信Etcd，以及响应于所转换的API对象不具有数据敏感性，将API对象经过加密后持久化到不可信Etcd，并且将第一可信Pod持久化到可信Etcd。

可信Etcd承载其它开销，比如，对持久化数据的加密和认证、比如Merkle树的新鲜度保护、可信柜台服务的调用等。因此，需要降低对可信Etcd的访问。为此，提出了基于数据敏感性的对象分流策略。

按照对象分流策略，仅仅将具有数据敏感性的API对象和第一可信Pod持久化到可信Etcd，而对于不具有数据敏感性的API对象，比如，资源规范API和运算&维护API等，由于不存在敏感数据，从而可以不必持久化到可信Etcd中，而是在进行加密后持久化到不可信Etcd。资源规范API的示例例如可以包括但不限于ResourceQuotaSpec(用于设置每个命名空间的quota限制)和PersistentVolumeClaim(请求和声明持久化卷)。运算&维护API的示例例如可以包括但不限于Event(按照尽力而为的方式记录集群中的事件)。基于对象分流策略，可以使用API服务器的内置etcd-servers-overrides配置来将不同API对象的目的地设置到不同的Etcd集群。

在一些实施例中，为了避免给可信K8s集群部署另一不可信Etcd集群，可以再用不可信K8s集群中的不可信Etcd，并且通过设置etcd-prefix字符串标志来与不可信API对象相区分，这样可以将可信K8s集群中的所有不敏感API对象置于具有前缀路径的目录下，从而避免发生潜在冲突。

在拦截到所生成的第一可信Pod后，可信准入控制器对第一可信Pod的Pod配置信息进行字段遮蔽处理得到影子Pod(Shadow Pod)，并将Shadow Pod转发给不可信K8s集群中的不可信API服务器以供调度器来进行Pod调度。Shadow Pod是供不可信容器组管理器中管理的可信K8s集群中的Pod对象的脱敏资源消耗代表。

Pod配置信息中的字段类型各种各样，例如，包括与容器，所涉及的卷、服务账户、主机名称等有关的字段。在这些字段中，部分字段所记录的字段信息属于隐私信息，部分字段所记录的信息涉及API对象引用和资源消耗，部分字段所记录的信息涉及Pod编排配置或处理。

所生成的Shadow Pod应该确保：(1)所有隐私信息被移除或利用不敏感数据替换；(2)在Shadow Pod的生命周期期间不会触发不期望的错误(例如，如果可信Pod引用可信K8s集群中的其它API对象并且Shadow Pod保留这些引用，则由于在不可信K8s集群中不存在这些API对象而会触发资源未发现的错误)；(3)Shadow Pod自身占用最小的资源(例如，如果可信Pod需要镜像，而Shadow Pod的镜像字段没有改变，则会发生不必要的存储占用)。

在一些实施例中，可信准入控制器可以基于隐私保护策略来对第一可信Pod的Pod配置信息进行字段遮蔽处理。在一些实施例中，可信准入控制器还可以基于资源最小占用策略和/或非预期错误触发规避策略对第一可信Pod的Pod配置信息进行字段遮蔽处理。

图4示出了根据本说明书的实施例的可信Pod的字段遮蔽处理过程400的示例流程图。要说明的是，图4中示出的字段遮蔽处理过程是针对可信Pod的Pod配置信息中的一个字段的处理过程。在进行字段遮蔽处理时，需要针对Pod配置信息的所有字段执行图4所示的字段遮蔽处理过程。

如图4所示，在401，确定当前Pod字段所记录的数据是否是隐私数据，即，当前Pod字段是否是隐私字段。如果确定当前Pod字段为隐私字段，则在402，判断移除当前Pod字段是否会影响不可信K8s集群中的不可信执行。如果判断为不会影响不可信K8s集群中的不可信执行，则在403，采用移除方式进行字段信息遮蔽。例如，对于包含环境变量的敏感值的.spec.container[].env[]字段，由于其值为空不会影响不可信K8s集群中的不可信执行，从而可以采用移除方式进行字段信息遮蔽。如果判断为影响不可信K8s集群中的不可信执行，则在404，采用不敏感数据替换方式进行字段信息遮蔽。例如，对于用于指定要被拉起的镜像的required.spec.container[].image字段，由于其值为空会影响不可信K8s集群中的不可信执行，从而需要利用伪字段(例如，k8s.gcr.io/pause)替换的方式进行字段信息遮蔽。

如果确定当前Pod字段不是隐私字段，则在405，确定当前Pod字段是否要求其他被遮蔽的API对象(Shadow对象)，即，Shadow对象引用。如果不存在Shadow对象引用，比如，.spec.hostname和.spec.container[].resource等，则在406，保留当前Pod字段，以供不可信kubelet考虑当前可信Pod所占用的资源。

如果存在Shadow引用，比如，ConfigMaps字段、ServiceAccounts字段和.smetadata.namespace字段，则在407，判断当前Pod字段的保留或移除是否会触发不可信K8s集群/可信K8s集群中的执行错误。

如果判断为当前Pod字段的移除会触发可信K8s集群中的执行错误，并且当前Pod字段的保留不会触发不可信K8s集群中的执行错误，则在408，保留或修改当前Pod字段。比如，可信Pod中的.smetadata.namespace字段被使用与相同名称的Pod进行区分，从而这些字段应该保留在shadow Pod中。否则，相同名称的shadow Pod将会合并。对于namespece字段，由于namespece字段对应于Namespace对象，Namespce对象也被要求进行遮蔽，从而需要对namespace字段中的字段值进行修改。

如果判断为当前Pod字段的移除不会触发可信K8s集群中的执行错误，和/或当前Pod字段的保留会触发不可信K8s集群中的执行错误，则在409，移除当前Pod字段。比如，对于ConfigMaps字段和ServiceAccounts字段，可信K8s集群不需要它们在不可信K8s集群中的不可信执行结果，从而可以移除ConfigMaps字段和ServiceAccounts字段。

图5示出了根据本说明书的实施例的可信Pod的示例示意图，以及图6示出了根据本说明书的实施例的影子Pod的示例示意图。

此外，出于机密性和资源管理正确考虑，需要对移除或替换的字段的数量进行限制。而且，还可以增加键值对in.metdata.annotations来指示该Pod是Shadow Pod，从而容器运行时管理器CRI shim之后的容器运行时将不会在不可信K8s集群中拉起镜像。要注意的是，对于比如local的卷，由于它不会存储敏感数据，不可信K8s集群应该考虑它们消耗的资源，因此，这些字段应该保留在shadow Pod中。

在接收到影子Pod后，不可信API服务器将影子Pod持久化到不可信Etcd，并将影子Pod提供给调度器来进行容器组调度。调度器可以监控不可信K8s集群中的节点资源利用率和工作负载情况，并基于一系列的调度策略和Pod配置信息中定义的Pod资源需求，将影子Pod调度到最合适的数据平面节点来运行。例如，调度器可以根据影子Pod的资源需求、亲和性和反亲和性等策略，将影子Pod调度到可用的数据平面节点上运行。

在影子Pod被调度到可用数据平面节点后，该可用数据平面节点处的不可信Kubelet从不可信API服务器拉起影子Pod，并且为影子Pod分配资源。在从不可信Kubelet取回影子Pod的Pod配置信息和资源分配信息后，CRI Shim将影子Pod的Pod配置信息和资源分配信息转发给可信Kubelet。这里，Pod配置信息和资源分配信息可以统称为Pod规范。

在接收到影子Pod的Pod规范后，可信Kubelet将影子Pod的Pod规范中的Pod配置信息发送给可信API服务器。可信Kubelet根据影子Pod的Pod配置信息从可信API服务器拉起第一可信Pod，并基于所接收的资源分配信息来为第一可信Pod分配资源。随后，使用所分配的资源来在可信容器运行时中启动第一可信Pod。例如，可信Kubelet可以使用影子Pod的Pod配置信息中的Pod名称和Pod命名空间，从可信API服务器拉起第一可信Pod。然后，在第一可信Pod启动时填入所接收的资源分配信息(即，硬件资源分配信息)，由此使用所分配的资源来启动第一可信Pod。

在一些实施例中，可选控制平面节点可以包括可信定制控制器。可信API服务器可以将影子Pod的Pod配置信息转发给可信定制控制器。可信定制控制器从可信Etcd中取回第一可信Pod的Pod配置信息，并且使用所取回的第一可信Pod的Pod配置信息和所接收的影子Pod的Pod配置信息进行容器组完整性验证，以验证在调度过程中是否发生Pod篡改。在一些实施例中，可信定制控制器可以使用影子Pod的Pod配置信息中的Pod定义字段来进行容器组完整性验证。例如，可信定制控制器可以从影子Pod的Pod配置信息中的Pod定义字段提取出Pod名称和Pod命名空间，并基于所提取出的Pod名称和Pod命名空间来进行容器组完整性验证。

在容器组完整性验证成功后，可信Kubelet根据影子Pod的Pod配置信息从可信API服务器拉起第一可信Pod，并基于所接收的资源分配信息来为第一可信Pod分配资源。随后，使用所分配的资源来在可信容器运行时中启动第一可信Pod。例如，可信Kubelet可以使用影子Pod的Pod配置信息中的Pod名称和Pod命名空间，从可信API服务器拉起第一可信Pod。然后，在第一可信Pod启动时填入所接收的资源分配信息(即，硬件资源分配信息)，由此使用所分配的资源来启动第一可信Pod。

在从不可信K8s集群接收的影子Pod的Pod规范中，可信Kubelet主要使用Pod规范中的下述字段信息：(1)表示要启动Pod的Pod名称和命名空间字段，以及(2)用于指示分配资源的路径(例如卷)的资源分配信息字段。考虑到第一个字段信息来自不可信K8s集群，它可能会欺骗可信Kubelet运行错误的Pod。要注意的是，虽然要运行的Pod是由可信Kubelet直接从可信API服务器拉取，这样可以保证单个Pod的完整性，但是，由于调度器被布置在不可信K8s集群中，从而使得Pod编排的完整性仍然可能受到破坏，例如，启动两个具有相同名称的Pod或者不按规定的数量启动Pod，这是因为没有可信的集中组件来确保同一Pod只能被指定给一个节点。此外，每个可信Kubelet在接收到Pod配置时都会尝试独立拉取Pod，由此可能在不同的节点上生成两个相同的Pod。

为此，可以在准入控制器中创建调度约束来解决上述问题。例如，可以利用K8s框架中的自定义CRD对象来在准入控制器中定义一个额外的资源对象(例如，Pod模板)，作为Pod调度时需要遵循的调度约束(Scheduling Constraint)。例如，可以针对高级资源(高级工作负载)对多个pod的部署关系施加调度约束。所创建的容器组模板持久化到可信Etcd中，从而使得在可信Kubelet拉起可Pod时可以使用可信Etcd中存储的容器组模板来进行调度约束验证。

下面以StatefulSet对象为例说明调度约束。StatefulSet对象的调度约束主要包括以下字段：(1)StatefulSet hash；(2)Whether it is root；(3)Pods数量；(4)Pod map:id->(hash,allow_start)。

在可信准入控制器拦截到高级资源的CRUD请求时，需要创建或者删除新的调度约束。在创建调度约束时，可以根据高级资源的内容填充contraint的字段，保留Pod names等字段，以待后面拦截Pod时填充。

调度约束刚生成时，填充前三个字段。在生成Pod时，如果Pod中记载的parenthash和Pod模板中记录的StatefulSet hash对比通过，则填充Pod map为具体id->(具体hash,false)。

在可信Kubelet拉起Pod之前，可信定制控制器使用待拉起的Pod的id进行索引，并对比hash值。如果比对成功，则将allow_start设置为true。在监听到可信Kubelet监听到allow_start为true后，允许拉起Pod。

另外，高级资源在创建后依旧会面临更新操作，这会导致Pod的新增、减少或者重启。对于K8s框架中的原生资源，无论是Deployment、StatefulSet还是Pod本身，如果想升级Pod中的镜像，则k8s会销毁该Pod并重新调度和创建一个Pod。对于StatefulSet，虽然可以保持原有Pod的名字，但是实际UID及Pod IP都会发生改变。基于以上考虑，需要拦截高级资源的更新操作。

在拦截到高级资源的更新后，首先，根据Pod name和Pod namespace索引到对应的调度约束，取出其创建时填入的Pod模板的hash值和整个对象的hash值，以确定更新的内容。如果确定为更新了Pod模板，则需要重新创建调度约束，即，删除旧的调度约束并创建新的调度约束。如果更新的是Pod模板之外的字段，比如，修改的是replica字段，则不进行任何操作，转由webhook-pod对调度约束进行更新。在拦截到高级资源产生的pod时，如果调度约束中不包含这个pod，那么就将该Pod添加到调度约束中。如果已经存在了对应的pod，则利用最新的内容进行更新。

在存在调度约束的情况下，不可信CRI Shim可以进一步将第二可信容器组的调度信息转发给可信Kubelet。可信Kubelet随后将所接收的调度信息发送给可信API服务器，并由可信API服务器转发给可信定制控制器根据可信Etcd中存储的调度约束进行调度约束验证。

图7示出了根据本说明书的实施例的调度约束验证过程的示例示意图。

如图7所示，在可信准入控制器中创建用于指示调度约束的Pod模板，并将所创建的Pod模板作为一种API对象持久化到可信Etcd。Pod模板用于定义API对象(API资源)需要遵循的策略。例如，针对StatefulSet对象，可以将调度约束设置为“Server-id不可以重复有多个Mysql-0，从而保证不会存在多个Primary Server”。

在接收到API对象部署请求后，可信API服务器创建对应的可信Pod，并且经由可信准入控制器生成所创建的可信Pod的影子Pod后，将影子Pod转发到不可信K8s集群的控制平面节点中的调度器来进行Pod调度。调度后的影子Pod的Pod配置信息和调度信息由不可信Kubelet通过不可信CRI Shim传回可信Kubelet。可信Kubelet将调度信息返回给可信API服务器来转交给可信定制控制器。可信定制控制器使用可信Etcd中的Pod模板以及所接收的Pod配置信息和调度信息来进行容器组完整性验证和调度约束验证。

在容器组完整性验证和调度约束验证成功后，可信Kubelet根据影子Pod的Pod信息从可信API服务器拉起第一可信Pod，并基于所接收的资源分配信息来为第一可信Pod分配资源。随后，使用所分配的资源来在可信容器运行时中启动第一可信Pod。

在一些实施例中，在可信Kubelet从可信API服务器拉起第一可信Pod之前，可以为第一可信Pod创建无限期租约(Indefinite Leases)。在一些实施例中，仅仅在拉起第一可信Pod的Pod配置来自不可信CRI shim时，尝试创建无限期租赁，从而没有机会不正确地占用Leader节点，由此可以提升安全性和性能。上述无限期租约可以利用K8s框架中的租约(Leases)对象来实现。

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

如图8所示，响应于接收到用于删除第一可信Pod的第一Pod删除请求，可信API服务器将第一可信Pod标记为“删除(Deleting)”。可信Kubelet监测到第一可信Pod被标记为删除后，停止运行第一可信Pod，并且向可信API服务器通知第一可信Pod停止运行。在接收到第一可信Pod停止运行的通知后，API服务器删除可信Etcd中存储的第一可信Pod。

在拦截到第一Pod删除请求后，可信准入控制器向不可信API服务器发送第二Pod删除请求。响应于接收到第二Pod删除请求，不可信API服务器删除影子Pod。在监测到影子Pod被删除后，不可信Kubelet针对分配给影子Pod的资源进行资源重声明(Reclaim)，由此释放影子Pod所占用的API资源。按照这种Pod删除方式，可信K8s集群中的可信Pod删除过程不会依赖不可信K8s集群中的任何组件，从而可以实现可信Pod的安全删除。

上述参照图1到图8描述的层次式容器编排系统是应用于单租户场景的容器编排系统。要说明的是，在应用于多租户场景下，需要对图2示出的容器编排系统进行修改。

图9示出了根据本说明书的实施例的多租户容器编排系统的示例架构示意图。

如图9所示，多租户容器编排系统，包括至少两个租户容器编排集群和服务端容器编排集群。每个租户容器编排集群包括租户可信容器编排集群。租户可信容器编排集群可以包括可信控制平面节点和可信数据平面节点。可信控制平面节点包括可信API服务器、可信准入控制器、可信定制控制器和可信数据存储系统，以及可信数据平面节点包括可信Kubelet、可信容器运行时管理器和可信容器运行时。租户可信容器编排集群的结构和操作可以参考上面参照图1到图8所述的可信容器编排集群的结构和操作。

服务端容器编排集群包括第一不可信控制平面节点和第一不可信数据平面节点。第一不可信控制平面节点包括第一不可信API服务器和容器组调度器，以及不可信数据平面节点包括第一不可信Kubelet、不可信容器运行时管理器和不可信容器运行时。服务端可信容器编排集群的结构和操作可以参考上面参照图1到图8所述的不可信容器编排集群的结构和操作。

在多租户容器编排系统中，可以为每个租户定制单独的租户容器编排集群，并将所定制的租户容器编排集群以可插拔的方式叠加在服务端容器编排集群上，从而实现租户集群的灵活配置。

图10示出了根据本说明书的实施例的多租户容器编排系统的另一示例架构示意图。图10示出的多租户容器编排系统是图9示出的多租户容器编排系统的修改实施例。

与图9示出的实施例相比，在图10中示出的多租户容器编排系统中，在服务端容器编排集群中，第一不可信控制平面节点还可以包括同步器，并且不可信API服务器经由同步器来与租户可信容器编排集群中的可信准入控制器进行通信。

此外，租户容器编排集群还可以包括租户不可信容器编排集群。租户不可信容器编排集群位于租户可信容器编排集群和服务端容器编排集群之间。租户不可信容器编排集群包括第二不可信控制平面节点和第二不可信数据平面节点。第二不可信控制平面节点包括第二不可信API服务器，以及第二不可信数据平面节点包括第二不可信Kubelet。

租户可信容器编排集群中的可信准入控制器和第一不可信API服务器经由第二不可信API服务器进行通信，以及服务端容器编排集群中的不可信容器运行时管理器CRIShim经由第二不可信Kubelet将调度后的第一可信容器组的容器组规范发送给可信Kubelet。

如上参照图1到图10，对根据本说明书实施例的层级式容器编排系统、容器编排方法及多租户容器编排系统进行了描述。上述层级式容器编排系统可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。

图11示出了根据本说明书的实施例的基于计算机系统实现的层级式容器编排系统1100的示例示意图。如图11所示，层级式容器编排系统1100可以包括至少一个处理器1110、存储器(例如，非易失性存储器)1120、内存1130和通信接口1140，并且至少一个处理器1110、存储器1120、内存1130和通信接口1140经由总线1160连接在一起。至少一个处理器1110执行在存储器中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。

在一个实施例中，在存储器中存储计算机可执行指令，其当执行时使得至少一个处理器1110：响应于可信容器编排集群中的可信API服务器接收到API对象部署请求，经由可信API服务器将API对象部署请求转换为所请求的API对象并生成对应的第一可信容器组，并将第一可信容器组存储到所述可信容器编排集群中的可信数据存储系统；响应可信容器编排集群中的可信准入控制器拦截到第一可信容器组，经由可信准入控制器对第一可信容器组的容器组配置信息进行字段信息遮蔽得到第一可信容器组的影子容器组，并将影子容器组转发给不可信API服务器来经由调度器进行容器组调度；在不可信容器组管理器从不可信API服务器拉起影子容器组并分配资源后，经由不可信容器运行时管理器将调度后的影子容器组的容器组规范转发给可信容器组管理器，容器组规范包括容器组配置信息和资源分配信息；经由可信容器组管理器根据所述影子容器组的容器组配置信息从可信API服务器拉起所述第一可信容器组，并使用基于所接收的资源分配信息分配的资源来在可信容器运行时中运行第一可信容器组。

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

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

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

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

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

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

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

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

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

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

Claims (17)

1.一种层级式容器编排系统，包括：

可信容器编排集群，包括可信控制平面节点和可信数据平面节点，所述可信控制平面节点包括可信API服务器、可信准入控制器和可信数据存储系统，所述可信数据平面节点包括可信容器组管理器、可信容器运行时管理器和可信容器运行时；以及

不可信容器编排集群，包括不可信控制平面节点和不可信数据平面节点，所述不可信控制平面节点包括不可信API服务器和容器组调度器，所述不可信数据平面节点包括不可信容器组管理器、不可信容器运行时管理器和不可信容器运行时，

其中，在拦截到所述可信API服务器响应于所接收的API对象部署请求而生成的第一可信容器组后，所述可信准入控制器对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组，并将所述影子容器组转发给所述不可信API服务器来经由所述调度器进行容器组调度，

在所述不可信容器组管理器从所述不可信API服务器拉起所述影子容器组并分配资源后，所述不可信容器运行时管理器将调度后的影子容器组的容器组规范转发给所述可信容器组管理器，所述容器组规范包括容器组配置信息和资源分配信息，

所述可信容器组管理器根据所接收的容器组配置信息从所述可信API服务器拉起所述第一可信容器组，并使用基于所接收的资源分配信息分配的资源来在所述可信容器运行时中运行所述第一可信容器组。

2.如权利要求1所述的层级式容器编排系统，其中，所述可信准入控制器对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组包括：

所述可信准入控制器基于隐私保护策略来对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组。

3.如权利要求2所述的层级式容器编排系统，其中，所述可信准入控制器基于隐私保护策略来对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组包括：

针对所述第一可信容器组的容器配置信息中的每个字段，所述可信准入控制器：

确定该字段是否是隐私字段；

响应于确定该字段是隐私字段，判断移除该字段是否会影响所述不可信容器编排集群中的不可信执行；

如果判断为不影响所述不可信容器编排集群中的不可信执行，则从所述容器组配置信息中移除该字段来进行字段信息遮蔽，

如果判断为影响所述不可信容器编排集群中的不可信执行，则利用不敏感数据替换该字段的字段信息来进行字段信息遮蔽。

4.如权利要求3所述的层级式容器编排系统，其中，所述可信准入控制器对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组还包括：

如果确定该字段不是隐私字段，则确定该字段是否要求其他被遮蔽的API对象；

如果不要求其它被遮蔽的API对象，则保留该字段；

如果要求其它被遮蔽的API对象，则判断该字段的保留或移除是否会触发所述不可信容器编排集群和/或所述可信容器编排集群中的执行错误；

如果判断为该字段的移除会触发所述可信容器编排集群中的执行错误，并且该字段的保留不会触发所述不可信容器编排集群中的执行错误，则保留或修改该字段的字段信息；

如果判断为该字段的移除不会触发所述可信容器编排集群中的执行错误，和/或该字段的保留会触发所述不可信容器编排集群中的执行错误，则从所述容器配置信息中移除该字段。

5.如权利要求1所述的层级式容器编排系统，其中，所述可信控制平面节点还包括可信定制控制器，所述可信容器组管理器将所述影子容器组的容器组配置信息发送给所述可信API服务器，以由所述可信定制控制器根据所述影子容器组的容器组配置信息和所述可信数据存储系统中存储的所述第一可信容器组的容器组配置信息进行容器组完整性验证，并且在容器组完整性验证成功后，所述可信容器组管理器根据所接收的容器组配置信息从所述可信API服务器拉起所述第一可信容器组。

6.如权利要求1所述的层级式容器编排系统，其中，所述可信控制平面节点还包括可信定制控制器，并且所述可信准入控制器创建用于指示调度约束的容器组模板，并将所述容器组模板持久化到所述可信数据存储系统，

所述不可信容器运行时管理器进一步将所述第一可信容器组的调度信息转发给所述可信容器组管理器，并且所述可信容器组管理器将所述调度信息发送给所述可信API服务器来经由所述可信定制控制器根据所述调度约束进行调度约束验证，

在所述调度约束验证成功后，所述可信容器组管理器根据所接收的容器组配置信息从所述可信API服务器拉起所述第一可信容器组，并使用基于所接收的资源分配信息分配的资源来在所述可信容器运行时中启动所述第一可信容器组。

7.如权利要求1所述的层级式容器编排系统，其中，在所述可信容器组管理器从所述可信API服务器拉起所述第一可信容器组之前，为所述第一可信容器组创建无限期租约。

8.如权利要求1所述的层级式容器编排系统，其中，在接收到所述API对象部署请求后，所述API服务器将所述API对象部署请求转换为API对象并生成对应的第一可信容器组，响应于所述API对象具有数据敏感性，将所述API对象和所述第一可信容器组存储到所述可信数据存储系统，或者响应于所述API对象不具有数据敏感性，将所述API对象经过加密后存储到不可信数据存储系统并且将所述第一可信容器组存储到所述可信数据存储系统。

9.如权利要求1所述的层级式容器编排系统，其中，响应于接收到用于删除第一可信容器组的第一容器组删除请求，所述可信准入控制器向所述不可信API服务器发送第二容器组删除请求，并且所述可信容器组管理器停止运行所述第一可信容器组，

响应于所述第一可信容器组停止运行，所述可信API服务器删除所述第一可信容器组，

响应于接收到所述第二容器组删除请求，所述不可信API服务器删除所述影子容器组，并且响应于所述影子容器组被删除，所述不可信容器组管理器针对分配给所述影子容器组的资源进行资源重声明。

10.一种多租户容器编排系统，包括：

至少两个租户容器编排集群，每个租户容器编排集群包括租户可信容器编排集群，所述租户可信容器编排集群包括可信控制平面节点和可信数据平面节点，所述可信控制平面节点包括可信API服务器、可信准入控制器和可信数据存储系统，所述可信数据平面节点包括可信容器组管理器、可信容器运行时管理器和可信容器运行时；以及

服务端容器编排集群，包括第一不可信控制平面节点和第一不可信数据平面节点，所述第一不可信控制平面节点包括第一不可信API服务器和容器组调度器，所述不可信数据平面节点包括第一不可信容器组管理器、不可信容器运行时管理器和不可信容器运行时，

其中，在拦截到所述可信API服务器响应于租户经由安全通信信道发起的API对象部署请求而生成的第一可信容器组后，所述可信准入控制器对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组，并将所述影子容器组转发给所述不可信API服务器来经由所述调度器进行容器组调度，

在所述不可信容器组管理器从所述不可信API服务器拉起所述影子容器组并分配资源后，所述不可信容器运行时管理器将调度后的影子容器组的容器组规范转发给所述可信容器组管理器，所述容器组规范包括容器组配置信息和资源分配信息，

所述可信容器组管理器根据所述影子容器组的容器组配置信息从所述可信API服务器拉起所述第一可信容器组，并使用基于所接收的资源分配信息分配的资源来在所述可信容器运行时中运行所述第一可信容器组。

11.如权利要求10所述的多租户容器编排系统，其中，所述第一不可信控制平面节点还包括同步器，所述不可信API服务器经由所述同步器来与所述可信准入控制器进行通信。

12.如权利要求10所述的多租户容器编排系统，其中，所述租户容器编排集群还包括位于租户可信容器编排集群和服务端容器编排集群之间的租户不可信容器编排集群，所述租户不可信容器编排集群包括第二不可信控制平面节点和第二不可信数据平面节点，所述第二不可信控制平面节点包括第二不可信API服务器，所述第二不可信数据平面节点包括第二不可信容器组管理器，

所述可信准入控制器和所述第一不可信API服务器经由所述第二不可信API服务器进行通信，以及所述不可信容器运行时管理器经由所述第二不可信容器组管理器将所述调度后的第一可信容器组的容器组规范和资源分配信息发送给所述可信容器组管理器。

13.一种容器编排方法，包括：

响应于可信容器编排集群中的可信API服务器接收到API对象部署请求，经由所述可信API服务器将所述API对象部署请求转换为所请求的API对象并生成对应的第一可信容器组，并将所述第一可信容器组存储到所述可信容器编排集群中的可信数据存储系统；

响应于所述可信容器编排集群中的可信准入控制器拦截到所述第一可信容器组，经由所述可信准入控制器对所述第一可信容器组的容器组配置信息进行字段信息遮蔽得到所述第一可信容器组的影子容器组，并将所述影子容器组转发给所述不可信API服务器来经由所述调度器进行容器组调度，

在所述不可信容器组管理器从所述不可信API服务器拉起所述影子容器组并分配资源后，经由所述不可信容器运行时管理器将调度后的影子容器组的容器组规范转发给所述可信容器组管理器，所述容器组规范包括容器组配置信息和资源分配信息，

经由所述可信容器组管理器根据所述影子容器组的容器组配置信息从所述可信API服务器拉起所述第一可信容器组，并使用基于所接收的资源分配信息分配的资源来在所述可信容器运行时中运行所述第一可信容器组。

14.如权利要求13所述的容器编排方法，还包括：

响应于接收到用于删除第一可信容器组的第一容器组删除请求，经由所述可信准入控制器向所述不可信API服务器发送第二容器组删除请求，并且经由所述可信容器组管理器停止运行所述第一可信容器组；

响应于所述第一可信容器组停止运行，经由所述可信API服务器删除所述第一可信容器组；

响应于接收到所述第二容器组删除请求，经由所述不可信API服务器删除所述影子容器组，并且响应于所述影子容器组被删除，经由所述不可信容器组管理器针对分配给所述影子容器组的资源进行资源重声明。

15.一种容器编排系统，包括：

至少一个处理器；

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

存储在所述存储器中的计算机程序，所述至少一个处理器执行所述计算机程序来实现如权利要求13或14所述的容器编排方法。

16.一种计算机可读存储介质，其存储有计算机程序，所述计算机程序被处理器执行来实现如权利要求13或14所述的容器编排方法。

17.一种计算机程序产品，包括计算机程序指令，所述计算机程序指令被处理器执行来实现如权利要求13或14所述的容器编排方法。