ERP non-core business migration method based on K8s dynamic resource scheduling

Abstract

The application relates to an ERP non-core business migration method based on K8s dynamic resource scheduling, and belongs to the technical field of cloud computing containerization and ERP system optimization. The method comprises the following steps: identifying non-core modules based on business criticality, generating a migration list, transforming internal interfaces into standard API gateway routing, and asynchronously decoupling strong dependence communication through a message queue. Historical resource load data is collected, a time series decomposition model is used to extract periodic rules, a benchmark value is set, and K8s scheduling parameters are generated. A multi-stage construction separation compilation and running environment is generated, and a lightweight image is generated. Security reinforcement, health check probes and dynamic configuration updates are implemented. According to the stateless and persistent requirements, the controller is selected; the Numa domain resource locality is optimized through topology sensing; the dynamic storage is bound to the persistent volume according to the QoS; the network strategy realizes the container-level traffic isolation. The resource quota and the number of replicas are dynamically adjusted. Efficient and safe migration of ERP non-core business in the K8s environment is realized.

Description

Technical Field

[0001] The present invention belongs to the technical field of cloud computing containerization and ERP system optimization, and specifically relates to an ERP non-core business migration method based on K8s dynamic resource scheduling. Background Art

[0002] Traditional ERP uses a monolithic architecture, with core modules (such as finance) and non-core modules (such as report generation) deeply coupled, leading to rigid resource allocation. The high fluctuation load of non-core business (such as periodic report generation) easily preempts core business resources, causing performance bottlenecks.

[0003] The old system data is redundant and has inconsistent formats (such as multiple versions of customer information stored), which requires cleaning and conversion during migration, which can easily lead to data loss or business interruption.

[0004] The default Kubernetes scheduler only supports homogeneous resources like CPU and memory, and cannot dynamically adapt to heterogeneous resource requirements like GPUs and disk I / O, resulting in underutilized or overloaded resources. Traditional ERP relies on specific hardware environments, making it difficult to directly containerize. For example, hard-coded database connection strings can lead to container migration failures, and stateful services (such as session persistence) conflict with Kubernetes' stateless design.

[0005] Inter-container communication lacks fine-grained control, with the default policy allowing full access, increasing the attack surface. Manually configuring Network Policy is prone to errors, and excessive policies reduce network throughput. ERP stores mixed hot and cold data, with modules requiring high IOPS (such as real-time transactions) competing for resources with batch processing modules. Local SSDs and distributed storage are not isolated as needed. Summary of the Invention

[0006] To solve the above problems existing in the prior art, the present invention provides an ERP non-core business migration method based on K8s dynamic resource scheduling. The purpose of the present invention can be achieved through the following technical solutions:

[0007] S1: Based on a pre-set business criticality matrix, identify non-core business modules in the ERP system and generate a migration priority list; transform the internal call interfaces of the non-core business modules to the original ERP system into standard API gateway routing; decouple the highly dependent inter-service communication between the non-core business modules and the core system into asynchronous communication based on message queues;

[0008] Collecting historical resource load time series data corresponding to the non-core business module; applying a time series decomposition model to analyze the historical resource load time series data, extracting its periodic variation pattern, and setting a benchmark resource load value accordingly; generating a K8s scheduling parameter dictionary based on the periodic variation pattern and the benchmark resource load value;

[0009] S2: Separate the compilation environment and runtime environment of the non-core business modules through a multi-stage image building strategy, and build a lightweight container image. Secure the container image and configure health check probes, separate and manage environment-sensitive configuration information, and implement a dynamic configuration file update mechanism.

[0010] S3: Selects a target controller type from the Kubernetes controller set based on stateless service characteristics, data persistence requirements, and node-level deployment requirements. A topology-aware scheduler allocates containerized deployment instances to physical nodes that meet node affinity constraints, optimizing resource locality within non-uniform memory access domains. A dynamic storage provisioning mechanism is established to respond to volume declaration requests and bind persistent storage volumes that match the quality of service level on demand. Network policy-based traffic control rules are applied to restrict network communication between container groups of non-core business modules, achieving container-level traffic isolation.

