CN115543548B - 一种容器组的配置方法、装置、设备及可读存储介质 - Google Patents

Abstract

本申请涉及容器技术领域，具体公开了一种容器组的配置方法、装置、设备及可读存储介质，改无状态控制器中原有的业务容器模板为初始化容器模板加业务容器模板，初始化容器模板中设有自适应参数获取脚本，用于在要创建的容器组中，在初始化容器被首先创建后，自动获取配置参数并生成所在容器组的配置文件；业务应用容器模板中挂载配置文件的路径，在业务应用容器生成后，根据该路径获取配置文件并根据配置参数完成应用配置。实现了单个无状态控制器创建容器组时差异化自适应配置参数，使得k8s集群中同一个无状态控制器内的容器组能够根据自身所处的位置动态生成、加载不同的配置参数，降低k8s中应用部署的复杂度，提高k8s中容器的灵活性。

Description

一种容器组的配置方法、装置、设备及可读存储介质

技术领域

本申请涉及容器技术领域，特别是涉及一种容器组的配置方法、装置、设备及可读存储介质。

背景技术

Kubernetes（又称k8s）是一个开源的容器集群管理系统，在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。k8s也是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时k8s提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

容器组（Pod）是k8s中的最小调度单元。一个容器组封装一个容器（container）（也可以封装多个容器）。一个容器组里的容器共享存储、网络等。也就是说，可以把整个容器组看作虚拟机，每个容器相当于运行在虚拟机的进程。同一个容器组里的所有容器都被统一安排和调度。

运行控制器（Controller Manager）是k8s的核心组件，是k8s集群内部的管理控制中心，负责k8s集群内的节点（Node）、容器组副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）等资源的管理，当某个节点意外宕机时，运行控制器会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

生产环境中可以用运行控制器中的多种控制器创建和管理多个容器组。控制器在容器组失败的情况下可以处理副本、更新以及自动修复。控制器可以指定创建的容器组副本数，使其管理的容器组始终维持在指定副本数量。例如，如果某个节点发生故障，则控制器会注意到该节点上的容器组已停止工作，并创建一个新的容器组替换故障的容器组。调度程序将替换的容器组放置到健康的节点上。常见的用于管理容器组的控制器有Deployment（一种无状态控制器，用于管理无状态应用）、StatefulSet（有状态控制器，用于管理有状态应用）、DaemonSet（在节点上以守护进程的方式运行一个指定的容器组副本，例如监控节点在收集节点上的日志时，可使用 DaemonSet）、Job（临时控制器，使用Job 执行任务，执行完后结束）等。

控制器是通过容器组模板来创建和管理容器组的，容器组模板（Pod Template）是用于创建容器组的规范，并且包含在Deployment等控制器中。每个控制器使用自己内部的容器组模板来创建实际的容器组，同一个控制器实例内的容器组模板相同。

很多生产环境中的应用程序配置较为复杂，可能需要多个配置（config）文件、命令行参数和环境变量的组合。使用容器部署时，应该把配置从应用程序镜像中解耦出来，以保证镜像的可移植性。在k8s1.2版本后引入配置地图（ConfigMap）来处理这种类型的配置数据。

ConfigMap是存储通用的配置变量的，类似于配置文件，使用户可以将分布式系统中用于不同模块的环境变量统一到一个对象中管理；而它与配置文件的区别在于它是存在集群的“环境”中的，并且支持k8s集群中所有通用的操作调用方式。从数据角度来看，ConfigMap的类型只是键值组，用于存储被容器组访问的信息。这与secret的设计理念有异曲同工之妙，主要区别在于ConfigMap通常不用于存储敏感信息，而只存储简单的文本信息。在创建容器组时，通过绑定ConfigMap，容器组内的应用可以直接引用ConfigMap的配置。相当于利用ConfigMap为应用/运行环境封装配置。容器组使用ConfigMap通常用于设置环境变量的值、设置命令行参数、创建配置文件。

伴随着云原生技术和云市场的不断成熟，k8s管理的应用的复杂度也会随之增加。在实际的生产过程中，对于k8s这种使用无状态控制器通过统一模板创建容器组的模式，有一个实际的场景问题需要解决，那就是容器组的差异化自适应参数配置问题。

具体来说，有些容器组中的程序，需要配置信息与自身所在的运行环境相符。例如，有些程序运行在多网卡节点上时，需要配置所使用的网卡地址（ip）；有些容器组运行在带有图形处理器（Graphics Processing Unit，GPU）的节点上时，需要配置额外的GPU驱动信息，而在普通节点上不需要；有些容器组运行在不同硬件规格的节点上时，需要根据硬件配置调整自身的线程数、超分比等性能参数。

