An API-driven intelligent scheduling and dynamic adaptation method for service containers

Abstract

This invention discloses an API-driven intelligent scheduling and dynamic adaptation method for service containers, applicable to Kubernetes clusters and / or Docker Swarm clusters. The method receives service container operation requests through an API gateway, authenticates and authorizes them via a security control module, and generates target instructions after a parameter validator verifies image information, resource quotas, and runtime parameters. The container management module then creates, starts, stops, deletes, and monitors the status of containers. The resource scheduling module selects target nodes and controls scaling based on business priorities and node resource usage. The log management module centrally collects, stores, and analyzes requests, runtime status, and scheduling results, providing a basis for blue-green deployment, rolling upgrades, and anomaly rollback of service versions. This method achieves full lifecycle management and cross-environment dynamic adaptation of containers based on a unified API, reducing the operational threshold and improving resource utilization and service stability.

Description

Technical Field

[0001] This invention belongs to the field of containerized application management and automated deployment technology, specifically involving an API-driven intelligent scheduling and dynamic adaptation method for service containers. Background Technology

[0002] Container scheduling systems are a key component of containerization technology. Their main task is to automate the deployment, startup, shutdown, and resource allocation of containers, ensuring their efficient and stable operation within a cluster. This requires balancing resource utilization, high availability, and isolation and security. Common container scheduling systems include Kubernetes, Docker Swarm, and Apache Mesos, with Kubernetes, due to its powerful features and flexible architecture, becoming the mainstream choice in container orchestration.

[0003] In typical existing solutions, Kubernetes employs a master node and worker node architecture. The master node is responsible for cluster management and scheduling, while the worker nodes run containers. The system receives requests through an API server, and the scheduler schedules Pods to suitable nodes based on the resource availability of each node, supporting capabilities such as automatic scaling, rolling updates, and rollback. Docker Swarm also uses a master node and worker node model. The master node is responsible for executing scheduling policies, while the worker nodes run containers, supporting random scheduling, optimal placement, distributed strategies, and affinity scheduling to simplify container cluster management. For scenarios without an orchestration platform, users typically manage the container lifecycle directly using the Docker command-line tool, requiring manual scripting to perform operations such as container deployment, startup, stopping, and deletion, resulting in low automation.

[0004] However, the aforementioned existing technologies still have several shortcomings in practical use: First, they are highly complex to operate. The conceptual framework and operational methods of systems such as Kubernetes and Docker Swarm are complex, requiring a high level of technical expertise from users, resulting in a high learning and usage threshold. Second, resource scheduling flexibility is limited. In business scenarios with high real-time requirements, the scheduling latency of existing scheduling tools is insufficient to meet the needs. Third, service upgrades and rollbacks are cumbersome, often requiring manual stopping of old version containers, pulling and starting the new version image, and adjusting configurations. If a problem occurs with the new version, the rollback process is equally complex and error-prone, affecting service availability and continuity. Fourth, log management functionality is limited. The system suffers from several drawbacks: First, it lacks the ability to handle log data, which is scattered across various nodes and containers, resulting in a lack of centralized management and intelligent analysis. Operations personnel need to collect and analyze the data manually, leading to low efficiency. Second, it has weak environmental awareness and cannot automatically identify the container orchestration environment currently used by the server. Users need to manually adapt to different orchestration tools such as Kubernetes and Docker Swarm, increasing management costs and the risk of errors. Third, it lacks fine-grained access control and security protection mechanisms during container management and operation, which can easily lead to data leakage and abuse of permissions. Fourth, it has poor scalability and integration when integrated with other systems or tools, making it difficult to meet the needs of system collaboration and capability expansion in diverse business scenarios.

[0005] Therefore, there is an urgent need for a service container scheduling method that uses APIs as a unified entry point, can improve scheduling flexibility, simplify upgrades and rollbacks, strengthen log and security management, and adapt to different container orchestration environments while ensuring ease of use. Summary of the Invention

[0006] The purpose of this invention is to address the problems of existing container orchestration and scheduling solutions, such as complex operation, insufficient resource scheduling flexibility, cumbersome version upgrade and rollback processes, difficulty in unified management of logs and runtime status, and weak adaptability to different container runtime environments. This invention provides an API-driven intelligent scheduling and dynamic adaptation method for service containers. By using a unified API gateway as the entry point, it encapsulates container lifecycle management, resource scheduling, log collection and analysis, and security verification capabilities into the business process. This allows users or external systems to complete container creation, startup, stopping, scaling, rolling upgrades, and rollback operations simply by calling standardized APIs. Combined with execution environment detection and parameter verification mechanisms, it achieves dynamic adaptation to different container platforms without needing to be aware of the underlying Kubernetes, DockerSwarm, or independent Docker environments. This simplifies operation and maintenance, improves resource utilization and service stability, shortens version release and fault recovery time, and enhances the observability of container runtime status and the overall scalability and reusability of the system.

[0007] To achieve the above objectives, the technical solution adopted by this invention is: an API-driven intelligent scheduling and dynamic adaptation method for service containers, comprising the following steps:

[0008] (1) The API gateway layer receives service container operation requests from users and / or external systems and forwards the service container operation requests to the business logic layer;

[0009] (2) The security control module performs identity authentication and permission verification on the service container operation request, and the parameter validator performs legality verification on the request parameters in the service container operation request. The target service container operation instruction is generated only when the verification passes.

[0010] (3) The container management module in the business logic layer performs at least one of the following operations on the target service container: creation, startup, stop, deletion and status monitoring, according to the target service container operation instructions;

[0011] (4) The resource scheduling module in the business logic layer schedules the operation instructions of the target service container according to the current cluster resource usage and the preset scheduling strategy, determines the target node and / or target resource quota, and issues the corresponding service container creation and / or update commands to the container orchestration cluster to complete the deployment and / or adjustment of the target service container;

[0012] (5) The log management module in the business logic layer collects, stores and analyzes the service container operation requests, service container running status and resource scheduling results, and writes the log data related to the service container operation and scheduling into the data storage layer to support subsequent scheduling optimization and dynamic adaptation.

[0013] Through the collaboration among the API gateway layer, security control module, parameter validator, container management module, resource scheduling module, and log management module, service containers can achieve unified access, centralized scheduling, and dynamic adaptation based on APIs throughout their entire lifecycle.

[0014] Furthermore, for the service container creation request, steps (1) to (4) specifically include:

[0015] Users call the API interface to create service containers and send a creation request containing image information, resource quotas and running parameters to the API gateway layer;

[0016] The API gateway layer forwards the creation request to the authentication module. The authentication module verifies the user's identity and access permissions based on the token carried and returns the verification result to the API gateway layer.

[0017] If the verification result is successful, the API gateway layer forwards the creation request to the parameter validator, which performs format and constraint verification on the request parameters such as image identifier, resource parameters and business tags to generate valid creation service container request parameters.

[0018] The API gateway layer forwards the valid service container creation request parameters to the business logic layer. The container management module constructs the target operation instruction for creating the service container, and the resource scheduling module selects the target node and converts the operation instruction into a service container creation command that can be recognized by the container orchestration cluster. The command is then sent to the Kubernetes cluster and / or DockerSwarm cluster for execution, and the returned service container identifier is obtained.