[0011] S4: Establish a workload elastic scaling model based on multi-dimensional indicators to predict resource requirements; based on the output of the workload elastic scaling model, dynamically adjust the resource quota and number of replicas of the containerized deployment instance.

[0012] Specifically, the evaluation dimensions of the business criticality matrix include time tolerance, resource fluctuation coefficient, and state separation feasibility.

[0013] Specifically, the non-core business module in S1 creates a database read-only copy query and redirects the file storage path of the non-core business module to the object storage service to isolate the input and output load of the core system.

[0014] Specifically, the time series decomposition model in S1 is an STL decomposition model, which separates the time series characteristics of the periodic component, trend component and residual component of the historical resource load time series data; extracts the daily resource fluctuation pattern based on the periodic component, and establishes a dynamic calculation model of the benchmark resource load value in combination with the trend component; identifies abnormal load events through residual analysis, and eliminates abnormal data points when generating the K8s scheduling parameter dictionary.

[0015] Specifically, the environment-sensitive configuration information in S2 includes a database connection string and an API key, which are declaratively defined by configuring mapping resources and key resources, and provided to the containerized deployment instance by volume mounting or environment variable injection.

[0016] Specifically, the configuration file dynamic update mechanism in S2 triggers a rolling restart of related containerized deployment instances to apply new configurations by monitoring change events of configuration mapping resources.

[0017] Specifically, the execution process of the topology-aware scheduler in S3 includes:

[0018] The topology information collector deployed on the K8s cluster nodes collects the non-uniform memory access domain distribution information, CPU core binding policy, and memory area configuration of the physical nodes in real time, generates a custom resource object of the node resource topology, and reports it to the K8s API server.

[0019] The scheduling engine preferentially selects physical nodes that meet the optimal memory access locality condition for container group scheduling based on the non-uniform memory access domain topology data in the custom resource object and the resource request declaration of the containerized deployment instance;

[0020] The dynamic core binding control module parses the historical core binding records in the K8s proxy component kubelet runtime status file; generates a node-level CPU core binding policy file based on the topology scheduling results recorded in the container group annotation;

[0021] The CPU core binding policy is injected into the target container execution environment through the container runtime interface to complete the binding of the container process to the specified non-uniform memory access domain.

[0022] Specifically, the dynamic storage provisioning mechanism in S3 includes:

[0023] Predefined storage class resource templates, mapping the associated quality of service levels to the underlying storage driver types;

[0024] When responding to a persistent volume claim request, the corresponding storage class resource template is matched based on the quality of service level tag in the claim;

[0025] Call the storage provider to allocate local SSD storage pools for volumes with high IOPS requirements; bind distributed file system storage backends to volumes with high throughput requirements; enable automatic compression and tiered storage policies for cold data volumes;

[0026] Perform online capacity expansion based on volume usage monitoring data: When the allocated storage space utilization continuously exceeds the first threshold, the volume capacity expansion operation is automatically triggered; when the data growth rate exceeds the second threshold, cross-volume data migration is initiated.

[0027] Specifically, the traffic control rules of the network policy in S3 include:

[0028] Define micro-segmentation isolation domains based on business criticality tags and assign independent network segmentation identifiers to each non-core business module;

[0029] Create a network policy resource object and specify enforcement rules: deny all east-west traffic between container groups by default; allow only container groups within the same micro-segmentation isolation domain to communicate through specified ports; open north-south ingress traffic from the core system API gateway to non-core modules;

[0030] The policy execution engine parses network policy resource objects and generates iptables rule chains. It updates rule chain mappings in real time based on container group labels. It rejects cross-domain communication requests that are not explicitly allowed and records security events.

[0031] Specifically, the workload elastic scaling model in S4 includes:

[0032] Obtain container group-level CPU and memory usage time series, application layer QPS and transaction processing latency, message queue backlog depth, and container readiness status change frequency;

[0033] Reuse the periodic variation patterns extracted by S1 and combine them with the sliding window moving average algorithm to generate a set of resource demand prediction values ​​for the future time window;

