CN114721719B - 一种在集群中容器化部署异构应用的方法和系统 - Google Patents

Abstract

本申请提供了一种在集群中容器化部署异构应用的方法和系统。该方法包括：检测应用支持的CPU架构与部署所述应用的节点的CPU架构是否相同；响应于所述应用支持的CPU架构与部署所述应用的节点的CPU架构不相同，启动所述应用所在容器组的容器运行时中的动态翻译引擎，以将所述应用的指令动态翻译为所述节点的CPU能够运行的指令。籍此，借助于部署在容器运行时中的动态翻译引擎，将应用的指令动态翻译为能够在异构节点中直接运行的指令，无需对应用的代码进行改造和重新编译，即可让应用直接在异构节点中正常运行，极大地提高了应用在异构集群中的调度效率。

Description

一种在集群中容器化部署异构应用的方法和系统

技术领域

本申请涉及云原生技术领域，特别涉及一种在集群中容器化部署异构应用的方法、系统、计算机可读存储介质和电子设备。

背景技术

Kubernetes系统是一种开源的支持异构节点的容器编排引擎，能够纳管不同CPU架构的节点到同一集群中进行统一调度，让应用的部署、运维更简单、更便捷、更高效。也就是说，同一Kubernetes集群可以由各种不同CPU架构的节点组成，比如amd、amd64、arm、arm64、ppc64le、s390x等。

在Kubernetes系统对应用进行调度时，需要将应用部署在同构节点中，即应用支持的CPU架构与该节点的CPU架构相同，才能确保应用正常运行。如果Kubernetes集群中该应用的所有同构节点均处于不可调度状态，则该应用将无法调度至Kubernetes集群中，只能将对应的调度任务压入调度队列，等待该应用的某个同构节点恢复可调度状态后，再完成对该应用的调度，调度效率极低。

因而，亟需提供一种针对上述现有技术不足的技术方案。

发明内容

本申请的目的在于提供一种在集群中容器化部署异构应用的方法、系统、计算机可读存储介质和电子设备，以解决或缓解上述现有技术中存在的问题。

为了实现上述目的，本申请提供如下技术方案：

本申请提供一种在集群中容器化部署异构应用的方法，包括：检测应用支持的CPU架构与部署所述应用的节点的CPU架构是否相同；响应于所述应用支持的CPU架构与部署所述应用的节点的CPU架构不相同，启动所述应用所在容器组的容器运行时中的动态翻译引擎，以将所述应用的指令动态翻译为所述节点的CPU能够运行的指令。

优选的，所述应用所在容器组的容器运行时中的动态翻译引擎使用指令翻译软件对所述应用的指令进行翻译，以生成所述节点的CPU能够运行的指令。

优选的，所述应用的指令具体为用户态指令，所述应用所在容器组的容器运行时中的动态翻译引擎将所述应用的用户态指令切换为对应的内核态指令，并调用操作系统内核提供的二进制翻译硬件驱动，对所述内核态指令进行翻译，以生成所述节点的CPU能够运行的指令。

优选的，部署所述应用的节点的CPU架构的指令集中的第一指令的语法和结构与所述内核态指令相同或者近似。

优选的，部署所述应用的节点的CPU架构的指令集包括基础指令集和拓展指令集，所述第一指令属于所述拓展指令集。

优选的，所述在集群中容器化部署异构应用的方法还包括：预先对部署所述应用的节点的CPU架构的硬件进行修改，以及在所述拓展指令集中设置第二指令，以模拟所述应用支持的CPU的运行状态。

优选的，在所述启动所述应用所在容器组的容器运行时中的动态翻译引擎之后，还包括：对所述应用所在容器组进行横向扩容。

本申请实施例还提供一种在集群中容器化部署异构应用的系统，包括：检测单元，配置为检测应用支持的CPU架构与部署所述应用的节点的CPU架构是否相同；翻译单元，配置为响应于所述应用支持的CPU架构与部署所述应用的节点的CPU架构不相同，启动所述应用所在容器组的容器运行时中的动态翻译引擎，以将所述应用的指令动态翻译为所述节点的CPU能够运行的指令。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述程序为如上任一所述的在集群中容器化部署异构应用的方法。

本申请实施例还提供一种电子设备，包括：处理器、存储器、以及存储在存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现如上任一所述的在集群中容器化部署异构应用的方法。

