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

Abstract

The invention relates to an ERP non-core service 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 a non-core module based on business criticality, and generating a migration list; an internal interface is transformed into a standard API gateway route, and strong dependency communication is asynchronously decoupled through a message queue. Historical resource load data is collected, a periodic rule is extracted by using a time sequence decomposition model, a reference value is set, and a K8s scheduling parameter is generated. Adopting multi-stage construction to separate compilation and operation environments, and generating a lightweight mirror image; and implementing security reinforcement, and dynamically updating the health examination probe and configuration. Selecting a controller according to stateless and persistent requirements; the locality of NUMA domain resources is optimized through topology awareness scheduling; dynamic storage binds a persistent volume according to QoS; the network policy implements container-level traffic isolation. And dynamically adjusting the resource quota and the number of copies. The efficient and safe migration of the 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. 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.

[0003] 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.

[0004] 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

[0005] 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: 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; 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: 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. 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.

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

[0007] 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.

[0008] 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.

[0009] 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.

[0010] 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.

[0011] Specifically, 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.

[0012] Specifically, 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.

[0013] Specifically, 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.

[0014] Specifically, 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-down period, the number of replicas is compressed to a safe lower limit and unused resource quotas are released.

[0015] 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. 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

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

[0017] Figure 1 This 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; Figure 2 This is a timing diagram of redirecting the file storage path to object storage in the present invention; Figure 3 It is a schematic diagram of the process of STL decomposition in the present invention; Figure 4 This is a schematic diagram of the scheduler extension architecture integrated with the K8s core components of the present invention; Figure 5 A schematic diagram of a storage provider decision logic in the present invention; Figure 6 Schematic diagram of the online capacity expansion process in the present invention. DETAILED DESCRIPTION

[0018] 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.

[0019] See also Figure 1-6 A method for migrating non-core ERP services based on K8s dynamic resource scheduling, including: 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; 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: 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. 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.

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

[0021] In this embodiment, the business criticality matrix is ​​a core tool for migrating non-core ERP services. It assesses the migration priority of business modules based on three dimensions: time tolerance, resource volatility, and state separation feasibility. Time tolerance refers to the maximum delay or interruption a business module can tolerate; exceeding this threshold results in business losses. Its implementation must be quantified based on business scenarios and embedded into the migration decision-making process.

[0022] In this example, the monthly financial report generation module is analyzed. This module executes once a month at the end of the month, with a T+3 generation cycle (complete within 72 hours of the data cutoff). Task execution is allowed to be delayed (up to 6 hours in case of peak system load). Tolerance thresholds are set: a maximum delay limit and execution duration flexibility. The monthly financial report generation module is assigned a high timeliness tolerance (non-real-time task) and a high migration priority. After migration to Kubernetes, it is asynchronously triggered via message queues, and resource scheduling avoids core business peak hours. The volatility coefficient is calculated by comparing the difference between peak load and baseline load to the ratio of the baseline load, and high volatility is determined based on the comparison threshold. Regarding the business scenario where state separation is feasible, this example is based on a user session cache service. Current session data is stored in local memory, and node failures can cause session loss. The business logic allows session reestablishment (users can restore by logging in again) and migrates session data to a Redis cluster (compliant with state separation). Only the data storage location needs to be modified (low-cost transformation). Therefore, the user session cache service is concluded to have high state separation feasibility. It is transformed into a stateless service: session data is asynchronously synchronized to Redis via message queues. K8s deployment uses the Deployment controller, which supports dynamic scaling of replicas.

[0023] 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.

[0024] 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: { #File operation interceptor def file_redirect(path): if path.startswith(" / erp / reports / "): # Redirection logic s3_key = "reports / " + os.path.basename(path) s3_client.upload_file(path, "erp-noncore", s3_key) os.unlink(path) # delete local files return f"s3: / / erp-noncore / {s3_key}" else: return path # The core file keeps the original path } 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.

[0025] 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); 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.

[0026] 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: { from statsmodels.tsa.seasonal import STL decomposition = STL(load_data, period=7).fit()# load_data is the historical load timing data seasonal_component = decomposition.seasonal # Extract daily periodic component } Calculate the average of the periodic component during the same period of each day to generate a "daily resource fluctuation baseline."

[0027] In this embodiment, the benchmark value needs to integrate the prediction results of the trend component and the periodic component to achieve dynamic adjustment: The trend component fits the long-term change direction (such as monthly resource growth trend) through local weighted regression. Its mathematical expression is: ,in is the trend estimate after smoothing; 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.

[0028] 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.

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

[0030] 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.

[0031] 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.

[0032] Specifically, 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.

[0033] 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; 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.

[0034] Specifically, 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.

[0035] 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. 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] Specifically, 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.

[0044] Specifically, 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-down period, the number of replicas is compressed to a safe lower limit and unused resource quotas are released.

[0045] The generation process of the resource demand forecast value set is divided into four stages: multi-source indicator normalization, periodic law reuse, sliding window prediction, and threshold mapping. The details are as follows: Normalization of multi-source metrics: Collected container group granular metrics are normalized to a unified dimension according to the following rules. CPU and memory usage are directly expressed as percentages. Application layer QPS is normalized based on historical peak values. Transaction processing latency is calculated as (1-current latency / server latency limit). Message queue backlog depth is calculated as (number of backlogged messages / maximum capacity). Container readiness status change frequency is calculated by counting the number of status changes per unit time and normalized based on the historical maximum change frequency. The above statistics are obtained after data normalization to obtain a five-dimensional vector X(t); reuse the daily periodic component s(t) obtained by STL decomposition in S1, and correct the five-dimensional vector to X1(t)=X(t)*(1+α*s(t)); α is the periodic weight coefficient; Take the moving weighted average of the past N time windows for the corrected X1(t), with the weight decaying over time; generate a prediction vector sequence for the next M time windows: P={X1(t+1),X1(t+2),...,X1(t+M)}; P is the set of resource demand forecast values.

[0046] 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, characterized in that 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