[0034] When the predicted resource demand exceeds the first margin threshold of the current resource quota, the number of container group replicas is expanded in advance in combination with the K8s scheduling parameter dictionary;

[0035] When the real-time monitoring indicator exceeds the second margin threshold, the resource quota is immediately adjusted based on the preset scaling policy matrix;

[0036] When resource utilization remains below the recycling threshold for a cooling period, the number of replicas is compressed to a safe lower limit and unused resource quotas are released.

[0037] This paper proposes a business-aware migration framework based on the particularity of cloud-native ERP systems. It solves the blind spots of migration priority decision-making through a business criticality matrix, eliminates the competition between core and non-core business resources through message queue decoupling, and predicts the load cycle based on a prediction-driven dynamic scheduling timing decomposition model to avoid reactive scheduling lags. The integrated topology-aware scheduler reduces latency within the NUMA domain.

[0038] This solution fills a technological gap in the cloud-native transformation of enterprise applications. Traditional containerization solutions (such as the default Kubernetes scheduler) are designed for general-purpose workloads and cannot meet the specific requirements of ERP systems for transaction consistency, hardware topology sensitivity, and business-level isolation. This invention achieves collaborative innovation by combining dynamic resource scheduling with business decoupling. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] To facilitate understanding by those skilled in the art, the present invention is further described below with reference to the accompanying drawings.

[0040] Figure 1This is a schematic diagram of the system structure of an ERP non-core business migration method based on K8s dynamic resource scheduling for the present invention;

[0041] Figure 2 This is a timing diagram of redirecting the file storage path to object storage in the present invention;

[0042] Figure 3 It is a schematic diagram of the process of STL decomposition in the present invention;

[0043] Figure 4 This is a schematic diagram of the scheduler extension architecture integrated with the K8s core components of the present invention;

[0044] Figure 5 A schematic diagram of a storage provider decision logic in the present invention;

[0045] Figure 6 Schematic diagram of the online capacity expansion process in the present invention. DETAILED DESCRIPTION

[0046] In order to further illustrate the technical means and effects adopted by the present invention to achieve the predetermined purpose of the invention, the specific implementation methods, structures, features and effects of the present invention are described in detail below in conjunction with the accompanying drawings and preferred embodiments.

[0047] See also Figure 1-6 A method for migrating non-core ERP services based on K8s dynamic resource scheduling, including:

[0048] S1: Based on a pre-set business criticality matrix, identify non-core business modules in the ERP system and generate a migration priority list; transform the internal call interfaces of the non-core business modules to the original ERP system into standard API gateway routing; decouple the highly dependent inter-service communication between the non-core business modules and the core system into asynchronous communication based on message queues;

[0049] Collecting historical resource load time series data corresponding to the non-core business module; applying a time series decomposition model to analyze the historical resource load time series data, extracting its periodic variation pattern, and setting a benchmark resource load value accordingly; generating a K8s scheduling parameter dictionary based on the periodic variation pattern and the benchmark resource load value;

[0050] S2: Separate the compilation environment and runtime environment of the non-core business modules through a multi-stage image building strategy, and build a lightweight container image. Secure the container image and configure health check probes, separate and manage environment-sensitive configuration information, and implement a dynamic configuration file update mechanism.

[0051] S3: According to one of the stateless service characteristics, data persistence requirements and node-level deployment requirements, select the target controller type from the K8s controller set; through the topology-aware scheduler, assign the containerized deployment instance to the physical node that meets the node affinity constraint, realize the resource locality optimization in the non-uniform memory access domain; establish a dynamic storage supply mechanism, respond to the storage volume declaration request, and bind the persistent storage volume matching the quality of service level on demand; apply network policy-based traffic control rules to limit the inter-container group network communication of non-core business modules, and realize traffic isolation at the container level;

[0052] S4: Establish a workload elasticity scaling model based on multi-dimensional indicators to predict resource demand; based on the output of the workload elasticity scaling model, dynamically adjust the resource quota and the number of replicas of the containerized deployment instance.

[0053] Specifically, the evaluation dimensions of the business criticality matrix include time tolerance, resource fluctuation coefficient, and state separation feasibility.