有益效果：

本申请提供的在集群中容器化部署异构应用的技术，检测应用支持的CPU架构与部署该应用的节点的CPU架构是否相同，当该应用支持的CPU架构与部署该应用的节点的CPU架构不相同时，启动该应用所在容器组的容器运行时中的动态翻译引擎，由动态翻译引擎将该应用的指令动态翻译为该应用所在节点的CPU能够运行的指令。籍此，借助于部署在容器运行时中的动态翻译引擎，将应用的指令动态翻译为能够在异构节点中直接运行的指令，无需对应用的代码进行改造和重新编译，即可让应用直接在异构节点中正常运行，极大地提高了应用在异构集群中的调度效率。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。其中：

图1为根据本申请的一些实施例提供的一种在集群中容器化部署异构应用的方法的流程示意图；

图2为根据本申请的一些实施例提供的将应用部署在同构节点上的技术逻辑图；

图3为根据本申请的一些实施例提供的将应用部署在异构节点上的技术逻辑图；

图4为根据本申请的一些实施例提供的一种基于软件的动态翻译引擎的技术逻辑图；

图5为根据本申请的一些实施例提供的一种基于硬件优化的动态翻译引擎的技术逻辑图；

图6为根据本申请的一些实施例提供的一种在集群中容器化部署异构应用的系统的结构示意图；

图7为根据本申请的一些实施例提供的电子设备的结构示意图；

图8为根据本申请的一些实施例提供的电子设备的硬件结构图。

具体实施方式

下面将参考附图并结合实施例来详细说明本申请。各个示例通过本申请的解释的方式提供而非限制本申请。实际上，本领域的技术人员将清楚，在不脱离本申请的范围或精神的情况下，可在本申请中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。

中央处理器(central processing unit，简称CPU)的架构是CPU厂商给属于同一系列的CPU产品定的一个规范，主要目的是为了区分不同类型CPU的重要标识。

市面上的CPU分类主要分有两大阵营，一个是intel、AMD为首的复杂指令集CPU，另一个是以IBM、ARM为首的精简指令集CPU。两个不同品牌的CPU，其产品的架构也不相同，例如，Intel、AMD的CPU是X86架构的，而IBM公司的CPU是PowerPC架构，ARM公司是ARM架构，国内的飞腾CPU也是ARM架构。此外还有MPIS架构、SPARC架构、Alpha架构。

指令集，又被称作指令系统，是CPU中用来计算和控制计算机系统的一套指令的集合，而每一种CPU在设计时就规定了一系列与其他硬件电路相配合的指令系统。指令集中的指令与CPU紧密相关，不同架构的CPU所对应的指令集不同。

应用运行在操作系统上时，应用产生的指令经操作系统转换为二进制指令，交由CPU具体执行。而只有当交由CPU执行的二进制指令属于CPU所对应的指令集时，才能让节点的底层硬件对该指令进行识别和处理，并反馈处理结果。但是，应用产生的指令无法被操作系统转换为异构的二进制指令，并交由异构的CPU执行。简单来说，应用无法在异构的CPU所在的节点中正常运行。

因此在应用开发时，软件工程师需要开发多个版本的应用，来分别适配不同架构的CPU和指令集。如果要开发能够适配新架构的新版本的应用，则需要对现有应用的代码进行改造和重新编译。比如，某应用只有X86架构版本，要想在非X86架构CPU的节点中运行该应用，就需要对X86架构版本的应用的代码进行改造和重新编译，生成与待部署的节点的CPU架构适配的新版本的应用，以使该应用能够在非X86架构CPU的节点中正常运行。

Kubernetes系统是一种开源的支持异构节点的容器编排引擎，能够纳管不同CPU架构的节点到同一集群中进行统一调度，让应用的部署、运维更简单、更便捷、更高效。也就是说，同一Kubernetes集群可以由各种不同CPU架构的节点组成，比如amd、amd64、arm、arm64、ppc64le、s390x等。

在Kubernetes系统对应用进行调度时，需要将应用部署在同构节点中，即应用支持的CPU架构与该节点的CPU架构相同，才能确保应用正常运行。如果Kubernetes集群中该应用的所有同构节点均处于不可调度状态，则该应用将无法调度至Kubernetes集群中，只能将对应的调度任务压入调度队列，等待该应用的某个同构节点恢复可调度状态后，再完成对该应用的调度，调度效率极低。

