Container instance deployment method and device, equipment, storage medium and product

Abstract

The invention discloses a container instance deployment method and device, equipment, a storage medium and a product, and relates to the technical field of instance deployment, and the container instance deployment method comprises the steps that when a container fault is detected, a preset container deployment template corresponding to a container is determined, the preset container deployment template is associated with a resource object locally storing a configuration file; based on the preset container deployment template, creating a new container, so that the created container mounts the configuration file in the resource object to a specified path based on a preset mounting rule; and starting the created container, and loading the configuration file in the specified path to realize container instance deployment. According to the method, external platform injection is not needed, so that when the external platform breaks down or encounters network interruption, deployment of the container is not affected.

Description

Technical Field

[0001] The present application relates to the field of instance deployment technology, and in particular to a container instance deployment method, apparatus, device, storage medium, and product. Background Art

[0002] With the increasing popularity of cloud computing and microservice architecture, containerized deployment has become a key strategy for enterprises to achieve rapid application delivery, elastic expansion, and efficient operation and maintenance.

[0003] In related technologies, configuration information usually needs to rely on an external platform for injection. This approach increases dependence on the external platform. Once the external platform fails or encounters a network interruption, the container may not be able to correctly obtain the required configuration information, which in turn causes the container deployment to fail. Summary of the Invention

[0004] The main purpose of this application is to provide a container instance deployment method, device, equipment, storage medium and product, aiming to solve the technical problem that when an external platform fails or encounters a network interruption, the container may not be able to correctly obtain the required configuration information, thereby causing the container deployment to fail.

[0005] To achieve the above objectives, the present application proposes a container instance deployment method, which includes:

[0006] When a container failure is detected, determining a preset container deployment template corresponding to the container, wherein the preset container deployment template is associated with a resource object having a configuration file stored locally;

[0007] Based on the preset container deployment template, a new container is created, so that the created container mounts the configuration file in the resource object to a specified path based on a preset mounting rule;

[0008] The created container is started, and the configuration file in the specified path is loaded to implement the container instance deployment.

[0009] In one embodiment, when a container failure is detected, the step of determining a preset container deployment template corresponding to the container includes:

[0010] Obtain the configuration file encapsulated in the resource object, wherein the configuration file is the configuration file required when the container is started;

[0011] The resource object is deployed locally, and an association relationship is established between the resource object and a preset container deployment template.

[0012] In one embodiment, the step of encapsulating the configuration file into a resource object includes:

[0013] Read the content in the configuration file as a content string;

[0014] Encapsulate the character string and the file name of the configuration file to obtain a resource object;

[0015] The resource object is converted into a resource object with a tree structure that complies with the local calling specification.

[0016] In one embodiment, when a container failure is detected, the step of creating a new container based on a preset container deployment template corresponding to the container includes:

[0017] Deploy the created container on the target working node and assign an IP address to the container on the target working node;

[0018] The IP address is injected into the environment variables of the container, and the IP address is injected into the environment variables of the container, so that the container after startup loads the configuration file in the specified path and the IP address in the environment variables to implement the container instance deployment.

[0019] In one embodiment, the step of detecting a container failure includes:

[0020] Determining the number of first containers set in a preset container deployment template;

[0021] Determining the number of active second containers in the container created based on the preset container deployment template;

[0022] If the first container quantity is not equal to the second container quantity, it is determined that a container failure exists.

[0023] In one embodiment, the step of determining the first number of containers set in the preset container deployment template includes:

[0024] Obtaining indicator data related to container resource usage, wherein the indicator data includes resource utilization;

[0025] Calculating the standard deviation of the resource utilization rate within a preset first time period to obtain a volatility corresponding to the resource utilization rate;

[0026] Calculating a load variation trend within the preset second time period;

[0027] Based on the resource utilization, the fluctuation rate, and the load change trend, the number of containers is set to a first number of containers in a preset container deployment template.

[0028] In addition, to achieve the above objectives, the present application also proposes a container instance deployment device, which includes:

[0029] a determination module, configured to, when a container failure is detected, determine a preset container deployment template corresponding to the container, wherein the preset container deployment template is associated with a resource object having a configuration file stored locally;

[0030] A creation module, configured to create a new container based on the preset container deployment template, so that the created container mounts the configuration file in the resource object to a specified path based on a preset mounting rule;

[0031] A loading module is used to start the created container, so that the started container loads the configuration file in the specified path to implement the container instance deployment.