[0054] In this embodiment, the business criticality matrix is the core tool for ERP non-core business migration, which evaluates the migration priority of business modules through three dimensions of time tolerance, resource fluctuation coefficient and state separation feasibility; time tolerance refers to the maximum delay or interruption time that the business module can tolerate, and exceeding the threshold will cause business loss. Its implementation needs to be quantified in combination with business scenarios and embedded in the migration decision-making process.

[0055] In this embodiment, the monthly financial statement generation module is analyzed, which is executed once at the end of each month, and the generation period is T+3 (it can be completed within 72 hours after the data cutoff). Delayed task execution is allowed (it can be moved back 6 hours if it encounters a system load peak). Set the tolerance threshold: delay upper limit and execution time flexibility, set the monthly financial statement generation module as high time tolerance (non-real-time task), high migration priority, after migration to K8s, trigger asynchronously through the message queue, and avoid the resource scheduling during the peak period of core business; calculate the fluctuation coefficient through the difference between the peak load and the baseline load and the ratio of the baseline load, and determine it as high volatility based on the comparison threshold. For the business scenario of state separation feasibility, this embodiment is based on the user session cache service, and the current session data is stored in the local memory. Node failure causes session loss. The business logic allows session reconstruction (users can recover by logging in again); migrate the session data to the Redis cluster (consistent with state separation). Only the data storage pointer needs to be modified (low transformation cost). Therefore, the conclusion is that the user session cache service has high state separation feasibility. The transformation is a stateless service: session data is synchronized to Redis asynchronously through the message queue. K8s deployment uses the Deployment controller, which supports dynamic scaling of replicas.

[0056] Specifically, the non-core business module in S1 creates a database read-only copy query and redirects the file storage path of the non-core business module to the object storage service to isolate the input and output load of the core system.

[0057] In this embodiment, the sales data analysis service in the ERP system is migrated. The original architecture directly reads and writes the core order database (OLTP cluster), and executes a large number of historical order analysis queries (full table scans) every day, resulting in an increase in the core database CPU peak. The analysis reports exported by users are stored in the local NAS, occupying the core system storage bandwidth; the file storage path is redirected to the object storage such as Figure 2 As shown, the pseudo code of the corresponding file operation interceptor is as follows:

[0058] {

[0059] #File operation interceptor

[0060] def file_redirect(path):

[0061] if path.startswith(" / erp / reports / "):

[0062] # Redirection logic

[0063] s3_key = "reports / " + os.path.basename(path)

[0064] s3_client.upload_file(path, "erp-noncore", s3_key)

[0065] os.unlink(path) # delete local files

[0066] return f"s3: / / erp-noncore / {s3_key}"

[0067] else:

[0068] return path # The core file keeps the original path

[0069] }

[0070] Specifically, the time series decomposition model in S1 is an STL decomposition model, which separates the time series characteristics of the periodic component, trend component and residual component of the historical resource load time series data; extracts the daily resource fluctuation pattern based on the periodic component, and establishes a dynamic calculation model of the benchmark resource load value in combination with the trend component; identifies abnormal load events through residual analysis, and eliminates abnormal data points when generating the K8s scheduling parameter dictionary.

[0071] In this embodiment, the STL model uses local weighted regression to transform the historical resource load time series data y i Decomposed into three components, expressed by the additive model: y i =s i +t i +r i ;s i is the seasonal component (periodic fluctuation); t i is the trend component (long-term change direction); r i is the residual component (random noise and abnormal events);

[0072] The decomposition process is implemented through an inner and outer loop. The inner loop iteratively calculates the seasonal and trend components. The original data is first smoothed using a moving window to initially extract the trend, and then the seasonal component is extracted using periodic subsequence smoothing. The outer loop calculates robustness weights based on the residual size to reduce the impact of outliers on the decomposition results and ensure model stability.

[0073] Periodic component s i Directly reflects daily fluctuation patterns. Its technical implementation relies on parameter configuration and component analysis. Setting the STL period parameter to 7 (in days) will allow the model to automatically identify recurring patterns in weeks. An example implementation using the Python statsmodels library is:

