CN115993977A - 一种应用部署的方法及装置 - Google Patents

Abstract

本申请公开了一种应用部署的方法及装置，应用于应用部署技术领域。本公开将应用的deployment文件中的环境变量提取出来，组成应用模板。配置每个kubernetes集群中的环境变量和相关配置信息。根据负载均衡的方式，确定每个kubernetes集群的发布步骤。用每个kubernetes集群中的环境变量的变量值替换应用模板中的环境变量的变量值。通过组成应用模板的方式，可以实现一个应用只做一次编排就可以部署到多个kubernetes集群。即使对同一个应用进行多次部署，也不会因为环境的不同造成发布差异，修改时也不用在多个集群中分别进行修改。因此，解决了应用部署版本不统一，kubernetes集群发布存在差异性，后期修改困难的问题。

Description

一种应用部署的方法及装置

技术领域

本公开涉及应用部署技术领域，特别是涉及一种应用部署的方法及装置。

背景技术

Kubernetes集群是一组用于运行容器化应用的负载服务器，将应用部署到kubernetes集群中后，可以应对应用负载服务器故障。通常情况下，会将应用部署到多个kubernetes集群中。根据具体应用的服务的不同，可以采取不同的kubernetes集群的形式，具体实现形式可以是多活集群或主备集群。

一般情况下，应用部署是将一个应用分别部署到多个集群中。但每一个集群都有对应的环境，让一个应用分别部署到多个集群，可能会因为部署环境的不同，导致应用部署版本不一致，多次对同一个应用在不同集群中部署会造成发布差异，修改时需要在多个集群中分别进行修改。会导致应用部署版本不统一，增加了kubernetes集群发布的差异性，提高了后期修改困难度。

发明内容

基于上述问题，本公开提供了一种应用部署的方法及装置，解决了应用部署版本不统一，kubernetes集群发布存在差异性，后期修改困难的问题。

本公开实施例公开了如下技术方案：

第一方面，本公开提供一种应用部署的方法，所述应用部署于多个kubernetes集群，所述方法包括：

提取应用中deployment部署文件中的环境变量，组成应用模板，对所述应用模板中的所述环境变量赋予变量值；

配置每个所述kubernetes集群的配置信息，并对每个所述kubernetes集群的环境变量赋予变量值；

根据每个所述kubernetes集群的负载均衡的方式，确定每个所述kubernetes集群的发布方式；

根据每个所述kubernetes集群的发布方式，将所述应用模板中的环境变量的变量值替换为每个所述kubernetes集群的环境变量的变量值，并根据每个所述kubernetes集群的配置信息，发布每个所述kubernetes集群；

验证每个所述kubernetes集群发布是否成功，若成功，则所述应用部署完成。

第二方面，本公开提供了一种应用部署的装置，包括：

kubernetes集群，用于配置每个所述kubernetes集群的配置信息，对每个所述kubernetes集群的环境变量赋予变量值，根据每个所述kubernetes集群的负载均衡的方式，确定每个所述kubernetes集群的发布方式，发布每个所述kubernetes集群，验证每个所述kubernetes集群发布是否成功；

应用，用于向所述kubernetes集群发起服务请求；

应用模板，用于存放所述应用中提取的环境变量和所述应用的环境变量变量值，存放所述kubernetes集群的环境变量的变量值。

相较于现有技术，本公开具有以下有益效果：

本公开技术方案中，将应用的deployment文件中的环境变量提取出来，组成应用模板。配置每个kubernetes集群中的环境变量和相关配置信息。根据负载均衡的方式，确定每个kubernetes集群的发布步骤。用每个kubernetes集群中的环境变量的变量值替换应用模板中的环境变量的变量值。通过组成应用模板的方式，可以实现一个应用只做一次编排就可以部署到多个kubernetes集群。即使对同一个应用进行多次部署，也不会因为环境的不同造成发布差异，修改时也不用在多个集群中分别进行修改。因此，解决了应用部署版本不统一，kubernetes集群发布存在差异性，后期修改困难的问题。

附图说明

结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1为本公开实施例一提供的一种应用部署的方法的流程图；

图2为本公开实施例二提供的一种应用部署的方法的流程图；