[0019] The API gateway layer sends the service container identifier to the user as a successful creation result.

[0020] Furthermore, the authentication module performs signature verification and validity period verification on the token, and determines that the authentication is successful only if the signature is correct and the token has not expired; the parameter validator performs integrity verification on the required parameters in the service container creation request, upper and lower limit constraint verification on the resource quota parameters, and legality verification on the image repository address. If any verification fails, an error message is returned to the API gateway layer and the service container creation process is terminated.

[0021] Furthermore, the scheduling performed by the resource scheduling module in step (4) includes at least one of the following processes:

[0022] The scheduling requests for different service containers are queued and sorted according to the business priority label, and computing resources are allocated to high-priority service containers first.

[0023] The system dynamically matches the resource requirements of the target service container with the current resource usage of each node, and selects the target node that meets the resource requirements such as processor and memory from the available nodes.

[0024] During the operation of the service container, when the load change of the target service container is detected to reach a preset threshold, the scaling up or scaling down operation is automatically triggered to adjust the number of target service container instances and / or resource quotas, so as to achieve dynamic adaptation to the running status.

[0025] Furthermore, for service version upgrade requests, the method also includes:

[0026] The API gateway layer receives service version upgrade requests initiated by users and forwards them to the business logic layer.

[0027] After completing permission and parameter verification, the business logic layer selects one of the blue-green deployment strategy and the rolling upgrade strategy as the upgrade strategy based on the strategy identifier carried in the upgrade request.

[0028] Based on the upgrade strategy, the container management module and resource scheduling module are invoked to gradually replace the version of the target service container. During the upgrade process, key operational indicators are reported to the log management module and / or monitoring system to determine whether the upgrade process is normal.

[0029] Furthermore, when a blue-green deployment strategy is selected, the service version upgrade process includes:

[0030] Create a new deployment unit to host the new version of the service container, and perform startup and health checks on the deployment unit;

[0031] Before switching traffic on the live network, conduct traffic switching tests on the new version of the service to verify that the functionality and performance meet the preset conditions.

[0032] After the test is passed, gradually switch online access traffic from the old version deployment unit to the new version deployment unit;

[0033] Once it is detected that all business traffic has been switched to the new version and is running stably, the old version deployment unit is destroyed, completing this blue-green upgrade.

[0034] Furthermore, when a rolling upgrade strategy is selected, the service version upgrade process includes:

[0035] Replace existing service instances of the target service in batches, and keep the number of service instances to be upgraded in each batch within a preset range.

[0036] During each upgrade batch, we continuously monitor service-related operational metrics to determine whether the service is normal after the current upgrade batch.

[0037] If the monitoring results indicate that the service is running normally, continue to replace the next batch of service instances until all service instances have been upgraded.

[0038] If monitoring results indicate that the service is not running normally, subsequent upgrades will be paused, an automatic rollback process will be triggered, and the old version of the service instance will be restored to its running state by calling the rollback interface.

[0039] Furthermore, the data storage layer in step (5) includes at least:

[0040] Message middleware is used to store asynchronous messages and event notifications from the business logic layer, and is used to decouple service container scheduling operations from subsequent processing flows.

[0041] A distributed search engine is used to store and index service container runtime logs and scheduling logs collected by the log management module, supporting index-based log retrieval and analysis.

[0042] Time-series databases are used to monitor time-series metrics during the operation of storage service containers, in order to support trend analysis of resource usage and service performance.

[0043] Image repositories are used to store image files for service containers, providing a source of images for creating and upgrading service containers.

[0044] Furthermore, when performing step (5), the log management module also includes:

[0045] The API gateway layer receives service container operation requests, the processing results of the authentication module and parameter validator, the lifecycle operation records of the container management module, and the scheduling decision results of the resource scheduling module.

[0046] The log data is written to the message middleware and then forwarded to the distributed search engine and / or time-series database to support multi-dimensional retrieval and visualization analysis of the service container's running status, scheduling behavior, and upgrade process.

[0047] This invention, through its overall architecture design of unified API gateway access, centralized orchestration of the business logic layer, and unified database storage, combined with the collaboration between the security control module, parameter validator, container management module, resource scheduling module, and log management module, has significant advantages over existing technologies in the following aspects:

[0048] First, it reduces the complexity of container operation and maintenance and minimizes the risk of misoperation. Existing management methods based on Kubernetes, DockerSwarm, or directly on Docker command lines require operations personnel to directly interact with the commands and concepts of the underlying orchestration platform, resulting in long and error-prone operation paths. This invention encapsulates operations such as service container creation, startup, stopping, deletion, status query, and version upgrades through an API gateway layer. All operations enter the system in the form of standardized API requests. Combined with token authentication and permission verification by the security control module, and parameter validators verifying the legality of key parameters such as image identifiers, resource quotas, and business tags, operation instructions for the target service container are only generated after verification. This fundamentally simplifies the operation steps and reduces the risk of misoperation and unauthorized access.

[0049] Second: Enhancing resource scheduling flexibility and dynamic adaptability to service operation status. Addressing the rigid scheduling strategies and difficulty in responding promptly to load changes in the background technology, this invention sets up a resource scheduling module at the business logic layer. Combining the current cluster resource usage with preset scheduling strategies, it intelligently schedules service container operation commands: on one hand, it sorts scheduling requests according to business priority tags, prioritizing the allocation of processors, memory, and other resources to high-priority service containers; on the other hand, it dynamically matches the resource requirements of the target service container with the real-time resource usage of each node, selecting a suitable target node from available nodes; during service container operation, when load changes reach a preset threshold, it automatically triggers scaling up or down, adjusting the number of instances and / or resource quotas, achieving dynamic adaptation during operation. Compared to solutions that rely solely on the default scheduling strategy of the underlying orchestration platform, this invention provides more granular control over resource allocation, improving resource utilization and business responsiveness.

[0050] Third: Simplify service version upgrade and rollback processes to improve business continuity. In existing technologies, service version upgrades typically require manual step-by-step stopping of the old version, starting of the new version, and manual handling of abnormal rollbacks. This process is cumbersome and prone to causing prolonged interruptions. This invention introduces two optional upgrade modes: blue-green deployment and rolling upgrade. When choosing blue-green deployment, a new deployment unit is created to host the new version service container. Health checks and traffic switching tests are performed. After successful verification, online traffic is gradually switched from the old version to the new version. Once stability is confirmed, the old version deployment unit is destroyed. When choosing rolling upgrade, existing service instances are replaced in batches. After each batch upgrade, relevant operational metrics are continuously monitored. If normal, the upgrade continues; if abnormal, subsequent batches are paused, and the old version service instance is restored through the rollback interface. This design significantly reduces the complexity and risk of upgrade and rollback operations while maintaining business continuity, achieving the goals of shortening version release and fault recovery time and ensuring service availability.