目前大多数的云原生应用只适配了X86架构，即只存在X86架构版本，如果将大量X86架构版本的应用调度至纳管有非X86架构CPU的节点的Kubernetes集群中，势必造成X86架构CPU的节点不断被各个应用抢占，而非X86架构CPU的节点则大部分处于空闲状态。

要让云原生应用适配不同CPU架构，则需要对几乎所有云原生应用的代码进行改造和重新编译，不仅工程量浩大，而且不能保证覆盖所有应用。

为此，申请人提出了一种在集群中容器化部署异构应用的方案，借助于应用所在容器组的容器运行时中的动态翻译引擎，将应用的指令动态翻译为节点的CPU能够运行的指令，无需对应用的代码进行改造和重新编译，即可让应用直接在集群中的异构节点中正常运行，极大地提高了应用在异构集群中的调度效率。

示例性方法

图1为根据本申请的一些实施例提供的一种在集群中容器化部署异构应用的方法的流程示意图；如图1所示，该方法包括：

步骤S101、检测应用支持的CPU架构与部署应用的节点的CPU架构是否相同。

应当理解，本申请实施例中的Kubernetes集群可以由各种不同CPU架构的节点组成，既包括应用的同构节点，也包括应用的异构节点。将应用直接调度至同构节点进行部署，无需对应用的指令进行翻译，即可让节点的CPU直接运行，因此优先将应用部署在同构节点中，以最大限度地发挥节点底层硬件的性能。比如，在对X86架构版本的应用进行部署时，优先将该应用调度至X86架构CPU的节点上，如图2所示。

具体来说，在将节点纳入Kubernetes系统管理时，Kubernetes系统可自动获知该节点的CPU架构，并自动为该节点打上对应的标签，而将该应用调度至Kubernetes集群中时，可以从镜像仓库中下载该应用的容器镜像，镜像仓库中容器镜像的元数据信息中记载了该应用支持的CPU架构。因此，可以根据应用支持的CPU架构和每个节点的CPU架构标签，筛选出应用的同构节点，如果存在处于可调度状态的同构节点，则可以优先将应用部署在同构节点上。如果存在多个可调度的同构节点，则按照Kubernetes系统的调度机制在多个可调度的同构节点中选出最佳调度节点，此处不再赘述。

而如果Kubernetes集群中该应用的所有同构节点均处于不可调度状态，或者Kubernetes集群中不存在该应用的同构节点，则需要将应用部署在异构节点中，使应用在异构节点中运行。具体是借助于动态翻译引擎实现应用在异构节点中的正常运行，如图3所示。

基于上述说明可知，在将应用调度至Kubernetes集群中时，需要对应用支持的CPU架构和每个节点的CPU架构进行一次匹配，来将应用调度至Kubernetes集群中的某个具体节点，根据Kubernetes集群的实际状态不同，该应用可能被调度至同构节点，也可能被调度至异构节点。

因此，在确定将应用部署至Kubernetes集群中的某个具体节点后，该具体节点还需要判断节点本身是否属于该应用的异构节点，进而决定是否需要启动动态翻译引擎。

应当理解，本申请实施例在Kubernetes集群中的每个节点中预先设置了动态翻译引擎，节点确定节点本身属于所部署应用的异构节点，则确定需要启动动态翻译引擎。

步骤S102、响应于应用支持的CPU架构与部署应用的节点的CPU架构不相同，启动应用所在容器组的容器运行时中的动态翻译引擎，以将应用的指令动态翻译为节点的CPU能够运行的指令。

容器技术是一种新型的虚拟化技术，能够将单个操作系统的资源划分到孤立的组中，容器组(Pod)是Kubernetes系统中最小的可部署单元，由单个容器或者几个紧耦合在一起的容器组成。Kubernetes系统具体使用Kubelet组件来对容器组进行管理，Kubelet组件在对接容器组时，真正对接的是Containerd等高级容器运行时，再由Containerd等高级容器运行时对接runc等不同的低级容器运行时，也就是本申请实施例中提及的容器运行时(Container runtime)，由容器运行时具体创建，启动，停止和监视容器。

