CN112346821A - 基于kubernetes的应用配置管理方法与系统 - Google Patents

Abstract

本申请涉及一种基于kubernetes的应用配置管理方法与系统，其中，在基于kubernetes的应用配置管理方法中，所述控制平台通过将不同类型的配置文件分别应用到容器的不同配置模块中，实现了在开发人员无感的情况下，使应用程序获取到对应的配置文件。并且针对私密配置文件，控制平台将私密配置文件的配置值以加密算法加密存放于私有配置模块中，该私密配置文件不会对OPS运维人员以外的人员公开，实现了高保密性的效果。

Description

基于kubernetes的应用配置管理方法与系统

技术领域

本申请涉及kubernetes技术领域，特别是涉及一种基于kubernetes的应用配置管理方法与系统。

背景技术

kubernetes是现代容器化微服务部署的重要工具，在容器部署过程中，无法对应用的配置进行管理，所有的配置都跟随应用直接编译到容器中，当应用的配置需要修改就必须要需要重新发布部署，整个过程会花费相当长的时间。

并且服务的配置会非常多元化，大致分为公共配置，私有配置，静态配置，动态配置以及secret密码等敏感配置(如图一)，对这些配置的处理也相对多元化，比如密码配置如何做到不泄漏，如何让开发人员无感。如何支持多种开发语言(java，go，python，nodejs)都是需要考虑的。并且如何减少部署依赖，提升与kubernetes的耦合性，如何做到部署和维护更加轻量。

因此，传统kubernetes的的应用配置管理方法是公共配置和私有配置等配置文件一同配置，每一个应用都需要维护和配置，浪费时间，最重要的是，这种配置方法不具有保密性，直接能够看到明文的配置文件，并且根据明文的配置文件回溯查询数据库，这大大威胁了数据库的安全性。

发明内容

基于此，有必要针对传统kubernetes的应用配置管理方法中配置文件缺乏保密性的问题，提供一种基于kubernetes的应用配置管理方法。

本申请提供一种基于kubernetes的应用配置管理方法，所述方法包括：

应用程序检测当前运行环境，判断当前运行环境是线上运行环境还是本地测试环境；

若当前运行环境是线上运行环境，则应用程序监控配置文件的下发状态，判断是否有新配置文件下发；

控制平台将不同类型的配置文件下发至与应用程序对应的容器的不同位置，控制平台包括公共控制平台和私有控制平台，配置文件包括普通配置文件和私密配置文件；

控制平台将不同类型的配置文件下发至与应用程序对应的容器的不同位置，包括：

公共控制平台将普通配置文件下发至与应用程序对应的容器的app配置模块；

私有控制平台将私密配置文件分别下发至与应用程序对应的app配置模块和与应用程序对应的私有配置模块，所述app配置模块接收的私密配置文件包括配置文件名称，所述私有配置模块接收的私密配置文件包括配置文件名称和配置值；所述配置值以密文的形式显示；

若有新配置文件下发，应用程序获取新配置文件；

将新配置文件加载到应用程序的容器的第一运行目录中。

本申请还提供一种基于kubernetes的应用配置管理系统。

所述基于kubernetes的应用配置管理系统，应用前述内容提及的基于kubernetes的应用配置管理方法。

所述基于kubernetes的应用配置管理系统包括至少一个容器、控制平台、公共控制平台和私有控制平台。所述容器包括app配置模块和私有配置模块；所述容器搭载有一个应用程序。所述控制平台与容器通信连接。所述控制平台包括公共控制平台和私有控制平台。所述公共控制平台与所述app配置模块通信连接。所述私有控制平台分别与所述app配置模块、所述私有配置模块通信连接。

本申请涉及一种基于kubernetes的应用配置管理方法与系统，控制平台通过将不同类型的配置文件分别应用到容器的不同配置模块中，实现了在开发人员无感的情况下，使应用程序获取到对应的配置文件。并且针对私密配置文件，控制平台将私密配置文件的配置值以加密算法加密存放于私有配置模块中，该私密配置文件不会对OPS运维人员以外的人员公开，实现了高保密性的效果。

附图说明

图1为本申请一实施例提供的基于kubernetes的应用配置管理方法的流程示意图；

图2为本申请一实施例提供的基于kubernetes的应用配置管理系统的结构示意图。

附图标记：

10-容器；110-app配置模块；120-私有配置模块；20-控制平台；