图3为本公开实施例三提供的一种应用部署的装置的结构示意图。

具体实施方式

为了使本领域技术人员更清楚地理解本公开的技术方案，下面首先说明本公开方案的应用场景。

Kubernetes集群是一组用于运行容器化应用的负载服务器。应用部署到kubernetes集群，为了应对应用负载服务器故障的问题。例如自然灾害或是人为导致的机房供电、制冷出现问题，以及服务器遭到破坏等，或是网络故障，光缆因为自然灾害或是人为原因被破坏等。根据具体应用的服务的不同，可以采取不同的kubernetes集群的形式，具体实现形式可以是多活集群或主备集群。多活集群是至少两个kubernetes集群各自作为一个线程同时进行发布，主备集群是主集群和备集群作为一个线程，先发布主集群再发布备集群。

目前，应用部署是将一个应用分别部署到多个集群中。但每一个集群都有对应的环境，让一个应用分别部署到多个集群，可能会因为部署环境的不同，导致应用部署版本不一致，多次对同一个应用在不同集群中部署会造成发布差异，修改时需要在多个集群中分别进行修改。会导致应用部署版本不统一，增加了kubernetes集群发布的差异性，提高了后期修改困难度。

为了解决以上技术问题，本公开提供了一种应用部署的方法及装置。本公开技术方案中，将应用的deployment文件中的环境变量提取出来，组成应用模板。配置每个kubernetes集群中的环境变量和相关配置信息。根据负载均衡的方式，确定每个kubernetes集群的发布步骤。用每个kubernetes集群中的环境变量的变量值替换应用模板中的环境变量的变量值。通过组成应用模板的方式，可以实现一个应用只做一次编排就可以部署到多个kubernetes集群。即使对同一个应用进行多次部署，也不会因为环境的不同造成发布差异，修改时也不用在多个集群中分别进行修改。因此，解决了应用部署版本不统一，kubernetes集群发布存在差异性，后期修改困难的问题。

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

图1为本公开实施例一提供的一种应用部署的方法的流程图。如图1所示，该方法包括：

S101：提取应用中deployment部署文件中的环境变量，组成应用模板，对应用模板中的环境变量赋予变量值。

需要部署的应用中包括deployment部署文件，将deployment部署文件中涉及环境相关的属性，提取到应用模板中，并且对提取出的环境变量赋值。其中，应用中环境相关的属性例如命名空间、使用的配置中心地址等。

将涉及环境相关的属性提取组成应用模板，可以在后续部署到不同集群环境时，直接将集群中相关的环境变量的变量值替换到应用模板的对应环境变量中。避免了对于应用进行多次编排产生多个应用环境，造成环境差异，也避免了修改时需要在多个集群中分别进行修改。

S102：配置每个kubernetes集群的配置信息，并对每个kubernetes集群的环境变量赋予变量值。

在进行应用部署之前，先要对kubernetes集群进行相关信息的配置，例如kubeconfig文件等基础资源配置文件。

此外，还需要在kubernetes集群中设置环境相关的属性，例如命名空间、拉取镜像时使用的密钥、挂在存储shiy用的pvc声明等。并且对相关环境变量进行赋值。

完成kubeconfig文件的部署和相关环境变量赋值后，需要将设置的环境变量和kubernetes集群绑定，对应的kubeconfig文件与kubernetes集群进行绑定。这样在选择这个kubernetes集群时，就可以获取到这个kubernetes集群对应的kubeconfig文件和环境变量。

S103：根据每个kubernetes集群的负载均衡的方式，确定每个kubernetes集群的发布方式。

查看kubernetes集群负载均衡的方式，可以根据相关的负载设备或软件查看具体配置，确定负载均衡的方式。

举例说明，当同时将流量导入到多个kubernetes集群中时，此时kubernetes集群实现方式是多活集群；当将流量先导入到一个kubernetes集群中，在kubernetes集群失效时，通过自动或人工的方式将流量导入另一个集群，此时kubernetes集群实现方式是主备集群。当kubernetes集群实现方式是多活集群时，则采用并行发布，并行发布是将每一个kubernetes集群都作为一个线程，同时发布对应的kubernetes集群。当kubernetes集群实现方式是主备集群时，则采用串行发布，串行发布是两个kubernetes集群在同一个线程上，先发布主集群，再发布备集群。

