容器内逻辑配置方法、设备以及计算机可读介质

技术领域

本申请涉及信息技术领域，尤其涉及一种容器内逻辑配置方法、设备以及计算机可读介质。

背景技术

Java应用监控，如业务实时监控服务等，通常需要通过javaAgent的方式，对用户java应用进行字节码插桩，从而注入相应的监控逻辑，提供无侵入式监控服务。在以Kubernetes为代表的容器环境中，用户的java应用通过构建容器镜像的方式输出，若需要在容器环境中注入相应的处理逻辑，一般可以采用以下的方式：

方案一：在制作用户容器的镜像(image)时加入相应功能的注入逻辑。以Java应用监控场景为例，生成容器的镜像时，需要为每个使用的镜像加入JavaAgent的挂载流程，从而实现Java应用监控功能。该方案的缺点是：用户需要修改容器的镜像，增加了运维的成本，注入的逻辑是绑定在制作的镜像中，不易修改、升级。若需要修改、升级，则需重新制作镜像，运维成本进一步增加。

方案二：手动修改Kubernetes的Deployment配置文件，在其中关于pod的配置中加入关于注入逻辑的内容。以Java应用监控场景为例，用户需要手动对每个Java应用的deployment配置文件进行修改。该方案的缺点是：如果有多个deployment配置文件，都需要手工添加，运维成本高；若需要升级注入的逻辑，需重新手动修改各个Java应用的deployment配置文件，接入流程长、运维成本高、且需要操作者具备相应知识。

综上所述，目前的注入方案运维成本较高，且不便于对注入的逻辑进行修改和升级。

本申请的一个目的是提供一种容器内逻辑配置方案，用以解决现有方案中运维成本高，修改、升级不易的问题。

本申请实施例中提供了一种容器内逻辑配置方法，其中，该方法包括：

在监测到Pod生成时，所述准入控制器修改Pod的配置，以使所述Pod在根据修改后的配置生成时，下载逻辑执行文件；

所述准入控制器修改所述Pod中用户容器的启动设置，以使所述Pod中的用户容器在启动时调用逻辑执行文件。

本申请实施例还提供了一种容器内逻辑配置设备，该设备中安装有准入控制器，所述准入控制器用于在监测到Pod生成时，修改Pod的配置，以使所述Pod在根据修改后的配置生成时，下载逻辑执行文件；以及修改所述Pod中用户容器的启动设置，以使所述Pod中的用户容器在启动时调用逻辑执行文件。

此外，本申请实施例还提供了一种计算设备，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行所述容器内逻辑配置方法。

本申请实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现所述容器内逻辑配置方法。

本申请实施例提供容器内逻辑配置方案中，Admission在监测到Pod生成时，所述准入控制器(Admission Controller)修改Pod的配置，以使所述Pod在根据修改后的配置生成时，下载逻辑执行文件，而后所述准入控制器修改所述Pod中用户容器的启动设置，以使所述Pod中的用户容器在启动时调用逻辑执行文件。该方案采用了Admission Controller的方式实现逻辑注入，在Pod生成时自动修改其配置，使得生成的Pod中能够自动完成相关逻辑的注入，整个注入过程中无需修改容器的镜像，也无需修改deployment配置，运维成本较低，且由于Admission Controller可以管理注入的逻辑，因此在升级、修改时可以统一管理，而不需要针对每个不同应用的镜像或者deployment配置进行调整。此外，基于本申请实施例提供容器内逻辑配置，可以进一步实现容器内应用监控以及弹性扩容。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为本申请实施例提供的一种容器内逻辑配置方法的处理流程图；

图2为采用本申请实施例提供的方案实现逻辑注入时的时序图；

图3为本申请实施例中通过Admission Controller修改Pod的配置的过程的示意图；

图4为本申请实施例提供的一种计算设备的结构示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的装置或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请实施例提供了一种容器内逻辑配置方法，该方法采用了AdmissionController的方式实现逻辑注入，Admission Controller是Kubernetes提供的一种webhook的机制。Admission Controller在Pod生成时自动修改其配置，使得生成的Pod中能够自动完成相关逻辑的注入，整个注入过程中无需修改容器的镜像，也无需修改deployment配置，运维成本较低，且由于Admission Controller可以管理注入的逻辑，因此在升级、修改时可以统一管理，而不需要针对每个不同应用的镜像或者deployment配置进行调整。