210-公共控制平台；220-私有控制平台

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供一种基于kubernetes的应用配置管理方法。需要说明的是，本申请提供的基于kubernetes的应用配置管理方法的应用于处于kubernetes容器编排引擎下的各个容器中的应用程序。

此外，本申请提供的基于kubernetes的应用配置管理方法不限制其执行主体。可选地，本申请提供的基于kubernetes的应用配置管理方法的执行主体的可以为一种基于kubernetes构建的应用配置管理系统或终端。具体地，本申请提供的基于kubernetes的应用配置管理方法的执行主体的可以为基于kubernetes构建的应用配置管理系统或终端中的一个或多个处理器。

所述基于kubernetes构建的应用配置管理系统可以有多个容器10。应用程序搭载于容器10之中，容器10是应用程序的运行环境。

如图1所示，在本申请的一实施例中，所述基于kubernetes的应用配置管理方法包括如下步骤S100至步骤S600：

S100，应用程序检测当前运行环境。进一步地，应用程序判断当前运行环境是线上运行环境还是本地测试环境。

具体地，本地测试环境可以理解为一个远程的配置环境。

S200，若当前运行环境是线上运行环境，则应用程序监控配置文件的下发状态，判断是否有新配置文件下发。

具体地，由于是线上运行环境，因此容器10和控制平台20是近程通信的，应用程序可以监控配置文件的下发状态，以判断是否有新配置文件下发。

S300，控制平台20将不同类型的配置文件下发至与应用程序对应的容器10的不同位置。控制平台20包括公共控制平台210和私有控制平台220。配置文件包括普通配置文件和私密配置文件。

具体地，普通配置文件属于私密性较低的配置文件。私密配置文件属于私密性较高的配置文件。本实施例中，控制平台20可以实现不同私密性等级的配置文件自动派发至容器10的不同位置。

所述控制平台20将不同类型的配置文件下发至与应用程序对应的容器10的不同位置的步骤，即所述步骤S300具体包括：

S310，公共控制平台210将普通配置文件下发至与应用程序对应的容器10的app配置模块110。

具体地，开发人员只能浏览普通配置文件。app配置模块110可以为app-configmap。

S320，私有控制平台220将私密配置文件分别下发至与应用程序对应的app配置模块110和与应用程序对应的私有配置模块120。所述app配置模块110接收的私密配置文件包括配置文件名称。所述私有配置模块120接收的私密配置文件包括配置文件名称和配置值。所述配置值以密文的形式显示。

具体地，私有配置模块120可以为shaman-secret。所述配置值可以任意加密方式进行预先加密。可选地，所述配置值可以sha256的形式进行加密。只有OPS运维人员知晓配置值的明文，有且仅有OPS运维人员可以对私有控制平台220下发的所有数据进行调控。

开发人员通过应用程序浏览私密配置文件时，由于配置值是以密文形式显示，因此开发人员只知晓私密配置文件的配置文件名称，不知晓配置值，通过这种方式可以保障私密配置文件的安全性。

S400，若有新配置文件下发，应用程序获取新配置文件。

S600，将新配置文件加载到应用程序的容器10的第一运行目录中。

具体地，若有新配置文件下发，则会自动下发至app配置模块110或私有配置模块120中，应用程序可以获取新配置文件，并将新配置文件加载到应用程序的容器10的第一运行目录中。

当普通配置文件被私自删除时，会触发配置文件的下发请求。此时，应用程序主动向公共控制平台210请求再次下发普通配置文件，保证配置文件不丢失。

本实施例中，控制平台20通过将不同类型的配置文件分别应用到容器10的不同配置模块中，实现了在开发人员无感的情况下，使应用程序获取到对应的配置文件。并且针对私密配置文件，控制平台20将私密配置文件的配置值以加密算法加密存放于私有配置模块120中，该私密配置文件不会对OPS运维人员以外的人员公开，实现了高保密性的效果。

此外，本实施例的技术方案还具有便捷性，能够实现配置文件的自动分发。

在本申请的一实施例中，所述配置文件具有等级标签，所述等级标签显示第一等级、第二等级和第三等级中的一种，第一等级为针对全部命名空间下发的配置文件，第二等级为针对唯一命名空间下发的配置文件，第三等级为针对唯一应用程序下发的配置文件。一个命名空间包括多个应用程序。

具体地，例如，1个命名空间有10个应用程序，且整个kubernetes运行环境下有3个命名空间，那么当针对全部命名空间下发配置文件时，可以向全部30个应用程序所在的容器10同时发送一份配置文件，这就是第一等级的配置文件下发。同理，也可以只针对某一个应用程序，下发一份配置文件，那么这就是第三等级的配置文件下发。