在这种情况下，无状态控制器提供的单一容器组模板，或采用k8s默认的ConfigMap方式为容器组挂载配置文件，那么该无状态控制器创建的所有容器组将被挂载同一份配置文件，无法实现容器组的差异化自适应参数配置。如果需要创建配置不同的容器组，只能使用不同的无状态控制器进行控制，例如使用Deployment A控制普通容器组，使用Deployment B控制GPU节点上的容器组，那么一方面会增加管理的整体复杂度，另一方面如果出现另一个维度的差异化配置，不同的无状态控制器之间也很难实现正交的划分。最终随着差异化配置的需求的增多，对于同一个应用的多副本部署的情况，有多少的差异化配置，就需要多少个无状态控制器进行控制，这就类似于传统的指定节点进行差异化分发的方案，失去了k8s动态调度、统一管理的优点。

而若采用为无状态控制器绑定不同的ConfigMap的方式来为同一个无状态控制器下的容器组实现差异化配置，即有多少差异化配置，就为无状态控制器绑定多少ConfigMap，则会造成大量的重复性配置代码出现，且需要用户端在创建好的容器组的业务应用容器中更改业务代码以绑定到不同的ConfigMap上，对业务逻辑产生影响，实现与管理逻辑都非常麻烦。且绑定后的ConfigMap也是不可更改的，同样丧失了k8s动态调度的优势。

提供一种k8s集群中单个无状态控制器内容器组参数差异化自适应配置的方案，使得k8s集群中同一个无状态控制器内的容器组能够根据自身所处的位置动态生成、加载不同的配置参数，降低k8s中应用部署的复杂度，提高k8s中容器的灵活性，是本领域技术人员需要解决的技术问题。

发明内容

本申请的目的是提供一种容器组的配置方法、装置、设备及可读存储介质，用于实现k8s集群中单个无状态控制器内容器组参数差异化自适应配置，使得k8s集群中同一个无状态控制器内的容器组能够根据自身所处的位置动态生成、加载不同的配置参数，降低k8s中应用部署的复杂度，提高k8s中容器的灵活性。

为解决上述技术问题，本申请提供一种容器组的配置方法，应用于无状态控制器所在节点，包括：

在接收到容器组创建命令后，调用预设的初始化容器模板和预设的业务应用容器模板；

利用所述初始化容器模板为容器组创建初始化容器，以使所述初始化容器运行所述初始化容器模板中的自适应参数获取脚本获取配置参数并生成所述容器组的配置文件；

利用所述业务应用容器模板为所述容器组创建业务应用容器，以使所述业务应用容器基于所述业务应用容器模板中挂载的所述配置文件的路径获取所述配置文件，并根据所述配置参数完成应用配置。

可选的，所述配置文件具体存储于所述容器组的临时存储卷。

可选的，所述临时存储卷具体存储于所述容器组所在节点的后端存储。

可选的，所述临时存储卷具体存储于所述容器组的临时文件系统，且所述临时存储卷的临时存储卷媒介字段定义为内存。

可选的，所述配置文件具体存储于预先为所述容器组分配的共享存储空间。

可选的，所述初始化容器获取所述配置参数并生成所述容器组的配置文件，具体包括：

所述初始化容器获取所述容器组所在节点的环境信息，以确定第一配置参数；

所述初始化容器根据所述第一配置参数生成所述配置文件。

可选的，所述初始化容器获取所述容器组所在节点的环境信息，以确定第一配置参数，具体为：

所述初始化容器基于所述初始化容器模板中挂载的所述容器组所在节点的系统目录，获取所述容器组所在节点的环境信息，以确定所述第一配置参数。

可选的，所述第一配置参数具体包括：系统小型计算机系统接口参数、系统控制群组参数、标准程序设计库模块参数。

可选的，所述初始化容器获取所述配置参数并生成所述容器组的配置文件，具体包括：

所述初始化容器获取所述容器组所在节点的环境信息，以确定第一配置参数；

所述初始化容器基于所述自适应参数获取脚本记载的应用配置中心地址，向应用配置中心上传包含所述第一配置参数的配置请求；

所述初始化容器接收所述应用配置中心分配的第二配置参数；

所述初始化容器根据所述第一配置参数和所述第二配置参数生成所述配置文件。

可选的，所述第二配置参数具体为高性能配置参数、高可用配置参数、均衡配置参数、低功耗配置参数中的一种。

可选的，所述第二配置参数具体为管理员配置的与所述容器组所在节点对应的运行策略配置参数。

可选的，所述第二配置参数具体为调用监控脚本分析所述容器组所在节点的运行状态后生成的运行策略配置参数。

可选的，所述第二配置参数具体为所述应用配置中心在接收到所述第一配置参数后周期性下发的运行策略配置参数。

可选的，所述第二配置参数具体为所述应用配置中心在接收到所述第一配置参数后，在所述容器组所在节点的运行状态参数被监控到运行状态变化时下发的运行策略配置参数。