[0032] In addition, to achieve the above-mentioned purpose, the present application also proposes a container instance deployment device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is configured to implement the steps of the container instance deployment method described above.

[0033] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium. A computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the container instance deployment method described above are implemented.

[0034] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the steps of the container instance deployment method described above.

[0035] One or more technical solutions proposed in this application have at least the following technical effects:

[0036] Compared with the related technologies, configuration information usually needs to rely on an external platform for injection. This method increases the dependence on the external platform. Once the external platform fails or encounters a network interruption, the container may not be able to correctly obtain the required configuration information, which in turn causes the container to fail to self-heal. In comparison, when a container fails, the present application will create a new container according to the preset container deployment template corresponding to the container. Since the preset container deployment template is associated with the resource object where the configuration file is stored locally, after creating a new container through the preset container deployment template, the container can obtain the configuration file and can mount the configuration file to the specified path in the container according to the preset mounting rules. When the container starts, it can automatically obtain the configuration file stored in the instruction path of the container without the need for external platform injection. Therefore, when the external platform fails or encounters a network interruption, it will not affect the deployment of the container. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0038] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0039] Figure 1 A flowchart illustrating the first embodiment of the container instance deployment method of this application;

[0040] Figure 2 This is a flowchart of the container self-healing method for deploying container instances in this application;

[0041] Figure 3 This is a flowchart of the instance deployment method for the container instance deployment method of this application;

[0042] Figure 4 A flowchart illustrating the second embodiment of the container instance deployment method of this application is provided;

[0043] Figure 5 This is a schematic diagram of the module structure of the container instance deployment device according to an embodiment of the present application;

[0044] Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the container instance deployment method in the embodiment of the present application.

[0045] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0046] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0047] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0048] The main solution of the embodiment of the present application is: when a container failure is detected, determining a preset container deployment template corresponding to the container, wherein the preset container deployment template is associated with a resource object that locally stores a configuration file; based on the preset container deployment template, creating a new container, so that the created container mounts the configuration file in the resource object to a specified path based on a preset mounting rule; starting the created container, so that the started container loads the configuration file in the specified path to implement the container instance deployment.

[0049] In related technologies, configuration information usually needs to rely on an external platform for injection. This approach increases dependence on the external platform. Once the external platform fails or encounters a network interruption, the container may not be able to correctly obtain the required configuration information, which in turn causes the container deployment to fail.

[0050] When a container fails, this application will create a new container based on the preset container deployment template corresponding to the container. Since the preset container deployment template is associated with the resource object where the configuration file is stored locally, after the new container is created through the preset container deployment template, the container can obtain the configuration file and can mount the configuration file to the specified path in the container according to the preset mounting rules. When the container is started, it can automatically obtain the configuration file stored in the instruction path of the container without the need for external platform injection. Therefore, when the external platform fails or encounters a network interruption, it will not affect the deployment of the container.

[0051] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of implementing the above functions, a container instance deployment device, etc. The following uses the container instance deployment device as an example to illustrate this embodiment and the following embodiments.

[0052] Based on this, the embodiment of the present application provides a container instance deployment method, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the container instance deployment method of the present application.

[0053] In this embodiment, the container instance deployment method includes steps S100 to S300:

[0054] Step S100: When a container failure is detected, determining a preset container deployment template corresponding to the container, wherein the preset container deployment template is associated with a resource object having a configuration file stored locally;

[0055] It should be noted that the execution subject of this embodiment is a container instance deployment device. The container instance deployment device deploys a Kubernetes (K8S) cluster architecture. K8S, as a container orchestration engine, is responsible for managing core functions such as the container lifecycle, resource scheduling, service discovery, and load balancing. The K8S cluster is generally composed of a control plane and worker nodes.

[0056] Specifically, the control plane and working nodes include the following parts:

[0057] 1. Control plane: This includes components such as the API server, scheduler, controller manager, and etcd storage, and is responsible for the global management and decision-making of the cluster.

[0058] 2. Worker node: The actual node that runs the containerized application, including components such as Kubelet, container runtime (such as Docker), and network plug-ins. It is responsible for receiving and executing instructions from the control plane and managing the operation of containers.

[0059] In addition, it should be noted that Deployment is also deployed in K8S. Deployment is a declarative resource object used in K8S to manage stateless applications. It is used to define the deployment template of the container, including configurations such as container image, number of replicas, resource requests and restrictions, and ConfigMap (a resource object used to store configuration data in K8S). The container is deployed on the Pod. In this application, only one container is deployed on each Pod. When the Pod where the container is located hangs up due to force majeure factors (such as node failure, container crash, etc.), the Kubernetes controller (such as ReplicaSet controller) will automatically detect the abnormality of the Pod status. Once a Pod failure is detected, the K8S controller will automatically create a new Pod, that is, a new container, according to the preset container deployment template defined in the Deployment. For details, refer to Figure 2 , Figure 2 Provides a container self-healing flowchart.