本实施例中，通过将配置文件按等级下发，使得配置文件的下发的可控力度高，不会浪费容器10的存储空间和无意义的配置文件下发，干扰其他容器10中的数据进行交互。

在本申请的一实施例中，在所述步骤S300中，控制平台还依据配置文件的等级标签下发配置文件。

具体地，当控制平台下发配置文件至容器10时，不但将不同类型的配置文件下发至与应用程序对应的容器10的不同位置，还根据等级标签下发配置文件。

本实施例中，通过在下发配置文件时同时依据配置文件的等级和类型，使得配置更效率化，安全化。

可选地，如果应用程序接受到了相同等级标签的两个或两个以上不同的配置文件，则应用程序向控制平台发送警示消息。例如，对一个应用程序发送了第三等级的两个配置文件，应用程序拒绝配置该配置文件，并向控制平台发送警示信息，提示OPS运维人员及时修改。另外，当配置文件中出现不合规的配置时，例如，同一个配置文件里出现多个相同的配置项，这时应用程序也拒绝配置该配置文件，并向控制平台发送警示信息。

在本申请的一实施例中，在S500之前，所述基于kubernetes的应用配置管理方法还包括如下步骤S510至步骤S541：

S510，应用程序判断是否接收到多种新配置文件。

S521，若接收到多种新配置文件，则应用程序判断多种新配置文件的配置文件名称是否相同。

S531，若多种新配置文件的配置文件名称相同，则进一步判断多种新配置文件的配置值是否相同。

S541，若多种新配置文件的配置值不同，则依次读取每一个新配置文件的等级标签，选取等级数值最大的配置文件执行后续步骤S600。

具体地，本实施例规定了同时出现不同等级标签的多个配置文件发送到统一应用程序时，应用程序启用优先级处理，优先选择等级数值大的配置文件进行配置。可以理解，第三等级的配置优先级大于第二等级的配置优先级大于第一等级的配置优先级。

本实施例中,通过不同等级标签的多个配置文件发送到统一应用程序时，应用程序优先选取等级数值最大的配置文件进行配置，避免了应用程序不知道具体配置哪一个配置文件的BUG问题。

在本申请的一实施例中，在所述步骤S600之后，所述基于kubernetes的应用配置管理方法还包括如下步骤S710至步骤S721：

S710，应用程序判断新配置文件是普通配置文件还是私密配置文件。

S721，若新配置文件是私密配置文件，则应用程序读取app配置模块110中，新配置文件的配置文件名称，并以软连接的形式读取私有配置模块120中，新配置文件的的配置值，基于所述配置文件名称和所述配置值进行解密，生成明文形式的新配置文件。

具体地，当新配置文件是私密配置文件时，应用程序将通过软连接方式从私有控制平台220中获取私密配置文件对应加密的配置值之后，进行解密形成明文密码，便于后续加载到内存供应用程序使用。

本实施例中，应用程序通过软连接的形式读取私有配置模块120中，新配置文件的的配置值，基于所述配置文件名称和所述配置值进行解密，实现了私密配置文件的解密。

在本申请的一实施例中，在所述步骤S721之后，所述基于kubernetes的应用配置管理方法还包括如下步骤S731至步骤S733：

S731，应用程序进一步判断新配置文件是动态配置文件还是静态配置文件。

S732，若新配置文件是动态配置文件，则应用程序将新配置文件从第一运行目录加载到应用程序的内存中。

具体地，如果新配置文件是动态配置文件，那么直接加载即可，动态配置文件的特点是及时加载，及时能够生效。

S733，若新配置文件是静态配置文件，则应用程序维持当前状态，以使所述新配置文件在应用程序下一次重启时自动加载到应用程序的内存中。

具体地，动态配置文件的特点是无法及时生效，需要等到应用程序重启之后，应用程序方能自动读取，动加载到应用程序的内存中。

本实施例中，通过对配置文件是动态配置文件还是静态配置文件的判断，避免了配置文件因加载方式错误导致配置失败的问题。

在本申请的一实施例中，在所述步骤S710之后，所述基于kubernetes的应用配置管理方法还包括如下步骤：

S722，若新配置文件是普通配置文件，则应用程序直接执行所述步骤S731。

具体地，如果新配置文件是普通配置文件，则无需解密，直接执行后续步骤S731。此处不再赘述。

在本申请的一实施例中，在所述步骤S100之后，所述基于kubernetes的应用配置管理方法还包括如下步骤S810至步骤S840：