[0074] {

[0075] from statsmodels.tsa.seasonal import STL

[0076] decomposition = STL(load_data, period=7).fit()# load_data is the historical load timing data

[0077] seasonal_component = decomposition.seasonal # Extract daily periodic component

[0078] }

[0079] Calculate the average of the periodic component during the same period of each day to generate a "daily resource fluctuation baseline."

[0080] In this embodiment, the benchmark value needs to integrate the prediction results of the trend component and the periodic component to achieve dynamic adjustment:

[0081] The trend component fits the long-term change direction (such as monthly resource growth trend) through local weighted regression. Its mathematical expression is:

[0082] ,in is the trend estimate after smoothing;

[0083] The dynamic benchmark value is set to the sum of the smoothed trend estimate and the mean of the cyclical component of the current date in the same historical period.

[0084] The residual component is used to detect sudden abnormal events (such as traffic surges or system failures). The judgment threshold is set by the standard deviation of the residual series, the abnormal point index is marked, and abnormal data points are excluded when generating the K8s scheduling parameter dictionary.

[0085] Among them, the complete workflow of STL decomposition is as follows Figure 3 shown.

[0086] Specifically, the environment-sensitive configuration information in S2 includes a database connection string and an API key, which are declaratively defined by configuring mapping resources and key resources, and provided to the containerized deployment instance by volume mounting or environment variable injection.

[0087] Specifically, the configuration file dynamic update mechanism in S2 triggers a rolling restart of related containerized deployment instances to apply new configurations by monitoring change events of configuration mapping resources.

[0088] Specifically, the execution process of the topology-aware scheduler in S3 includes:

[0089] The topology information collector deployed on the K8s cluster nodes collects the non-uniform memory access domain distribution information, CPU core binding policy, and memory area configuration of the physical nodes in real time, generates a custom resource object of the node resource topology, and reports it to the K8s API server.

[0090] The scheduling engine preferentially selects physical nodes that meet the optimal memory access locality condition for container group scheduling based on the non-uniform memory access domain topology data in the custom resource object and the resource request declaration of the containerized deployment instance;

[0091] The dynamic core binding control module parses the historical core binding records in the K8s proxy component kubelet runtime status file; generates a node-level CPU core binding policy file based on the topology scheduling results recorded in the container group annotation;

[0092] The CPU core binding policy is injected into the target container execution environment through the container runtime interface to complete the binding of the container process to the specified non-uniform memory access domain.

[0093] In this embodiment, the CPU binding policy file ( / etc / kubelet / cpumanager-policy.json) generated by dynamic core binding is executed. When the target NUMA node resources are insufficient, the scheduler decision process performs cross-NUMA allocation. The scheduler extension architecture integrated with the K8s core components is as follows Figure 4 As shown in the figure, the kublet node agent is responsible for communicating with the Kubernetes master node and managing the Pods and containers on the node; the kublet node agent interacts with the node topology coordinator, which is responsible for collecting and managing the topology information of the node; the node topology coordinator interacts with the container runtime, which is responsible for running and managing containers;

[0094] Figure 4 The topology-aware scheduler in Kubernetes is part of the Kubernetes scheduler and is responsible for scheduling Pods based on the node's topology information. The topology-aware scheduler obtains and processes the node's topology information through the topology-aware plug-in. The topology-aware plug-in interacts with the topology cache, which is used to store and manage the node's topology information for fast access. The topology cache interacts with the Kubernetes API service, which is the central interface of Kubernetes for managing and accessing various resources in the cluster. The custom resource of the node resource topology is used to define and manage the node's topology information. Figure 4 The figure shows how Kubernetes manages node topology information through the node agent, topology orchestrator, and container runtime, and implements topology-based scheduling through the topology-aware scheduler, plug-ins, cache, and API services. This enables Kubernetes to manage and schedule resources more intelligently, especially in large-scale and complex cluster environments.

[0095] Specifically, the dynamic storage provisioning mechanism in S3 includes:

[0096] Predefined storage class resource templates, mapping the associated quality of service levels to the underlying storage driver types;

[0097] When responding to a persistent volume claim request, the corresponding storage class resource template is matched based on the quality of service level tag in the claim;