[0060] Step S200: creating a new container based on the preset container deployment template, so that the created container mounts the configuration file in the resource object to a specified path based on a preset mounting rule;

[0061] It is understandable that the K8S controller will create a new container based on the preset container deployment template defined in the Deployment. Because the preset container deployment template in the Deployment defines the preset mounting rules, after the container is created, the container will mount the configuration file in the resource object to a specific path inside the container according to the preset mounting rules. Specifically, the preset container deployment template contains the following key information:

[0062] Image: The basic image that the container runs on.

[0063] Number of replicas: The number of Pod replicas you want to run.

[0064] Resource requests and limits: CPU and memory requirements.

[0065] Environment variables: Environment variables required for the application to run.

[0066] ConfigMap mounting: How to mount the configuration file into the container.

[0067] Specifically, the container uses the volumes and volumeMounts fields to mount a ConfigMap as a file or directory within the container. For example, if you mount the application.yml file in a ConfigMap to the / opt / configMap directory of the container, the container can directly read the configuration information in this file when it starts. The path in configMap.items specifies the path and file name to be mounted within the container. Specifically, referring to the following code, the current working directory is already set when setting workingDir. Simply specifying a file name will indicate the current working directory.

[0068] voLumeMounts

[0069] <4keys>

[0070] Name:configs

[0071] mountPath: / opt / configMap

[0072] readOnly:true

[0073] <3keys>

[0074] mountPath: / dev / random

[0075] subPath:urandom

[0076] name:rondom

[0077] readOnly:true

[0078] terminationGracePeriodSeconds:60

[0079] volumes:

[0080] <2keys>

[0081] name:configs

[0082] configMap:

[0083] name:$fdplName}

[0084] items:

[0085] key:appstartConfigXml

[0086] path:app_start_config.xml

[0087] key:insConfig

[0088] path:application.yml

[0089] key:appstartShell

[0090] path:start.sh

[0091] key:agentStartShell

[0092] path:agentStart.sh

[0093] Since ConfigMap is a resource object used to store configuration data in K8S, it allows decoupling configuration information from images, enabling centralized management and dynamic updates of configurations. Therefore, step S200 is performed. By deploying ConfigMap to the K8S cluster in advance and associating the name of ConfigMap in the container deployment template (such as Deployment), the container can automatically read the configuration data in ConfigMap when it starts, without relying on external platform injection. This avoids the situation where the external platform fails or encounters network interruption, and the container may not be able to correctly obtain the required configuration information, which in turn leads to the failure of container deployment. With the help of K8S's Deployment and ReplicaSet controllers, this solution implements the automatic fault recovery capability of the container. When the Pod where the container is located hangs up, K8S will automatically create a new Pod and ensure that the new Pod can correctly read the configuration information in ConfigMap, and the service can be restored without manual intervention. This feature greatly reduces operation and maintenance costs and improves the availability and stability of the system. It is especially suitable for scenarios with high requirements for service continuity, such as e-commerce platforms and financial systems.

[0094] Step S300: Start the created container so that the started container loads the configuration file in the specified path to implement the container instance deployment.

[0095] It should be noted that when a new container is created in the K8S cluster, it will start automatically. When the container starts, it will load the configuration file from the instruction path of the mount configuration file. Since these configuration files are dynamically mounted, the application configuration can be updated without changing the image, which greatly improves flexibility. For details, refer to Figure 3 , Figure 3 Provides an example deployment flowchart.

[0096] In a feasible implementation manner, the following steps may be included before step S100:

[0097] Obtain the configuration file encapsulated in the resource object, wherein the configuration file is the configuration file required when the container is started;

[0098] It is understandable that the configuration files obtained by K8S are the organized configuration files related to container startup, which are encapsulated in the resource object ConfigMap. Specifically, the configuration files include but are not limited to:

[0099] Application configuration: such as application.yml, which may contain database connection strings, log levels, etc.

[0100] Environment variables: Some configurations can be passed to the application through environment variables instead of being hard-coded in the configuration files.

[0101] Startup scripts: For example, agentStart.sh and start.sh, which are used to initialize the environment within the container or directly start the application.

