Distribution method and device of deployment unit and nonvolatile storage medium

Abstract

The invention discloses a deployment unit allocation method and device and a nonvolatile storage medium. The method comprises the steps that a plurality of deployment units deployed on a plurality of service nodes of a target cluster are acquired, and the working modes of the deployment units at least comprise a master-slave mode, a master-slave mode and a load balancing mode; periodically detecting the states of the plurality of service nodes based on the timed task; and when it is detected that the state of the first service node is converted from the non-running state to the running state in any detection period, the deployment unit with the working mode being the load balancing mode on the first service node is returned to the first service node based on a return strategy. According to the method and the device, the technical problems that in the related technology, after a node on a k8s cluster breaks down, a deployment unit in a load balancing mode on the fault node can automatically migrate to other nodes, and after the fault node returns to normal, the deployment unit which is automatically migrated to other nodes cannot return, so that the service reliability is low are solved.

Description

Technical Field

[0001] The present application relates to the field of network security, and in particular to a method and device for allocating deployment units and a non-volatile storage medium. Background Art

[0002] In related technologies, the distribution of deployment units directly affects the operating efficiency of the system. How to scientifically and reasonably allocate deployment units to meet the business needs of different scenarios is an important issue that needs to be considered in distributed systems. The allocation of deployment units is often based on business volume evaluation, and a static deployment strategy is adopted, that is, the deployment units are statically deployed on multiple business nodes in the cluster. Since the distribution of deployment units is fixed, for example, when a node in the k8s (Kubernetes, referred to as K8s, is an open source, containerized application management platform) cluster is abnormal, the pod in load balancing mode (the smallest deployment unit in Kubernetes) will automatically migrate. The k8s scheduler recognizes that there are available resources that meet the conditions in the cluster, and the migration of the pod in load balancing mode will succeed. After the migration is completed, after the pod migrates to a new node, it will continue to run on it. Even if the node returns to normal, it will not be migrated back, resulting in low business reliability.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present application provide a method, device and non-volatile storage medium for allocating deployment units, so as to at least solve the technical problem in the related art that after a node failure on a k8s cluster, the deployment units in the load balancing mode on the failed node will automatically migrate to other nodes, and after the failed node returns to normal, the deployment units automatically migrated to other nodes will not migrate back, resulting in low business reliability.

[0005] According to one aspect of an embodiment of the present application, a method for allocating deployment units is provided, including: obtaining multiple deployment units deployed on multiple business nodes of a target cluster, wherein the working modes of the deployment units include at least a master-slave mode, a master-slave mode, and a load balancing mode; periodically detecting the status of multiple business nodes based on a scheduled task; when it is detected in any detection cycle that the status of a first business node changes from a non-operable state to an operable state, migrating the deployment unit whose working mode is a load balancing mode on the first business node back to the first business node based on a migration strategy, wherein the migration strategy is used to determine the number of deployment units that need to be migrated.

[0006] In some embodiments of the present application, the deployment units whose working mode is the load balancing mode follow the soft anti-affinity strategy, wherein the soft anti-affinity strategy is to deploy the same type of deployment units on different business nodes or to deploy the same type of deployment units on the same business node; the deployment units whose working mode is the master-slave mode or the master-slave mode follow the hard anti-affinity strategy, wherein the hard anti-affinity strategy requires that the same type of deployment units must be deployed on different business nodes, wherein the same type of deployment units refers to deployment units with the same configuration and service functions.

[0007] In some embodiments of the present application, the method also includes: when it is detected in any detection cycle that the state of the first business node changes from an operable state to an inoperable state, the deployment unit whose working mode is the load balancing mode on the first business node migrates to other business nodes among multiple business nodes that meet the soft anti-affinity policy based on the soft anti-affinity policy; the deployment unit whose working mode is the master-slave mode or the master-slave mode on the first business node migrates to other business nodes among multiple business nodes that meet the hard anti-affinity policy based on the hard anti-affinity policy.

[0008] In some embodiments of the present application, multiple deployment units are deployed to multiple business nodes of the target cluster in the following manner: for deployment units in load balancing mode, they are deployed on multiple business nodes based on a soft anti-affinity strategy; for deployment units in master-slave mode or master-slave mode, they are deployed on multiple business nodes based on a hard anti-affinity strategy; for deployment units in working modes other than master-slave mode, master-slave mode, and load balancing mode, they are deployed on multiple business nodes in a randomly distributed manner.

[0009] In some embodiments of the present application, the migration strategy is determined in the following manner: obtaining the total number of deployment units, the total number of business nodes, and the total number of business nodes in an inoperable state; determining the quotient of the total number of deployment units and the total number of business nodes as an intermediate value; determining the product of the intermediate value and the total number of business nodes as the migration number, and determining the migration number as the migration strategy.