[0051] Fourth: Centralized management and improved observability of logs and operational status. Addressing the issue in the background technology where logs are scattered across various nodes and containers, making unified retrieval and analysis difficult, this invention establishes a log management module. This module uniformly logs service container operation requests, authentication and parameter verification results, container lifecycle operation records, and resource scheduling decision results received by the API gateway layer. The log data is then written to a message middleware and forwarded to a distributed search engine and / or time-series database for storage and indexing. Through this mechanism, operations personnel can retrieve service container operational logs and scheduling logs on a unified platform based on specific conditions. Combined with time-series monitoring data, this allows for trend analysis and problem localization, while also providing data support for subsequent scheduling strategy optimization and dynamic adaptation. This significantly improves the observability of service container operational status and operational efficiency.

[0052] Fifth: Enhanced adaptability and system scalability across different container operating environments. In existing technologies, users need to write scripts and configure settings separately for Kubernetes, DockerSwarm, or standalone Docker environments, resulting in high environment switching costs. This invention establishes a unified service container operation semantics between the API gateway layer and the business logic layer. The container management module and resource scheduling module then convert this unified semantics into service container creation and / or update commands recognizable by the container orchestration cluster, which are then distributed to the Kubernetes cluster and / or DockerSwarm cluster for execution, decoupling the upper-layer API calls from the underlying container platform. Combined with the layered architecture design of the API gateway layer, business logic layer, and data storage layer, this invention not only facilitates migration and expansion across different container platforms but also reserves a unified extension interface for subsequent integration with other orchestration environments or external systems, improving the overall scalability and reusability of the system.

[0053] This invention addresses the problems in the background technology, such as complex operation, inflexible scheduling, cumbersome upgrade and rollback, weak log management, and insufficient environment adaptability, by synergistically applying technical features such as unified API access, security and parameter verification, container lifecycle management, intelligent resource scheduling, version upgrade and rollback control, and centralized log management. It can simplify container operation and maintenance while improving resource utilization and service stability. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a flowchart of the intelligent scheduling and dynamic adaptation method for service containers of the present invention.

[0056] Figure 2 This invention is a service container intelligent scheduling and dynamic adaptation system.

[0057] Figure 3 This is a schematic diagram illustrating the process and call sequence for creating the container API interface according to the present invention.

[0058] Figure 4 This is a schematic diagram of the main API interfaces of this invention.

[0059] Figure 5 This is a schematic diagram of the process for upgrading the service version of this invention. Detailed Implementation

[0060] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0061] Example 1

[0062] like Figure 1 As shown, this embodiment provides an API-driven intelligent scheduling and dynamic adaptation method for service containers, including the following steps:

[0063] (1) The API gateway layer receives service container operation requests from users and / or external systems and forwards the service container operation requests to the business logic layer;

[0064] (2) The security control module performs identity authentication and permission verification on the service container operation request, and the parameter validator performs legality verification on the request parameters in the service container operation request. The target service container operation instruction is generated only when the verification passes.

[0065] (3) The container management module in the business logic layer performs at least one of the following operations on the target service container: creation, startup, stop, deletion and status monitoring, according to the target service container operation instructions;

[0066] (4) The resource scheduling module in the business logic layer schedules the operation instructions of the target service container according to the current cluster resource usage and the preset scheduling strategy, determines the target node and / or target resource quota, and issues the corresponding service container creation and / or update commands to the container orchestration cluster to complete the deployment and / or adjustment of the target service container;

[0067] (5) The log management module in the business logic layer collects, stores and analyzes the service container operation requests, service container running status and resource scheduling results, and writes the log data related to the service container operation and scheduling into the data storage layer to support subsequent scheduling optimization and dynamic adaptation.

[0068] Through the collaboration among the API gateway layer, security control module, parameter validator, container management module, resource scheduling module, and log management module, service containers can achieve unified access, centralized scheduling, and dynamic adaptation based on APIs throughout their entire lifecycle.

[0069] By combining the above steps, this embodiment ensures a unified operation entry point and centralizes security verification, parameter verification, container lifecycle management, resource scheduling, and log collection in the business logic layer and data storage layer. On the one hand, it avoids the configuration complexity and risk of misoperation caused by users directly operating the underlying container orchestration environment. On the other hand, it ensures that the entire process of service container creation, operation, and adjustment is under a controllable and traceable unified governance framework, which is conducive to improving the overall stability and operation and maintenance efficiency of the system.

[0070] As one implementation method, in this embodiment, for a service container creation request, steps (1) to (4) specifically include:

[0071] Users call the API interface to create service containers and send a creation request containing image information, resource quotas and running parameters to the API gateway layer;

[0072] The API gateway layer forwards the creation request to the authentication module. The authentication module verifies the user's identity and access permissions based on the token carried and returns the verification result to the API gateway layer.

[0073] If the verification result is successful, the API gateway layer forwards the creation request to the parameter validator, which performs format and constraint verification on the request parameters such as image identifier, resource parameters and business tags to generate valid creation service container request parameters.

[0074] The API gateway layer forwards the valid service container creation request parameters to the business logic layer. The container management module constructs the target operation instruction for creating the service container, and the resource scheduling module selects the target node and converts the operation instruction into a service container creation command that can be recognized by the container orchestration cluster. The command is then sent to the Kubernetes cluster and / or DockerSwarm cluster for execution, and the returned service container identifier is obtained.

[0075] The API gateway layer sends the service container identifier to the user as a successful creation result.

[0076] By setting up the service container creation process described above, this implementation decouples the external caller from the underlying Kubernetes cluster and / or DockerSwarm cluster. The caller only needs to submit a creation request in accordance with a unified API format. The API gateway layer and business logic layer internally handle the details such as authentication, parameter organization, scheduling, and command conversion, thereby reducing the caller's awareness and adaptation workload of the underlying environment differences and lowering the threshold for service deployment.

[0077] As one implementation method, in this embodiment, the authentication module performs signature verification and validity period verification on the token, and determines that the authentication is successful only when the signature is correct and the token has not expired; the parameter validator performs integrity verification on the required parameters in the service container creation request, performs upper and lower limit constraint verification on the resource quota parameters, and performs legality verification on the image repository address. If any verification fails, an error message is returned to the API gateway layer and the current service container creation process is terminated.

[0078] By introducing token authentication and parameter constraint verification into the creation process, we can prevent unauthorized users or requests exceeding their permissions from entering the container orchestration cluster. On the other hand, we can intercept issues such as missing parameters, over-configuration, or invalid image addresses before the request enters the execution phase, avoiding the need to roll back and fix incorrect configurations after they enter the cluster, thus improving the security and correctness of the service container creation phase.

[0079] As one implementation method, the scheduling performed by the resource scheduling module in step (4) of this embodiment includes at least one of the following processes:

[0080] The scheduling requests for different service containers are queued and sorted according to the business priority label, and computing resources are allocated to high-priority service containers first.

[0081] The system dynamically matches the resource requirements of the target service container with the current resource usage of each node, and selects the target node that meets the resource requirements such as processor and memory from the available nodes.

[0082] During the operation of the service container, when the load change of the target service container is detected to reach a preset threshold, the scaling up or scaling down operation is automatically triggered to adjust the number of target service container instances and / or resource quotas, so as to achieve dynamic adaptation to the running status.