[0102] Microservice authentication configuration: such as app_start_config.xml, which may contain security-related settings, such as authentication and authorization information.

[0103] The configuration file can be in the form of .properties, .yaml, .json, or key-value pairs, depending on the application requirements.

[0104] The resource object is deployed locally, and an association relationship is established between the resource object and a preset container deployment template.

[0105] It is understandable that K8S deploys the ConfigMap to the Kubernetes cluster through the API server and checks the results of the API call. If the call does not throw an exception, the deployment is considered successful. Otherwise, the exception should be caught and the error should be handled, such as printing error logs or retry logic. In the definition of Deployment, an association relationship between the resource object and the preset container deployment template should be established. Specifically, the volumes and volumeMounts fields are used to reference the newly created ConfigMap to ensure that the configuration information can be read from the ConfigMap when the new Pod is started.

[0106] In a feasible implementation, the step of obtaining the configuration file encapsulated in the resource object includes the following steps:

[0107] Read the content in the configuration file as a content string;

[0108] It should be noted that K8S reads the contents of the configuration file and stores the contents of each configuration file as a string for subsequent encapsulation.

[0109] Encapsulate the content string and the file name of the configuration file to obtain a resource object;

[0110] It can be understood that K8S encapsulates the name and content string of each configuration file into a data structure suitable for subsequent processing, using the file name as the key and the file content as the value, encapsulating the configuration file in the form of a key-value pair, and then obtaining a resource object.

[0111] Specifically, K8S provides multiple ways to create ConfigMaps, including file-based, directory-based, and literal-based methods. Because the platform uses a wide variety of configuration files with complex content, directly filling a configmap.yaml file can introduce numerous issues, such as string escaping. Therefore, we define a ConfigMap Java class, ConfigMapTemplate, to encapsulate the required configuration file string. We then use the valueToTree method of com.fasterxml.jackson.databind.ObjectMapper to convert the configmap into a JsonNode. The recommended fields are:

[0112] / **

[0113] *Create configMap

[0114] *Create or update configMap, try to update configMap after failure

[0115] *@param configMapTemplate

[0116] * @param clusten

[0117] *@throws KeyManagementException

[0118] *@throws NoSuchAlgorithmException

[0119] *@throws 0penShiftFeignException

[0120] * /

[0121] Public void deployOrUpdateConfigMap

[0122] (ConfigMapTemplate configMapTemplate,containercluster cluster)

[0123] throwsKeyManagementException,NoSuchAlgorithmException,0penShiftFeignException{

[0124] JsonNode jsonNode=0BJECT MAPPER.valueToTree(configMapTemplate);

[0125] OpenShiftclientTwoProxyclient=

[0126] new 0penShiftclientTwoProxy(cluster.getUrl());

[0127] try{

[0128] client.deployConfigMap

[0129] (jsonNode,cluster.getNamespace(),cluster.getToken());

[0130] }catch(0penShiftFeignException e){

[0131] / / Check if it is an existing exception

[0132] if(ALREADY_EXIST.equals(e.getOpenShiftExceptionDto().getReason())){

[0133] / / Create an exception without throwing an error, try to update

[0134] L0G.error(e,ZWDK074,configMapTemplate.getMetadata().getName());

[0135] client.updateConfigMap(jsonNode,

[0136] configMapTemplate.getMetadata().getName(),cluster.getNamespace(),cluster.getToken());

[0137] }else{

[0138] Throw newAppException

[0139] (e,ZwDK076,configMapTemplate.getMetadata().getName());

[0140] }

[0141] }

[0142] }

[0143] The resource object is converted into a resource object with a tree structure that complies with the local calling specification.

[0144] It should be noted that K8S converts Java objects into JSON tree structures to facilitate the subsequent generation of Kubernetes API call ConfigMap.

[0145] Specifically, ConfigMap is deployed to the cluster by calling the K8S interface. In the above code, client.deployConfig is an encapsulated method, specifically the following interface. If no exception is thrown during execution, the deployment is considered successful.

[0146] / **

[0147] *Deploy a configMap

[0148] *@param namespace namespace

[0149] *@param token

[0150] * @return

[0151] * /

[0152] @RequestLine("PosT / api / v1 / namespaces / {namespace} / configmaps")

[0153] @Headers({"Accept:application / json",

[0154] "Authorization:Bearer{token}",

[0155] "Connection:close"

[0156] "Content-Type:application / json"})