[0010] In some embodiments of the present application, when it is detected in any detection cycle that the state of the first business node changes from a non-operable state to an operable state, the deployment units whose working mode is a load balancing mode on the first business node are migrated back to the first business node based on the migration strategy, including: taking the total number of deployment units whose working mode is a load balancing mode on all business nodes as the first total number; reducing the first total number; determining the migration number based on the migration strategy, wherein the migration number is the total number of deployment units whose working mode is a load balancing mode that need to be migrated; and expanding the number of deployment units whose working mode is a load balancing mode on the first business node to the migration number.

[0011] In some embodiments of the present application, scaling down the first total number includes: randomly scaling down the number of deployment units whose working mode is a load balancing mode on business nodes other than the first business node by the number of migrations, wherein the scaled-down first total number reduces the number of migrations.

[0012] In some embodiments of the present application, before the number of deployment units whose working mode is load balancing mode on the first business node is expanded to the number of migrations, the method also includes: locking the second business node, the locked second business node cannot receive the deployment units whose working mode is load balancing mode during expansion, and after the number of deployment units whose working mode is load balancing mode on the first business node is expanded to the number of migrations, unlocking the second business node, wherein the second business node is a business node other than the first business node that has deployment units whose working mode is load balancing mode.

[0013] According to another aspect of an embodiment of the present application, a deployment unit allocation device is also provided, including: an acquisition module, used to acquire multiple deployment units deployed on multiple business nodes of a target cluster, wherein the working modes of the deployment units include at least a master-slave mode, a master-slave mode and a load balancing mode; a detection module, used to periodically detect the status of multiple business nodes based on a scheduled task; a migration module, used to migrate the deployment unit whose working mode is a load balancing mode on the first business node to the first business node based on a migration strategy when the state of the first business node is detected to be changed from a non-operable state to an operable state in any detection cycle, wherein the migration strategy is used to determine the number of deployment units that need to be migrated.

[0014] According to another aspect of an embodiment of the present application, a non-volatile storage medium is provided, in which a program is stored, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the above method for allocating deployment units.

[0015] According to another aspect of an embodiment of the present application, an electronic device is further provided, including: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the above method for allocating deployment units is executed when the program is run.

[0016] According to another aspect of an embodiment of the present application, a computer program product is also provided, including computer instructions, which implement the above deployment unit allocation method when executed by a processor.

[0017] In an embodiment of the present application, multiple deployment units deployed on multiple business nodes of a target cluster are obtained, wherein the working modes of the deployment units include at least a master-slave mode, a master-slave mode and a load balancing mode; the status of multiple business nodes is periodically detected based on a scheduled task; when it is detected in any detection period that the status of the first business node is changed from a non-operable state to an operable state, the deployment unit whose working mode is a load balancing mode on the first business node is migrated back to the first business node based on a migration strategy, wherein the migration strategy is used to determine the number of deployment units that need to be migrated, and when it is detected that the status of the first business node is changed from a non-operable state to an operable state, the deployment unit whose working mode is a load balancing mode on the first business node is migrated back to the first business node based on the migration strategy, thereby achieving the purpose of migrating the part of the deployment units whose working mode is a load balancing mode that cannot be migrated back to the first business node, thereby solving the technical problem in the related technology that after a node failure on the k8s cluster, the deployment unit in the load balancing mode on the failed node will automatically migrate to other nodes, and after the failed node returns to normal, the deployment units automatically migrated to other nodes will not migrate back, resulting in low business reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 It is a hardware structure block diagram of a computer terminal for implementing a method for allocating deployment units provided in accordance with an embodiment of the present application;

[0020] Figure 2 is a flowchart of a method for allocating deployment units provided according to an embodiment of the present application;

[0021] Figure 3 is a flow chart of a deployment unit migration provided according to an embodiment of the present application;

[0022] Figure 4 is a flowchart of another deployment unit migration provided according to an embodiment of the present application;

[0023] Figure 5 It is a module schematic diagram of a 5GC deployment system provided according to an embodiment of the present application;

[0024] Figure 6 It is a structural schematic diagram of a distribution device of a deployment unit provided according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0026] The information collected in the embodiments of the present application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or reject automated decision-making results; if the user chooses to reject, the expert decision-making process will be entered.

[0027] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0028] In order to better understand the embodiments of the present application, the technical terms involved in the embodiments of the present application are explained as follows:

[0029] Pod (Persistent Object Domain): In Kubernetes, pod is its basic scheduling unit. A pod can contain one or more containers. These containers share storage and network resources and can be scheduled and run as a group on a node.

[0030] In the related art, after a node failure on a k8s cluster, the deployment units in the load balancing mode on the failed node will automatically migrate to other nodes, and after the failed node returns to normal, the deployment units automatically migrated to other nodes will not migrate back, resulting in low service reliability. In order to solve this problem, a relevant solution is provided in the embodiment of the present application, which is described in detail below.

