Treatment of containerized environments
By monitoring and cache container initialization time and number of requests, selecting and cache common or long initialization time container status snapshots, and quickly starting services with checkpoint settings and recovery system, the problem of container initialization delay is solved, and user experience and response speed is improved.
Patent Information
- Application Number
- CN202510123445.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2024-02-26
- Filing Date
- 2025-01-26
- Publication Date
- 2025-08-26
AI Technical Summary
In the existing container orchestration platform, poor response speed and user interaction delay caused by excessive container initialization process affect user experience and satisfaction.
By monitoring the container initialization time and service requests, selecting and cacheing common or long initialization snapshots of container status, use checkpoint settings and recovery systems such as CRIU to quickly start services.
Reduces container initialization delay, improves service response speed, improves user experience and satisfaction, and saves computing resources.
Smart Images
Figure CN120540773A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a computer-implemented method for processing a containerized environment associated with a service requested by a client; a data processing device comprising a processor configured to execute the method; a computer program comprising instructions that, when implemented by a computer, cause the computer to perform the method; and a computer-readable medium comprising instructions that, when implemented by a computer, cause the computer to perform the method. Background Art
[0002] Container orchestration platforms such as Kubernetes and Docker Swarm distribute containers and can be used in any computing environment that supports containers, including public, private, hybrid, and multi-cloud computing environments.
[0003] Display call times can be important; for example, a goal of 1 second is used to open a graphic. However, DCS (distributed control system) software services in containers often undergo lengthy initialization phases (e.g., >10 seconds to several minutes), especially when they are loading data or establishing network connections. These lengthy processes can cause users attempting to interact with these services to wait for extended periods of time. As a result, users may experience poor responsiveness and / or delayed interactions, which can lead to frustration and reduce their overall satisfaction. These delays can harm the user experience, especially in interactive scenarios. Therefore, minimizing these initialization delays can help enhance the user experience, ensure more timely interactions, and improve user satisfaction.
[0004] Therefore, there is a need to increase the speed associated with container orchestration. Summary of the Invention
[0005] Claim 1 provides a computer-implemented method for processing a containerized environment associated with a service requested by a client (particularly a service that takes a long time to initialize), comprising the following steps:
[0006] (a) (the computing device) monitors the time it takes for the container to initialize and / or the number of requests for service received by the container from clients,
[0007] (b) (the computing device) determines a container to be selected from the containers based on the monitoring,
[0008] (c) (the computing device) checkpoints the selected containers and stores the checkpoint of each selected container in a container checkpoint cache,
[0009] (d) Upon a service request from the client, (the computing device) reads the corresponding checkpoint in the container checkpoint cache and restores the corresponding selected container from the stored checkpoint to serve the request.
[0010] Checkpointing a container can be thought of as saving a snapshot of the container's state as a set of images.
[0011] Determining the selected container means selecting a container from a plurality of (all) containers based on the results of monitoring (e.g., repeated checking over time, e.g., counting). In particular, the containers may be identified by monitoring and then selected based on the time taken for the container to initialize and / or the number of requests for service received by the container from clients. The selected container may be considered as a container to be cached (or already cached). For example, a container may be selected that has a longer initialization time (e.g., exceeding the average initialization time (e.g., 1 second to 10 seconds, more specifically, 2 seconds to 5 seconds)). Alternatively or additionally, a container that is frequently used, e.g., the 10% or 30% most frequently used containers, may be selected.
[0012] The present invention can provide state preservation at the container level and can be transferred to many services. The present invention involves caching the state of a service after initialization and then quickly starting a new instance by restoring the state from the cache.
[0013] The present invention can provide (especially Linux) container checkpoint setting and recovery in user space (especially in DCS system).
[0014] Thus, the system can be viewed as learning containers, e.g., the (most) used containers and / or the containers with the longest startup delays, and (autonomously) snapshotting these selected containers for quick restoration later.
[0015] The present invention can be viewed as freezing a running application (or a portion thereof) and checkpointing it to persistent storage as a collection of files. These files can then be used to recover and run the application from the point at which it was frozen.
[0016] Container checkpointing may allow for autonomous checkpointing of the state of services with long startup latencies once they have been initialized. By understanding the most frequently used services or those with the longest startup latencies, a list of such services can be collected. Checkpointing the state of such services after initialization may enable faster container startup upon further client requests.
[0017] This can improve the user experience for plant operators. In particular, it enables faster service startup. In particular, it can save computing resources used for service initialization. The present invention can mitigate delayed user interactions for DCS users. In particular, service caching can be used to enable faster service startup. For example, this can save approximately 1 to 10 seconds.
[0018] Optionally, the present invention is performed on platforms such as Kubernetes and Docker Swarm. Optionally, the present invention is performed on a Linux system.
[0019] The present invention may optionally use CRIU (Checkpoint / Restore In Userspace) as the checkpoint setting and recovery system (in user space). Therefore, CRIU (Linux software "Checkpoint / Restore In Userspace") may be optionally used to complete the checkpoint setting and recovery mechanism.
[0020] The present invention may include two main phases. In the first phase, steps (a) to (c) are performed. For example, a cache may be populated with container checkpoints, particularly for services that are (most) frequently used and / or have long startup delays. The list of containers to be checkpointed can be selected by continuously monitoring container initialization time and / or the number of requests per service. In the second phase, step (d) is performed. In particular, containers can be restored (relatively quickly) from the cache.
[0021] Finally, the client's request is served based on the restored services associated with the selected container.
[0022] Optionally, a dynamic list of selected containers as determined in step (b) is generated.
[0023] Optionally, in step (c), the service cache manager requests checkpointing of the selected container (optionally, the selected container on the list).
[0024] Optionally, in step (c), setting checkpoints for the selected containers includes: starting the container, initializing the container, and obtaining a checkpoint according to each selected container.
[0025] Optionally, in step (c), storing the checkpoint includes storing the selected container state in a set of images, and writing the checkpoint including the set of images into a container checkpoint cache.
[0026] Optionally, in step (d), the service cache manager requests resumption of service.
[0027] Optionally, in step (d), restoring the container comprises reading a checkpointed image of the service from a container checkpoint cache.
[0028] Optionally, the image of the container includes an initialized state of the container.
[0029] Optionally, at least during step (a) and upon request of the service by the client, a container is at least partially loaded and / or initialized and the service is run in the container, in particular if a hitherto unselected container is used.
[0030] Optionally, while steps (a) and / or (b) are ongoing, a request for the service and a request for the container are received simultaneously, but before completing step (c), the container continues to initialize directly from the container registry.
[0031] Optionally, on each request, the service cache manager may check the container checkpoint cache. If the relevant image exists, it can be served by recovery. Otherwise, the image may be loaded from the container registry.
[0032] One or more of these optional features may be used in combination or individually to further improve efficiency and reliability.
[0033] The present invention also relates to a data processing device comprising a processor configured to perform the method; a computer program comprising instructions which, when implemented by a computer, cause the computer to perform the steps of the method; and a computer-readable medium comprising instructions which, when implemented by a computer, cause the computer to perform the steps of the method.
[0034] The apparatus may optionally include an API server. For step (a), the API server is configured to record the time taken for container initialization and / or the number of container startups.
[0035] The apparatus may also optionally include a service cache manager, which, for step (c), is configured to request checkpointing of the selected container.
[0036] The apparatus may also optionally include a checkpoint setting and recovery unit, which is configured to start the selected container, initialize the container and obtain a checkpoint for step (c), and / or to read the checkpoint and restore the container from the checkpoint for step (d). BRIEF DESCRIPTION OF THE DRAWINGS
[0037] Figure 1 (a) is a schematic diagram reflecting stage 1 of an embodiment of the present invention.
[0038] Figure 1(b) is a schematic diagram reflecting stage 2 of an embodiment of the present invention. DETAILED DESCRIPTION
[0039] Figure 1 (a) and Figure 1 (b) shows the steps performed according to one embodiment of the invention: Phase 1 checkpoints the state of services (e.g. which have long startup delays after initialization), while phase 2 enables (faster) startup of such services.
[0040] Phase 1 checkpoints the container state according to steps (a) to (c), with eight more specific steps being used as an example. First, the system pulls the service image from the registry (step 1). Then, the system initializes the container and runs the service within it (step 2). The service then begins serving requests from clients (step 3). This can be considered a general process when using containers. Simultaneously, for example, the Kube API server continuously monitors the initialization time and the number of client requests for each service (step 4). Based on these metrics, the service cache manager obtains a dynamic list of containers that have a long initialization time and receive a large number of client requests (step 5). Steps 4 and 5 are repeated over time. In other words, the (Kube) API server and the service cache manager are repeatedly updated. The service cache manager then requests the CRIU to checkpoint the containers in the provided list (step 6). After initialization, the CRIU checkpoints these containers (step 7), stores their state in a set of images, and stores them in the registry (step 8). Thus, in step (c), checkpointing the selected containers includes, for each selected container, starting the container, initializing the container, and obtaining a checkpoint. Furthermore, in step (c), storing the checkpoint includes storing the selected container state in a set of images, and writing the checkpoint comprising the set of images to a container checkpoint cache. Specifically, the container image includes the initialized state of the container.
[0041] Phase 2 enables the rapid startup of services using checkpoints stored in the container checkpoint registry. Phase 2 corresponds to step (d), and is exemplified here by five subsequent, more specific steps. During step (a), and upon a client request for a service, the container is at least partially loaded and / or initialized, and the service is run within the container.
[0042] Upon receiving a request from the client (step 9), the service cache manager requests that the service be restored, for example, from the CRIU (step 10). To do this, the CRIU reads the checkpointed image of the service from the container checkpoint registry (step 11) and restores the container from the stored state (step 12). The CRIU can quickly restore the stored state, and since the service is already in the desired initialized state after restoring the saved state, it can skip the entire lengthy initialization process. The service then begins servicing requests from the client (step 13).
[0043] While steps (a) and / or (b) are in progress, and requests for services and requests for containers are received, the container continues to initialize directly from the container registry before completing step (c).
[0044] At each request from a client, the service cache manager checks the container checkpoint cache. If the image in question is in the container checkpoint cache, it is served by restoring it from the container checkpoint cache. Otherwise, the image is loaded from the container registry.
[0045] Assuming that the selected container becomes an "unselected" container over time, for example, because it is used less frequently, the corresponding container can be removed from the container checkpoint cache (e.g., manually or through the service cache manager).
[0046] The detailed description of the present invention is provided with respect to the embodiments depicted in the accompanying drawings. Based on the inventive content of the present invention, a skilled person may think of obvious variations and alternatives. These variations and alternatives are a part of the present invention as described in the appended claims.
[0047] Figure 1 The steps of the embodiment:
[0048] 1 Loading container
[0049] 2 Start container + initialize container
[0050] 3 Service Request
[0051] 4. Record the number of containers started
[0052] 5 Get the container list
[0053] 6 Request checkpoints for most started containers
[0054] 7 Start container + initialize + get checkpoint
[0055] 8 Writing Checkpoints
[0056] 9 Request Service
[0057] 10 Request for recovery
[0058] 11 Read Checkpoint
[0059] 12Recovering from a Checkpoint
[0060] 13Service Request
Claims
1. A computer-implemented method for processing a containerized environment associated with a service requested by a client, comprising the steps of: (a) monitoring the time taken for the container to initialize and / or the number of requests for the service received by the container from the client; (b) determining a container to be selected from the containers based on the monitoring; (c) checkpointing the selected containers and storing the checkpoint of each selected container in a container checkpoint cache; (d) when the client requests the service, reading the corresponding checkpoint in the container checkpoint cache and restoring the corresponding selected container from the stored checkpoint to service the request.
2. The method of claim 1, wherein a dynamic list of the selected containers as determined in step (b) is generated.
3. The method according to claim 1 or 2, wherein in step (c), the service cache manager requests checkpointing of the selected container, optionally, checkpointing of the selected container in the list.
4. The method of any preceding claim, wherein in step (c), checkpointing the selected container comprises: For each selected container, the container is started, initialized, and the checkpoint is obtained.
5. The method of any one of the preceding claims, wherein in step (c), storing the checkpoint comprises: The selected container state is stored in a set of images, and the checkpoint including the set of images is written to the container checkpoint cache.
6. A method according to any one of the preceding claims, wherein in step (d), the service cache manager requests resumption of the service.
7. The method of any one of the preceding claims, wherein in step (d), restoring the container comprises: A checkpointed image of the service is read from the container checkpoint cache. The method of claim 7 , wherein the image of a container comprises an initialized state of the container.
9. A method according to any preceding claim, wherein at least partly during step (a) and when the client requests the service, a container is loaded and / or initialized and the service runs in the container.
10. A data processing apparatus comprising a processor configured to perform the method according to any one of the preceding claims.
11. The apparatus according to claim 10, further comprising an API server, wherein for step (a), the API server is configured to record the time taken for container initialization and / or the number of container startups.
12. The apparatus according to claim 10 or 11, further comprising a service cache manager, wherein for step (c), the service cache manager is configured to request checkpointing of the selected container.
13. The apparatus according to claim 10 or 11 or 12 further comprises a checkpoint setting and recovery unit, wherein for step (c), the checkpoint setting and recovery unit is configured to start the selected container, initialize the container and obtain the checkpoint, and / or for step (d), the checkpoint setting and recovery unit is configured to read the checkpoint and restore the container from the checkpoint.
14. A computer program comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method according to any one of the preceding claims 1 to 9.
15. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method according to any one of the preceding claims 1 to 9.