通过判断kubernetes集群负载均衡方式，决定kubernetes集群发布顺序，这样让用户对多个kubernetes集群的发布方式可以配置，可以让系统的灵活度更高，适配性更强。

S104：根据集群发布方式，将应用模板中的环境变量的变量值替换为每个kubernetes集群的环境变量的变量值，并根据每个kubernetes集群的配置信息，发布每个kubernetes集群。

根据kubernetes集群的发布方式，在发布的时候将S102中获得的kubernetes集群的环境变量的变量值，替换到S101中组成的应用模板的环境变量。并且根据S102配置的kubernetes集群对应的kubeconfig文件，对kubernetes集群进行发布。

S105：验证每个kubernetes集群发布是否成功。

在kubernetes集群完成发布后，需要验证kubernetes集群是否发布成功。通过人工测试应用的访问服务是否正常，若正常，则kubernetes集群发布成功；或者人工监控查看每个kubernetes集群中的最小单元pod的状态是否为启动成功，若启动成功，则kubernetes集群发布成功。kubernetes集群发布成功，则应用部署完成。

本公开技术方案中，将应用的deployment文件中的环境变量提取出来，组成应用模板。配置每个kubernetes集群中的环境变量和相关配置信息。根据负载均衡的方式，确定每个kubernetes集群的发布步骤。用每个kubernetes集群中的环境变量的变量值替换应用模板中的环境变量的变量值。通过组成应用模板的方式，可以实现一个应用只做一次编排就可以部署到多个kubernetes集群。即使对同一个应用进行多次部署，也不会因为环境的不同造成发布差异，修改时也不用在多个集群中分别进行修改。因此，解决了应用部署版本不统一，kubernetes集群发布存在差异性，后期修改困难的问题。

图2为本公开实施例二提供的一种应用部署的方法的流程图。如图2所示，该方法包括：

S201：提取应用中deployment部署文件中的环境变量，组成应用模板，对应用模板中的环境变量赋予变量值。

前文提到将应用中的deployment部署文件的环境属性提取到应用模板，并且对提取出来的环境变量赋值的具体方法，在此不再一一赘述。

S202：配置每个kubernetes集群的配置信息，利用Helm组件生成每个kubernetes集群对应的Chart软件包，并对每个kubernetes集群的环境变量赋予变量值。

对每个kubernetes集群配置这个集群的相关信息，例如kubeconfig文件等基础资源配置文件。Kubeconfig文件与kubernetes集群是一一对应绑定的关系。还需要在kubernetes集群设置环境相关的属性，并且对相关环境变量赋变量值。

具体的，可以使用Helm组件实现环境属性的设置及赋值。在kubernetes集群中利用Helm组件生成kubernetes集群对应的Chart软件包。其中Chart软件包包括了存放环境变量变量值的values文件，templates文件夹包括这个kubernetes集群中所需要的资源类型模板。templates文件夹中包括deployment文件，deployment文件是这个kubernetes集群的环境属性的模板。如果采用Helm Chart实现kubernetes集群的配置，需要将values文件中的环境变量的变量值赋值到deployment文件对应的环境属性。实现了kubernetes集群的环境变量的设置和赋值。

此外，因为每个kubernetes集群生成的Chart软件包都是对应的，所以valuse文件中的变量值和deployment文件中的环境属性，与kubernetes集群是绑定的。选择这个kubernetes集群就可以获得对应的环境属性的变量值。

可选地，如果不采用Helm Chart实现kubernetes集群的配置，还可以在kubernetes集群对应的deployment文件中，自定义特定标识符对环境变量赋值。

S203：根据每个kubernetes集群的负载均衡的方式，确定每个kubernetes集群的发布方式。

查看kubernetes集群负载均衡的方式，可以根据相关的负载设备或软件查看具体配置，确定负载均衡的方式。

前文提到，负载均衡的方式包括流量同时导入多个集群的多活方式和流量依次导入两个集群的主备方式。前文对确定每个kubernetes集群的发布方式已详细说明，在此不再一一赘述。