[0031] An embodiment of the present application provides an embodiment of a method for allocating a deployment unit. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0032] The method embodiments provided in the embodiments of the present application can be executed in a computer terminal or a similar computing device. Figure 1 FIG. 1 shows a hardware structure block diagram of a computer terminal for implementing a method for allocating deployment units. Figure 1 As shown, the computer terminal 10 may include one or more (102a, 102b, ..., 102n are used to illustrate) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission module 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0033] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10. As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0034] The memory 104 can be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the method for allocating deployment units in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, the method for allocating deployment units described above is implemented. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0035] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0036] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 .

[0037] In the above-mentioned operating environment, an embodiment of the present application provides an embodiment of a method for allocating a deployment unit. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0038] like Figure 2 FIG. 1 is a flowchart of a method for allocating deployment units according to an embodiment of the present application, including:

[0039] Step S202, obtaining multiple deployment units deployed on multiple business nodes of the target cluster, wherein the working mode of the deployment unit (ie, pod) includes at least a master-slave mode, a master-slave mode, and a load balancing mode.

[0040] In the technical solution provided in step S202, the active-standby mode is a high-availability deployment strategy in which one pod is designated as the primary pod and the other pods are standby pods. Under normal circumstances, only the primary pod receives and processes all requests and business logic. The standby pod remains in the startup state but does not receive any traffic, and it continues to listen to the status of the primary pod. Once the primary pod fails, the standby pod automatically takes over the workload of the primary pod and becomes the new primary pod. This mode is usually implemented through Kubernetes's stateful set (StatefulSet, a controller for managing stateful applications in Kubernetes) or deployment controller (Deployment, one of the key components for deploying and managing stateless applications in Kubernetes) combined with anti-affinity configuration to ensure that the primary pod and the standby pod are not deployed on the same node at the same time, thereby enhancing the fault tolerance and high availability of the application. In the master-slave mode, one pod is the primary pod, responsible for write operations and key management tasks. Other pods are slave pods, responsible for read operations or as redundant storage for data. Changes to the master node will be synchronized to the slave node. In Kubernetes, the master-slave mode can be deployed using StatefulSet or other control mechanisms to ensure that each slave node can keep data synchronized with the master node in a timely manner. The master-slave mode improves the system's read performance and data redundancy, and reduces the risk of single point failure. The load balancing mode is used to improve system performance and resource utilization, and evenly distribute tasks to multiple pods. Each pod can handle a portion of the requests, avoiding overloading of a single pod. Pods in load balancing mode follow the Soft Anti-Affinity strategy, which is to try to schedule these pods to different nodes, but when resources are tight, they are allowed to be deployed on the same node. This mode improves the system's response time and throughput, and enhances the system's stability and scalability.

[0041] The deployment units whose working mode is load balancing mode follow the soft anti-affinity strategy, where the soft anti-affinity strategy is to deploy the same type of deployment units on different business nodes or to deploy the same type of deployment units on the same business node; the deployment units whose working mode is master-slave mode or master-slave mode follow the hard anti-affinity strategy, where the hard anti-affinity strategy requires that the same type of deployment units must be deployed on different business nodes, where the same type of deployment units refer to deployment units with the same configuration and service functions. Multiple deployment units are deployed to multiple business nodes of the target cluster in the following ways: for deployment units in load balancing mode, they are deployed on multiple business nodes based on the soft anti-affinity strategy; for deployment units in master-slave mode or master-slave mode, they are deployed on multiple business nodes based on the hard anti-affinity strategy; for deployment units whose working modes are other than master-slave mode, master-slave mode, and load balancing mode, they are deployed on multiple business nodes in a random distribution manner.

[0042] The following are specific embodiments:

[0043] When deploying the deployment unit (i.e., pod) of 5GC (5G Core, the core network of the fifth-generation mobile communication network, which is based on the core idea of ​​cloud native and realizes network customization, openness and service-orientedness through service-based network architecture, slicing of network resources, separation of control plane and user plane, and cloudification technology) products on k8s based on the 5GC deployment system, the key types (network functions or service components that are critical to the operation, reliability and performance of the system, such as control plane functions, user plane functions, database or state storage, and key services (such as authentication services, billing services, network slice management, etc.)) of pods are planned in the deployment script. The working modes of pods are master-slave, master-slave, and load balancing modes. Other pods are deployed in a randomly distributed manner to ensure that the overall pod deployment is evenly distributed.