[0157] JsonNode deployConfigMap(JsonNode deployment,

[0158] @Param("namespace")String namespace,

[0159] @Param("token")String token)throws 0penShiftFeignException;

[0160] In this implementation, ConfigMap enables centralized management of configuration information, decoupling configuration from images and avoiding the problem of hard-coding configuration in images. Configuration information can be updated and maintained independently of the image, eliminating the need to rebuild and release images. This significantly improves the flexibility and efficiency of configuration management. Furthermore, because configuration information is stored in a ConfigMap within the K8S cluster, it eliminates the need for external platform injection, enhancing the system's independence and reliability. Even if the external platform fails, the container can still read the configuration information in the ConfigMap and start and run normally.

[0161] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 4 After step S100, the container instance deployment method further includes steps S01 to S02:

[0162] Step S01, deploying the created container on a target working node and assigning an IP address to the container on the target working node;

[0163] Understandably, the target worker node is determined based on factors such as resource requirements and affinity policies. The Kubernetes scheduler selects an appropriate target worker node to run the Pod based on these factors. It then deploys the Pod's containers on the target worker node. After the containers are deployed, the CNI plugin (network plugin) assigns the Pod a unique IP address (i.e., the Pod IP) for intra-cluster communication.

[0164] Furthermore, after receiving the Pod creation instruction, the kubelet component on the target node pulls the image and starts the container through the container runtime (such as Docker, containerd).

[0165] Step S02: Inject the IP address into the environment variables of the container, and inject the IP address into the environment variables of the container, so that the container after startup loads the configuration file in the specified path and the IP address in the environment variables to implement the container instance deployment.

[0166] Specifically, the following code extracts some key information, mainly reflecting the parts of associating ConfigMap with the container, injecting environment variables into the ConfigMap definition, and mounting the Volume. The ZA24_POD_IP in the env field is bound to the container's IP address. Reading the environment variable ZA24_POD_IP can obtain the pod's business IP address. Other keys need to be set as environment variables. At that time, reading the environment variable key can obtain the value of the corresponding key in the ConfigMap.

[0167] env:

[0168] <#list en.ey>-name:${key}

[0169] value:"${environments[key]}

[0170] < / #list>

[0171] <2keys>

[0172] -<2keys>

[0173] name:2A24_POD_IP

[0174] valueFrom:

[0175] fieldRef:

[0176] apiVersion:v1

[0177] fieldPath:status.podIP

[0178] -name:ZA24_NODE_NAME

[0179] valueFrom:

[0180] fieldRef:

[0181] apiVersion:v1

[0182] fieldPath:spec.nodeName

[0183] name:APP_START_COMMAND

[0184] valueFrom:

[0185] configMapKeyRef:

[0186] name:${dplName}

[0187] key:appStartShell

[0188] name:ENV_CONFIG

[0189] valueFrom:

[0190] configMapKeyRef:

[0191] name:${dplName}

[0192] key:evnJsonstring

[0193] name:2A24_PLATFORM_CONFIG

[0194] valueFrom:

[0195] configMapKeyRef:

[0196] name:za24-platform-config

[0197] key:platformConfigMapJsonString

[0198] volumeMounts:

[0199] <4keys>

[0200] name:configs

[0201] mountPath: / opt / configMap

[0202] readOnly:true

[0203] It should be noted that in order to obtain its own IP address within the container, the Pod's IP address can be injected into the container as an environment variable through Kubernetes' Downward API. When the container starts, the configuration file in the specified path in the container and the IP address in the environment variable are loaded to implement the container instance deployment. Through the IP allocation mechanism of the K8S cluster, the Pod can automatically obtain the IP address assigned by the node at startup without the involvement of an external platform, reducing dependence on external systems and improving the autonomy and reliability of network configuration. At the same time, the K8S network plug-in ensures the efficiency and stability of communication between Pods, providing strong network support for containerized applications.

[0204] In a feasible embodiment, the step of detecting a container failure includes the following steps:

[0205] Determining the number of first containers set in a preset container deployment template;

[0206] It is understood that the first number of containers is the expected number of replicas defined in the Deployment. K8S determines the first number of containers set in the preset container deployment template.

[0207] Determining the number of active second containers in the container created based on the preset container deployment template;

[0208] It should be noted that K8S determines the number of Pods in the current cluster that are in the Running state and Ready.

[0209] If the first container quantity is not equal to the second container quantity, it is determined that a container failure exists.

[0210] It can be understood that K8S compares the two numbers to determine whether there is a container failure. If the numbers are not equal, it is determined that there is a container failure or abnormal exit.