S204：根据集群发布方式，将应用模板中的环境变量的变量值替换为每个kubernetes集群的环境变量的变量值，并根据每个kubernetes集群的配置信息，发布每个kubernetes集群。

根据kubernetes集群的发布方式，在发布的时候将S102中获得的kubernetes集群的环境变量的变量值，替换到S101中组成的应用模板的环境变量。并且根据S102配置的kubernetes集群对应的kubeconfig文件，对kubernetes集群进行发布。

S205：确定每个kubernetes集群是否完成发布，待完成发布后，确定每个kubernetes集群是否发布成功。

执行操作指令，确定每个kubernetes集群是否完成发布。

具体的，如果使用Helm Chart实现kubernetes集群的部署，则可以通过Helm插件的命令行工具执行helm命令，Helm upgrade-i--wait app chart-f app.values-nnamespace来进行部署。

上述命令中使用到了--wait参数，所以在kubernetes集群发布完成后才会返回新的命令行，显示发布成功标识。如果不使用—wait参数，则需要每个kubernetes集群依次调用kubernetes master接口，查看发布状态。

可选地，如果不使用Helm Chart实现kubernetes集群的部署，还可以使用kubectl或javaClient等工具进行部署。需要将kubernetes集群的环境变量变量值替换到应用模板中后，执行kubectl appy-f app.yaml-nnamespace等类似的命令进行发布。

在kubernetes集群发布完成后，需要进行需要验证kubernetes集群是否发布成功。通过人工测试应用的访问服务是否正常，若正常，则kubernetes集群发布成功；或者人工监控查看每个kubernetes集群中的最小单元pod的状态是否为启动成功，若启动成功，则kubernetes集群发布成功。kubernetes集群发布成功，则应用部署完成。

如果发布不成功，则人为判断是否需要进行回滚重新部署发布，或发布成功但人工人为存在问题的情况，也可以进行回滚。

本公开技术方案中，将应用的deployment文件中的环境变量提取出来，组成应用模板。利用Helm Chart配置每个kubernetes集群中的环境变量和相关配置信息。根据负载均衡的方式，确定每个kubernetes集群的发布步骤。用每个kubernetes集群中的环境变量的变量值替换应用模板中的环境变量的变量值。因此，解决了应用部署版本不统一，kubernetes集群发布存在差异性，后期修改困难的问题。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

图3为本公开实施例三提供的一种应用部署的装置的结构示意图。如图3所示，该装置包括：

kubernetes集群310，用于配置每个kubernetes集群的配置信息，对每个kubernetes集群的环境变量赋予变量值，根据每个kubernetes集群的负载均衡的方式，确定每个kubernetes集群的发布方式，发布每个kubernetes集群，验证每个kubernetes集群发布是否成功。

应用模板320，用于存放应用中提取的环境变量和应用的环境变量变量值，存放kubernetes集群的环境变量的变量值。

应用330，用于向kubernetes集群发起服务请求。

可选地，该装置还包括Helm组件340，用于应用在每个kubernetes集群中生成Chart软件包，执行kubernetes集群的命令。其中，执行kubernetes集群的命令还可以是kubectl或javaClient等工具。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元提示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

根据本公开的一个或多个实施例，实施例一和实施例二提供了一种应用部署的方法，包括:

提取应用中deployment部署文件中的环境变量，组成应用模板，对所述应用模板中的所述环境变量赋予变量值；

配置每个所述kubernetes集群的配置信息，并对每个所述kubernetes集群的环境变量赋予变量值；

根据每个所述kubernetes集群的负载均衡的方式，确定每个所述kubernetes集群的发布方式；

根据每个所述kubernetes集群的发布方式，将所述应用模板中的环境变量的变量值替换为每个所述kubernetes集群的环境变量的变量值，并根据每个所述kubernetes集群的配置信息，发布每个所述kubernetes集群；

验证每个所述kubernetes集群发布是否成功，若成功，则所述应用部署完成。

可选地，所述对每个所述kubernetes集群的环境变量赋予变量值，具体包括：