[0044] Multiple deployment units include multiple pods and their pod replicas. Pod replicas are multiple instances of pods, i.e., replicas, created to ensure high availability, fault tolerance, and load balancing of applications. Multiple pod replicas are multiple running instances of the same pod. They are derived from the same pod template and have the same configuration, image, and environment. The creation, management, and update of pod replicas are all completed by the corresponding scheduler. When a node in the cluster fails or requires maintenance, the scheduler can reschedule pod replicas to other nodes to maintain the continuous operation and load balancing of the application. When multiple deployment units are deployed on multiple business nodes of the target cluster (e.g., k8s cluster), deployment units in master-slave or master-slave mode are forced to be deployed on multiple different business nodes according to the soft anti-affinity strategy. For deployment units in load balancing mode, they are deployed on multiple business nodes based on the soft anti-affinity strategy. Specifically: pods are preferentially deployed on different business nodes, but are not forced to be deployed on different business nodes. In special circumstances (e.g., resource constraints), multiple pods are allowed to be deployed on the same task node.

[0045] Step S204: periodically detect the status of multiple service nodes based on the scheduled task.

[0046] In the technical solution provided in step S204, when it is detected in any detection cycle that the state of the first business node changes from an operable state to an inoperable state, the deployment unit whose working mode is the load balancing mode on the first business node migrates to other business nodes among the multiple business nodes that meet the soft anti-affinity policy based on the soft anti-affinity policy; the deployment unit whose working mode is the master-slave mode or the master-slave mode on the first business node migrates to other business nodes among the multiple business nodes that meet the hard anti-affinity policy based on the hard anti-affinity policy.

[0047] The following are specific embodiments:

[0048] By starting the scheduled task cronjob (in k8s, cronjob is a job controller used to perform periodic tasks), start periodic detection, and regularly collect the status of the target cluster business nodes. Specifically: in the k8s cluster, create a cronjob to implement periodic detection tasks. The cronjob will generate job instances (resource objects used to run one-time tasks). These instances run in privileged mode (in k8s, it refers to a special permission state for container operation. When a container runs in privileged mode, it can access more resources and functions of the host (i.e., the physical or virtual server running the container), which is usually to provide a higher level of system access or management capabilities). The nsenter tool (a Linux command line tool that allows you to enter another namespace from one namespace) can access the Linux environment of the cluster node (i.e., node). In the job instance, the kubectl tool (a command line tool for interacting with the Kubernetes API, which is used to regularly query and collect the status information of each business node in the target cluster and perform pod scaling operations) can be called to regularly query and collect the status information of each business node in the target cluster. In the privileged mode, the job container can access the host namespace through the nsenter tool, so as to run kubectl commands for the host service node inside the container. This enables the job to directly perform operations on the service node, such as obtaining the node status, managing the node's scheduling capabilities, and scaling pods.

[0049] The scheduled task is to collect abnormal business node status, that is, when the state of the first business node is detected to change from the runnable state (ready state) to the non-runnable state (notready state) in any detection cycle, the business node has a node failure, and the pod that meets the migration conditions will be migrated, that is, the deployment unit with the working mode of load balancing mode on the first business node is migrated to other business nodes that meet the soft anti-affinity policy among multiple business nodes based on the soft anti-affinity policy. When migrating to different business nodes based on the soft anti-affinity policy, it is preferred to migrate to different business nodes, but it can be migrated to the same business node based on business needs. When the deployment unit with the working mode of master-slave mode or master-slave mode on the first business node is migrated to other business nodes that meet the hard anti-affinity policy among multiple business nodes based on the hard anti-affinity policy, it is forced to migrate to a different business node. If the conditions are not met, it will enter the waiting state and no migration will occur.

[0050] Step S206, when it is detected in any detection cycle that the state of the first business node changes from a non-operable state to an operable state, the deployment unit whose working mode is the load balancing mode on the first business node is migrated back to the first business node based on the migration strategy, wherein the migration strategy is used to determine the number of deployment units that need to be migrated.

[0051] In the technical solution provided in step S206, the migration strategy is determined in the following manner: obtaining the total number of deployment units, the total number of business nodes, and the total number of business nodes in an inoperable state; determining the quotient of the total number of deployment units and the total number of business nodes as an intermediate value; determining the product of the intermediate value and the total number of business nodes as the migration quantity, and determining the migration quantity as the migration strategy.

[0052] When it is detected in any detection cycle that the state of the first business node changes from a non-operable state to an operable state, there are multiple ways to implement migrating the deployment units whose working mode is the load balancing mode on the first business node back to the first business node based on the migration strategy, for example: taking the total number of deployment units whose working mode is the load balancing mode on all business nodes as the first total number; reducing the first total number; determining the migration number based on the migration strategy, wherein the migration number is the total number of deployment units whose working mode is the load balancing mode that need to be migrated; and expanding the number of deployment units whose working mode is the load balancing mode on the first business node to the migration number.

[0053] There are many ways to reduce the first total number, for example: randomly reduce the number of deployment units working in load balancing mode on business nodes other than the first business node by the number of migrations, wherein the reduced first total number reduces the number of migrations.