可选的，所述初始化容器向所述应用配置中心上传包含所述第一配置参数的配置请求，具体为：

所述初始化容器周期性向所述应用配置中心上传所述配置请求。

可选的，所述初始化容器向所述应用配置中心上传包含所述第一配置参数的配置请求，具体为：

所述初始化容器在所述第一配置参数发生变更后，向所述应用配置中心上传包含变更后的所述第一配置参数的所述配置请求。

可选的，所述业务应用容器基于所述业务应用容器模板中挂载的所述配置文件的路径获取所述配置文件，具体为：

所述业务应用容器基于写在所述业务应用容器的业务配置参数中的所述配置文件的路径获取所述配置文件。

为解决上述技术问题，本申请还提供一种容器组的配置装置，包括：

调用单元，用于在接收到容器组创建命令后，调用预设的初始化容器模板和预设的业务应用容器模板；

第一创建单元，用于利用所述初始化容器模板为容器组创建初始化容器，以使所述初始化容器运行所述初始化容器模板中的自适应参数获取脚本获取配置参数并生成所述容器组的配置文件；

第二创建单元，用于利用所述业务应用容器模板为所述容器组创建业务应用容器，以使所述业务应用容器基于所述业务应用容器模板中挂载的所述配置文件的路径获取所述配置文件，并根据所述配置参数完成应用配置。

为解决上述技术问题，本申请还提供一种容器组的配置设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序，所述计算机程序被所述处理器执行时实现如上述任意一项所述容器组的配置方法的步骤。

为解决上述技术问题，本申请还提供一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述任意一项所述容器组的配置方法的步骤。

本申请所提供的容器组的配置方法，改无状态控制器中原有的业务容器模板为初始化容器模板加业务容器模板，初始化容器模板中设有自适应参数获取脚本，在要创建的容器组中，在初始化容器被首先创建后，会自动获取配置参数并生成所在容器组的配置文件；业务应用容器模板中挂载配置文件的路径，在业务应用容器生成后，根据该路径获取配置文件，并根据配置参数完成应用配置。实现了单个无状态控制器创建容器组时差异化自适应配置参数，使得k8s集群中同一个无状态控制器内的容器组能够根据自身所处的位置动态生成、加载不同的配置参数，降低了k8s中应用部署的复杂度，提高了k8s中容器的灵活性。

本申请还提供一种容器组的配置装置、设备及可读存储介质，具有上述有益效果，在此不再赘述。

附图说明

为了更清楚的说明本申请实施例或现有技术的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种容器组的配置方法的流程图；

图2为本申请实施例提供的一种组件部署架构示意图；

图3为本申请实施例提供的一种容器组的配置装置的结构示意图；

图4为本申请实施例提供的一种容器组的配置设备的结构示意图。

具体实施方式

本申请的核心是提供一种容器组的配置方法、装置、设备及可读存储介质，用于实现k8s集群中单个无状态控制器内容器组参数差异化自适应配置，使得k8s集群中同一个无状态控制器内的容器组能够根据自身所处的位置动态生成、加载不同的配置参数，降低k8s中应用部署的复杂度，提高k8s中容器的灵活性。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

实施例一

图1为本申请实施例提供的一种容器组的配置方法的流程图；图2为本申请实施例提供的一种组件部署架构示意图。

如图1所示，本申请实施例提供的容器组的配置方法应用于无状态控制器所在节点，包括：

S101：在接收到容器组创建命令后，调用预设的初始化容器模板和预设的业务应用容器模板。

S102：利用初始化容器模板为容器组创建初始化容器，以使初始化容器运行初始化容器模板中的自适应参数获取脚本获取配置参数并生成容器组的配置文件。

S103：利用业务应用容器模板为容器组创建业务应用容器，以使业务应用容器基于业务应用容器模板中挂载的配置文件的路径获取配置文件，并根据配置参数完成应用配置。

在具体实施中，无状态控制器为k8s提供的控制器组件，运行于容器集群中的物理节点上。针对业务应用提供服务时，由无状态控制器创建的容器组（Pod）也可能运行于容器集群中的不同物理节点。

对于S101来说，现有的无状态控制器采用统一的容器组模板创建业务应用容器后，业务应用容器挂载业务应用正常运行所需的系统目录。但采用这种方式，由无状态控制器创建的多个业务应用容器只能采用同样的配置文件。而在本申请实施例提供的容器组的配置方法中，改无状态控制器原本仅有业务应用容器模板为设有初始化容器模板以及业务应用容器模板，由容器集群中首个创建的初始化容器来获取差异化的配置参数、生成配置文件，供后续创建的业务应用容器挂载，实现不同容器组的差异化配置，无需挂载ConfigMap，也不会对业务应用逻辑产生影响。