[0211] Furthermore, when K8S determines that there is a container failure, it will immediately rebuild the Pod to make up for the expected number of replicas defined in the Deployment, so that the number of second containers is always equal to the number of first containers.

[0212] In a feasible implementation, before the step of determining the first number of containers set in the preset container deployment template, the following steps are included:

[0213] Obtaining indicator data related to container resource usage, wherein the indicator data includes resource utilization;

[0214] It should be noted that resource utilization is the actual usage of resources by the current container and is the basic indicator for determining whether to expand or shrink capacity. K8S obtains the indicator data of the actual resource usage of the current container, namely resource utilization.

[0215] Specifically, the impact of resource utilization on the number of replicas is as follows:

[0216] Too high: Capacity expansion is needed to avoid performance bottlenecks;

[0217] Too low: You can scale down to save resources.

[0218] Calculating the standard deviation of the resource utilization rate within a preset first time period to obtain a volatility corresponding to the resource utilization rate;

[0219] It is understood that the preset first time period can be set to the past 10 minutes. Volatility refers to the standard deviation of resource usage (such as CPU and memory) over a period of time (such as the past 10 minutes). It measures the stability of resource usage. If the volatility is low, it indicates that the load is relatively stable; conversely, if the volatility is high, it means that the load is unstable, there may be short-term peaks or other abnormal conditions.

[0220] Furthermore, suppose that the container experiences a sudden traffic peak within a short period of time, causing the CPU utilization to instantly soar to 90%, but quickly return to a normal level (for example, 30%). If the volatility is not taken into account, the expansion operation may be triggered immediately, increasing the number of Pods to cope with this short peak period.

[0221] Furthermore, when resource utilization is relatively stable but close to the threshold (for example, CPU utilization continues to fluctuate between 45% and 55%, with a target value of 50%), it is difficult to decide whether to adjust the number of replicas based solely on the current utilization. At this time, volatility becomes an important reference indicator. If the volatility is low, it means that although the utilization is close to the threshold, the change is not large. This may mean that the current configuration is sufficient to cope with the current load. Therefore, in this case, it is reasonable to keep the existing number of replicas unchanged. On the contrary, if the volatility is high and the utilization continues to approach or exceed the threshold, it may be necessary to expand the capacity in advance to prevent possible performance bottlenecks in the future.

[0222] Calculating a load variation trend within the preset second time period;

[0223] It should be noted that K8S uses technical means such as linear regression trend analysis or sliding window comparison method to evaluate the trend direction and intensity of resource utilization, obtain the load change trend, and determine whether the load is in an upward trend, downward trend, or stable state, thereby providing a basis for subsequent decision-making.

[0224] Based on the resource utilization, the fluctuation rate, and the load change trend, the number of containers is set to a first number of containers in a preset container deployment template.

[0225] It is understandable that K8S sets a target value for resource utilization and a threshold for volatility. Based on the comparison of the target value and threshold for resource utilization and volatility, and combined with the load change trend, it makes a decision on whether to adjust the number of Pod replicas. It also adjusts the policy based on the number of Pod replicas and sets the number of containers in the preset container deployment template to the first container number. Specifically, the policy adjustment table is shown in Table 1:

[0226]

[0227] Furthermore, during e-commerce promotions, website traffic will increase significantly. In this case, the system must not only cope with the huge traffic during peak periods, but also ensure efficient use of resources during non-peak hours to avoid waste. Therefore, it is crucial to accurately predict and respond to load change trends.

[0228] Specifically, changes in the number of replicas include the following:

[0229] Expand capacity in advance

[0230] Background: Before a promotion begins, although current resource utilization may not have reached the threshold, an upcoming traffic peak can be foreseen based on historical data analysis.

[0231] Strategy: Use linear regression trend analysis or sliding window comparison to identify a clear upward trend. Once the trend is confirmed to be upward and approaching the promotional event time, capacity expansion can be initiated in advance to ensure sufficient resources to handle the upcoming high traffic.

[0232] Effect: This approach can effectively prevent service unavailability or performance degradation caused by delayed expansion, while reducing system pressure caused by sudden expansion.

[0233] Delayed expansion

[0234] Background: Sometimes there are short-term surges in traffic, but these may be temporary and not indicative of a long-term trend.

[0235] Strategy: When resource utilization exceeds the target but fluctuates significantly, this indicates a possible temporary peak. If the load trend shows a decrease, you can delay capacity expansion and observe the situation for a while. This avoids unnecessary capacity expansion due to temporary peaks and conserves resources.