[0054] In order to ensure that only the business nodes that need to migrate pods accept the scheduling of pods, the second business node is locked before the number of deployment units in load balancing mode on the first business node is expanded to the number of migrations. The locked second business node cannot receive deployment units in load balancing mode during expansion. After the number of deployment units in load balancing mode on the first business node is expanded to the number of migrations, the second business node is unlocked, wherein the second business node is a business node that has deployment units in load balancing mode in addition to the first business node.

[0055] The following are specific embodiments:

[0056] Use cronjob to detect the status of each business node in the target cluster. When it is detected that the business node status changes from notready (i.e., non-operable status) to ready (i.e., operational status), the migration process is triggered. Based on the migration strategy, the pod is scaled down first and then expanded, and some deployment units on the migrated first business node whose working mode is load balancing mode are migrated back to the first business node. Specifically: first determine the number of migrations, obtain the total number of deployment units, the total number of business nodes, and the total number of business nodes whose status is non-operable; determine the quotient of the total number of deployment units and the total number of business nodes as the intermediate value; determine the product of the intermediate value and the total number of business nodes as the number of migrations, and determine the number of migrations as the migration strategy. The migration strategy also defines that the working mode of the migrated deployment unit is load balancing mode, and the destination node of the migration is the first node. In the job container in privileged mode, use the nsenter tool to execute the tasks specified by the pod migration strategy and the pod migration execution tasks (shrink and expand the deployment unit). Specifically: according to the migration strategy, use the kubectl tool to shrink the deployment unit (shrunk the pod replica), use the scheduler to randomly distribute the deployment units in the load balancing mode on other business nodes other than the first business node to reduce the number of migrations. After the shrinkage, the total number of pods in the load balancing mode on other business nodes other than the first business node is reduced by the number of migrations. Then expand the capacity. Based on the scheduler's expansion operation on the job container in privileged mode, set the expansion number to the migration number, and expand the number of deployment units in the load balancing mode on the first business node to the migration number. After the expansion is completed, the migration process ends. In order to ensure that the pod is only migrated back to the failed recovery node, we implement a node scheduling lock strategy: before executing the pod migration operation, use the cordon command (a tool used in k8s to manage node scheduling policies, which is part of the kubectl command line tool. The main function of the cordon command is to mark a node as unschedulable, which means that new pods will not be scheduled to the node) to lock all second business nodes except the first business node, preventing load balancing mode pods from being scheduled on them. The second business node is locked, and the locked second business node cannot receive deployment units with a working mode of load balancing mode when expanding. After the number of deployment units with a working mode of load balancing mode on the first business node is expanded to the number of migrations, the second business node is unlocked, where the second business node is a business node with a deployment unit with a working mode of load balancing mode other than the first business node. For example, there are a total of 6 business nodes, of which 1 faulty business node A is converted from an inoperable state to an operable state. The total number of pods with a working mode of load balancing is 30.The number of relocations is 5. The number of deployment units in the load balancing mode in the business nodes other than A is randomly reduced by 5, and then the number of deployment units in the load balancing mode in A is expanded by 5.

[0057] Through the above steps, the method and process of formulating pod migration strategy and running pod migration instructions are realized. The recycling strategy can be customized according to the needs of different application products, and the types and quantities of pod migration can be differentiated. Ultimately, after the product is restored from disaster recovery or fault recovery, the load balancing and reliability customized by various scheduling strategies during product installation can be restored. It can monitor the health status of nodes in the cluster in real time to ensure that it can respond quickly when the node status changes, thereby improving the overall stability and reliability of the system. It solves the technical problem in related technologies that after a node fails on the k8s cluster, the deployment unit in the load balancing mode on the failed node will automatically migrate to other nodes, and after the failed node returns to normal, the deployment unit automatically migrated to other nodes will not migrate back, resulting in low business reliability.