具体地，在创建需要进行差异化配置的无状态负载时，使用k8s的初始化容器（Init-container）机制，为业务应用的容器组模板增加初始化容器模板，该初始化模板挂载有写入配置文件的目录，同时设有用于获取配置参数生成配置文件的自适应参数获取脚本。

同时对业务应用容器模板进行改动，为业务应用容器模板挂载写入配置文件的目录，以使创建的业务应用容器能够获取差异化的配置文件。

对于S102来说，初始化容器是k8s的容器组机制中首个创建的容器，故可以保证该初始化容器先于业务应用容器运行。初始化容器被创建后，运行自适应参数获取脚本，即可根据预先编写的逻辑自适应获取所需的配置参数。例如，初始化容器获取配置参数并生成容器组的配置文件，具体可以包括：初始化容器获取容器组所在节点的环境信息，以确定第一配置参数；初始化容器根据第一配置参数生成配置文件。

其中，初始化容器获取容器组所在节点的环境信息，以确定第一配置参数，具体可以为：初始化容器基于初始化容器模板中挂载的容器组所在节点的系统目录，获取容器组所在节点的环境信息，以确定第一配置参数。

即在初始化容器模板中，不仅挂载有预先为配置文件分配的目录，还挂载有系统目录，并设置自适应参数获取脚本的运行逻辑为根据初始化容器所在容器组所在节点的系统目录确定该节点的环境信息，进而生成配置文件。

则初始化容器模板中预先挂载有生成配置文件所必需的获取系统信息的目录，可以包括/etc/iscsi（系统小型计算机系统接口目录）、/sys/fs/cgroup（系统控制群组目录）、/lib/modules（标准程序设计库模块目录）等。由此获取的第一配置参数具体可以包括：系统小型计算机系统接口参数、系统控制群组参数、标准程序设计库模块参数等。

则为了实现S102的创建初始化容器与运行自适应参数获取脚本生成配置文件的过程，在无状态控制器中，为需要动态生成差异化配置的无状态负载模板增加初始化容器模板和业务应用容器模板，其内部主要逻辑至少包括：

挂载动态生成配置所必须的目录，如/etc/iscsi（系统小型计算机系统接口目录）、/sys/fs/cgroup（系统控制群组目录）、/lib/modules（标准程序设计库模块目录）等；

挂载预先为配置文件分配的目录，用于写入生成的配置文件，并作为共享卷同时挂载给业务应用容器使用；

开发业务逻辑，根据所在容器组的所在节点的信息，自动生成所需的配置文件；

将配置文件写入预先为配置文件分配的目录。

其中，预先为配置文件分配的目录可以存储于预先为容器组分配的共享存储空间。该共享存储空间可以来源于容器组所在节点的任意后端存储，或远程的其他存储资源。

除了初始化容器刚被创建后运行自适应参数获取脚本生成配置文件，也可以设计自适应参数获取脚本在容器组运行过程中，如获取配置参数的信息源发生变化，则更新配置参数并更新配置文件。例如采用挂载所在节点的系统目录的方式来获取所在节点的属性的第一配置参数，则随着系统目录中参数的更新，第一配置参数进行适应改变，同时更新配置文件。而当容器组迁移后，根据系统目录路径获取迁移后的节点的系统目录，更新第一配置参数并更新配置文件。

对于S103来说，按照k8s机制，在无状态控制器创建的容器组中，业务应用容器后于初始化容器创建，且根据预设的挂载有预先为配置文件分配的目录的业务应用容器模板，创建的业务应用容器挂载到预先为配置文件分配的目录，这样就可以通过共享的卷目录，读取初始化容器启动完成后创建的配置文件，以根据该配置文件进行对业务应用的配置。

则S103中业务应用容器基于业务应用容器模板中挂载的配置文件的路径获取配置文件，具体可以为：业务应用容器基于写在业务应用容器的业务配置参数中的配置文件的路径获取配置文件。

由于业务应用和初始化配置文件的过程使用不同的容器，因此可以分别挂载各自所需的系统目录，业务应用容器中无需挂在单纯为了生成配置文件而挂载的系统目录，防止潜在的越权访问风险，且业务应用本身无需做任何修改，对业务应用代码无侵入。

如图2所示，记无状态控制器所在节点201为节点1，记无状态控制器创建的容器组1所在节点202为节点2，记无状态控制器创建的容器组2所在节点203为节点3。假设节点2为有8核32G CPU、有GPU的节点，节点3为有8核32G CPU、有大页内存的节点。应用本申请实施例提供的容器组的配置方法，则无状态控制器运行后调用预设的初始化容器模板和预设的业务应用容器模板，分别在节点2和节点3创建容器组1和容器组2。在节点2的容器组1中，首先创建容器组1中的初始化容器，初始化容器被创建后在节点2运行自适应参数获取脚本根据节点2的属性，创建配置文件1，而后创建业务应用容器，业务应用容器与初始化容器挂载配置文件所在目录，业务应用容器被创建后读取配置文件1。在节点3的容器组2中，首先创建容器组2中的初始化容器，初始化容器被创建后在节点3运行自适应参数获取脚本根据节点3的属性，创建配置文件2，而后创建业务应用容器，业务应用容器与初始化容器挂载配置文件所在目录，业务应用容器被创建后读取配置文件2。通过配置文件1和配置文件2的差异化，实现了容器组1的业务应用和容器组2的业务应用的差异化配置，且能够自动适应其所属环境的特性，当容器组重新被创建或迁移时，依然能够自适应获取配置参数实现差异化配置。