[0083] Through the above-mentioned resource scheduling and dynamic scaling mechanism, this implementation method can flexibly select the deployment location according to the real-time resource occupancy of different nodes while ensuring that high-priority services receive resource guarantees. It can also automatically adjust the number of instances and resource quotas when the load increases or decreases, thereby alleviating the problem of long-term idle resources or local overload and improving the cluster resource utilization and service quality.

[0084] As one implementation method, in this embodiment, for a service version upgrade request, the method further includes:

[0085] The API gateway layer receives service version upgrade requests initiated by users and forwards them to the business logic layer.

[0086] After completing permission and parameter verification, the business logic layer selects one of the blue-green deployment strategy and the rolling upgrade strategy as the upgrade strategy based on the strategy identifier carried in the upgrade request.

[0087] Based on the upgrade strategy, the container management module and resource scheduling module are invoked to gradually replace the version of the target service container. During the upgrade process, key operational indicators are reported to the log management module and / or monitoring system to determine whether the upgrade process is normal.

[0088] By uniformly managing service version upgrade requests at the business logic layer and combining preset blue-green deployment strategies and rolling upgrade strategies for version replacement, this implementation method can provide multiple upgrade path options for the same service without changing the caller's interface usage habits. This facilitates the adoption of a more reliable upgrade method in critical business scenarios and also facilitates rapid version iteration in general scenarios.

[0089] As one implementation method, in this embodiment, when a blue-green deployment strategy is selected, the service version upgrade process includes:

[0090] Create a new deployment unit to host the new version of the service container, and perform startup and health checks on the deployment unit;

[0091] Before switching traffic on the live network, conduct traffic switching tests on the new version of the service to verify that the functionality and performance meet the preset conditions.

[0092] After the test is passed, gradually switch online access traffic from the old version deployment unit to the new version deployment unit;

[0093] Once it is detected that all business traffic has been switched to the new version and is running stably, the old version deployment unit is destroyed, completing this blue-green upgrade.

[0094] Through the above blue-green deployment process, this implementation method completes the verification of the new version and the switching of traffic while the old version deployment unit and the new version deployment unit exist in parallel. The old version is destroyed only when the new version meets the preset requirements in terms of functionality and performance and runs stably. This minimizes the impact on online business during the version replacement process and achieves a near-unnoticed version upgrade.

[0095] As one implementation method, when a rolling upgrade strategy is selected in this embodiment, the service version upgrade process includes:

[0096] Replace existing service instances of the target service in batches, and keep the number of service instances to be upgraded in each batch within a preset range.

[0097] During each upgrade batch, we continuously monitor service-related operational metrics to determine whether the service is normal after the current upgrade batch.

[0098] If the monitoring results indicate that the service is running normally, continue to replace the next batch of service instances until all service instances have been upgraded.

[0099] If monitoring results indicate that the service is not running normally, subsequent upgrades will be paused, an automatic rollback process will be triggered, and the old version of the service instance will be restored to its running state by calling the rollback interface.

[0100] By adopting a phased rolling upgrade approach and combining operational metrics for health assessment after each upgrade, this implementation method can gradually complete the version replacement while ensuring overall service availability. Once an anomaly is detected in an intermediate batch, subsequent upgrades can be stopped immediately and a rollback operation can be triggered, keeping the impact within a limited number of instances. This helps to shorten fault recovery time and reduce upgrade risks.

[0101] As one implementation method, the data storage layer in step (5) of this embodiment includes at least:

[0102] Message middleware is used to store asynchronous messages and event notifications from the business logic layer, and is used to decouple service container scheduling operations from subsequent processing flows.

[0103] A distributed search engine is used to store and index service container runtime logs and scheduling logs collected by the log management module, supporting index-based log retrieval and analysis.

[0104] Time-series databases are used to monitor time-series metrics during the operation of storage service containers, in order to support trend analysis of resource usage and service performance.

[0105] Image repositories are used to store image files for service containers, providing a source of images for creating and upgrading service containers.

[0106] By introducing message middleware, distributed search engine, time-series database and image repository into the data storage layer, this implementation achieves centralized management and efficient retrieval of service container operation logs, scheduling logs, monitoring metrics and image resources on a unified platform. This facilitates subsequent statistical analysis and optimization of scheduling behavior and service performance, and ensures reliable acquisition of container images during creation and upgrade.

[0107] As one implementation method, the log management module in this embodiment further includes the following when performing step (5):

[0108] The API gateway layer receives service container operation requests, the processing results of the authentication module and parameter validator, the lifecycle operation records of the container management module, and the scheduling decision results of the resource scheduling module.

[0109] The log data is written to the message middleware and then forwarded to the distributed search engine and / or time-series database to support multi-dimensional retrieval and visualization analysis of the service container's running status, scheduling behavior, and upgrade process.

[0110] Through the above log management model, this implementation method can form a closed-loop log record from the complete chain of "entry request - permission and parameter verification - lifecycle operation - resource scheduling decision - operation result". Combined with the retrieval and visualization capabilities provided by the distributed search engine and time series database, it provides a fine-grained data foundation for fault diagnosis, performance analysis and scheduling strategy optimization.

[0111] This embodiment, through the collaborative design of modules in the API gateway layer, business logic layer, and data storage layer, enables the service container to form a clear and well-defined integrated processing flow in terms of creation, operation, scaling, upgrade rollback, and log analysis. This not only solves the problems of complex operation, inflexible scheduling, cumbersome upgrade rollback, and scattered and difficult-to-analyze logs in the background technology, but also provides a unified technical foundation for subsequent promotion and application in different container orchestration environments, and has good engineering practical value and promotion prospects.

[0112] Example 2

[0113] This embodiment provides an API-driven intelligent scheduling and dynamic adaptation system for service containers, used to implement the method described in Embodiment 1. Figure 2 As shown, the system is divided into several parts according to logical functions, including the user / external system layer, API gateway layer, security control module, business logic layer, and data storage layer. These parts are connected and communicate with each other through a network.

[0114] The user / external system layer is used to host various callers of this system, including front-end pages used by operations and maintenance personnel, third-party business systems, and automation scripts. The user / external system layer calls the service container operation interface provided by the API gateway layer through HTTP requests. The request content includes at least container deployment, status query, start, stop, delete, upgrade, and log retrieval.

[0115] The API gateway layer is used for unified access and forwarding of HTTP requests from the user / external system layer. Following the REST style, the API gateway layer provides a unified interface entry point, routes and distributes requests based on different paths and methods, forwards service container operation requests to the security control module and business logic layer, and also returns information such as service container creation results, status query results, and upgrade execution results to the caller.

[0116] The security control module, connected to the API gateway layer, performs security verification on service container operation requests forwarded by the API gateway layer. The security control module includes at least an authentication unit and a permission verification unit: the authentication unit completes identity authentication based on the token information carried in the request; the permission verification unit determines whether the caller has the corresponding operation permissions based on the caller's role and preset access control rules, allowing only requests that have passed both authentication and authorization to enter the business logic layer.

[0117] The business logic layer is situated between the API gateway layer and the data storage layer, and is responsible for hosting the core functions of service container management and intelligent scheduling. The business logic layer includes at least:

[0118] (1) Container management module, which is used to perform operations such as creating, starting, stopping, deleting and monitoring the status of service containers according to the service container operation instructions verified by the security control module; when receiving a creation request from the API gateway layer, the container management module constructs a container creation instruction according to the request parameters and submits the instruction to the underlying Kubernetes cluster and / or DockerSwarm cluster for execution.

[0119] (2) Resource scheduling module, which is used to make scheduling decisions on the service container operation instructions submitted by the container management module based on the current cluster resource usage and preset scheduling strategy, select target nodes that meet the resource conditions such as processor and memory, and determine the target resource quota; the resource scheduling module sends the service container creation or adjustment command containing target node information and resource quota to the container orchestration cluster to realize the deployment, scaling up and down and dynamic resource adaptation of service containers.

[0120] (3) Log management module, which is used to uniformly log the service container operation requests received by the API gateway layer, the life cycle operation records of the container management module and the scheduling results of the resource scheduling module; the log management module writes the sorted log data into the corresponding storage component in the data storage layer, and supports centralized query and analysis of the service container running status, scheduling behavior and upgrade process.

[0121] The data storage layer is bidirectionally connected to the business logic layer, providing persistent storage capabilities for service container runtime monitoring, log analysis, and image management. The data storage layer includes at least:

[0122] Kafka, a message middleware, is used to receive asynchronous messages and event notifications from the log management module and other business modules, buffer and forward logs and events, and decouple service container scheduling operations from subsequent analysis and processing.

[0123] Elasticsearch, a distributed search engine, is used to store and index service container runtime logs and scheduling logs collected and processed by the log management module, and supports multi-condition log retrieval and statistical analysis based on indexes.

[0124] Influxdb, a time-series database, is used to store time-series monitoring metrics during the operation of storage containers, including processor utilization, memory usage, disk I / O, etc., providing a data foundation for the resource scheduling module to evaluate resource usage and perform trend analysis.

[0125] Harbor, the image repository, is used to centrally store image files of various service containers. When the business logic layer performs creation or upgrade operations, it can pull the corresponding image from the image repository, providing image protection for the deployment, upgrade and rollback of service containers.

[0126] In this embodiment, the above layers and modules work together: the user / external system layer initiates a service container operation request through the API gateway layer. After the security control module completes identity authentication and permission verification, the container management module and resource scheduling module of the business logic layer complete the creation, operation, maintenance and version upgrade of the service container. The operation logs and monitoring data generated by the business logic layer are uniformly written to the data storage layer by the log management module, thereby forming a service container intelligent scheduling and dynamic adaptation system with API as the unified entry point and layered architecture as the basis, realizing the specific implementation of the method described in Embodiment 1 at the system level.

[0127] Example 3

[0128] like Figure 3 As shown in the diagram, this embodiment illustrates the call sequence of the Application Programming Interface (API) for creating a service container based on the method of this invention. It demonstrates the interaction logic between the user, the API gateway, the authentication module, the parameter validator, the business logic processing module, and the container orchestration platform of the Kubernetes cluster and / or Docker Swarm cluster. The specific process is as follows:

[0129] First, the user side sends a request to the API gateway to create a service container by calling the "Create Service Container API" interface through the client. This request carries image information, resource quotas, running parameters, and authentication information such as tokens ("Calling the Create Container API" in the diagram).

[0130] After receiving the creation request, the API gateway forwards the JSONWebToken (JWT, JSON Web Token) carried in the request to the authentication module. The authentication module then performs "JWT token verification," which verifies the token's signature and validity period, and returns the "verification result" to the API gateway.

[0131] Assuming the signature verification passes, the API gateway continues to call the parameter validator to validate the request body parameters of the creation request ("Validate Request Body Parameters" in the diagram). The validation includes checking whether required parameters are complete, whether the parameter format is correct, and whether resource parameters are within the allowed range. After completing the validation, the parameter validator returns the "Validation Result".

[0132] When both the authentication module and the parameter validator return a pass result, the parameter validator "forwards the valid request parameters" to subsequent modules, that is, it sends the valid container creation request parameters to the business logic processing module.

[0133] After receiving the valid request parameters, the business logic processing module constructs a specific "create container command" based on the container management module and resource scheduling module, and calls the underlying Kubernetes / DockerSwarm cluster interface to send the command to the container orchestration platform for execution ("call the create container command" in the figure).

[0134] The Kubernetes / DockerSwarm cluster pulls the image, allocates resources, and starts the container according to the container creation command. After successful creation, it returns a "container ID" to the business logic processing module, where "id" is the container's unique identifier. The business logic processing module then returns this "container ID" to the API gateway.

[0135] The API gateway ultimately returns the container identifier to the user in the form of "responding with container ID and returning a message indicating successful container creation". This allows the user to confirm the success of the creation operation and perform subsequent operations such as status querying, starting, and stopping the container using the container identifier.

[0136] Through the above interaction process Figure 3 The various messages, such as "Call the Container Creation API", "JWT Token Verification", "Verification Result", "Verification Request Body Parameters", "Verification Result", "Forwarding Valid Request Parameters", "Call the Container Creation Instruction", "Return Container ID", and "Response Container ID, Returning Successful Container Creation", fully reflect the sequential relationship and data flow of unified access, authentication verification, and business logic processing based on the API gateway when creating a service container in this embodiment.

[0137] like Figure 5As shown in the figure, this embodiment further provides a flowchart of the service version upgrade process, which is used to illustrate how the system can perform secure and controllable version replacement of running service containers according to different upgrade strategies based on the method of the present invention.

[0138] First, the process starts from the "Start" node. The user "initiates an upgrade request" in the operation and maintenance interface or an external system, and the system receives the request and proceeds to the "Accept Request" step.

[0139] In the "Verify Permissions and Parameters" node, the system verifies the permissions of the person initiating the upgrade request, as well as the version number, target image, upgrade policy identifier, and other parameters carried in the request. It will only continue to execute subsequent steps if the permissions are satisfied and the parameters are valid.

[0140] The system then proceeds to the "Select Upgrade Strategy" decision node: based on the strategy identifier carried in the upgrade request, the system selects between two strategies: "Blue-Green Deployment" and "Rolling Upgrade".

[0141] When a blue-green deployment strategy is selected, the process enters the left branch. The system first "creates a new Deployment", which means creating a new deployment unit to host the new version of the service container, and completing the startup and health checks of the new deployment unit.

[0142] After the newly deployed unit starts up and stabilizes, the system performs a "traffic switching test" to redirect some requests to the new version of the service within a controlled traffic range, verifying its functional correctness and whether its performance indicators meet the preset requirements.

[0143] After the test is passed, the system enters the "gradual traffic switching" step, which gradually migrates online access traffic from the old version deployment unit to the new version deployment unit until all business traffic is switched to the new version.

[0144] After confirming that the new version service is running stably, the system performs the "destroy old version" operation, deletes the old version deployment unit, ends the blue-green deployment branch, and the process returns to the "all updates completed" stage of the overall process, finally reaching the "end" node.