S810，若当前运行环境是线下测试环境，则应用程序进一步判断本地是否存在第二运行目录。

具体地，第二运行目录是区别于第一运行目录的，在线下测试环境中自动创建的线下工程配置目录。但是可能会存在也可能没有自动创建成功。

S820，若本地存在第二运行目录，则应用程序进一步判断第二运行目录是否存在应用程序所需求的配置文件。

具体地，在线下测试环境中，控制平台无法主动下发配置文件至容器10。那么需要判断本地的第二运行目录中是否已经存在应用程序所需求的配置文件。

应用程序所需求的配置文件就是与应用程序适配的，也必须的配置文件。

S830，若第二运行目录存在应用程序所需求的配置文件，则应用程序将第二运行目录中的配置文件加载到应用程序的内存中。

具体地，若第二运行目录存在应用程序所需求的配置文件，则应用程序直接加载即可。

S840，若第二运行目录不存在应用程序所需求的配置文件或本地不存在第二运行目录，则应用程序从线下测试环境中抓取应用程序所需求的配置文件。

具体地，这里是两个条件，一个是第二运行目录不存在应用程序，那么应用程序会从线下测试环境中抓取应用程序所需求的配置文件。另一个是本地不存在第二运行目录，应用程序也会从线下测试环境中抓取应用程序所需求的配置文件。

本实施例可以实现线下测试环境中远程对应用程序进行配置文件的配置。

在本申请的一实施例中，所述步骤S840包括如下步骤S840至步骤S844：

S841，若第二运行目录不存在应用程序所需求的配置文件或本地不存在第二运行目录或本地不存在第二运行目录，则应用程序判断应用程序所需求的配置文件为普通配置文件还是私密配置文件。

S842，若应用程序所需求的配置文件为普通配置文件，则应用程序从线下测试环境中读取与应用程序所需求的配置文件对应的配置文件名称和配置值。

S843，若新配置文件为私密配置文件，则应用程序从线下测试环境中读取与应用程序所需求的配置文件对应的配置文件名称。

S844，应用程序向私有控制平台220发送解密请求，以获取新配置文件对应的配置值，并基于所述配置文件名称和所述配置值进行解密，生成明文形式的配置文件。

具体地，本实施例中关于普通配置文件和私密配置文件的读取与解密，和所述步骤S710至步骤S721的原理相同，此处不再赘述。

第二运行目录可以具体为{repo}/shaman-config。线下测试环境本地具有的配置文件也可以及时更新，那么应用程序也可以随之及时进行动态更新。

本申请还提供一种基于kubernetes的应用配置管理系统。所述基于kubernetes的应用配置管理系统应用前述内容提及的基于kubernetes的应用配置管理方法。

如图2所示，在本申请的一实施例中，所述基于kubernetes的应用配置管理系统包括至少一个容器10、控制平台20、公共控制平台210和私有控制平台220。所述容器10包括app配置模块110和私有配置模块120。所述容器10搭载有一个应用程序。所述控制平台20与容器10通信连接。所述控制平台20包括公共控制平台210和私有控制平台220。所述公共控制平台210与所述app配置模块110通信连接。所述私有控制平台220分别与所述app配置模块110、所述私有配置模块120通信连接。

以上所述实施例的各技术特征可以进行任意的组合，各方法步骤也并不做执行顺序的限制，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (10)

1.一种基于kubernetes的应用配置管理方法，应用于kubernetes容器内的应用程序，其特征在于，所述方法包括：

S100，应用程序检测当前运行环境，判断当前运行环境是线上运行环境还是本地测试环境；

S200，若当前运行环境是线上运行环境，则应用程序监控配置文件的下发状态，判断是否有新配置文件下发；

S300，控制平台将不同类型的配置文件下发至与应用程序对应的容器的不同位置，控制平台包括公共控制平台和私有控制平台，配置文件包括普通配置文件和私密配置文件；

控制平台将不同类型的配置文件下发至与应用程序对应的容器的不同位置，包括：

S310，公共控制平台将普通配置文件下发至与应用程序对应的容器的app配置模块；

S320，私有控制平台将私密配置文件分别下发至与应用程序对应的app配置模块和与应用程序对应的私有配置模块，所述app配置模块接收的私密配置文件包括配置文件名称，所述私有配置模块接收的私密配置文件包括配置文件名称和配置值；所述配置值以密文的形式显示；

S400，若有新配置文件下发，应用程序获取新配置文件；