本申请实施例提供的容器组的配置方法，改无状态控制器中原有的业务容器模板为初始化容器模板加业务容器模板，初始化容器模板中设有自适应参数获取脚本，在要创建的容器组中，在初始化容器被首先创建后，会自动获取配置参数并生成所在容器组的配置文件；业务应用容器模板中挂载配置文件的路径，在业务应用容器生成后，根据该路径获取配置文件，并根据配置参数完成应用配置。实现了单个无状态控制器创建容器组时差异化自适应配置参数，使得k8s集群中同一个无状态控制器内的容器组能够根据自身所处的位置动态生成、加载不同的配置参数，降低了k8s中应用部署的复杂度，提高了k8s中容器的灵活性。

实施例二

在上述实施例的基础上，为方便对配置文件与容器组进行容器管理，在本申请实施例提供的容器组的配置方法中，采用容器组的临时存储卷（emptyDir）作为写入配置文件的目录。则在S102中，将配置文件存储于容器组的临时存储卷。

emptyDir顾名思义，是一个空目录，其生命周期和所属的容器组是完全一致的。emptyDir可以在同一容器组的不同容器之间共享工作工程中产生的文件。emptyDir类型的卷（Volume）在容器组分配到节点上时被创建，k8s会在节点上自动分配一个目录，因此无需指定宿主机节点上对应的目录文件。这个目录的初始内容为空。当容器组从节点上移除时，emptyDir中的数据会被永久删除。且容器的崩溃（crashing）事件不会导致emptyDir中的数据被删除。

在本申请实施例中，采用临时存储卷emptyDir存储容器组自适应生成的配置文件，临时存储卷emptyDir与所属容器组同生命周期，便于管理。

默认情况下，emptyDir可以使用任何类型的由节点提供的后端存储。则在本申请实施例提供的容器组的配置方法中，可以将临时存储卷存储于容器组所在节点的后端存储。此种方式下，临时存储卷占用容器组所在节点的内存资源。

在特殊场景下，也可以采用容器组的临时文件系统（tmpfs）作为emptyDir的可用存储资源。则也可以将临时存储卷存储于容器组的临时文件系统，且临时存储卷的临时存储卷媒介（emptyDir.medium）字段定义为内存（Memory）。这种设置，配置文件所在的卷的占用会消耗容器的内存份额，但作为临时文件可以供外部访问，以便获取容器组的配置信息实现监控功能。

实施例三

在上述实施例的基础上，为实现单个无状态控制器下为容器组配置更为复杂的配置参数，如运行策略参数，在本申请实施例提供的容器组的配置方法中，初始化容器获取配置参数并生成容器组的配置文件，具体可以包括：

初始化容器获取容器组所在节点的环境信息，以确定第一配置参数；

初始化容器基于自适应参数获取脚本记载的应用配置中心地址，向应用配置中心上传包含第一配置参数的配置请求；

初始化容器接收应用配置中心分配的第二配置参数；

初始化容器根据第一配置参数和第二配置参数生成配置文件。

在具体实施中，对于更加负载的应用配置文件，无法由应用自身根据系统信息生成的，或者需要较为复杂的逻辑判断的，可以设计一个应用配置中心的服务，在初始化容器启动时，可以获取到自身所在的节点当前信息，按需向应用配置中心发起请求，获取经应用配置中心动态计算的配置参数，生成所需的配置文件，写入预先为配置文件分配的目录。

将应用配置中心部署于需要动态形成差异化配置的业务应用所在的容器集群中。应用配置中心可以运行于无状态控制器所在节点、容器组所在节点之外的另一节点，如监控节点。

设计初始化容器模板中的自适应参数获取脚本在获取所在节点的属性作为第一配置参数后，再将包括第一配置参数的节点信息上传应用配置中心以获取应用配置中心分配的第二配置参数，初始化容器根据第一配置参数和第二配置参数生成配置文件。

则在无状态控制器的初始化容器模板中，除了本申请实施例一提供的内部主要逻辑之外，还包括：

开发业务逻辑，携带节点信息，访问容器集群的应用配置中心，由应用配置中心获取第二配置参数并返回给初始化容器；