可以理解，在云原生场景下，应用预先经过容器化处理后，可以被部署在节点中的容器组中，由Kubernetes系统对容器组进行编排。因此，将应用部署至Kubernetes集群中的节点，实际上是将该应用部署至该节点中的某个容器组中，并由容器运行时运行容器组中的每个容器。因此，本申请实施例将动态翻译引擎设置在了每个容器组的容器运行时中，当检测到应用支持的CPU架构与部署应用的节点的CPU架构不相同，则启动应用所在容器组的容器运行时中的动态翻译引擎，由动态翻译引擎对应用的指令进行动态翻译，转换为该节点的CPU所对应的指令集中的二进制指令，交由该CPU具体执行。

比如，X86架构版本的应用被调度至ARM架构CPU的节点中后，由X86架构版本的应用所在容器组的容器运行时中的动态翻译引擎，对X86架构版本的应用的指令进行动态翻译，将X86架构版本的应用的指令动态翻译为ARM架构的二进制指令，交由ARM架构CPU执行，使得X86架构版本的应用能够在ARM架构CPU的节点中正常运行。

进一步地，本申请实施例可以通过软件、硬件或者软硬结合(软件与硬件结合)的方式将应用的指令翻译为异构CPU对应的指令集中的二进制指令；比如，将X86架构版本的应用的指令翻译为ARM架构CPU对应的指令集中的二进制指令。

图4为根据本申请的一些实施例提供的一种基于软件的动态翻译引擎的技术逻辑图；如图4所示，应用所在容器组的容器运行时中的动态翻译引擎使用指令翻译软件对应用的指令进行翻译，以生成节点的CPU能够运行的指令。

具体的，将应用部署在容器运行时中，容器运行时使用指令翻译软件对应用运行过程中产生的指令进行动态翻译，并将指令动态翻译成异构CPU对应的指令集中的指令，由异构CPU接受指令并进行相应的处理，使得应用能够部署和运行在异构节点上。

在一应用场景中，采用虚拟操作系统模拟器(quick emulator，简称QEMU)将应用运行过程中产生的指令翻译为异构CPU对应的指令集中的指令。具体的，在异构节点中，通过QEMU模拟应用的同构节点的CPU等底层硬件，接收应用运行过程中产生的指令，并将其转换为虚拟的同构CPU对应的指令集中的二进制指令，由虚拟的同构CPU执行二进制指令，QEMU在模拟同构节点的底层硬件时也在不断产生指令，QEMU的指令被转换为真实的异构CPU对应的指令集中的二进制指令，由真实的异构CPU进行处理，从而让应用在QEMU模拟出的同构节点中正常运行，相当于让应用在异构节点中正常运行。

在此过程中，由于需要通过QEMU模拟应用的同构节点的底层硬件，因此需要额外占用异构节点的底层硬件的性能，指令动态翻译过程中会不可避免的存在运行性能损失。但在本应用场景下，动态翻译引擎的功能是基于软件实现的，即使用的是虚拟操作系统模拟器，对所在节点的操作系统和底层硬件没有任何影响。

在另一应用场景中，可以采用指令翻译软件直接将应用运行过程中产生的指令翻译为异构CPU对应的指令集中的指令。具体地，预先在指令翻译软件中建立不同架构CPU对应的指令集中各个二进制指令之间的映射关系，在接收到应用运行过程中产生的指令后，通过查询前述映射关系，实现对二进制指令的动态翻译。

在又一应用场景中，还可以通过操作系统内核提供的二进制翻译硬件驱动对应用运行过程中产生的指令进行动态翻译，生成异构节点的CPU能够运行的指令。图5为根据本申请的一些实施例提供的一种基于硬件优化的动态翻译引擎的技术逻辑图；如图5所示，应用的指令具体为用户态指令，应用所在容器组的容器运行时中的动态翻译引擎将应用的用户态指令切换为对应的内核态指令，并调用操作系统内核提供的二进制翻译硬件驱动，对内核态指令进行翻译，以生成节点的CPU能够运行的指令。

在操作系统设计中，将程序的运行状态划分为用户态和内核态。处于用户态的应用具有较低的特权，仅能执行规定的指令，访问特定的寄存器和存储器。处于内核态的应用具有较高特权，能执行一切指令，访问所有寄存器和存储器。由此，对操作系统进行保护和提升操作系统的运行效率。