每个所述kubernetes集群利用Helm组件生成对应的Chart软件包，将对应的所述Chart软件包中的values文件中的环境变量的变量值，赋值到对应的所述Chart软件包中的deployment文件的环境变量中，所述Chart软件包包括对应的所述kubernetes集群的资源文件；

每个所述kubernetes集群与对应的所述Chart软件包进行绑定，每个所述Chart软件包与对应的所述values文件和所述deployment文件进行绑定。

可选地，所述配置每个所述kubernetes集群的信息，具体包括：

为每个所述kubernetes集群分别配置kubeconfig文件；

在选择一个所述kubernetes集群时，得到与所述kubernetes集群对应的所述kubeconfig文件和所述kubernetes集群对应的环境变量。

可选地，所述根据每个所述kubernetes集群的负载均衡的方式，确定每个所述kubernetes集群的发布方式，具体包括：

当每个所述kubernetes集群的负载均衡的方式是流量导入到多个所述kubernetes集群时，则选择第一发布方式，所述第一发布方式为每个所述kubernetes集群作为一个线程同时发布对应的所述kubernetes集群；

当每个所述kubernetes集群的负载均衡的方式是流量导入到第一所述kubernetes集群后，在第一所述kubernetes集群失效时，通过自动或人工的方式将流量导入第二所述kubernetes集群，则选择第二发布方式，所述第二发布方式为第一所述kubernetes集群和第二所述kubernetes集群作为一个线程依次发布所述kubernetes集群。

可选地，所述验证每个所述kubernetes集群是否发布成功，具体包括：

确定每个所述kubernetes集群是否完成发布；

待完成发布后，根据人工测试所述应用的访问服务是否正常，或人工监控查看每个所述kubernetes集群中的pod单元的状态是否启动成功，确定每个所述kubernetes集群是否发布成功。

可选地，所述确定每个所述kubernetes集群是否完成发布，具体包括：

若所述人工测试所述应用的访问服务正常或所述人工监控查看所述kubernetes集群中的pod的状态启动成功，则所述kubernetes集群发布成功。

可选地，所述根据每个所述kubernetes集群的配置信息，发布每个所述kubernetes集群，具体包括：

根据每个所述kubernetes集群的配置信息，当利用所述Helm组件的命令行工具执行每个所述kubernetes集群发布命令时，若所述发布命令使用wait参数，则所述发布命令等待所述kubernetes集群完成发布后跳转到新的命令行，显示发布完成标识；

若所述发布命令不使用wait参数，则将依次调用所述kubernetes集群的kubernetes master接口，查看每个所述kubernetes集群的发布状态。

可选地，所述对每个所述kubernetes集群的环境变量赋予变量值，具体包括：

在每个所述kubernetes集群的所述deployment文件中自定义标识符作为所述环境变量的变量值。

根据本公开的一个或多个实施例，实施例三提供了一种应用部署的装置，包括：

kubernetes集群，用于配置每个所述kubernetes集群的配置信息，对每个所述kubernetes集群的环境变量赋予变量值，根据每个所述kubernetes集群的负载均衡的方式，确定每个所述kubernetes集群的发布方式，发布每个所述kubernetes集群，验证每个所述kubernetes集群发布是否成功；

应用，用于向所述kubernetes集群发起服务请求；

应用模板，用于存放所述应用中提取的环境变量和所述应用的环境变量变量值，存放所述kubernetes集群的环境变量的变量值。

可选地，所述装置还包括：

Helm组件，用于在每个所述kubernetes集群中生成Chart软件包，执行所述kubernetes集群的命令。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (10)

1.一种应用部署的方法，其特征在于，所述应用部署于多个kubernetes集群，所述方法包括：

提取应用中deployment部署文件中的环境变量，组成应用模板，对所述应用模板中的所述环境变量赋予变量值；

配置每个所述kubernetes集群的配置信息，并对每个所述kubernetes集群的环境变量赋予变量值；

根据每个所述kubernetes集群的负载均衡的方式，确定每个所述kubernetes集群的发布方式；

根据每个所述kubernetes集群的发布方式，将所述应用模板中的环境变量的变量值替换为每个所述kubernetes集群的环境变量的变量值，并根据每个所述kubernetes集群的配置信息，发布每个所述kubernetes集群；