在实际场景中，该方法的执行主体可以是用户设备、网络设备或者用户设备与网络设备通过网络相集成所构成的设备，此外也可以是运行于上述设备中的程序。所述用户设备包括但不限于计算机、手机、平板电脑等各类终端设备；所述网络设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。

图1示出了本申请实施例提供的一种容器内逻辑配置方法的处理流程，在该方法执行之前，需要预先安装Admission Controller。以Kubernetes为例，可以在集群(cluster)中安装Admission Controller，安装完成后Admission Controller即可监测该集群中各个资源的生命周期过程，其中，包括了Pod的生成时机。由此，安装AdmissionController之后，可以通过Admission Controller来监控Pod的生成时机。

步骤S101，在监测到Pod生成时，Admission Controller修改Pod的配置，以使所述Pod在根据修改后的配置生成时，下载逻辑执行文件。

在Kubernetes中，在生成Pod的过程一般是由用户向API Server发送请求，该请求包括容器的Deployment配置，API Server在收到请求之后可以根据Deployment配置来生成Pod的配置，例如，一个Deployment配置中，会有一个template子配置部分，该部分的属性即为生成的Pod的配置的模板。在获取到Pod的配置之后，即可用于启动实例化的Pod资源，即生成Pod。

由此，Admission Controller可以在API Server接收到请求之后，拦截该请求的后续处理过程，在API Server根据所述Deployment配置生成的Pod的配置时，修改Pod的配置，使得基于Pod的配置生成Pod后，会自动下载逻辑执行文件，由此可以在Pod中的容器内顺利注入相应的处理逻辑。

Admission Controller在修改Pod的配置时，可以为所述Pod添加用于下载逻辑执行文件的执行对象以及用于存储逻辑执行文件的存储卷，以使所述执行对象在所述Pod生成时将所述逻辑执行文件下载至所述存储卷中，其中，所述执行对象和所述Pod中的用户容器挂载于所述存储卷。

本申请的一些实施例中，所述执行对象可以是init Container(初始化容器)。由此，Admission Controller会在所述Pod中用于下载逻辑执行文件的初始化容器以及用于存储逻辑执行文件的存储卷，并将所述Pod中的初始化容器和用户容器挂载至所述存储卷，以使所述初始化容器在所述Pod生成时启动，将所述逻辑执行文件下载至所述存储卷中。

所述初始化容器在Pod生成时会首先启动，init Container启动完成之后，用于封装应用程序的用户容器才会启动。Admission Controller在修改Pod的配置时，可以添加一个init Container以及一个Volume(存储卷)，init Container和用户容器都可以挂载(Mount)至该Volume上，init Container负责下载逻辑执行文件至其挂载的Volume。由此，该修改后的配置生成Pod时，首先执行init Container，init Container执行成功则表示已经成功将辑执行文件下载至新添加的Volume中。

在本申请的另一些实施例中，所述执行对象也可以是DaemonSet。由此，AdmissionController会在所述Pod中添加用于存储逻辑执行文件的存储卷，并将预先部署的用于下载执行文件的Daemonset以及所述Pod中的用户容器挂载至所述存储卷中，以使所述Daemonset在所述Pod生成时将所述逻辑执行文件下载至所述存储卷中。

在Kubernetes中，DaemonSet用于管理集群的节点(node)上运行的Pod，由此可以在Kubernetes集群中预先部署一个能在每个节点的下载逻辑执行文件的Daemonset，由Daemonset来替代init Container下载逻辑执行文件。类似地，本实施例中也需要将Daemonset以及所述Pod中的用户容器挂载至所述存储卷中，使得逻辑执行文件能够被下载至存储卷中，并可以Pod启动之后被用户容器调用。

步骤S102，Admission Controller修改所述Pod中用户容器的启动设置，以使所述Pod中的用户容器在启动时调用逻辑执行文件，从而实现逻辑注入。