[0236] Effect: This approach helps reduce frequent scaling (i.e., oscillation) caused by short-term fluctuations, thereby stabilizing system performance and reducing operating costs.

[0237] Gradually shrink

[0238] Background: After the promotion ended, traffic gradually returned to normal levels.

[0239] Strategy: Determine whether the load is declining based on the load trend. If so, gradually reduce the number of replicas rather than drastically reducing them immediately. This ensures service quality while gradually releasing unnecessary resources.

[0240] Effect: Gradual scaling down can avoid the risk of service interruption caused by a one-time large-scale scaling down, while ensuring that resources are properly recovered.

[0241] In this implementation, the Kubernetes cluster's IP allocation mechanism allows pods to automatically obtain node-assigned IP addresses upon startup, eliminating the need for external platform involvement. This reduces reliance on external systems and improves the autonomy and reliability of network configuration. Furthermore, the Kubernetes network plugin ensures efficient and stable communication between pods, providing robust network support for containerized applications.

[0242] It should be noted that the above examples are only used to understand this application and do not constitute a limitation on the container instance deployment method of this application. More simple transformations based on this technical concept are all within the scope of protection of this application.

[0243] This application also provides a container instance deployment device, please refer to Figure 5 , the container instance deployment device includes:

[0244] A determination module 10 is configured to determine, when a container failure is detected, a preset container deployment template corresponding to the container, wherein the preset container deployment template is associated with a resource object having a configuration file stored locally;

[0245] A creation module 20 is configured to create a new container based on the preset container deployment template, so that the created container mounts the configuration file in the resource object to a specified path based on a preset mounting rule;

[0246] The loading module 30 is used to start the created container so that the started container loads the configuration file in the specified path to implement the container instance deployment.

[0247] Optionally, the determining module includes:

[0248] Establish a submodule for obtaining a configuration file encapsulated in a resource object, wherein the configuration file is a configuration file required for container startup; deploy the resource object locally, and establish an association relationship between the resource object and a preset container deployment template.

[0249] The allocation submodule deploys the created container on the target working node and allocates an IP address to the container on the target working node; injects the IP address into the environment variables of the container, so that the container after startup can load the configuration file in the specified path and the IP address in the environment variable to realize the container instance deployment.

[0250] A determination submodule is configured to determine the number of first containers set in a preset container deployment template; determine the number of active second containers in a container created based on the preset container deployment template; and determine that a container failure exists if the number of the first containers is not equal to the number of the second containers.

[0251] Optionally, the establishing submodule includes:

[0252] The encapsulation unit is used to read the content in the configuration file as a content string; encapsulate the string and the file name of the configuration file to obtain a resource object; and convert the resource object into a resource object with a tree structure that complies with the local call specification.

[0253] Optionally, the determination submodule includes:

[0254] A setting unit is configured to obtain indicator data related to container resource usage, wherein the indicator data includes resource utilization; calculate a standard deviation of the resource utilization within a preset first time period to obtain a fluctuation rate corresponding to the resource utilization; calculate a load change trend within a preset second time period; and set the number of containers in a preset container deployment template to a first container number based on the resource utilization, the fluctuation rate, and the load change trend.

[0255] The container instance deployment device provided in this application utilizes the container instance deployment method described in the aforementioned embodiments to address the technical issues surrounding container instance deployment. Compared to the prior art, the container instance deployment device provided in this application offers the same beneficial effects as the container instance deployment method described in the aforementioned embodiments. Other technical features of the container instance deployment device are the same as those disclosed in the aforementioned embodiments and are not further detailed here.

[0256] The present application provides a container instance deployment device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the container instance deployment method in the above-mentioned embodiment 1.

[0257] Reference below Figure 6, which shows a schematic diagram of the structure of a container instance deployment device suitable for implementing embodiments of the present application. The container instance deployment device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptops, tablet computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The container instance deployment device shown is merely an example and should not limit the functionality and scope of use of the embodiments of the present application.

[0258] like Figure 6 As shown, the container instance deployment device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the container instance deployment device. Processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input device 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output device 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage device 1003 including, for example, a magnetic tape, hard disk, etc.; and communication device 1009. Communication device 1009 can allow the container instance deployment device to communicate with other devices wirelessly or wired to exchange data. Although the figure shows a container instance deployment device with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented or have alternatively.