[0058] The present application embodiment also provides a flow chart of deployment unit migration, such as Figure 3As shown, the migration process of the deployment unit (i.e., pod) in the related technology is shown. In the related technology, 1.5GC deployment and installation are first performed. In the initial stage, the 5GC product is deployed to the Kubernetes cluster, including creating pods and deploying them to different business nodes. Then the deployment controller Deployment performs 2. Setting the pod to soft anti-affinity deployment between multiple copies, that is, setting a soft anti-affinity policy for the pods in the load balancing mode to ensure that they are distributed on different business nodes as much as possible. Then the K8s (i.e., k8s) Scheduler scheduler distributes the pods evenly on different worker nodes (also called node nodes, i.e., the above-mentioned working nodes) according to the affinity policy set in the deployment (i.e., Deployment). That is, for the above-mentioned deployment unit in the load balancing mode, it is deployed on multiple business nodes based on the soft anti-affinity policy; for the deployment unit in the master-slave mode or the master-slave mode, it is deployed on multiple business nodes based on the hard anti-affinity policy; for the deployment unit whose working mode is other than the master-slave mode, the master-slave mode, and the load balancing mode, it is deployed on multiple business nodes in a random distribution manner. In the event of a node failure, that is, a business node failure, pod migration is triggered. The scheduler reselects a node that can carry the pod to be migrated, and the pods that meet the migration conditions are migrated to other nodes: pods in load balancing mode will be migrated to other nodes with sufficient resources, and pods in master-slave or master-slave mode will also be migrated to other nodes with available resources, but if there are not enough resources, they will remain in a waiting state. Finally, the node failure is recovered, and the pods that were previously migrated on the failure recovery business node will not be migrated back, that is, the pods that were successfully migrated will not be migrated back to the original business node. As a result, the pods with load balancing mode will no longer run on the failure recovery business node, or the number of running pods cannot reach a state of even distribution within the cluster. As a result, pods of the same type are concentrated in some business nodes, which reduces the reliability of 5GC services and increases the risk of a large number of load sharing pods being abnormal due to the failure of a single business node.

[0059] The present application embodiment also provides another flow chart of deployment unit migration, such as Figure 4 As shown, it is Figure 3The process is improved by starting the scheduled task cronjob (in k8s, cronjob is a job controller used to perform periodic tasks), starting periodic detection, and regularly collecting the status of the target cluster business nodes. In step 8, the pods that meet the migration conditions are migrated to other node nodes, which will break the principle of fast priority anti-affinity and uniform scheduling, that is, some deployment units with load balancing mode as the working mode are migrated to the same business node. 9. Scheduled task: record the node status notready; 10. Fault recovery; 11. Scheduled task: record the node status ready. Steps 9-11 correspond to the use of cronjob scheduled tasks in the above embodiment to detect the status of each business node in the target cluster. It is detected that the business node status changes from notready state (i.e., non-operable state) to ready state (i.e., operable state). 12. Calculate the number of pods that need to be migrated back, and perform pod migration operations in privileged mode; 13. The pods are migrated back to the faulty node; 14. Determine that the migration of various types of pods to be migrated is completed, and end this migration process. Steps 12-14 correspond to the above-mentioned embodiment of scaling down the pod first and then expanding it based on the migration strategy, and migrating some of the deployment units in the load balancing mode on the migrated first business node back to the first business node, which will not be described in detail here. The above improvements solve the technical problem that in the related technology, after a node failure on the k8s cluster, the deployment units in the load balancing mode on the failed node will automatically migrate to other nodes, and after the failed node returns to normal, the deployment units automatically migrated to other nodes will not migrate back, resulting in low business reliability.

[0060] The present application embodiment also provides a module schematic diagram of a 5GC deployment system, such as Figure 5As shown, a module schematic diagram of the 5GC deployment system for deploying 5GC products in an embodiment of the present application is shown, including a node node kubectl tool module: providing a command line tool that interacts with the Kubernetes API, used to manage pods in the target cluster, obtain business node status, and perform pod scaling operations. Cron job (i.e., cronjob) timing task module: responsible for periodically checking node status, identifying fault and recovery events, and triggering the migration process. Deployment deployment template module: responsible for pod deployment strategy, including the configuration of master-slave, master-slave, and load balancing modes, as well as the deployment of soft anti-affinity strategy and hard anti-affinity strategy. Cluster status acquisition module: obtains the status of business nodes in the cluster from the node node kubectl tool module for analysis by the migration strategy module. Pod migration strategy module: based on the status of business nodes in the cluster, calculates the number of migrations and provides a decision-making basis for the migration execution module. Pod migration execution module: according to the migration strategy, uses the kubectl tool to perform pod scaling, expansion, and rescheduling operations.

[0061] The present application also provides a distribution device for a deployment unit, such as Figure 6 As shown, including:

[0062] The acquisition module 602 is used to acquire multiple deployment units deployed on multiple service nodes of the target cluster, wherein the working modes of the deployment units at least include the master-slave mode, the master-slave mode and the load balancing mode.

[0063] The acquisition module 602 is also used to deploy deployment units in load balancing mode on multiple business nodes based on a soft anti-affinity strategy; to deploy deployment units in master-slave mode or master-slave mode on multiple business nodes based on a hard anti-affinity strategy; and to deploy deployment units in working modes other than master-slave mode, master-slave mode, and load balancing mode on multiple business nodes in a randomly distributed manner.

[0064] The detection module 604 is used to periodically detect the status of multiple service nodes based on the scheduled task.