在本申请实施例中，节点的容器运行时使用基于硬件优化的动态翻译引擎对应用运行过程中的产生的指令进行翻译。具体地，基于硬件优化的动态翻译引擎需要调用操作系统内核提供的二进制翻译硬件驱动，因此需要先将应用的运行状态由用户态切换为内核态，即将应用运行过程中产生的用户态指令切换为对应的内核态指令，使其能够直接使用操作系统的资源，才能够调用操作系统内核提供的二进制翻译硬件驱动，进而将内核态指令动态翻译为异构节点的CPU对应的指令集中的二进制指令，再传递给异构节点的CPU，由异构节点的CPU接受二进制指令并执行，从而实现应用在异构节点中的正常运行。

可以理解，由于只有内核态指令才能调用操作系统内核提供的二进制翻译硬件驱动，因此需要先将应用的程序运行状态由用户态切换为内核态，从而让应用运行过程中产生的指令由用户态指令转换为内核态指令，进而调用二进制翻译硬件驱动将内核态指令动态翻译为异构节点的CPU对应的指令集中的二进制指令，使异构CPU能够执行二进制指令。

其中，二进制翻译硬件驱动是使用底层硬件进行翻译的工具，用于将异构节点的底层硬件的功能暴露给上层应用，在上层应用和底层硬件之间建立起指令翻译的绿色通道，由集群管理员预先安装在每个节点的操作系统中，由于每个节点的底层硬件的存在差别，相应地，每个节点上安装的二进制翻译硬件驱动也存在区别。可以理解，底层硬件中存储了异构节点的CPU对应的指令集中的全部二进制指令，以及囊括了寄存器等大量CPU执行二进制指令时所需的物理元器件，在进行指令翻译时，可以充分利用二进制翻译硬件驱动所提供的底层硬件的功能，来将内核态指令动态翻译成为异构节点的CPU对应的指令集中的二进制指令。

需要特别说明的是，在指令翻译时，如果原指令和译指令在语法和结构上相同或者近似，那么就可以预先在原指令和译指令之间建立起操作码和地址码的映射关系。对于语法和结构完全相同的情况，只需将原指令中的操作码和地址码按照映射关系替换为译指令中的操作码和地址码，即可将原指令翻译成译指令。而对于语法和结构近似的情况，在将原指令中的操作码和地址码按照映射关系替换为译指令中的操作码和地址码后，还需要根据译指令的语法和结构，对译指令进行语法和结构上的调整，即可将原指令翻译成译指令。

可以理解，本申请实施例中部署应用的节点的CPU架构的指令集中的第一指令的语法和结构与内核态指令相同或者近似，因此使用操作系统内核提供的二进制翻译硬件驱动进行动态翻译时，即可让内核态指令准确且快速地动态翻译成部署应用的节点的CPU架构的指令集中的第一指令。

需要说明的是，对于不同架构CPU对应的指令集中的二进制指令来说，语法和结构有可能相同，也可能近似，还可能存在较大差异。也就是说，部署应用的节点的CPU架构的指令集中的指令的语法和结构与应用的内核态指令在语法和结构上并不一定相同或者近似，还可能存在较大差异。

为了解决这个问题，本申请实施例对部署应用的节点的CPU架构的指令集进行拓展，将CPU架构的原始指令集作为基础指令集，在此基础上，引入在语法和结构上与应用的内核态指令相同或者近似的若干条指令作为拓展指令集，即部署应用的节点的CPU架构的指令集包括基础指令集和拓展指令集，并且上述的第一指令属于拓展指令集，从而确保了第一指令与内核态指令在语法和结构上相同或者近似。

此外，在拓展指令集中设置对应的第一指令的成本较高，对于某些不常见的内核态指令，出于成本的考虑，不在拓展指令集中特意设置对应的第一指令，如果还遇到部分与指令集中的二进制指令在语法和结构上存在较大差异的内核态指令，则可以使用前述的指令翻译软件将该指令翻译为异构CPU对应的指令集中的指令，以确保对指令动态翻译的完整性。

籍此，通过调用操作系统内核提供的二进制翻译硬件驱动对动态翻译引擎进行优化，对应用运行过程中的产生的指令进行翻译，生成异构节点的CPU能够运行的指令，减少了动态翻译引擎对底层硬件的性能占用，提升了指令翻译的效率和准确性。