[0098] Call the storage provider to allocate local SSD storage pools for volumes with high IOPS requirements; bind distributed file system storage backends to volumes with high throughput requirements; enable automatic compression and tiered storage policies for cold data volumes;

[0099] Perform online capacity expansion based on volume usage monitoring data: When the allocated storage space utilization continuously exceeds the first threshold, the volume capacity expansion operation is automatically triggered; when the data growth rate exceeds the second threshold, cross-volume data migration is initiated.

[0100] In this embodiment, the storage provider decision logic is as follows: Figure 5 As shown, a persistent volume claim (PVC) carries a quality of service (QoS) label to the storage provider. The storage provider parses the QoS label in the PVC and determines the priority of the storage demand based on the label content.

[0101] High priority: If the QoS tag indicates a high-priority requirement (such as high IOPS or high throughput), the local SSD driver is used. A high-performance local SSD is selected as the storage medium, and the corresponding storage resources are allocated from the local SSD storage pool to the PVC.

[0102] Medium priority: If the QoS tag indicates a medium priority requirement (such as general performance requirements), the distributed file system driver is invoked. The distributed file system is selected as the storage medium, and the PVC is bound to the network file system cluster to utilize the cluster's distributed storage capabilities.

[0103] Low priority: If the QoS tag indicates a low-priority request (such as cold data storage), the object storage driver is invoked. Lower-cost object storage is selected as the storage medium. Data is stored in cold archive storage, which is suitable for infrequently accessed data.

[0104] The storage provisioner automatically selects appropriate storage drivers and resources based on the QoS tags in the PVC to meet storage needs of varying priorities. High-priority requests use high-performance local SSDs, medium-priority requests use distributed file systems, and low-priority requests use lower-cost object storage. This decision-making logic automatically selects the most appropriate storage resources for different storage needs, thereby improving storage system performance and efficiency.

[0105] The online expansion process is as follows Figure 6As shown in the figure, this process implements online storage volume expansion through a closed-loop mechanism of monitoring, triggering, and execution. The monitoring system periodically collects storage volume utilization data. When the storage volume utilization exceeds the preset threshold, the monitoring system generates an expansion event and issues a critical storage volume space alarm. After receiving the expansion event from the monitoring system, the storage controller checks whether there is expansion space on the node. If there is expansion space, the storage controller returns the expansion capacity and executes the file system expansion operation. After the expansion is complete, the storage controller returns a successful expansion status.

[0106] If the local volume is expandable, the storage controller directly performs the file system expansion and returns a success status. If the local volume is not expandable and data migration is required, the storage controller creates a new target volume and initiates an incremental data synchronization task to synchronize data from the old volume to the new one. During the data synchronization process, the monitoring system continuously monitors the synchronization progress. After the data synchronization is complete, the storage controller switches the storage mount point and mounts the pod on the new volume.

[0107] Upon receiving the capacity expansion event, the capacity expansion controller calls the storage provisioner API to request volume capacity expansion and simultaneously updates the capacity declaration of the PVC. The storage backend performs the online capacity expansion and returns a success status to the Kubernetes API server. The Kubelet notifies the pod to remount the expanded volume to ensure that the pod can use the new storage capacity.

[0108] Through the above steps, the system can automatically detect the usage of storage space and automatically expand the capacity online when needed, thus avoiding service interruptions caused by insufficient storage space.

[0109] Specifically, the traffic control rules of the network policy in S3 include:

[0110] Define micro-segmentation isolation domains based on business criticality tags and assign independent network segmentation identifiers to each non-core business module;

[0111] Create a network policy resource object and specify enforcement rules: deny all east-west traffic between container groups by default; allow only container groups within the same micro-segmentation isolation domain to communicate through specified ports; open north-south ingress traffic from the core system API gateway to non-core modules;

[0112] The policy execution engine parses network policy resource objects and generates iptables rule chains. It updates rule chain mappings in real time based on container group labels. It rejects cross-domain communication requests that are not explicitly allowed and records security events.

[0113] Specifically, the workload elastic scaling model in S4 includes:

[0114] Obtain the time series of CPU, memory usage rate, application layer QPS and transaction processing delay, message queue backlog depth and container readiness state change frequency at the container group granularity;

[0115] Reuse the periodic variation law extracted in S1, combined with the moving average algorithm of the sliding window, to generate a set of resource demand prediction values for the future time window;

[0116] When the predicted resource demand exceeds the first margin threshold of the current resource quota, combine the K8s scheduling parameter dictionary to expand the number of container group replicas in advance;

[0117] When the real-time monitoring indicators exceed the second margin threshold, immediately adjust the resource quota based on the preset scaling strategy matrix;

[0118] When the resource utilization rate continues to be below the recovery threshold for a cooling period, compress the number of replicas to the safe lower limit and release the unused resource quota.

[0119] Among them, the generation process of the resource demand prediction value set is divided into four stages: multi-source indicator normalization, periodic law reuse, sliding window prediction and threshold mapping, as follows:

[0120] Multi-source indicator normalization: Normalize the collected container group granularity indicators to a unified dimension according to the following rules: CPU and memory usage rate directly take the percentage value; Application layer QPS is normalized based on historical peak value; Transaction processing delay is (1-current delay / server delay upper limit); Message queue backlog depth is (backlog message number / maximum capacity); The frequency of container readiness state change is the number of state changes per unit time, which is normalized based on the historical maximum change frequency;

[0121] Statistical five-dimensional vector X(t) after data normalization; Reuse the daily periodic component s(t) obtained by STL decomposition in S1, and modify the five-dimensional vector to X1(t)=X(t)*(1+α*s(t)); α is the periodic weight coefficient;

[0122] Take the moving weighted average of the modified X1(t) for the past N time windows, and the weight decays with time; Generate a prediction vector sequence for the future M time windows:

[0123] P={X1(t+1),X1(t+2),......,X1(t+M)};

[0124] P is the set of resource demand prediction values.

[0125] The above description is merely a preferred embodiment of the present invention and does not constitute any form of limitation to the present invention. Although the present invention has been disclosed as a preferred embodiment as above, it is not intended to limit the present invention. Any person skilled in the art can make some changes or modifications to equivalent embodiments using the technical contents disclosed above without departing from the scope of the technical solution of the present invention. However, any simple modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention are still within the scope of the technical solution of the present invention.

Claims

1. A method for migrating non-core ERP services based on K8s dynamic resource scheduling, characterized in that: include: S1: Based on the pre-set business criticality matrix, identify non-core business modules in the ERP system and generate a migration priority list; Transform the internal call interface of the non-core business module to the original ERP system into a standard API gateway route; Decoupling the strongly dependent inter-service communication between the non-core business modules and the core system into asynchronous communication based on message queues; Collecting historical resource load time series data corresponding to the non-core business module; applying a time series decomposition model to analyze the historical resource load time series data, extracting its periodic variation pattern, and setting a benchmark resource load value accordingly; generating a K8s scheduling parameter dictionary based on the periodic variation pattern and the benchmark resource load value; S2: Separate the compilation environment and runtime environment of the non-core business modules through a multi-stage image building strategy, and build a lightweight container image. Secure the container image and configure health check probes, separate and manage environment-sensitive configuration information, and implement a dynamic configuration file update mechanism. S3: Select the target controller type from the Kubernetes controller set based on one of the following: stateless service characteristics, data persistence requirements, and node-level deployment requirements. A topology-aware scheduler allocates containerized deployment instances to physical nodes that meet node affinity constraints, optimizing resource locality within non-uniform memory access domains. A dynamic storage provisioning mechanism is established to respond to storage volume declaration requests and bind persistent storage volumes that match the quality of service level on demand. Network policy-based traffic control rules are applied to restrict network communication between container groups of non-core business modules, achieving container-level traffic isolation. S4: Establish a workload elastic scaling model based on multi-dimensional indicators to predict resource requirements; based on the output of the workload elastic scaling model, dynamically adjust the resource quota and number of replicas of the containerized deployment instance.

2. The method according to claim 1, characterized in that The evaluation dimensions of the business criticality matrix include time tolerance, resource fluctuation coefficient, and state separation feasibility.