[0065] The detection module 604 is also used to detect that when the state of the first business node changes from an operable state to an inoperable state in any detection cycle, the deployment unit on the first business node whose working mode is the load balancing mode migrates to other business nodes among multiple business nodes that meet the soft anti-affinity policy based on the soft anti-affinity policy; the deployment unit on the first business node whose working mode is the master-slave mode or the master-slave mode migrates to other business nodes among multiple business nodes that meet the hard anti-affinity policy based on the hard anti-affinity policy.

[0066] The migration module 606 is used to migrate the deployment units whose working mode is the load balancing mode on the first business node back to the first business node based on the migration strategy when it is detected that the state of the first business node changes from an inoperable state to an operable state in any detection cycle, wherein the migration strategy is used to determine the number of deployment units that need to be migrated.

[0067] The migration module 606 is also used to obtain the total number of deployment units, the total number of business nodes, and the total number of business nodes in an inoperable state; determine the quotient of the total number of deployment units and the total number of business nodes as the intermediate value; determine the product of the intermediate value and the total number of business nodes as the migration number, and determine the migration number as the migration strategy.

[0068] The migration module 606 is also used to take the total number of deployment units whose working mode is load balancing mode on all business nodes as the first total number; to reduce the first total number; to determine the migration number based on the migration strategy, wherein the migration number is the total number of deployment units whose working mode is load balancing mode that need to be migrated; and to expand the number of deployment units whose working mode is load balancing mode on the first business node to the migration number.

[0069] The migration module 606 is further configured to randomly reduce the number of deployment units in the load balancing mode on the service nodes other than the first service node by the migration number, wherein the first total number after reduction is reduced by the migration number.

[0070] The migration module 606 is also used to lock the second business node. The locked second business node cannot receive deployment units whose working mode is load balancing mode during expansion. After the number of deployment units whose working mode is load balancing mode on the first business node is expanded to the migration number, the second business node is unlocked, wherein the second business node is a business node other than the first business node that has deployment units whose working mode is load balancing mode.

[0071] It should be noted that Figure 6 The distribution device of the deployment unit shown is used to perform Figure 2 The deployment unit allocation method shown is therefore Figure 2 The relevant explanations in the allocation method of the deployment unit in are also applicable to the allocation device of the deployment unit, and will not be repeated here.

[0072] It should be noted that the various modules in the allocation device of the above-mentioned deployment unit can be program modules (for example, a set of program instructions that implement a certain specific function) or hardware modules. For the latter, it can be expressed in the following forms, but is not limited to this: the expression form of each of the above-mentioned modules is a processor, or the functions of each of the above-mentioned modules are implemented by a processor.

[0073] The embodiment of the present application also provides a non-volatile storage medium, the non-volatile storage medium includes a stored program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the above deployment unit allocation method. For example, multiple deployment units deployed on multiple business nodes of the target cluster are obtained, wherein the working modes of the deployment units include at least master-slave mode, master-slave mode and load balancing mode; the status of multiple business nodes is periodically detected based on a scheduled task; when the state of the first business node is detected to be changed from a non-operable state to an operable state in any detection cycle, the deployment unit whose working mode is a load balancing mode on the first business node is migrated back to the first business node based on the migration strategy, wherein the migration strategy is used to determine the number of deployment units that need to be migrated back.

[0074] The embodiment of the present application also provides an electronic device, the electronic device includes a processor, the processor is used to run a program, wherein the above deployment unit allocation method is executed when the program is running. For example, multiple deployment units deployed on multiple business nodes of the target cluster are obtained, wherein the working mode of the deployment unit includes at least a master-slave mode, a master-slave mode and a load balancing mode; the status of multiple business nodes is periodically detected based on a scheduled task; when the state of the first business node is detected to be changed from an inoperable state to an operable state in any detection cycle, the deployment unit whose working mode is a load balancing mode on the first business node is migrated back to the first business node based on the migration strategy, wherein the migration strategy is used to determine the number of deployment units that need to be migrated back.

[0075] According to another aspect of the embodiment of the present application, a computer program product is also provided, including a computer program, which implements the above method for allocating deployment units when executed by a processor. For example, multiple deployment units deployed on multiple business nodes of a target cluster are obtained, wherein the working modes of the deployment units include at least a master-slave mode, a master-slave mode, and a load balancing mode; the status of multiple business nodes is periodically detected based on a scheduled task; when the state of the first business node is detected to be changed from an inoperable state to an operable state in any detection cycle, the deployment unit whose working mode is a load balancing mode on the first business node is migrated back to the first business node based on a migration strategy, wherein the migration strategy is used to determine the number of deployment units that need to be migrated back.

[0076] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0077] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0078] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0079] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0080] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the relevant technology or all or part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, RandomAccess Memory), mobile hard disk, disk or optical disk, etc. Various media that can store program codes.