验证每个所述kubernetes集群发布是否成功，若成功，则所述应用部署完成。

2.根据权利要求1所述的应用部署的方法，其特征在于，所述对每个所述kubernetes集群的环境变量赋予变量值，具体包括：

每个所述kubernetes集群利用Helm组件生成对应的Chart软件包，将对应的所述Chart软件包中的values文件中的环境变量的变量值，赋值到对应的所述Chart软件包中的deployment文件的环境变量中，所述Chart软件包包括对应的所述kubernetes集群的资源文件；

每个所述kubernetes集群与对应的所述Chart软件包进行绑定，每个所述Chart软件包与对应的所述values文件和所述deployment文件进行绑定。

3.根据权利要求1所述的应用部署的方法，其特征在于，所述配置每个所述kubernetes集群的信息，具体包括：

为每个所述kubernetes集群分别配置kubeconfig文件；

在选择一个所述kubernetes集群时，得到与所述kubernetes集群对应的所述kubeconfig文件和所述kubernetes集群对应的环境变量。

4.根据权利要求1所述的应用部署的方法，其特征在于，所述根据每个所述kubernetes集群的负载均衡的方式，确定每个所述kubernetes集群的发布方式，具体包括：

当每个所述kubernetes集群的负载均衡的方式是流量导入到多个所述kubernetes集群时，则选择第一发布方式，所述第一发布方式为每个所述kubernetes集群作为一个线程同时发布对应的所述kubernetes集群；

当每个所述kubernetes集群的负载均衡的方式是流量导入到第一所述kubernetes集群后，在第一所述kubernetes集群失效时，通过自动或人工的方式将流量导入第二所述kubernetes集群，则选择第二发布方式，所述第二发布方式为第一所述kubernetes集群和第二所述kubernetes集群作为一个线程依次发布所述kubernetes集群。

5.根据权利要求2所述的应用部署的方法，其特征在于，所述验证每个所述kubernetes集群是否发布成功，具体包括：

确定每个所述kubernetes集群是否完成发布；

待完成发布后，根据人工测试所述应用的访问服务是否正常，或人工监控查看每个所述kubernetes集群中的pod单元的状态是否启动成功，确定每个所述kubernetes集群是否发布成功。

6.根据权利要求5所述的应用部署的方法，其特征在于，所述确定每个所述kubernetes集群是否完成发布，具体包括：

若所述人工测试所述应用的访问服务正常或所述人工监控查看所述kubernetes集群中的pod的状态启动成功，则所述kubernetes集群发布成功。

7.根据权利要求1所述的应用部署的方法，其特征在于，所述根据每个所述kubernetes集群的配置信息，发布每个所述kubernetes集群，具体包括：

根据每个所述kubernetes集群的配置信息，当利用所述Helm组件的命令行工具执行每个所述kubernetes集群发布命令时，若所述发布命令使用wait参数，则所述发布命令等待所述kubernetes集群完成发布后跳转到新的命令行，显示发布完成标识；

若所述发布命令不使用wait参数，则将依次调用所述kubernetes集群的kubernetesmaster接口，查看每个所述kubernetes集群的发布状态。

8.根据权利要求1所述的应用部署的方法，其特征在于，所述对每个所述kubernetes集群的环境变量赋予变量值，具体包括：

在每个所述kubernetes集群的所述deployment文件中自定义标识符作为所述环境变量的变量值。

9.一种应用部署的装置，其特征在于，包括：

kubernetes集群，用于配置每个所述kubernetes集群的配置信息，对每个所述kubernetes集群的环境变量赋予变量值，根据每个所述kubernetes集群的负载均衡的方式，确定每个所述kubernetes集群的发布方式，发布每个所述kubernetes集群，验证每个所述kubernetes集群发布是否成功；

应用，用于向所述kubernetes集群发起服务请求；

应用模板，用于存放所述应用中提取的环境变量和所述应用的环境变量变量值，存放所述kubernetes集群的环境变量的变量值。

10.根据权利要求9所述的应用部署的装置，其特征在于，所述装置还包括：

Helm组件，用于在每个所述kubernetes集群中生成Chart软件包，执行所述kubernetes集群的命令。

Images