S600，将新配置文件加载到应用程序的容器的第一运行目录中。

2.根据权利要求1所述的基于kubernetes的应用配置管理方法，其特征在于，所述配置文件具有等级标签，所述等级标签显示第一等级、第二等级和第三等级中的一种，第一等级为针对全部命名空间下发的配置文件，第二等级为针对唯一命名空间下发的配置文件，第三等级为针对唯一应用程序下发的配置文件；一个命名空间包括多个应用程序。

3.根据权利要求2所述的基于kubernetes的应用配置管理方法，其特征在于，在所述步骤S300中，控制平台还依据配置文件的等级标签下发配置文件。

4.根据权利要求3所述的基于kubernetes的应用配置管理方法，其特征在于，在所述步骤S500之前，所述方法还包括：

S510，应用程序判断是否接收到多种新配置文件；

S521，若接收到多种新配置文件，则应用程序判断多种新配置文件的配置文件名称是否相同；

S531，若多种新配置文件的配置文件名称相同，则进一步判断多种新配置文件的配置值是否相同；

S541，若多种新配置文件的配置值不同，则依次读取每一个新配置文件的等级标签，选取等级数值最大的配置文件执行后续步骤S600。

5.根据权利要求4所述的基于kubernetes的应用配置管理方法，其特征在于，在所述步骤S600之后，所述方法还包括：

S710，应用程序判断新配置文件是普通配置文件还是私密配置文件；

S721，若新配置文件是私密配置文件，则应用程序读取app配置模块中，新配置文件的配置文件名称，并以软连接的形式读取私有配置模块中，新配置文件的的配置值，基于所述配置文件名称和所述配置值进行解密，生成明文形式的新配置文件。

6.根据权利要求5所述的基于kubernetes的应用配置管理方法，其特征在于，在所述步骤S721之后，所述方法还包括：

S731，应用程序进一步判断新配置文件是动态配置文件还是静态配置文件；

S732，若新配置文件是动态配置文件，则应用程序将新配置文件从第一运行目录加载到应用程序的内存中；

S733，若新配置文件是静态配置文件，则应用程序维持当前状态，以使所述新配置文件在应用程序下一次重启时自动加载到应用程序的内存中。

7.根据权利要求6所述的基于kubernetes的应用配置管理方法，其特征在于，在所述步骤S710之后，所述方法还包括：

S722，若新配置文件是普通配置文件，则应用程序直接执行所述步骤S731。

8.根据权利要求7所述的基于kubernetes的应用配置管理方法，其特征在于，在所述步骤S100之后，所述方法还包括：

S810，若当前运行环境是线下测试环境，则应用程序进一步判断本地是否存在第二运行目录；

S820，若本地存在第二运行目录，则应用程序进一步判断第二运行目录是否存在应用程序所需求的配置文件；

S830，若第二运行目录存在应用程序所需求的配置文件，则应用程序将第二运行目录中的配置文件加载到应用程序的内存中；

S840，若第二运行目录不存在应用程序所需求的配置文件或本地不存在第二运行目录或本地不存在第二运行目录，则应用程序从线下测试环境中抓取应用程序所需求的配置文件。

9.根据权利要求8所述的基于kubernetes的应用配置管理方法，其特征在于，所述步骤S840包括：

S841，若第二运行目录不存在应用程序所需求的配置文件或本地不存在第二运行目录或本地不存在第二运行目录，则应用程序判断应用程序所需求的配置文件为普通配置文件还是私密配置文件；

S842，若应用程序所需求的配置文件为普通配置文件，则应用程序从线下测试环境中读取与应用程序所需求的配置文件对应的配置文件名称和配置值；

S843，若新配置文件为私密配置文件，则应用程序从线下测试环境中读取与应用程序所需求的配置文件对应的配置文件名称；

S844，应用程序向私有控制平台发送解密请求，以获取新配置文件对应的配置值，并基于所述配置文件名称和所述配置值进行解密，生成明文形式的配置文件。

10.一种基于kubernetes的应用配置管理系统，其特征在于，应用前述权利要求1-9中任意一项提及的基于kubernetes的应用配置管理方法，所述基于kubernetes的应用配置管理系统包括：

至少一个容器，所述容器包括app配置模块和私有配置模块；所述容器搭载有一个应用程序；

控制平台，与容器通信连接，所述控制平台包括：

公共控制平台，与所述app配置模块通信连接；

私有控制平台，分别与所述app配置模块、所述私有配置模块通信连接。

Images