所述启动设置包括一些控制容器启动过程的参数，例如Admission Controller可以采用修改所述Pod中用户容器的预加载环境变量的方式，来修改启动参数。在Kubernetes中，可以通过配置JAVA_TOOL_OPTIONS、LD_PRELOAD等环境参数来修改预加载环境变量。所述逻辑执行文件中包括了需要向容器内注入的逻辑，例如以Java应用监控场景为例，所述逻辑执行文件可以是Agent逻辑执行文件，容器调用该Agent逻辑执行文件，便可以对用户java应用进行字节码插桩，实现Java应用监控的处理逻辑。

此外，在Pod中的容器的镜像包含CMD或者ENTRYPOINT的情况下，AdmissionController也可以通过修改Pod容器内的CMD或者ENTRYPOINT的方式，来实现启动设置的修改，使得所述Pod中的用户容器在启动时调用逻辑执行文件，从而实现逻辑注入。

图2示出了采用本申请实施例提供的方案实现逻辑注入时的时序图，其场景为用户在Kubernetes集群通过提交包含Deployment配置的请求部署Java应用的同时，为Java应用插入JavaAgent，实现Agent逻辑注入。

步骤S1，用户需要在部署应用前，在Kubernetes集群中安装AdmissionController。

步骤S2，安装完成后，Admission Controller开始监听调度系统接口服务器中Pod的启动时机。

步骤S3，用户向调度系统接口服务器提交应用的Deployment配置。

步骤S4，调度系统接口服务器获取到Deployment配置，从Deployment配置中生成Pod配置，开始生成Pod。该过程会被Admission Controller拦截，并执行AdmissionController的处理逻辑。该处理逻辑即为改写Pod的配置，添加一个Volume，并加上一个初始化容器(init Container)，此init Container和用户容器(Container)均挂载(Mount)至刚添加的Volume。

图3示出了通过Admission Controller修改Pod的配置的过程，AdmissionController可以在API Server处理用户的Pod配置并生成Pod的过程中，与AdmissionWebhook Server交互，在Pod生成之前使用Mutating Admission Controller用于修改Pod的配置，并使用Validating Admission Controller验证修改后的配置。

步骤S5，生成Pod时，初始化容器被执行，下载Agent逻辑执行文件到Mount地址，即之前添加的Volume中。

步骤S6，通过配置Pod中用户容器的ENV参数(环境参数)，修改用户容器的预加载环境变量，从而达到为容器对应的应用插入JavaAgent的效果。本实施例中，AdmissionController会为Pod内用户容器配置JAVA_TOOL_OPTIONS、LD_PRELOAD等环境参数，从而修改用户容器的预加载环境变量，使得用户容器启动时便会调用Agent逻辑执行文件。

在本申请的一些实施例中，还可以利用前述的容器内逻辑配置方法，实现容器内应用监控，由此提供了一种实现容器内应用监控的方法，该方法可以在监测到Pod生成时，由所述准入控制器修改Pod的配置，以使所述Pod在根据修改后的配置生成时，下载用于对用户容器内的应用进行字节码插桩的逻辑执行文件。而后，由所述准入控制器修改所述Pod中用户容器的启动设置，以使所述Pod中的用户容器在启动时调用逻辑执行文件，对用户容器内的应用进行字节码插桩，由字节码插桩所插入的字节码用于在运行后获取所述应用的运行状态信息。

例如，在实际场景中，所述用于对用户容器内的应用进行字节码插桩的逻辑执行文件可以是javaagent的Jar包，在Jar包在被用户容器调用时，可以将用户容器中的应用插入字节码，这些插入的字节码在运行时可以采集应用运行时的运行状态信息，从而实现应用监控。

此外，在弹性扩容场景中，也可以利用前述的容器内逻辑配置方法，从而实现弹性扩容时容器内逻辑的自动配置。基于此，本申请实施例还提供了一种弹性扩容方法，该方法可以根据扩容请求，生成新的Pod。在监测到Pod生成时，控制所述准入控制器修改Pod的配置，以使所述Pod在根据修改后的配置生成时，下载逻辑执行文件。而后可以控制所述准入控制器修改所述Pod中用户容器的启动设置，以使所述Pod中的用户容器在启动时调用逻辑执行文件。