根据第一配置参数和第二配置参数生成配置文件，写入预先为配置文件分配的目录。

其中，第一配置参数主要为容器组所在节点的系统信息，具体可以包括：系统小型计算机系统接口参数、系统控制群组参数、标准程序设计库模块参数等。

第二配置参数则可以为运行策略配置参数，即根据容器组所在节点的运行状态划分的运行策略对应的配置参数。则第二配置参数具体可以为：高性能配置参数、高可用配置参数、均衡配置参数、低功耗配置参数中的一种。

第二配置参数具体可以为管理员配置的与容器组所在节点对应的运行策略配置参数。由于运行策略配置参数的确定较为复杂，应用配置中心可以仅作为一个管理员管理容器组的平台，在平台上显示不同容器组所在节点的第一配置参数以供管理员查看，并由管理员根据经验分配第二配置参数。

进一步的，可以在应用配置中心预先开发接口，允许系统管理员配置各个应用的默认配置文件模板，如高性能模板、高可用模板、均衡模板、低功耗模板等，由管理员进行策略配置，通过来自容器组的请求信息，自动分析容器组所在节点的综合水平，选择合适的模板进行下发。

需要说明的是，应用配置中心需要在获取容器组所在节点的第一配置参数后才获悉容器组所在节点的信息，进而分配第二配置参数。但根据容器组所在节点的需求，在首次分配第二配置参数之后，容器组所在节点可以按需上传第一配置参数，应用配置中心所在节点也可以按预设规则下发第二配置参数。

则S102中初始化容器向应用配置中心上传包含第一配置参数的配置请求，具体可以为：初始化容器周期性向应用配置中心上传配置请求。即初始化容器可以每第一周期向应用配置中心发送携带第一配置参数的配置请求，以供应用配置中心确认是否需要更新对该容器组的第二配置参数。

或者，S102中初始化容器向应用配置中心上传包含第一配置参数的配置请求，具体可以为：初始化容器在第一配置参数发生变更后，向应用配置中心上传包含变更后的第一配置参数的配置请求。即初始化容器在刚被创建后获取第一配置参数后，监控第一配置参数的变更情况，在发现第一配置参数发生变动后，再向应用配置中心发送携带第一配置参数的配置请求，以供应用配置中心重新分配与更新后的第一配置参数对应的第二配置参数。

如图2所示，记应用配置中心所在节点204为节点4，在运行于节点2的容器组1的初始化容器被创建后，向应用配置中心上传容器组1的第一配置参数，应用配置中心向该初始化容器下发第二配置参数，容器组1的初始化容器根据第一配置参数和第二配置参数生成配置文件1。运行于节点3的容器组2的初始化容器被创建后，向应用配置中心上传容器组2的第一配置参数，应用配置中心向该初始化容器下发第二配置参数，容器组2的初始化容器根据第一配置参数和第二配置参数生成配置文件2。通过应用配置中心，进一步实现容器组1和容器组2的复杂差异化。

本申请实施例提供的容器组的配置方法，通过设计应用配置中心，设计初始化容器在启动后将获取的第一配置参数上传应用配置中心，应用配置中心为容器组分配第二配置参数，初始化容器根据第一配置参数和第二配置参数生成配置文件，从而能够根据节点运行状态进行动态配置，进一步提高单个无状态控制器内容器组的自适应参数配置的灵活性。

实施例四

在上述实施例的基础上，在本申请实施例提供的容器组的配置方法中，基于应用配置中心，可以实现对第二配置参数的自动分配。具体可以设计应用配置中心基于监控系统获得的容器组所在节点的运行状态，进行分析后，自动确定对容器组的第二配置参数。则第二配置参数具体可以为调用监控脚本分析容器组所在节点的运行状态后生成的运行策略配置参数。

在具体实施中，通过开发应用配置中心的接口，对接k8s集群的监控系统，动态感知集群当前的整体负载水平、业务流量、集群规模等，为动态生成配置文件内容字段提供参考。

通过对接k8s集群的监控系统，应用配置中心结合初始化容器上传的所在节点的第一配置参数，以及监控系统监控得到的容器组所在节点的运行状态，通过更加丰富的性能参数进行自动化的综合决策，动态生成最适合容器组的第二配置参数，进行下发。

在上述实施例中提到，在首次分配第二配置参数之后，容器组所在节点可以按需上传第一配置参数，应用配置中心所在节点也可以按预设规则下发第二配置参数。则在本申请实施例提供的容器组的配置方法中，第二配置参数具体可以为应用配置中心在接收到第一配置参数后周期性下发的运行策略配置参数。即应用配置中心可以在接收到第一配置参数后，每第二周期综合容器组所在节点的运行状态和容器组的第一配置参数生成第二配置参数并下发。