此外，对于某些特殊架构的CPU，比如X86架构的CPU，具有EFLAG标志寄存器、浮点寄存器等特殊寄存器，浮点寄存器由浮点协处理器指令采用栈访问模式进行访问。为了让X86架构版本的应用的指令能够翻译成异构CPU对应的指令集中的二进制指令，需要对异构CPU架构的硬件进行修改，以模拟X86架构的CPU的特殊功能。比如可以为异构CPU设计更多的寄存器，用于模拟X86架构的CPU所具有的特殊寄存器，具体可以在拓展指令集中定义专门的运算类指令来模拟产生EFLAG标志，以模拟X86架构的CPU中的EFLAG标志寄存器的功能，也可以使用多个浮点寄存器模拟X86架构的CPU中的栈访问模式，以便在拓展指令集中定义浮点协处理器指令对应的指令，还可以调整TLB(从虚拟内存地址到物理内存地址的转换)结构用于指令动态翻译过程中的访存操作的两级虚实地址映射。

简单来说，就是预先对部署应用的节点的CPU架构的硬件进行修改，以及在拓展指令集中设置第二指令，以模拟应用支持的CPU的运行状态。

其中，第二指令可以是上述用来模拟产生EFLAG标志的专门的运算类指令，也可以是上述在拓展指令集中定义的浮点协处理器指令对应的指令，本申请实施例对此不做限定。

在此，需要说明的是，基于硬件优化的动态翻译引擎通过对异构CPU架构的硬件进行修改，以及在对应的指令集中引入拓展指令集，利用底层硬件弥补软件翻译的不足，进一步提升了指令动态翻译的效率和准确度。

本申请实施例允许采用软件、硬件或者软硬结合的方式进行动态翻译，用户可以根据需求和使用场景选择合适的方式，本申请实施例对此不做限定。

基于前述说明可知，本申请实施例所提出的在集群中容器化部署异构应用的方法，使用应用所在容器组的容器运行时中的动态翻译引擎来对应用的指令进行动态翻译，转换为异构节点的CPU所对应的指令集中的二进制指令，交由该异构CPU具体执行。动态翻译引擎无论是采用软件、硬件还是软硬结合的方式进行动态翻译，都会占用底层硬件的性能，导致应用的性能相比于部署在同构节点中有所损失。

为了解决这一问题，本申请实施例在启动应用所在容器组的容器运行时中的动态翻译引擎之后，还可以对应用所在容器组进行横向扩容。

横向扩容是Kubernetes系统提供的容器编排基础能力，能够对特定的容器组进行复制，对应用所在容器组进行横向扩容，可以得到多个应用副本，这些应用副本共同分担应用的负载压力，以弥补应用的性能损失。

随着国内CPU厂商的快速发展，越来越多的硬件设备开始使用国产CPU，尤其是服务器节点，而国产CPU通常采用MIPS、ARM等架构，而非X86架构，将本申请实施例所提出的一种在集群中容器化部署异构应用的方法用于使用大量国产CPU的节点的集群，能够将X86架构版本的云原生应用调度至异构CPU的节点，整个过程对应用无感知，并且不影响用户的使用体验。

此外，在现有的Kubernetes集群中对应用进行调度时，有可能因为对节点的CPU架构或者应用的CPU架构版本识别错误，使得应用被错误地调度至异构节点上，导致应用无法正常运行，需要重新进行调度，而在本申请实施例中即便在应用调度时出现了识别错误，在应用被错误调度至某个节点后，仍可以借助动态翻译引擎实现正常运行，无需重新调度。

示例性系统

图6为根据本申请的一些实施例提供的一种在集群中容器化部署异构应用的系统的结构示意图；如图6所示，该在集群中容器化部署异构应用的系统包括：检测单元，配置为检测应用支持的CPU架构与部署应用的节点的CPU架构是否相同；翻译单元，配置为响应于应用支持的CPU架构与部署应用的节点的CPU架构不相同，启动应用所在容器组的容器运行时中的动态翻译引擎，以将应用的指令动态翻译为节点的CPU能够运行的指令。

本申请实施例提供的在集群中容器化部署异构应用的系统能够实现上述任一实施例的在集群中容器化部署异构应用的方法的步骤、流程，并达到相同的技术效果，在此不再一一赘述。

示例性设备

图7为根据本申请的一些实施例提供的电子设备的结构示意图；如图7所示，该电子设备包括：

一个或多个处理器701；