基于同一发明构思，本申请实施例中还提供了一种容器内逻辑配置设备，所述设备对应的方法是前述实施例中的容器内逻辑配置方法，并且其解决问题的原理与该方法相似。

本申请实施例提供的一种容器内逻辑配置设备采用了Admission Controller的方式实现逻辑注入，Admission Controller是Kubernetes提供的一种webhook的机制。Admission Controller在Pod生成时自动修改其配置，使得生成的Pod中能够自动完成相关逻辑的注入，整个注入过程中无需修改容器的镜像，也无需修改deployment配置，运维成本较低，且由于Admission Controller可以管理注入的逻辑，因此在升级、修改时可以统一管理，而不需要针对每个不同应用的镜像或者deployment配置进行调整。

在实际场景中，该设备可以是用户设备、网络设备或者用户设备与网络设备通过网络相集成所构成的设备，此外也可以是运行于上述设备中的程序。所述用户设备包括但不限于计算机、手机、平板电脑等各类终端设备；所述网络设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。

本申请实施例提供的一种容器内逻辑配置设备中安装有Admission Controller，所述Admission Controller用于在监测到Pod生成时，修改Pod的配置信息，以使所述Pod在根据修改后的配置信息生成时，下载逻辑执行文件；以及修改所述Pod中用户容器的启动设置，以使所述Pod中的用户容器在启动时调用逻辑执行文件，从而实现逻辑注入。

以Kubernetes为例，可以在集群(cluster)中安装Admission Controller，安装完成后Admission Controller即可监测该集群中各个资源的生命周期过程，其中，包括了Pod的生成时机。由此，安装Admission Controller之后，可以通过Admission Controller来监控Pod的生成时机。

在Kubernetes中，在生成Pod的过程一般是由用户向API Server发送请求，该请求包括容器的Deployment配置，API Server在收到请求之后可以根据Deployment配置来生成Pod的配置，例如，一个Deployment配置中，会有一个template子配置部分，该部分的属性即为生成的Pod的配置的模板。在获取到Pod的配置之后，即可用于启动实例化的Pod资源，即生成Pod。

由此，Admission Controller可以在API Server接收到请求之后，拦截该请求的后续处理过程，在API Server根据所述Deployment配置生成的Pod的配置时，修改Pod的配置，使得基于Pod的配置生成Pod后，会自动下载逻辑执行文件，由此可以在Pod中的容器内顺利注入相应的处理逻辑。

Admission Controller在修改Pod的配置时，可以为所述Pod添加用于下载逻辑执行文件的执行对象以及用于存储逻辑执行文件的存储卷，以使所述执行对象在所述Pod生成时将所述逻辑执行文件下载至所述存储卷中，其中，所述执行对象和所述Pod中的用户容器挂载于所述存储卷。

本申请的一些实施例中，所述执行对象可以是init Container(初始化容器)。由此，Admission Controller会在所述Pod中用于下载逻辑执行文件的初始化容器以及用于存储逻辑执行文件的存储卷，并将所述Pod中的初始化容器和用户容器挂载至所述存储卷，以使所述初始化容器在所述Pod生成时启动，将所述逻辑执行文件下载至所述存储卷中。

所述初始化容器在Pod生成时会首先启动，init Container启动完成之后，用于封装应用程序的用户容器才会启动。Admission Controller在修改Pod的配置时，可以添加一个init Container以及一个Volume(存储卷)，init Container和用户容器都可以挂载(Mount)至该Volume上，init Container负责下载逻辑执行文件至其挂载的Volume。由此，该修改后的配置生成Pod时，首先执行init Container，init Container执行成功则表示已经成功将辑执行文件下载至新添加的Volume中。