3. The method according to claim 1, characterized in that The non-core business module in S1 creates a database read-only copy query and redirects the file storage path of the non-core business module to the object storage service to isolate the input and output load of the core system.

4. The method according to claim 1, wherein The time series decomposition model in S1 is an STL decomposition model, which separates the time series characteristics of the periodic component, trend component and residual component of the historical resource load time series data; Based on the periodic component, the daily resource fluctuation pattern is extracted, and combined with the trend component, a dynamic calculation model of the benchmark resource load value is established; abnormal load events are identified through residual analysis, and abnormal data points are eliminated when generating the K8s scheduling parameter dictionary.

5. The method according to claim 1, wherein The environment-sensitive configuration information in S2 includes a database connection string and an API key, which is declaratively defined by configuring mapping resources and key resources, and provided to the containerized deployment instance by volume mounting or environment variable injection.

6. The method according to claim 1, characterized in that The configuration file dynamic update mechanism in S2 triggers a rolling restart of the relevant containerized deployment instance to apply the new configuration by monitoring the change events of the configuration mapping resources.

7. The method according to claim 1, characterized in that The execution process of the topology-aware scheduler in S3 includes: The topology information collector deployed on the K8s cluster nodes collects the non-uniform memory access domain distribution information, CPU core binding policy, and memory area configuration of the physical nodes in real time, generates a custom resource object of the node resource topology, and reports it to the K8s API server. The scheduling engine preferentially selects physical nodes that meet the optimal memory access locality condition for container group scheduling based on the non-uniform memory access domain topology data in the custom resource object and the resource request declaration of the containerized deployment instance; The dynamic core binding control module parses the historical core binding records in the K8s proxy component kubelet runtime status file; generates a node-level CPU core binding policy file based on the topology scheduling results recorded in the container group annotation; The CPU core binding policy is injected into the target container execution environment through the container runtime interface to complete the binding of the container process to the specified non-uniform memory access domain.

8. The method according to claim 1, characterized in that The dynamic storage provisioning mechanism in S3 includes: Predefined storage class resource templates, mapping the associated quality of service levels to the underlying storage driver types; When responding to a persistent volume claim request, the corresponding storage class resource template is matched based on the quality of service level tag in the claim; Call the storage provider to allocate local SSD storage pools for volumes with high IOPS requirements; bind distributed file system storage backends to volumes with high throughput requirements; enable automatic compression and tiered storage policies for cold data volumes; Perform online capacity expansion based on volume usage monitoring data: When the allocated storage space utilization continuously exceeds the first threshold, the volume capacity expansion operation is automatically triggered; when the data growth rate exceeds the second threshold, cross-volume data migration is initiated.

9. The method according to claim 1, characterized in that The traffic control rules of the network policy in S3 include: Define micro-segmentation isolation domains based on business criticality tags and assign independent network segmentation identifiers to each non-core business module; Create a network policy resource object and specify enforcement rules: deny all east-west traffic between container groups by default; allow only container groups within the same micro-segmentation isolation domain to communicate through specified ports; open north-south ingress traffic from the core system API gateway to non-core modules; The policy execution engine parses network policy resource objects and generates iptables rule chains. It updates rule chain mappings in real time based on container group labels. It rejects cross-domain communication requests that are not explicitly allowed and records security events.

10. The method according to claim 1, characterized in that The workload elastic scaling model in S4 includes: Obtain container group-level CPU and memory usage time series, application layer QPS and transaction processing latency, message queue backlog depth, and container readiness status change frequency; Reuse the periodic variation patterns extracted by S1 and combine them with the sliding window moving average algorithm to generate a set of resource demand prediction values ​​for the future time window; When the predicted resource demand exceeds the first margin threshold of the current resource quota, the number of container group replicas is expanded in advance in combination with the K8s scheduling parameter dictionary; When the real-time monitoring indicator exceeds the second margin threshold, the resource quota is immediately adjusted based on the preset scaling policy matrix; When resource utilization remains below the recycling threshold for a cooling period, the number of replicas is compressed to a safe lower limit and unused resource quotas are released.

Images