[0145] When the rolling upgrade strategy is selected in the "Select Upgrade Strategy" node, the process enters the right branch. The system first executes "Replace Pods (Service Instance Units) in Batches", which replaces the existing service instances of the target service in batches, replacing a portion of the instances in each batch.

[0146] In one specific implementation, "update 20% per batch" can be used as an example configuration, meaning that the number of service instances replaced in each batch is approximately 20% of the total number of service instances, to ensure that there are still enough instances to provide service capabilities during the upgrade process.

[0147] During each batch of replacements, the system performs "continuous monitoring of metrics," continuously collecting and analyzing key operational metrics related to the service through monitoring components, such as response time and error rate.

[0148] Then, the process proceeds to the "Determine if the service is normal" decision node. If the monitoring results indicate that the service is running normally ("Yes" branch), the process proceeds to "Continue to the next batch" and continues to replace the next batch of instances to be upgraded in the same way until all instances are updated. At this point, the process returns to the "All updates completed" section of the main process and finally reaches the "End" node.

[0149] If a service anomaly is detected at the "Determine if the service is normal" node ("No" branch), the process will enter the "Pause Upgrade" step, immediately stopping subsequent batches of upgrade operations.

[0150] After the upgrade is paused, the system triggers an "automatic rollback," automatically entering the rollback process. It calls the "RollingBackAPI (Rollback Application Programming Interface) to restore the old version of the Pod," reverting the service instance that was replaced with the new version to the old version to ensure the service returns to a stable state as quickly as possible. Once the rollback is complete, the process eventually reaches the "End" node.

[0151] pass Figure 5 The steps shown in this embodiment, including "Start," "User Initiates Upgrade Request," "Accept Request," "Verify Permissions and Parameters," "Select Upgrade Strategy," "Create New Deployment," "Traffic Switching Test," "Gradually Switch Traffic," "Destroy Old Version," "Replace Pod (Service Instance Unit) in Batches," "Update 20% in Each Batch," "Continuously Monitor Metrics," "Determine if Service is Normal," "Pause Upgrade," "Trigger Automatic Rollback," "Call RollingBack API (Rollback Application Programming Interface) to Restore Old Version Pod," "All Updates Completed," and "End," clearly demonstrate the complete control flow of service version upgrades and rollbacks under the method of this invention, as well as the logical relationships between each node.

[0152] Example 4

[0153] like Figure 3 , Figure 4 and Figure 5 As shown, this implementation provides a specific implementation case as follows:

[0154] For the process and call order of creating a container API interface, please refer to [link / reference]. Figure 3 Detailed descriptions are provided in Example 3. A partial list of major API interfaces is shown below. Figure 4 As shown; Figure 5 This is a flowchart illustrating the service version upgrade process;

[0155] The system architecture of this embodiment is mainly divided into four layers: the user / external system layer, the API gateway layer (application programming interface gateway layer), the business logic layer, and the data storage layer. The following is a detailed introduction to each layer and the implementation steps of the system functions.

[0156] ① This embodiment designs a set of API interfaces (Application Programming Interfaces) that conform to the RESTful style (representational state transition style), adopts intuitive resource naming conventions (such as " / api / containers / deploy" for container deployment, and " / api / containers / {id} / status" for obtaining container status) and standard HTTP methods (HTTP is Hypertext Transfer Protocol, where GET is used for querying, POST is used for creating, PUT is used for updating, and DELETE is used for deleting), so that users can complete various operations through simple HTTP requests.

[0157] ② Users send requests to the system via HTTP clients (such as browsers, Postman tools, or custom scripts), for example, by sending a POST request to " / api / containers / deploy" to deploy a new container. The system receives the request and begins processing it.

[0158] ③ The system uses the Spring Boot framework (a Java-based server-side development framework) to process received requests. First, it checks whether the parameters in the request meet the requirements (such as whether there are any missing required parameters or whether the parameter format is correct). At the same time, it verifies whether the identity of the request initiator is legitimate (such as checking whether the user is logged in and whether they have the corresponding permissions). Only requests that pass the verification will be processed to ensure the security and stability of the system.

[0159] ④ After successful verification, the system distributes the request to the corresponding business logic module according to the request path and method. For example, if the request is a container deployment operation, the request is sent to the container management module, which is responsible for the specific container creation and configuration work.

[0160] ⑤ Use the knife4j tool (an API documentation generator) to automatically generate detailed API documentation. The documentation includes not only the API path, request method, and parameter description, but also sample requests and return data formats, allowing users to quickly understand how to use each API and the expected results.

[0161] ⑥ The generated API documentation page provides an online testing function. Users can directly fill in the request parameters and send the request on the page. The system will return the processing result of the interface in real time, which makes it convenient for users to quickly verify the functionality of the interface during the development and learning process, thereby improving development efficiency and learning effectiveness.

[0162] Intelligent resource scheduling:

[0163] ① The system periodically collects container resource usage data, including key indicators such as CPU utilization, memory usage, and disk I / O, through the Docker Remote API (Docker Remote Application Programming Interface) and the Kubernetes / Docker Swarm API, in order to monitor the container's running status and resource requirements in real time.

[0164] ② The collected resource data is stored in the distributed time-series database InfluxDB (InfluxDB is a time-series data management database). By leveraging InfluxDB's efficient storage and query capabilities, it is convenient to analyze and query historical data in the future, providing data support for resource scheduling and optimization.

[0165] ③ Use TensorFlow (an open-source machine learning framework) to build a resource demand prediction model. Based on historical resource usage data, combine machine learning algorithms such as time series analysis to predict the resource demand of the container in the future, and provide a scientific basis for the rational allocation of resources.

[0166] ④ Combining real-time collected resource data and prediction results, the optimal resource allocation scheme is calculated through dynamic programming algorithm to ensure that the resource utilization rate is maximized while meeting the container's operating requirements and avoiding resource waste.

[0167] ⑤ When resources are scarce, the system will temporarily borrow idle resources from low-priority applications and return them in a timely manner after use, ensuring that high-priority applications can obtain sufficient resources and guaranteeing the overall performance and stability of the system.

[0168] ⑥ Utilize Kubernetes' HorizontalPodAutoscaler feature to automatically adjust the number of container replicas based on the actual load. When the load increases, the number of replicas is automatically increased to improve processing capacity, and when the load decreases, the number of replicas is automatically reduced to release resources, thereby achieving dynamic scaling and efficient utilization of resources.

[0169] Automated service upgrades and rollbacks:

[0170] ① Users trigger the service upgrade process by sending an upgrade command to the " / api / containers / {id} / upgrade" interface. After receiving the command, the system begins to execute the upgrade operation.

[0171] ② The upgrade management module gradually replaces older versions of services by calling the Kubernetes Deployment API (Deployment Application Programming Interface) according to a preset upgrade strategy (such as rolling updates or blue-green deployment). Under the rolling update strategy, the system will gradually update container image copies according to the set batch number to minimize the impact on business operations.

[0172] ③ During the upgrade process, Prometheus (monitoring system) and Grafana (visual monitoring panel) are used to monitor the service in real time. At the same time, custom health check scripts are injected into the service container to report its own health status to the monitoring system on a regular basis so as to detect potential problems in a timely manner.

