Simulation network kubernetes controller for dynamic network topology partitioning
By designing a simulated network Kubernetes controller for dynamic network topology partitioning, and optimizing resource scheduling using the DQN algorithm and Pod migration module, the performance bottleneck of existing simulation platforms in large-scale network scenarios is solved, achieving load balancing and efficient simulation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI JIAOTONG UNIV
- Filing Date
- 2024-12-19
- Publication Date
- 2026-06-23
AI Technical Summary
Existing simulation platforms suffer from problems such as low parallelism, low resource utilization, long simulation time, inability to complete real-time calculations in a timely manner, high network communication overhead, and difficulty in resource scheduling and management in large-scale heterogeneous network scenarios. They are unable to achieve efficient partitioning of dynamic network topologies and efficient deployment of Pods.
Design a simulated network Kubernetes controller for dynamic network topology partitioning. It adopts a network topology partitioning module, a Pod scheduling module, and a Pod migration module based on DQN and rolling upgrade. It optimizes resource scheduling through agent decision-making and deep Q network algorithm to achieve load balancing and Pod migration.
It significantly improves the performance of network simulation verification, reduces simulation time, improves load balancing and resource utilization, and ensures the real-time performance and accuracy of the simulation process.
Smart Images
Figure CN122268767A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to a technology in the field of network simulation, specifically a Kubernetes controller for simulating dynamic network topology partitioning. Background Technology
[0002] Currently, simulation platforms still have certain shortcomings in terms of performance. Using simulator-type platforms like NS3, when dealing with large-scale heterogeneous network scenarios, the discrete event simulation itself cannot load actual business logic; furthermore, in large-scale scenarios, simulators suffer from low parallelism and low resource utilization. Larger simulation scales lead to longer simulation times, resulting in low fidelity due to the inability to complete real-time calculations promptly. Emulator-type platforms like Mininet, running on limited hardware resources, cannot accurately simulate large-scale or high-load network environments. For single-machine simulations, limitations in hardware computing power and memory restrict existing platforms to simulating only a small number of nodes. Distributed simulations suffer from network communication overhead, resource scheduling, and management issues, resulting in poor performance and an inability to partition the network topology, deploy deployable computing units (Pods), or adjust Pod distribution in real-time based on verification algorithms. Summary of the Invention
[0003] To address the aforementioned shortcomings of existing technologies, this invention proposes a simulated network Kubernetes controller for dynamic network topology partitioning. Based on the KubeBuilder framework, a K8s controller is implemented for practical scheduling. This controller is used in cloud-native simulated network platforms to verify network resource scheduling algorithms in large-scale dynamic topology scenarios, achieving overall system load balancing.
[0004] This invention is achieved through the following technical solution:
[0005] This invention relates to a simulated network Kubernetes controller for dynamic network topology partitioning, comprising: a DQN-based network topology partitioning module, a Pod scheduling module, and a rolling upgrade-based Pod migration module, wherein: the DQN-based network topology partitioning module performs graph partitioning processing based on the network topology information to be simulated submitted by the user, obtaining the distribution results of virtual network components in the network topology on physical machines; the Pod scheduling module performs scheduling calculation processing based on the virtual network component information that needs to be modified during algorithm verification, obtaining the results of virtual network components that need to be migrated; the Pod migration module performs Pod migration processing based on the calculated list of virtual network components, obtaining the modified network topology distribution results.
[0006] This invention relates to a control method based on the above-mentioned controller, comprising:
[0007] Step 1: Construct a resource scheduling problem based on the network topology, physical machine states, and algorithm verification request information provided by the user. Specifically, represent the resource scheduling problem using a Markov decision process, defined as follows: a state set S describing the global states of physical machines and the network; an action set A representing possible Pod migration strategies; and a reward function R used to evaluate the effect of each scheduling action. At each time step t, the agent selects an action a_t according to its policy π(a_t|s_t) and executes the action in the environment. The environment transitions to the next state s_t+1 according to the state transition function T. The agent receives an immediate reward r_t. The goal of the algorithm is to maximize the cumulative discounted reward over the entire scheduling period T.
[0008] Step 2: Construct a Deep Q-Network (DQN) algorithm. This involves using a Q-value network to calculate the selected Q-value and iteratively updating the Q-value, and using a target network to calculate the Q-value for the next state. This process enables the training of the agent, specifically including:
[0009] 2.1 Initialization phase, specifically including:
[0010] i) Setting the State: At each time step, the system state can be represented as a vector s_t = {s_t_host, s_t_topology, s_t_pod, s_t_actionSet}, where: s_t_host represents the resource usage of the physical machine, including the current utilization of CPU and memory; s_t_topology represents the structural information of the network topology, including the set of nodes V and the set of connections E; s_t_pod represents the physical machine information currently allocated to each Pod; and s_t_actionSet represents the set of Pods involved in the current network resource scheduling algorithm operation.
[0011] ii) Set action: In each time step, the i-th Pod is moved to the p-th physical machine (excluding the physical machine where it is located) using the e-greedy strategy, and the entire network resource allocation is globally re-evaluated and adjusted at fixed time intervals to overcome the limitations of local optimization.
[0012] iii) Set rewards: Set dynamically adjustable weight parameter R i =-w1ΔT sched -w2ΔN cross -w3ΔT migrate +w4ΔL balance Where: w1, w2, w3, w4 are the weights of different reward items, and their values can be adjusted according to different system needs; by default, they are all 1; ΔTsched This represents the time difference between modifying the Pod for verifying the algorithm under different topologies, calculated as the verification time under the new topology minus the verification time under the original topology; ΔN cross This represents the difference in the number of Pod connections across physical machines, calculated as the number of connections across physical machines in the new topology minus the number in the original topology; ΔT migrate This represents the migration time cost, calculated as the number of Pods migrated; ΔL balance This indicates the change in the load balancing level of physical machines. The load balancing level of physical machines is calculated based on the variance of CPU and memory usage on each physical machine in the current topology.
[0013] 2.2 Calculate the Q value based on the current distribution of Pods on physical machines, the load of the physical machines, and the Pods that need to be modified to verify the algorithm. Specifically: Q = -(α1*T) sched +α2*N cross +α3*L balance ), where α1, α2, and α3 are the weights of different calculation items, and their values can be adjusted according to different system requirements. By default, they are all 1; T sched This indicates the time required to modify the Pod for algorithm verification under the current topology; N cross Indicates the number of Pod connections across physical machines; L balance It represents the load balancing level of physical machines, and is calculated as the variance of CPU and memory usage on each physical machine in the current topology.
[0014] 2.3 Compare the Q value with the threshold. If the Q value exceeds the threshold, the Pod migration result is obtained by iteratively based on the trained model. If the Q value does not exceed the threshold, no Pod migration is required.
[0015] Step 3: Perform Pod migration optimization, specifically including:
[0016] 3.1 Pre-configure and create new Pods and corresponding network topology connections on the target physical machine;
[0017] Preferably, the new Pod and topology have a version number suffix added to their names.
[0018] 3.2 Continuously monitor the running status of newly created Pods, and delete the original Pods and their associated network topology once the new Pods have reached a stable running state.
[0019] The stable operating state refers to the Pod maintaining a normal operating state throughout the 30-second monitoring period.
[0020] Step 4, controller implementation, specifically including:
[0021] 4.1 Define custom resource definitions (CRDs) for network topology, including: RouterSpec parameters for virtual routers, SwitchSpec parameters for virtual switches, and LinkSpec parameters for network connections. Among them, the parameters for virtual routers include: name, image used by Pods, route configuration, and routing rules; the parameters for virtual switches include: name and image used by Pods; and the parameters for network connections include: network interface, IP address, bandwidth, latency, and MAC address.
[0022] 4.2 Implement the initial graph partitioning logic in the Reconcile function of the controller. Specifically, the Reconcile function first parses the custom resource (CR) for the network topology. If the CR is empty, the initial graph partitioning logic is performed. Based on the DQN-based Pod partitioning algorithm described above, an allocation list for each Pod on the physical machines is obtained. According to this list, the kubelet on each physical machine actually starts the Pod and calls the CNI network plugin to establish a network connection based on the network connection information in the CR. Simultaneously, the CR structure cache is updated in Reconcile.
[0023] 4.3 Implementing the dynamic topology logic in the controller's Reconcile function includes: The Reconcile function first parses the custom network topology resource (CR). If the CR status is Running, then the dynamic topology logic is executed. The controller parses the network topology in the CR, including the node list (new Pod List) and network connections (new Link List). It compares this with the original CR structure cache (the original node list (old Pod List) and network connections (old Link List)) to obtain the network topology change ΔNetwork = ΔPod + ΔLink. Specifically, the node change is ΔPod = new Pod List - old Pod List, and the network connection change is ΔLink = new Link List - old Link List. ΔPod includes the addition and deletion of nodes, and ΔLink includes the addition and deletion of network connections. Next, the Pod migration algorithm of DQN is called to obtain the list of Pods to be migrated. Finally, the Pods are migrated according to the Pod migration algorithm, and kubelet and CNI network plugins are called to add and delete Pods and network connections. Technical effect
[0024] This invention significantly improves the performance of network resource scheduling algorithms in network simulation verification by using a DQN-based network topology partitioning algorithm, a Pod scheduling algorithm, and a Pod migration based on rolling upgrades, ensuring multi-faceted load balancing of the system during simulation. Attached Figure Description
[0025] Figure 1 This is a schematic diagram of the overall controller system of the present invention;
[0026] Figure 2 This is a diagram illustrating the Pod scheduling process.
[0027] Figure 3 This is a flowchart illustrating the Reconcile function in the controller.
[0028] Figure 4 A network topology diagram constructed for an embodiment;
[0029] Figure 5 The network topology diagram after the controller diagram has been partitioned;
[0030] Figure 6 A time comparison chart showing the modification of the flow table when verifying the algorithm on the simulation platform. Detailed Implementation
[0031] like Figure 1 As shown in the figure, this embodiment relates to a simulated network Kubernetes controller for dynamic network topology partitioning, including: a network topology partitioning module based on DQN, a Pod scheduling module, and a Pod migration module based on rolling upgrades.
[0032] The network topology partitioning module includes: a state data acquisition unit, a graph partitioning calculation unit, and a partitioning result unit. The state data acquisition unit loads and structures information based on the physical machine information in the cluster and the network topology information submitted by the user to obtain the input result for graph partitioning. The graph partitioning calculation unit performs graph partitioning operations based on the input information processed by the state data acquisition unit to obtain the Pod distribution result for each partition. The partitioning result unit performs summary processing based on the above Pod distribution information to obtain the result of the distribution of all Pods on physical machines.
[0033] The Pod scheduling module includes a status data acquisition unit, a Pod migration calculation unit, and a migration result unit. The status data acquisition unit loads and structures information based on the physical machine load information in the cluster, the list of Pods that need to be modified during algorithm verification, and the network topology information in the cluster to obtain the input results for Pod migration calculation. The Pod migration calculation unit performs Pod migration calculation based on the input information processed by the status data acquisition unit to obtain the optimal Pod migration result for each time. The migration result unit summarizes the Pod migration information from multiple migrations to obtain a list of all Pods that need to be migrated.
[0034] The Pod migration module based on rolling upgrades includes: a Pod preloading unit, a Pod detection unit, and an original Pod deletion unit. The Pod preloading unit pre-configures and creates new Pods and corresponding network topologies on the target physical machine based on the Pod migration information. The Pod detection unit monitors whether the Pods on the target physical machine are starting normally based on the Pod migration information and obtains the Pod status results. The original Pod deletion unit deletes the original Pod and its associated network topology based on the startup status information of the new Pod and if the new Pod has reached a stable running state.
[0035] Through specific experiments, Figure 4 The simulation is performed in a dynamic network topology scenario with 30 virtual network nodes, where a new custom network topology resource (CR) is submitted at specific times as required. This CR contains the definitions of all virtual network nodes and the connections between the virtual networks. The tested topology is a sparse graph, with each node directly connected to several other nodes.
[0036] In this embodiment, after receiving a new network topology YAML file, the controller first parses and processes the definition information of the resource to extract the key parameters and configuration details of the network topology. Then, based on the DQN-based topology partitioning algorithm designed above, the controller partitions the parsed network topology and obtains the result. For example... Figure 5 The specific partitioning result is as follows: node_allocation = [2,1,1,1,2,0,2,1,2,0,0,0,1,0,0,0,2,2,2,2,1,0,2,1,0,0,1,1,1,2]. When the network topology YAML file is submitted for the first time, the controller will also start the virtual network component Pod according to the partitioning and call the CNI network plugin to establish the corresponding network connections, ensuring that each node in the virtual network can communicate and collaborate normally according to the topology defined in the YAML file.
[0037] During subsequent network topology updates, this embodiment submits a new YAML file based on business needs or environmental changes. The controller modifies the data based on the expected state in the CR and the actual state in the cluster: First, it calculates the difference between the actual and expected states using a difference function. Then, it changes the virtual network nodes and network connections in the cluster according to the expected state. Simultaneously, during the change process, it calculates whether Pod physical machine migration is necessary. Finally, based on the results, it dynamically adjusts the distribution of virtual network node Pods and calls the CNI network plugin to establish new network connections. The test results are as follows: after modifying some network connections, the migration result is that Pod13 is migrated from physical machine 2 to physical machine 1.
[0038] Secondly, during algorithm verification, the distribution of virtual network nodes that need to be adjusted for each algorithm iteration may vary, potentially leading to Pod migration by the controller to ensure the efficiency of the verification process. For example... Figure 2 As shown, the controller inputs the resource usage of each physical machine, the network topology information submitted by the current user, the physical machine information currently allocated to each Pod, and the set of Pods involved in the current network resource scheduling algorithm operation as state into the trained DQN neural network. The Q-value of each action is calculated, and the action with the highest Q-value is iteratively selected until the expected load balancing threshold is reached. For the actual Pod migration, this set of actions is first pre-configured and a new Pod and corresponding network topology are created on the target physical machine. To avoid naming conflicts and facilitate version management, a version number suffix is added to the new Pod and topology names. After the new Pod is created, the system continuously monitors its status, and only after confirming that the new Pod has reached a stable running state is the original Pod and its associated network topology deleted.
[0039] like Figure 6 As shown, the embodiment verifies a network resource scheduling algorithm based on an SDN controller. Each time, the algorithm randomly modifies the flow tables of some Pods. By comparing the modification time of the first graph partitioning without Pod migration and the Pod migration of the present invention, it can be found that the present invention can reduce the verification time of the algorithm and improve the efficiency of algorithm verification.
[0040] Compared with existing technologies, this invention reduces the time and improves efficiency when using a network simulation platform to verify network resource scheduling algorithms; at the same time, it takes into account the uniform distribution of virtual network nodes on physical machines and reduces network connections across physical machines.
[0041] The above-described specific implementations can be partially adjusted by those skilled in the art in different ways without departing from the principles and purpose of the present invention. The scope of protection of the present invention is defined by the claims and is not limited to the above-described specific implementations. All implementation schemes within the scope of the claims are bound by the present invention.
Claims
1. A Kubernetes controller for simulated networks used in dynamic network topology partitioning, characterized in that, include: The system comprises a DQN-based network topology partitioning module, a Pod scheduling module, and a Pod migration module based on rolling upgrades. Specifically: the DQN-based network topology partitioning module performs graph partitioning based on user-submitted network topology information to obtain the distribution of virtual network components on physical machines; the Pod scheduling module performs scheduling calculations based on the virtual network component information that needs to be modified during algorithm verification to obtain the results of the virtual network components that need to be migrated; and the Pod migration module performs Pod migration based on the calculated list of virtual network components to obtain the modified network topology distribution.
2. The Kubernetes controller for dynamic network topology partitioning according to claim 1, characterized in that, The network topology partitioning module includes: a state data acquisition unit, a graph partitioning calculation unit, and a partitioning result unit. The state data acquisition unit loads and structures information based on the physical machine information in the cluster and the network topology information submitted by the user to obtain the input result for graph partitioning. The graph partitioning calculation unit performs graph partitioning operations based on the input information processed by the state data acquisition unit to obtain the Pod distribution result for each partition. The partitioning result unit performs summary processing based on the above Pod distribution information to obtain the result of the distribution of all Pods on physical machines.
3. The Kubernetes controller for dynamic network topology partitioning according to claim 1, characterized in that, The Pod scheduling module includes a status data acquisition unit, a Pod migration calculation unit, and a migration result unit. The status data acquisition unit loads and structures information based on the physical machine load information in the cluster, the list of Pods that need to be modified during algorithm verification, and the network topology information in the cluster to obtain the input results for Pod migration calculation. The Pod migration calculation unit performs Pod migration calculation based on the input information processed by the status data acquisition unit to obtain the optimal Pod migration result for each time. The migration result unit summarizes the Pod migration information from multiple migrations to obtain a list of all Pods that need to be migrated.
4. The Kubernetes controller for dynamic network topology partitioning according to claim 1, characterized in that, The Pod migration module based on rolling upgrades includes: a Pod preloading unit, a Pod detection unit, and an original Pod deletion unit. The Pod preloading unit pre-configures and creates new Pods and corresponding network topologies on the target physical machine based on the Pod migration information. The Pod detection unit monitors whether the Pods on the target physical machine are starting normally based on the Pod migration information and obtains the Pod status results. The original Pod deletion unit deletes the original Pod and its associated network topology based on the startup status information of the new Pod and if the new Pod has reached a stable running state.
5. A control method based on the controller according to any one of claims 1-4, characterized in that, include: Step 1: Construct a resource scheduling problem based on the network topology, physical machine states, and algorithm verification request information provided by the user. Specifically, the resource scheduling problem is represented in the form of a Markov decision process, defined as follows: a state set S describes the global state of the physical machines and the network; an action set A represents possible Pod migration strategies; and a reward function R is used to evaluate the effect of each scheduling action. At each time step t, the agent selects an action a_t according to its policy π(a_t|s_t) and executes the action in the environment. The environment transitions to the next state s_t+1 according to the state transition function T, and the agent receives an immediate reward r_t. The goal of the algorithm is to maximize the cumulative discount reward over the entire scheduling period T. Step 2: Construct a deep Q-network algorithm, using a Q-value network to calculate the selected Q-value and iteratively update the Q-value, and using a target network to calculate the Q-value of the next state, thereby training the agent. Specifically, this includes: 2.1 Initialization phase; 2.2 Calculate the Q value based on the current distribution of Pods on physical machines, the load of physical machines, and the Pods that need to be modified to verify the algorithm; 2.3 Compare the Q value with the threshold. If the Q value exceeds the threshold, the Pod migration result is obtained by iteratively based on the trained model. If the Q value does not exceed the threshold, no Pod migration is required. Step 3: Perform Pod migration optimization, specifically including: 3.1 Pre-configure and create new Pods and corresponding network topology connections on the target physical machine; 3.2 Continuously monitor the running status of newly created Pods, and delete the original Pods and their associated network topology once the new Pods have reached a stable running state; Step 4, controller implementation, specifically including: 4.1 Define custom resource definitions (CRDs) for network topology; 4.2 Implement the initial graph partitioning logic in the Reconcile function of the controller, specifically including: The Reconcile function first parses the custom resource CR of the network topology. If the CR is empty, the initial graph partitioning logic is performed. According to the Pod partitioning algorithm based on DQN mentioned above, the allocation list of each Pod on the physical machine is obtained. According to this list, the kubelet in each physical machine actually starts the Pod and calls the CNI network plugin to establish a network connection according to the network connection information in the CR. At the same time, the CR structure cache is updated in Reconcile. 4.3 Implement the dynamic topology logic in the Reconcile function of the controller, specifically including: The Reconcile function first parses the custom resource CR for the network topology. If the CR status is Running, then the dynamic topology logic is performed. The controller parses the network topology in the CR, including the node list newPodList and the network connection newLinkList. It compares the original CR structure cache (the original node list oldPodList and the network connection oldLinkList) to obtain the network topology change ΔNetwork = ΔPod + ΔLink. Specifically, the node change is ΔPod = newPodList - oldPodList, and the network connection change is ΔLink = newLinkList - oldLinkList. ΔPod includes the addition and deletion of nodes, and ΔLink includes the addition and deletion of network connections. Then, the Pod migration algorithm of DQN mentioned above is called to obtain the list of Pods that need to be migrated. Finally, the Pod migration is performed according to the Pod migration algorithm mentioned above, and the kubelet and CNI network plugin are called to add and delete Pods and network connections.
6. The control method according to claim 5, characterized in that, The initialization phase specifically includes: i) Setting the State: At each time step, the system state is represented as a vector s_t = {s_t_host, s_t_topology, s_t_pod, s_t_actionSet}, where: s_t_host represents the resource usage of the physical machine, including the current utilization of CPU and memory; s_t_topology represents the structural information of the network topology, including the set of nodes V and the set of connections E; s_t_pod represents the physical machine information currently allocated to each Pod; and s_t_actionSet represents the set of Pods involved in the current network resource scheduling algorithm operation. ii) Set actions: In each time step, the i-th Pod is moved to the p-th physical machine (excluding the physical machine where it is located) using the e-greedy strategy, and the entire network resource allocation is globally re-evaluated and adjusted at fixed time intervals to overcome the limitations of local optimization; iii) Set rewards: Set dynamically adjustable weight parameter R i =-w1ΔT sched -w2ΔN cross -w3ΔT migrate +w4ΔL balance Where: w1, w2, w3, w4 are the weights of different reward items, and their values are adjusted according to different system needs; by default, they are all 1; ΔT sched This represents the time difference between modifying the Pod for verifying the algorithm under different topologies, calculated as the verification time under the new topology minus the verification time under the original topology; ΔN cross This represents the difference in the number of Pod connections across physical machines, calculated as the number of connections across physical machines in the new topology minus the number in the original topology; ΔT migrate This represents the migration time cost, calculated as the number of Pods migrated; ΔL balance This indicates the change in the load balancing level of physical machines. The load balancing level of physical machines is calculated based on the variance of CPU and memory usage on each physical machine in the current topology.
7. The control method according to claim 5, characterized in that, The calculation of the Q value is specifically as follows: Q = -(α1*T) sched +α2*N cross +α3*L balance ), where α1, α2, and α3 are the weights of different calculation items, and their values are adjusted according to different system requirements. By default, they are all 1; T sched This indicates the time required to modify the Pod for algorithm verification under the current topology; N cross Indicates the number of Pod connections across physical machines; L balance It represents the load balancing level of physical machines, and is calculated as the variance of CPU and memory usage on each physical machine in the current topology.
8. The control method according to claim 5, characterized in that, The custom resource definitions include: RouterSpec parameters for virtual routers, SwitchSpec parameters for virtual switches, and LinkSpec parameters for network connections. Specifically, the parameters for virtual routers include: name, image used by Pods, route configuration, and routing rules; the parameters for virtual switches include: name and image used by Pods; and the parameters for network connections include: network interface, IP address, bandwidth, latency, and MAC address.