[0259] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0260] The container instance deployment device provided in this application utilizes the container instance deployment method described in the aforementioned embodiments to address the technical issues surrounding container instance deployment. Compared to the prior art, the container instance deployment device provided in this application achieves the same beneficial effects as the container instance deployment method described in the aforementioned embodiments. Other technical features of the container instance deployment device are the same as those disclosed in the aforementioned embodiments and are not further elaborated upon here.

[0261] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0262] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0263] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, a computer program) stored thereon, wherein the computer-readable program instructions are used to execute the container instance deployment method in the above embodiment.

[0264] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0265] The computer-readable storage medium may be included in the container instance deployment device, or may exist independently without being assembled into the container instance deployment device.

[0266] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the container instance deployment device, the container instance deployment device: when a container failure is detected, determines a preset container deployment template corresponding to the container, wherein the preset container deployment template is associated with a resource object that locally stores a configuration file; creates a new container based on the preset container deployment template, so that the created container mounts the configuration file in the resource object to a specified path based on a preset mounting rule; starts the created container and loads the configuration file in the specified path to implement the container instance deployment.

[0267] Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0268] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0269] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0270] The computer-readable storage medium provided in this application stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned container instance deployment method, thereby resolving the technical issues surrounding container instance deployment. Compared to the prior art, the computer-readable storage medium provided in this application offers the same beneficial effects as the container instance deployment method provided in the aforementioned embodiments, and will not be further elaborated upon here.

[0271] The present application also provides a computer program product, including a computer program, which implements the steps of the container instance deployment method as described above when executed by a processor.

[0272] The computer program product provided in this application can solve the technical problem of container instance deployment. Compared with the existing technology, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the container instance deployment method provided in the above embodiment, and will not be repeated here.

[0273] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A container instance deployment method, characterized in that: The container instance deployment method includes: When a container failure is detected, determining a preset container deployment template corresponding to the container, wherein the preset container deployment template is associated with a resource object having a configuration file stored locally; Based on the preset container deployment template, a new container is created, so that the created container mounts the configuration file in the resource object to a specified path based on a preset mounting rule; The created container is started so that the started container loads the configuration file in the specified path to implement the container instance deployment.

2. The container instance deployment method according to claim 1, wherein: The step of determining a preset container deployment template corresponding to the container when a container failure is detected includes: Obtain the configuration file encapsulated in the resource object, wherein the configuration file is the configuration file required when the container is started; The resource object is deployed locally, and an association relationship is established between the resource object and a preset container deployment template.

3. The container instance deployment method according to claim 2, wherein: The step of obtaining the configuration file encapsulated in the resource object includes: Read the content in the configuration file as a content string; Encapsulate the content string and the file name of the configuration file to obtain a resource object; The resource object is converted into a resource object with a tree structure that complies with the local calling specification.

4. The container instance deployment method according to claim 1, wherein: The step of creating a new container based on a preset container deployment template corresponding to the container when a container failure is detected includes: Deploy the created container on the target working node and assign an IP address to the container on the target working node; The IP address is injected into the environment variables of the container, and the IP address is injected into the environment variables of the container, so that the container after startup loads the configuration file in the specified path and the IP address in the environment variables to implement the container instance deployment.

5. The container instance deployment method according to claim 1, wherein: The steps of detecting a container failure include: Determining the number of first containers set in a preset container deployment template; Determining the number of active second containers in the container created based on the preset container deployment template; If the first container quantity is not equal to the second container quantity, it is determined that a container failure exists.

6. The container instance deployment method according to claim 5, wherein: The step of determining the first number of containers set in the preset container deployment template includes: Obtaining indicator data related to container resource usage, wherein the indicator data includes resource utilization; Calculating the standard deviation of the resource utilization rate within a preset first time period to obtain a volatility corresponding to the resource utilization rate; Calculating a load variation trend within the preset second time period; Based on the resource utilization, the fluctuation rate, and the load change trend, the number of containers is set to a first number of containers in a preset container deployment template.

7. A container instance deployment device, characterized in that: The device comprises: a determination module, configured to, when a container failure is detected, determine a preset container deployment template corresponding to the container, wherein the preset container deployment template is associated with a resource object having a configuration file stored locally; A creation module, configured to create a new container based on the preset container deployment template, so that the created container mounts the configuration file in the resource object to a specified path based on a preset mounting rule; A loading module is used to start the created container, so that the started container loads the configuration file in the specified path to implement the container instance deployment.

8. A container instance deployment device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the container instance deployment method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the container instance deployment method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the container instance deployment method according to any one of claims 1 to 6 are implemented.

Images