或者，第二配置参数具体可以为应用配置中心在接收到第一配置参数后，在容器组所在节点的运行状态参数被监控到运行状态变化时下发的运行策略配置参数。即应用配置中心在接收到第一配置参数后，定时或实时地根据监控系统提供的容器组所在节点的运行状态以及第一配置参数确定是否需要更新分配给容器组的第二配置参数，在更新第二配置参数后再将第二配置参数下发到容器组所在节点。

本申请实施例提供的容器组的配置方法，通过设计提供运行策略配置参数的应用配置中心对接k8s集群的监控系统，实现综合容器组所在节点的运行状态以及第一配置参数生成对容器组的运行策略配置参数，提高对单个无状态控制器内容器组自适应参数配置的智能水平。

上文详述了容器组的配置方法对应的各个实施例，在此基础上，本申请还公开了与上述方法对应的容器组的配置装置、设备及可读存储介质。

实施例五

图3为本申请实施例提供的一种容器组的配置装置的结构示意图。

如图3所示，本申请实施例提供的容器组的配置装置包括：

调用单元301，用于在接收到容器组创建命令后，调用预设的初始化容器模板和预设的业务应用容器模板；

第一创建单元302，用于利用初始化容器模板为容器组创建初始化容器，以使初始化容器运行初始化容器模板中的自适应参数获取脚本获取配置参数并生成容器组的配置文件；

第二创建单元303，用于利用业务应用容器模板为容器组创建业务应用容器，以使业务应用容器基于业务应用容器模板中挂载的配置文件的路径获取配置文件，并根据配置参数完成应用配置。

由于装置部分的实施例与方法部分的实施例相互对应，因此装置部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

实施例六

图4为本申请实施例提供的一种容器组的配置设备的结构示意图。

如图4所示，本申请实施例提供的容器组的配置设备包括：

存储器410，用于存储计算机程序411；

处理器420，用于执行计算机程序411，该计算机程序411被处理器420执行时实现如上述任意一项实施例所述容器组的配置方法的步骤。

其中，处理器420可以包括一个或多个处理核心，比如3核心处理器、8核心处理器等。处理器420可以采用数字信号处理DSP（Digital Signal Processing）、现场可编程门阵列FPGA（Field－Programmable Gate Array）、可编程逻辑阵列PLA（Programmable LogicArray）中的至少一种硬件形式来实现。处理器420也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称中央处理器CPU（CentralProcessing Unit）；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器420可以集成有图像处理器GPU（Graphics Processing Unit），GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器420还可以包括人工智能AI（Artificial Intelligence）处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器410可以包括一个或多个可读存储介质，该可读存储介质可以是非暂态的。存储器410还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器410至少用于存储以下计算机程序411，其中，该计算机程序411被处理器420加载并执行之后，能够实现前述任一实施例公开的容器组的配置方法中的相关步骤。另外，存储器410所存储的资源还可以包括操作系统412和数据413等，存储方式可以是短暂存储或者永久存储。其中，操作系统412可以为Windows。数据413可以包括但不限于上述方法所涉及到的数据。

在一些实施例中，容器组的配置设备还可包括有显示屏430、电源440、通信接口450、输入输出接口460、传感器470以及通信总线480。

本领域技术人员可以理解，图4中示出的结构并不构成对容器组的配置设备的限定，可以包括比图示更多或更少的组件。

本申请实施例提供的容器组的配置设备，包括存储器和处理器，处理器在执行存储器存储的程序时，能够实现如上所述的容器组的配置方法，效果同上。

实施例七

需要说明的是，以上所描述的装置、设备实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个可读存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，执行本申请各个实施例所述方法的全部或部分步骤。

为此，本申请实施例还提供一种可读存储介质，该可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如容器组的配置方法的步骤。

该可读存储介质可以包括：U盘、移动硬盘、只读存储器ROM（Read-Only Memory）、随机存取存储器RAM（Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

本实施例中提供的可读存储介质所包含的计算机程序能够在被处理器执行时实现如上所述的容器组的配置方法的步骤，效果同上。

以上对本申请所提供的一种容器组的配置方法、装置、设备及可读存储介质进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、设备及可读存储介质而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (19)

1.一种容器组的配置方法，其特征在于，应用于无状态控制器所在节点，包括：

在接收到容器组创建命令后，调用预设的初始化容器模板和预设的业务应用容器模板；

利用所述初始化容器模板为容器组创建初始化容器，以使所述初始化容器运行所述初始化容器模板中的自适应参数获取脚本获取配置参数并生成所述容器组的配置文件；

利用所述业务应用容器模板为所述容器组创建业务应用容器，以使所述业务应用容器基于所述业务应用容器模板中挂载的所述配置文件的路径获取所述配置文件，并根据所述配置参数完成应用配置；

其中，所述初始化容器获取所述配置参数并生成所述容器组的配置文件，具体包括：