在本申请的另一些实施例中，所述执行对象也可以是DaemonSet。由此，AdmissionController会在所述Pod中添加用于存储逻辑执行文件的存储卷，并将预先部署的用于下载执行文件的Daemonset以及所述Pod中的用户容器挂载至所述存储卷中，以使所述Daemonset在所述Pod生成时将所述逻辑执行文件下载至所述存储卷中。

在Kubernetes中，DaemonSet用于管理集群的节点(node)上运行的Pod，由此可以在Kubernetes集群中预先部署一个能在每个节点的下载逻辑执行文件的Daemonset，由Daemonset来替代init Container下载逻辑执行文件。类似地，本实施例中也需要将Daemonset以及所述Pod中的用户容器挂载至所述存储卷中，使得逻辑执行文件能够被下载至存储卷中，并可以Pod启动之后被用户容器调用。

所述启动设置包括一些控制容器启动过程的参数，例如Admission Controller可以采用修改所述Pod中用户容器的预加载环境变量的方式，来修改启动参数。在Kubernetes中，可以通过配置JAVA_TOOL_OPTIONS、LD_PRELOAD等环境参数来修改预加载环境变量。所述逻辑执行文件中包括了需要向容器内注入的逻辑，例如以Java应用监控场景为例，所述逻辑执行文件可以是Agent逻辑执行文件，容器调用该Agent逻辑执行文件，便可以对用户java应用进行字节码插桩，实现Java应用监控的处理逻辑。

此外，在Pod中的容器的镜像包含CMD或者ENTRYPOINT的情况下，AdmissionController也可以通过修改Pod容器内的CMD或者ENTRYPOINT的方式，来实现启动设置的修改，使得所述Pod中的用户容器在启动时调用逻辑执行文件，从而实现逻辑注入。

在本申请的一些实施例中，还可以利用前述的容器内逻辑配置方法，实现容器内应用监控，由此提供了一种实现容器内应用监控的设备，该设备中安装有准入控制器，所述准入控制器用于在监测到Pod生成时，修改Pod的配置，以使所述Pod在根据修改后的配置生成时，下载用于对用户容器内的应用进行字节码插桩的逻辑执行文件；而后可以修改所述Pod中用户容器的启动设置，以使所述Pod中的用户容器在启动时调用逻辑执行文件，对用户容器内的应用进行字节码插桩，由字节码插桩所插入的代码用于在运行后获取所述应用的运行状态信息。

例如，在实际场景中，所述用于对用户容器内的应用进行字节码插桩的逻辑执行文件可以是javaagent的Jar包，在Jar包在被用户容器调用时，可以将用户容器中的应用插入字节码，这些插入的字节码在运行时可以采集应用运行时的运行状态信息，从而实现应用监控。

此外，在弹性扩容场景中，也可以利用前述的容器内逻辑配置方法，从而实现弹性扩容时容器内逻辑的自动配置。基于此，本申请实施例还提供了一种弹性扩容设备，该设备包括扩容模块和控制模块，所述扩容模块可以根据扩容请求，生成新的Pod。而所述控制模块可以在监测到Pod生成时，控制所述准入控制器修改Pod的配置，以使所述Pod在根据修改后的配置生成时，下载逻辑执行文件。而后可以控制所述准入控制器修改所述Pod中用户容器的启动设置，以使所述Pod中的用户容器在启动时调用逻辑执行文件。

综上所述，本申请实施例提供的容器内逻辑配置方案无需修改容器的镜像，也无需修改deployment配置，运维成本较低，且由于Admission Controller可以管理注入的逻辑，因此在升级、修改时可以统一管理，而不需要针对每个不同应用的镜像或者deployment配置进行调整。同时可以在Pod扩容的情况下，也可以自动为新生成的Pod自动注入逻辑，此外由于逻辑执行文件可以单独设置，通过下载不同的逻辑执行文件，可以使得本方案应用于应用监控、流量拦截、流量统计等不同场景。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一些实施例包括一个如图4所示的计算设备，该设备包括存储有计算机可读指令的一个或多个存储器410和用于执行计算机可读指令的处理器420，其中，当该计算机可读指令被该处理器执行时，使得所述设备执行基于前述本申请的多个实施例的方法和/或技术方案。

此外，本申请的一些实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。