计算机可读介质，可以配置为存储一个或多个程序702，一个或多个处理器701执行一个或多个程序702时，实现如下步骤：检测应用支持的CPU架构与部署应用的节点的CPU架构是否相同；响应于应用支持的CPU架构与部署应用的节点的CPU架构不相同，启动应用所在容器组的容器运行时中的动态翻译引擎，以将应用的指令动态翻译为节点的CPU能够运行的指令。

图8为根据本申请的一些实施例提供的电子设备的硬件结构；如图8所示，该电子设备的硬件结构可以包括：处理器801、通信接口802、计算机可读介质803和通信总线804。

其中，处理器801、通信接口802、计算机可读存储介质803通过通信总线804完成相互间的通信。

可选地，通信接口802可以为通信模块的接口，如GSM模块的接口。

其中，处理器801具体可以配置为：检测应用支持的CPU架构与部署应用的节点的CPU架构是否相同；响应于应用支持的CPU架构与部署应用的节点的CPU架构不相同，启动应用所在容器组的容器运行时中的动态翻译引擎，以将应用的指令动态翻译为节点的CPU能够运行的指令。

处理器801可以是通用处理器，包括中央处理器(central processing unit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其它具有数据交互功能的电子装置。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的在集群中容器化部署异构应用的方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其它实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。

以上所描述得设备及系统实施例仅仅是示意性的，其中作为分离不见说明的单元可以使或者也可以不是物理上分开的，作为单元提示的不见可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的优选实施例，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (9)

1.一种在集群中容器化部署异构应用的方法，其特征在于，包括：

检测应用支持的CPU架构与部署所述应用的节点的CPU架构是否相同；

响应于所述应用支持的CPU架构与部署所述应用的节点的CPU架构不相同，启动所述应用所在容器组的容器运行时中的动态翻译引擎，由所述动态翻译引擎将所述应用的用户态指令切换为对应的内核态指令，并调用操作系统内核提供的二进制翻译硬件驱动，对所述内核态指令进行翻译，以生成所述节点的CPU能够运行的指令，使得所述应用部署、运维时无需进行重新编译就能够运行在与所述应用支持的CPU架构不相同的节点上。

2.根据权利要求1所述的在集群中容器化部署异构应用的方法，其特征在于，所述应用所在容器组的容器运行时中的动态翻译引擎使用指令翻译软件对所述应用的指令进行翻译，以生成所述节点的CPU能够运行的指令。

3.根据权利要求1所述的在集群中容器化部署异构应用的方法，其特征在于，部署所述应用的节点的CPU架构的指令集中的第一指令的语法和结构与所述内核态指令相同或者近似。

4.根据权利要求3所述的在集群中容器化部署异构应用的方法，其特征在于，部署所述应用的节点的CPU架构的指令集包括基础指令集和拓展指令集，所述第一指令属于所述拓展指令集。

5.根据权利要求4所述的在集群中容器化部署异构应用的方法，其特征在于，所述在集群中容器化部署异构应用的方法还包括：

预先对部署所述应用的节点的CPU架构的硬件进行修改，以及在所述拓展指令集中设置第二指令，以模拟所述应用支持的CPU的运行状态。

6.根据权利要求1-5中任一项所述的在集群中容器化部署异构应用的方法，其特征在于，在所述启动所述应用所在容器组的容器运行时中的动态翻译引擎之后，还包括：对所述应用所在容器组进行横向扩容。

7.一种在集群中容器化部署异构应用的系统，其特征在于，包括：

检测单元，配置为检测应用支持的CPU架构与部署所述应用的节点的CPU架构是否相同；

翻译单元，配置为响应于所述应用支持的CPU架构与部署所述应用的节点的CPU架构不相同，启动所述应用所在容器组的容器运行时中的动态翻译引擎，由所述动态翻译引擎将所述应用的用户态指令切换为对应的内核态指令，并调用操作系统内核提供的二进制翻译硬件驱动，对所述内核态指令进行翻译，以生成所述节点的CPU能够运行的指令，使得所述应用部署、运维时无需进行重新编译就能够运行在与所述应用支持的CPU架构不相同的节点上。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序为如权利要求1-6任一所述的在集群中容器化部署异构应用的方法。

9.一种电子设备，其特征在于，包括：处理器、存储器、以及存储在存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现如权利要求1-6任一所述的在集群中容器化部署异构应用的方法。