[0173] ④ If monitoring detects any abnormalities in the new version of the service, such as service response timeouts or increased error rates, the upgrade management module will immediately pause the upgrade operation and quickly call Kubernetes' RollingBack API to initiate the rollback process, rapidly restoring the service to the old version and ensuring business continuity and stability.

[0174] ⑤ Throughout the upgrade and rollback process, the system uses a distributed file system (such as Ceph distributed storage system) to perform real-time backup and synchronization of critical data, ensuring data consistency and integrity, and avoiding data loss or damage due to upgrade or rollback operations.

[0175] For detailed procedures on service upgrades and rollbacks, please refer to [link / reference]. Figure 5 .

[0176] Enhanced log management:

[0177] ① Deploy a lightweight log collection agent, Fluentd (an open-source log collector), within each container. Through carefully configured configuration files, explicitly specify the log collection path and uniform format to ensure the standardization and integrity of log data, facilitating subsequent log analysis and processing.

[0178] ② The collected log data is sent to the log collection server using the efficient and reliable Kafka high-performance message queue (Kafka is a distributed messaging system) transmission protocol. By leveraging Kafka's high throughput and reliability, the log data can be transmitted to the server quickly and stably.

[0179] ③ In the log aggregation service running on the server side, Kafka's consumer component performs preliminary cleaning, format conversion, and adds necessary metadata to the raw log data, removing invalid or redundant information, unifying the log format, and preparing it for subsequent storage and analysis.

[0180] ④ Store the processed log data in a centralized Elasticsearch log storage system (Elasticsearch is a distributed search and analysis engine). By leveraging Elasticsearch's powerful search and analysis capabilities, users can easily retrieve and analyze massive amounts of log data.

[0181] ⑤ Users can send API requests to the " / api / logs / search" interface to efficiently search logs based on various flexible conditions such as time range, keywords, and log level, and quickly locate log records related to the problem.

[0182] ⑥ The system uses machine learning tools provided by Elasticsearch to perform in-depth mining and intelligent analysis of massive log data, automatically identifying potential anomaly patterns and hidden risks, helping operations and maintenance personnel to discover potential problems in advance.

[0183] ⑦ The analysis results are presented to users in various forms such as trend charts and bar charts through the Kibana tool (a visualization component of Elasticsearch), helping operations and maintenance personnel to quickly and accurately locate the root cause of the fault, and greatly improving the efficiency of fault diagnosis and the timeliness of system maintenance.

[0184] Enhance environmental awareness and adaptation:

[0185] ① During the initial startup phase, the system automatically executes a series of carefully designed detection scripts and comprehensively and accurately identifies the type of container orchestration environment (such as Kubernetes cluster, DockerSwarm cluster, etc.) by calling the API interface of the container orchestration platform. At the same time, it obtains key information such as cluster size, detailed node configuration, and network topology.

[0186] ② Based on the identification results, the system will quickly retrieve the matching adaptation module from the predefined adaptation strategy library and dynamically and intelligently adjust its own configuration parameters to achieve seamless adaptation with the target environment. For example, in a Kubernetes environment, the system will adjust the resource scheduling module's strategy accordingly to match Kubernetes' native scheduling algorithm, taking into account its unique resource scheduling mechanism and management model; in a DockerSwarm environment, it will also match the corresponding scheduling mechanism and configuration requirements.

[0187] ③ The system leverages the event listening mechanism of the container orchestration platform to monitor dynamic environmental changes such as cluster size changes and node status updates in real time. Once an environmental change is detected, the adaptation module is immediately triggered to automatically reconfigure system parameters according to preset rules, ensuring stable operation of the system in different environments and effectively improving the system's compatibility, ease of use, and environmental adaptability.

[0188] Multi-layered security protection:

[0189] ① Adopt a role-based access control (RBAC) mechanism to set roles and assign permissions to different users and components.

[0190] ② Deeply integrate with Kubernetes RBAC API to associate user identity with roles through role binding and cluster role binding.

[0191] ③ When a user requests access to a resource, the Authorizer (authorization decision component) authentication and authorization plugin verifies the user's identity and permissions.

[0192] ④ Use DockerNamespace technology to allocate independent process space, network namespace and file system mount point for each container.

[0193] ⑤ Build a dedicated image repository, verify the signatures of the images, and regularly use the Clair tool (a container image security scanning tool) to scan for image vulnerabilities.

[0194] ⑥ Generate security patches and repair suggestions based on the scan results, and automatically download and apply the latest security patches.

[0195] Modular design and extended integration:

[0196] ① Divide the system into multiple modules with clearly defined functions and single responsibilities. For example, the container management module is responsible for operations such as creating, starting, stopping, and deleting containers; the resource scheduling module is responsible for dynamically allocating and adjusting resources based on resource usage; and the log management module is responsible for collecting, storing, and analyzing log information, ensuring that each module focuses on a specific task.

[0197] ② The modules communicate with each other through a standardized RESTful HTTP API interface (HTTP stands for Hypertext Transfer Protocol). For example, after creating a container, the container management module calls the API interface of the resource scheduling module to notify it to allocate resources to the new container. At the same time, the efficient message middleware Kafka is used to realize asynchronous communication and data interaction, thereby improving the system's response speed and scalability.

[0198] ③ The functional logic is implemented using Java object-oriented programming language within the module, strictly following the design principle of high cohesion and low coupling. Related functions are encapsulated in classes and methods to reduce direct dependencies between modules and facilitate code maintenance and expansion.

[0199] ④ The system provides rich and standardized API interfaces. All interfaces strictly follow unified specifications and data format standards (such as JSON data format). For example, it provides container status query interfaces and resource allocation adjustment interfaces, which reduces the difficulty and cost of integration with other systems.

[0200] ⑤ Provide a container deployment rollback API interface, enabling the CI / CD platform (continuous integration / continuous delivery platform) to automatically trigger container deployment operations by calling this interface after completing code building and testing, thereby automating and integrating the development, testing, and deployment processes.

[0201] ⑥ Design a flexible plug-in mechanism that allows users to independently develop new functional modules (such as custom log analysis plug-ins, personalized resource scheduling strategy plug-ins, etc.) according to their own business needs, and integrate them into the system through simple configuration, further expanding the functional boundaries of the system.

[0202] Resource allocation strategy adjustment:

[0203] ① The resource allocation strategy adjustment module evaluates and optimizes the existing resource allocation scheme based on real-time data and analysis results provided by the intelligent scheduling algorithm, so as to improve resource utilization and overall system performance.

[0204] ② The container resource monitoring module regularly collects resource utilization data of each container, including key indicators such as CPU utilization, memory usage, and disk I / O, and stores this data in an orderly manner in the InfluxDB database to provide data support for subsequent analysis and decision-making.

[0205] ③ The idle resource identification algorithm performs in-depth analysis of historical data stored in the database to accurately identify container nodes that have been in an inefficient operating state for a long time, such as those nodes whose CPU and memory utilization rates are consistently below a set threshold (e.g., 20%).

[0206] ④ The cost accounting module is based on the company's established cost model and calculates in detail the specific impact of resource adjustment operations on operating costs, including hardware costs, energy costs, etc., to ensure that the resource adjustment plan is economically feasible.