所述初始化容器获取所述容器组所在节点的环境信息，以确定第一配置参数；

所述初始化容器基于所述自适应参数获取脚本记载的应用配置中心地址，向应用配置中心上传包含所述第一配置参数的配置请求；

所述初始化容器接收所述应用配置中心分配的第二配置参数；

所述初始化容器根据所述第一配置参数和所述第二配置参数生成所述配置文件。

2.根据权利要求1所述的配置方法，其特征在于，所述配置文件具体存储于所述容器组的临时存储卷。

3.根据权利要求2所述的配置方法，其特征在于，所述临时存储卷具体存储于所述容器组所在节点的后端存储。

4.根据权利要求2所述的配置方法，其特征在于，所述临时存储卷具体存储于所述容器组的临时文件系统，且所述临时存储卷的临时存储卷媒介字段定义为内存。

5.根据权利要求1所述的配置方法，其特征在于，所述配置文件具体存储于预先为所述容器组分配的共享存储空间。

6.根据权利要求1所述的配置方法，其特征在于，所述初始化容器获取所述配置参数并生成所述容器组的配置文件，具体包括：

所述初始化容器获取所述容器组所在节点的环境信息，以确定第一配置参数；

所述初始化容器根据所述第一配置参数生成所述配置文件。

7.根据权利要求6所述的配置方法，其特征在于，所述初始化容器获取所述容器组所在节点的环境信息，以确定第一配置参数，具体为：

所述初始化容器基于所述初始化容器模板中挂载的所述容器组所在节点的系统目录，获取所述容器组所在节点的环境信息，以确定所述第一配置参数。

8.根据权利要求6所述的配置方法，其特征在于，所述第一配置参数具体包括：系统小型计算机系统接口参数、系统控制群组参数、标准程序设计库模块参数。

9.根据权利要求1所述的配置方法，其特征在于，所述第二配置参数具体为高性能配置参数、高可用配置参数、均衡配置参数、低功耗配置参数中的一种。

10.根据权利要求1所述的配置方法，其特征在于，所述第二配置参数具体为管理员配置的与所述容器组所在节点对应的运行策略配置参数。

11.根据权利要求1所述的配置方法，其特征在于，所述第二配置参数具体为调用监控脚本分析所述容器组所在节点的运行状态后生成的运行策略配置参数。

12.根据权利要求1所述的配置方法，其特征在于，所述第二配置参数具体为所述应用配置中心在接收到所述第一配置参数后周期性下发的运行策略配置参数。

13.根据权利要求1所述的配置方法，其特征在于，所述第二配置参数具体为所述应用配置中心在接收到所述第一配置参数后，在所述容器组所在节点的运行状态参数被监控到运行状态变化时下发的运行策略配置参数。

14.根据权利要求1所述的配置方法，其特征在于，所述初始化容器向所述应用配置中心上传包含所述第一配置参数的配置请求，具体为：

所述初始化容器周期性向所述应用配置中心上传所述配置请求。

15.根据权利要求1所述的配置方法，其特征在于，所述初始化容器向所述应用配置中心上传包含所述第一配置参数的配置请求，具体为：

所述初始化容器在所述第一配置参数发生变更后，向所述应用配置中心上传包含变更后的所述第一配置参数的所述配置请求。

16.根据权利要求1所述的配置方法，其特征在于，所述业务应用容器基于所述业务应用容器模板中挂载的所述配置文件的路径获取所述配置文件，具体为：

所述业务应用容器基于写在所述业务应用容器的业务配置参数中的所述配置文件的路径获取所述配置文件。

17.一种容器组的配置装置，其特征在于，包括：

调用单元，用于在接收到容器组创建命令后，调用预设的初始化容器模板和预设的业务应用容器模板；

第一创建单元，用于利用所述初始化容器模板为容器组创建初始化容器，以使所述初始化容器运行所述初始化容器模板中的自适应参数获取脚本获取配置参数并生成所述容器组的配置文件；

第二创建单元，用于利用所述业务应用容器模板为所述容器组创建业务应用容器，以使所述业务应用容器基于所述业务应用容器模板中挂载的所述配置文件的路径获取所述配置文件，并根据所述配置参数完成应用配置；

其中，所述初始化容器获取所述配置参数并生成所述容器组的配置文件，具体包括：

所述初始化容器获取所述容器组所在节点的环境信息，以确定第一配置参数；

所述初始化容器基于所述自适应参数获取脚本记载的应用配置中心地址，向应用配置中心上传包含所述第一配置参数的配置请求；

所述初始化容器接收所述应用配置中心分配的第二配置参数；

所述初始化容器根据所述第一配置参数和所述第二配置参数生成所述配置文件。

18.一种容器组的配置设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至16任意一项所述容器组的配置方法的步骤。

19.一种可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至16任意一项所述容器组的配置方法的步骤。

Images