[0081] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for allocating deployment units, characterized in that: include: Acquire multiple deployment units deployed on multiple service nodes of the target cluster, wherein the working modes of the deployment units at least include a master-slave mode, a master-slave mode, and a load balancing mode; Periodically detecting the status of the multiple service nodes based on a scheduled task; When it is detected in any detection cycle that the state of the first business node changes from a non-operable state to an operable state, the deployment units whose working mode is the load balancing mode on the first business node are migrated back to the first business node based on the migration strategy, wherein the migration strategy is used to determine the number of deployment units that need to be migrated.

2. The method according to claim 1, characterized in that The deployment units whose working mode is the load balancing mode follow the soft anti-affinity strategy, wherein the soft anti-affinity strategy is to deploy the same type of deployment units on different business nodes or to deploy the same type of deployment units on the same business node; the deployment units whose working mode is the master-slave mode or the master-slave mode follow the hard anti-affinity strategy, wherein the hard anti-affinity strategy requires that the same type of deployment units must be deployed on different business nodes, wherein the same type of deployment units refers to deployment units with the same configuration and service functions.

3. The method according to claim 2, characterized in that The method further comprises: When it is detected in any detection cycle that the state of the first service node changes from the operational state to the inoperable state, The deployment unit on the first service node, whose working mode is the load balancing mode, migrates to other service nodes among the multiple service nodes that meet the soft anti-affinity policy based on the soft anti-affinity policy; The deployment unit whose working mode is the master-slave mode or the master-slave mode on the first service node is migrated to other service nodes among the multiple service nodes that meet the hard anti-affinity policy based on the hard anti-affinity policy.

4. The method according to claim 2, characterized in that: The multiple deployment units are deployed to the multiple service nodes of the target cluster in the following manner: The deployment unit of the load balancing mode is deployed on the multiple service nodes based on the soft anti-affinity strategy; For the deployment units in the master-slave mode or the master-slave mode, they are deployed on the multiple service nodes based on the hard anti-affinity strategy; For deployment units whose working modes are other than the master-slave mode, the master-slave mode, and the load balancing mode, they are deployed on the multiple service nodes in a randomly distributed manner.

5. The method according to claim 1, characterized in that The migration strategy is determined by: Get the total number of deployment units, the total number of business nodes, and the total number of business nodes in an inoperable state; Determine the quotient of the total number of deployment units and the total number of service nodes as an intermediate value; The product of the intermediate value and the total number of service nodes is determined as the number of migrations, and the number of migrations is determined as the migration strategy.

6. The method according to claim 5, characterized in that When it is detected in any detection cycle that the state of the first service node changes from an inoperable state to an operable state, migrating the deployment unit whose working mode is a load balancing mode on the first service node back to the first service node based on the migration strategy includes: The total number of deployment units in the load balancing mode on all service nodes is taken as the first total number; reducing the first total quantity; Determine the number of migrations based on the migration strategy, wherein the number of migrations is the total number of deployment units whose working mode to be migrated is the load balancing mode; The number of deployment units whose working mode is the load balancing mode on the first service node is expanded to the migration number.

7. The method according to claim 6, characterized in that Scaling down the first total quantity includes: The number of deployment units whose working mode is the load balancing mode on the service nodes other than the first service node is randomly reduced by the relocation number, wherein the first total number after reduction is reduced by the relocation number.

8. The method according to claim 6, characterized in that Expanding the number of deployment units whose working mode is a load balancing mode on the first service node to a number before the number of migrations, the method further comprising: The second business node is locked. The locked second business node cannot receive deployment units whose working mode is load balancing mode during expansion. After the number of deployment units whose working mode is load balancing mode on the first business node is expanded to the migration number, the second business node is unlocked, wherein the second business node is a business node other than the first business node that has deployment units whose working mode is load balancing mode.

9. A distribution device for a deployment unit, characterized in that: include: An acquisition module, used to acquire multiple deployment units deployed on multiple service nodes of a target cluster, wherein the working modes of the deployment units include at least a master-slave mode, a master-slave mode and a load balancing mode; A detection module, used for periodically detecting the status of the multiple service nodes based on a scheduled task; The migration module is used to migrate the deployment units whose working mode is load balancing mode on the first business node back to the first business node based on the migration strategy when it is detected that the state of the first business node changes from an inoperable state to an operable state in any detection cycle, wherein the migration strategy is used to determine the number of deployment units that need to be migrated.

10. A non-volatile storage medium, characterized in that: The non-volatile storage medium stores a program, wherein when the program is executed, the device where the non-volatile storage medium is located is controlled to execute the method for allocating deployment units according to any one of claims 1 to 8.

11. An electronic device, characterized in that: include: A memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the method for allocating deployment units as described in any one of claims 1 to 8 when running.

12. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by a processor, the method for allocating deployment units described in any one of claims 1 to 8 is implemented.

Images