[0207] ⑤ Based on the above analysis results, the resource allocation strategy adjustment module generates detailed resource optimization and adjustment suggestions, such as suggesting that certain containers be migrated to nodes with low resource utilization, or suggesting that the hardware configuration of certain nodes be updated and upgraded.

[0208] ⑥ The system automatically performs resource adjustment operations, including container migration and node configuration updates, to achieve reasonable allocation and efficient utilization of resources, helping enterprises reduce operating costs and improve the return on investment of resources.

[0209] This embodiment offers at least the following advantages: a simplified API design and visual user interface, reducing the learning curve and operational difficulty of container management; a self-developed intelligent resource scheduling algorithm that analyzes application and resource status in real time, dynamically adjusts resource allocation, and improves utilization; an automated service upgrade and rollback mechanism triggered via API, combined with monitoring and data backup, ensuring high availability and continuity of services; an integrated log management platform that provides centralized storage and intelligent analysis, accelerating fault diagnosis; and an environment awareness and adaptation module that automatically identifies various container orchestration environments and dynamically adjusts configurations, simplifying deployment and management.

[0210] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. An API-driven intelligent scheduling and dynamic adaptation method for service containers, characterized in that: It includes the following steps: (1) The API gateway layer receives service container operation requests from users and / or external systems and forwards the service container operation requests to the business logic layer; (2) The security control module performs identity authentication and permission verification on the service container operation requests, and the parameter validator performs legality verification on the request parameters in the service container operation requests. Only when the verification passes, a target service container operation instruction is generated; (3) The container management module in the business logic layer performs at least one of the operations of creating, starting, stopping, deleting, and status monitoring on the target service container according to the target service container operation instruction; (4) The resource scheduling module in the business logic layer schedules the target service container operation instruction according to the current cluster resource usage situation and the preset scheduling policy, determines the target node and / or target resource quota, and issues corresponding service container creation and / or update commands to the container orchestration cluster to complete the deployment and / or adjustment of the target service container; (5) The log management module in the business logic layer collects, stores, and analyzes the service container operation requests, service container running status, and resource scheduling results, and writes the log data related to service container running and scheduling into the data storage layer to support subsequent scheduling optimization and dynamic adaptation; Among them, through the coordination among the API gateway layer, security control module, parameter validator, container management module, resource scheduling module, and log management module, the service container realizes unified access, centralized scheduling, and dynamic adaptation based on the API during the whole life cycle; For the service container creation request, steps (1) to (4) specifically include: The user calls the API interface for creating a service container and sends a creation request containing image information, resource quota, and running parameters to the API gateway layer; The API gateway layer forwards the creation request to the authentication module. The authentication module verifies the user identity and access permission based on the carried token and returns the verification result to the API gateway layer; When the verification result passes, the API gateway layer forwards the creation request to the parameter validator. The parameter validator performs format verification and constraint verification on the image identifier, resource parameters, and business label request parameters to generate legal creation service container request parameters; The API gateway layer forwards the legal creation service container request parameters to the business logic layer. The container management module constructs a target operation instruction for creating a service container, and after the resource scheduling module selects a target node, converts the operation instruction into a creation service container command recognizable by the container orchestration cluster and issues it to the Kubernetes cluster and / or DockerSwarm cluster for execution to obtain the returned service container identifier; The API gateway layer responds to the user with the service container identifier as the creation success result.

2. The method according to claim 1, wherein: The authentication module performs signature verification and validity period verification on the token, and determines that the authentication is passed only when the signature is correct and the token has not expired; the parameter validator performs integrity verification on the required parameters in the request for creating a service container, performs upper and lower limit constraint verification on the resource quota parameters, and performs legality verification on the image repository address. If any verification fails, an error message is returned to the API gateway layer and the current service container creation process is aborted.

3. The method according to claim 1, wherein: The scheduling performed by the resource scheduling module in step (4) at least includes any one of the following processes: Queue and sort the scheduling requests of different service containers according to the business priority tags, and preferentially allocate computing resources to high-priority service containers; Dynamically match the resource requirements of the target service container with the current resource usage of each node, and select a target node that meets the processor and memory resource conditions from the available nodes; During the running of the service container, when it is monitored that the load change of the target service container reaches the preset threshold, an expansion or contraction operation is automatically triggered to adjust the number of target service container instances and / or resource quotas to achieve dynamic adaptation to the running state.

4. The method according to claim 1, wherein: For a service version upgrade request, the method further includes: The API gateway layer receives the service version upgrade request initiated by the user and forwards it to the business logic layer; After completing the permission and parameter verification, the business logic layer selects one of the blue-green deployment strategy and the rolling upgrade strategy as the upgrade strategy according to the policy identifier carried in the upgrade request; Based on the upgrade strategy, call the container management module and the resource scheduling module to gradually replace the version of the target service container, and report the key running metrics to the log management module and / or the monitoring system during the upgrade process to determine whether the upgrade process is normal.

5. The method according to claim 4, characterized in that: When the blue-green deployment strategy is selected, the service version upgrade process includes: Create a new deployment unit carrying the new version of the service container, and start and perform a health check on the deployment unit; Before switching the live network traffic, perform a traffic switching test on the new version of the service to verify that the functions and performance meet the preset conditions; After the test passes, gradually switch the online access traffic from the old version deployment unit to the new version deployment unit; When it is detected that all business traffic has been switched to the new version and is running stably, destroy the old version deployment unit to complete this blue-green upgrade.

6. The method according to claim 4, wherein: When the rolling upgrade strategy is selected, the service version upgrade process includes: Replace the existing service instances of the target service in batches, and control the number of service instances to be upgraded in each batch within the range not exceeding the preset ratio; During the upgrade process of each batch, continuously monitor the running metrics related to the service to determine whether the service is normal after the current batch upgrade; If the monitoring result shows that the service is running normally, continue to perform the replacement of the next batch of service instances until all service instances have been upgraded; If the monitoring result shows that the service is running abnormally, suspend the subsequent upgrade, trigger the automatic rollback process, and restore the running state of the old version service instances by calling the rollback interface.

7. The method according to claim 1, wherein: The data storage layer in step (5) at least includes: A message middleware, which is used to store asynchronous messages and event notifications from the business logic layer and decouple the service container scheduling operation from the subsequent processing flow; A distributed search engine, which is used to store and index the service container running logs and scheduling logs collected by the log management module and support index-based log retrieval and analysis; A time series database, which is used to store the time series monitoring metrics during the running process of the service container to support trend analysis of resource usage and service performance; An image repository, which is used to store the image files of the service containers and provide an image pulling source for the creation and upgrade of the service containers.

8. The method according to any one of claims 1 to 7, characterized in that: When the log management module executes step (5), it further includes: Uniformly logging the service container operation requests received by the API gateway layer, the processing results of the authentication module and the parameter validator, the life cycle operation records of the container management module, and the scheduling decision results of the resource scheduling module; Writing the log data into the message middleware and then forwarding it to the distributed search engine and / or the time series database to support multi-dimensional retrieval and visualization analysis of the service container running status, scheduling behavior, and upgrade process.

Images