A container rescheduling method, device, equipment and storage medium

Abstract

The application discloses a container rescheduling method and device, equipment and medium, and relates to the technical field of computers, which comprises the following steps: when a service instance triggers a container rescheduling operation, determining an associated service with the maximum intimacy value of the service instance from a call link topology graph as a target service; judging whether the service instance and the target service both perform the container rescheduling operation to obtain a corresponding judgment result; if the judgment result is that both perform the container rescheduling operation, performing the container rescheduling on the service instance and the target service by using a destination node; and if the judgment result is not that both perform the container rescheduling operation, taking a container node where the service instance is located as the destination node to perform the container rescheduling on the service instance. When the container rescheduling operation is triggered, the actual call link data between microservices in a microservice architecture is used to determine an associated service, and services with actual call relations are preferentially called to the same or similar physical / network topology computing nodes.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a container rescheduling method, apparatus, device, and storage medium. Background Technology

[0002] Using open-source technologies as a "nutrient solution," and leveraging a series of native application operations such as microservices, containers, iteration, DevOps, and AIOps, a wave of IT construction has swept across various industries. Adopting cloud computing for centralized IT construction, and providing out-of-the-box cloud services such as databases and middleware, is becoming increasingly popular, significantly reducing the cost of IT construction and making it more convenient for end users to access IT services. With the rise of microservice architecture, modern applications are gradually becoming modularized and decoupled. The number of microservices in a single application is increasing. Based on the existing Kubernetes (K8s, container cluster management system) scheduling model, it is impossible to guarantee that services with business relationships are scheduled to the same or nearby nodes. Often, each individual service is encapsulated in a container and subject to scheduling and management by the container management system, which increases network latency and resource overhead between services and reduces performance.

[0003] In summary, how to schedule application services with business relationships to the same or adjacent computing nodes as much as possible, realize container rescheduling, reduce the overall network overhead of applications, improve performance, and accelerate the development and implementation of cloud-native technologies are technical problems that need to be solved in this field. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a container rescheduling method, apparatus, device, and storage medium that can schedule application services with business relationships to the same or adjacent computing nodes as much as possible, thereby achieving container rescheduling, reducing the overall network overhead of applications, improving performance, and accelerating the development and deployment of cloud-native technologies. The specific solution is as follows: Firstly, this application discloses a container rescheduling method, including: When a service instance triggers a container rescheduling operation, the associated service with the highest affinity value to the service instance is determined from the call chain topology graph as the target service. Determine whether both the service instance and the target service have undergone container rescheduling operations to obtain the corresponding determination result; If the determination result is that container rescheduling operation is performed on both, then the service instance and the target service are rescheduled using the destination node. If the judgment result is not that container rescheduling is performed, then the computing node where the target service is located is used as the destination node, and the service instance is rescheduled.

[0005] Optionally, before determining the associated service with the highest affinity value to the service instance as the target service from the call chain topology graph when the service instance triggers a container rescheduling operation, the method further includes: Collect call data from each service, and generate a call chain topology diagram between the services based on the call data.

[0006] Optionally, before collecting the call data of each service, the process further includes: Deploy the descriptive declarations that include resource declarations, deployment order declarations, and workload type declarations for cloud-native applications, and enable service governance for the cloud-native applications.

[0007] Optionally, generating a call chain topology diagram between various services based on the call data includes: Based on the call data, the traffic topology relationship of each microservice component is drawn, and a call chain topology diagram carrying the affinity value between each service is generated based on the traffic topology relationship.

[0008] Optionally, before deploying the description declaration containing the resource declaration, deployment order declaration, and workload type declaration of the cloud-native application, the method further includes: Analyze the cloud-native application to obtain its various microservice components; A service governance traffic component is injected into the microservice component to record service traffic and generate basic data for accessing and calling data.

[0009] Optionally, the process of generating the call chain topology graph carrying the affinity values ​​between various services based on the traffic topology relationship further includes: Record the call frequency between each service, and generate a closeness value between each service based on the call frequency.

[0010] Optionally, the container rescheduling method further includes: When a new access request is generated, the corresponding service associated with the access request is identified, and the affinity value between the corresponding services is increased.

[0011] Secondly, this application discloses a container rescheduling device, comprising: The service determination module is used to determine the associated service with the highest affinity value to the service instance from the call chain topology graph when a service instance triggers a container rescheduling operation. The result judgment module is used to determine whether both the service instance and the target service have undergone container rescheduling operations, so as to obtain the corresponding judgment result. The first container scheduling module is used to perform container rescheduling on the service instance and the target service using the destination node if the judgment result is that both should be rescheduled. The second container scheduling module is used to perform container rescheduling on the service instance if the judgment result is not that all container rescheduling operations are performed, by taking the computing node where the target service is located as the destination node.

[0012] Thirdly, this application discloses an electronic device, including: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the aforementioned disclosed container rescheduling method.

[0013] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the steps of the aforementioned disclosed container rescheduling method.

[0014] Therefore, this application discloses a container rescheduling method, comprising: when a service instance triggers a container rescheduling operation, determining the associated service with the highest affinity value to the service instance as the target service from the call chain topology graph; determining whether both the service instance and the target service perform container rescheduling operations to obtain a corresponding determination result; if the determination result is that both perform container rescheduling operations, then using the destination node to perform container rescheduling on the service instance and the target service; if the determination result is not that both perform container rescheduling operations, then using the compute node where the target service is located as the destination node to perform container rescheduling on the service instance. It can be seen that when a container rescheduling operation is triggered, based on the actual call chain data between microservices in a modern microservice architecture application, associated services are determined, and then services with actual call relationships are prioritized to call compute nodes with the same or similar physical / network topology, reducing network access latency between services, increasing throughput, and improving application performance. Attached Figure Description

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

[0016] Figure 1 This is a flowchart of a container rescheduling method disclosed in this application; Figure 2 This is a flowchart of a specific container rescheduling method disclosed in this application; Figure 3 This is a flowchart of a container rescheduling method based on K8s disclosed in this application; Figure 4 This is a schematic diagram of a container rescheduling device disclosed in this application; Figure 5 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0018] Using open-source technologies as a "nutrient solution," and leveraging native application operations such as microservices, containers, iteration, DevOps, and AIOps, a wave of IT construction has swept across various industries. Adopting cloud computing for centralized IT construction, and providing out-of-the-box cloud services such as databases and middleware, is becoming increasingly popular, significantly reducing the cost of IT construction and making it more convenient for end users to access IT services. With the rise of microservice architecture, modern applications are gradually becoming modularized and decoupled. The number of microservices in a single application is increasing. Based on the existing Kubernetes scheduling model, it is impossible to guarantee that services with business relationships are scheduled to the same or nearby nodes. Often, each individual service is encapsulated in a container and subject to scheduling and management by a container management system, which increases network latency and resource overhead between services, reducing performance.

[0019] To this end, this application provides a container rescheduling scheme that can schedule application services with business relationships to the same or adjacent computing nodes as much as possible, thereby realizing container rescheduling, reducing the overall network overhead of the application, improving performance, and accelerating the development and implementation of cloud-native technologies.

[0020] Reference Figure 1 As shown in the figure, an embodiment of the present invention discloses a container rescheduling method, including: Step S11: When a service instance triggers a container rescheduling operation, the associated service with the highest affinity value to the service instance is determined from the call chain topology graph as the target service.

[0021] In this embodiment, when a service instance fails and restarts or is manually triggered for rescheduling, the rescheduling device will use the associated services related to the service affinity values ​​recorded in the call link topology diagram in the call link data collection and recording device as the target service. Specifically, all services associated with the current service instance are sorted from largest to smallest affinity value, and the associated service with the largest affinity value is selected as the target service. The target service is one that has a high degree of correlation with the service instance that triggered the rescheduling operation. Therefore, when it is determined that the current service instance has triggered the container rescheduling operation, the target service is determined based on the affinity value.

[0022] In this embodiment, before determining the service with the highest affinity value to the service instance as the target service from the call chain topology graph when the service instance triggers a container rescheduling operation, the method further includes: collecting call data from each service and generating a call chain topology graph between the services based on the call data. It can be understood that the call data of each service instance is collected by the service call chain collection device, and call data for each service is generated based on the call data of each service instance. Specifically, since each service contains multiple service instances, the call data of each service instance is recorded and statistically analyzed to complete the collection of call data for the corresponding service. An internal call connection topology graph between services is generated based on the call data of each service. That is, the traffic topology relationship of each microservice component in the cloud-native application is drawn based on the call data, and a combination relationship is established between all services. The combination relationship is stored in a relational database to record the affinity relationships between services. For example, the call chain data and graph relationships are recorded and saved in Elasticsearch.

[0023] In this embodiment, the traffic topology of each microservice component is drawn based on the call data, and a call chain topology diagram carrying the affinity values ​​between each service is generated based on the traffic topology. Specifically, the process of generating the call chain topology diagram carrying the affinity values ​​between each service based on the traffic topology also includes: recording the call frequency between each service, and generating affinity values ​​between each service based on the call frequency. It can be understood that when a new access request is generated, the corresponding service associated with the access request is determined, and the affinity value between the corresponding service is increased. For example: the traffic topology of each microservice component is drawn based on the call data, then a call chain topology diagram is generated based on the traffic topology, and the affinity values ​​between each service in the call chain topology diagram are recorded in a relational database using a combination method, with the affinity value increasing each time a call request occurs.

[0024] Step S12: Determine whether both the service instance and the target service have undergone container rescheduling operations to obtain the corresponding determination result.

[0025] In this embodiment, the current service instance and the target service are judged to determine whether both services are rescheduled. The judgment condition is to determine whether the target service is rescheduled manually or triggered by a fault restart, so as to obtain the result that both services are rescheduled or the result that the two services are not rescheduled.

[0026] Step S13: If the judgment result is that container rescheduling operation is performed on both, then the target node is used to perform container rescheduling on the service instance and the target service.

[0027] In this embodiment, if the target service also participates in the same batch rescheduling of the current service instance, it will be rescheduled to the same destination node as the current service instance to achieve container rescheduling. If it is not possible to reschedule both services to the same destination node, nodes with similar physical or network topologies will be given priority in scheduling.

[0028] Step S14: If the judgment result is not that all containers are rescheduled, then the computing node where the target service is located is taken as the destination node, and the service instance is rescheduled.

[0029] In this embodiment, if the target service does not participate in the same batch rescheduling of the current service instance, then the compute node where the target service is located will be given a score during the K8s optimization phase, and the compute node where the target service is located will be used as the target node for container rescheduling of the service instance.

[0030] Therefore, this application discloses a container rescheduling method, comprising: when a service instance triggers a container rescheduling operation, determining the associated service with the highest affinity value to the service instance as the target service from the call chain topology graph; determining whether both the service instance and the target service perform container rescheduling operations to obtain a corresponding determination result; if the determination result is that both perform container rescheduling operations, then using the destination node to perform container rescheduling on the service instance and the target service; if the determination result is not that both perform container rescheduling operations, then using the compute node where the target service is located as the destination node to perform container rescheduling on the service instance. It can be seen that when a container rescheduling operation is triggered, based on the actual call chain data between microservices in a modern microservice architecture application, associated services are determined, and then services with actual call relationships are prioritized to call compute nodes with the same or similar physical / network topology, reducing network access latency between services, increasing throughput, and improving application performance.

[0031] Reference Figure 2As shown, this embodiment of the invention discloses a specific container rescheduling method. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution. Specifically: Step S21: Deploy the description declaration containing the resource declaration, deployment order declaration, and workload type declaration of the cloud-native application, and enable service governance for the cloud-native application.

[0032] In this embodiment, the cloud-native application deployment device calls the K8s APIServer to complete the orchestration and deployment of relevant resources based on the resource declarations, deployment order declarations, and workload type declarations of the cloud-native application in the description file. At the same time, service governance is enabled for the application, and a proxy container is deployed in each service instance to record the call chain data. It should be noted that the cloud-native application deployment device supports common application description methods, which may include, but are not limited to, YAML format, HELM format, Operator format, etc.

[0033] In this embodiment, before deploying the description declaration containing the resource declaration, deployment order declaration, and workload type declaration of the cloud-native application, the method further includes: parsing the cloud-native application to obtain its various microservice components; injecting a service governance traffic component into each microservice component to record service traffic and generate basic data for accessing and calling data. It can be understood that by using a cloud application deployment device to parse a cloud-native application in a general format, breaking it down into its various microservice components, injecting a service governance traffic component into each microservice component, intercepting and recording service traffic to form basic data for accessing and calling data, and then calling the API Server to create each resource and form a complete application, the deployment device can achieve this.

[0034] Step S22: Collect call data for each service and generate a call chain topology diagram between the services based on the call data.

[0035] In this embodiment, the traffic hijacking component in the microservice component is used to generate call data when accessing services, and the data is stored in the ElasticSearch component so as to generate a call chain topology map based on the call data.

[0036] Step S23: When a service instance triggers a container rescheduling operation, the associated service with the highest affinity value to the service instance is determined from the call chain topology graph as the target service.

[0037] Step S24: Determine whether both the service instance and the target service have undergone container rescheduling operations to obtain the corresponding determination result.

[0038] Step S25: If the judgment result is that container rescheduling operation is performed on both, then the target node is used to perform container rescheduling on the service instance and the target service.

[0039] Step S26: If the judgment result is not that all containers are rescheduled, then the computing node where the target service is located is taken as the destination node, and the service instance is rescheduled.

[0040] For more detailed processing steps S22, S24, S25, and S26, please refer to the aforementioned disclosed embodiments; they will not be repeated here.

[0041] Reference Figure 3As shown, the container rescheduling device includes: a cloud-native application deployment device, a service call chain data collection and recording device, and a container instance rescheduling device. The cloud-native application deployment device primarily completes the initial deployment of the application, with the following main steps: The cloud-native application deployment device parses the declarative description of the cloud-native application in YAML / HELM / Operator formats, including resource types and specifications, workload types, deployment order, etc., and parses it into various microservice components of the application; it injects a service governance traffic component into each microservice component to intercept and record service traffic, forming the basic data for access call data; the deployment device calls the API Server to complete the creation of each resource, forming a complete application; the service call chain data collection and recording device is responsible for collecting data from the running process... The process involves collecting service call data and forming service affinity information. The main steps are as follows: The traffic hijacking component in the microservice component generates call data during service access and stores this data in the ElasticSearch component; based on the access link data, the traffic topology of each component in the application is plotted, and all services are paired to establish combination relationships, which are stored in a relational database to record service affinity; whenever a new access occurs, the affinity value of the corresponding two services is incremented; the container rescheduling device is responsible for rescheduling services when a microservice instance fails and is rebuilt or manually triggered. Based on the service affinity values ​​recorded in the call link data collection and recording device, the rescheduling device prioritizes scheduling services with high affinity values ​​to the same or nearby nodes. The main operation steps are as follows: When a service instance fails and needs to be rebuilt or manually rescheduled across the entire application, the rescheduling device will sort all services associated with the current service instance according to their proximity values ​​from largest to smallest based on the service proximity information formed in the above steps, and select the service with the largest proximity value; it will then determine whether the current service instance and the closest service need to be rescheduled. If both services need to be rescheduled, they will be processed as a single scheduling unit and scheduled to a node or the closest node that meets the conditions; if the closest node does not participate in the scheduling, the current service instance will be scheduled with the node where the closest node is currently located as the destination node, and will be scheduled to the destination node or a node close to the destination node.

[0042] Therefore, by deploying cloud-native applications and using proxy containers within service instances to collect and record call data from each microservice component, an accurate call chain topology can be constructed based on this data. Furthermore, by recording the affinity values ​​of related services in the call chain topology according to their call frequency, a reliable call chain topology can be achieved. This ensures that during container rescheduling, services with actual call relationships are prioritized to call compute nodes with the same or similar physical / network topology, reducing network access latency between services, increasing throughput, and improving application performance.

[0043] Reference Figure 4 As shown, an embodiment of the present invention discloses a container rescheduling device, comprising: Service determination module 11 is used to determine the associated service with the highest affinity value to the service instance as the target service from the call link topology graph when the service instance triggers a container rescheduling operation; The result judgment module 12 is used to determine whether both the service instance and the target service have undergone container rescheduling operations, so as to obtain the corresponding judgment result. The first container scheduling module 13 is used to perform container rescheduling on the service instance and the target service using the destination node if the judgment result is that both should be rescheduled. The second container scheduling module 14 is used to perform container rescheduling on the service instance if the judgment result is not that all container rescheduling operations are performed, by taking the computing node where the target service is located as the destination node.

[0044] The service determination module 11 is specifically used to, when a service instance fails and restarts or is manually triggered for rescheduling, use the rescheduling device to select related services with high affinity values ​​recorded in the call link topology diagram of the call link data collection and recording device as target services. Specifically, all services associated with the current service instance are sorted from highest to lowest affinity value, and the associated service with the highest affinity value is selected as the target service. The target service is one that has a high affinity with the service instance that triggered the rescheduling operation. Therefore, when it is determined that the current service instance has triggered a container rescheduling operation, the target service is determined based on the affinity value. Before determining the associated service with the highest affinity value to the service instance as the target service from the call link topology diagram when the service instance triggers a container rescheduling operation, the module further includes: collecting call data from each service and generating a call link topology diagram between the services based on the call data. Understandably, the process involves collecting call data for each service instance using a service call chain collection device, and generating call data for each service based on this data. Specifically, since each service contains multiple service instances, the collection of call data for each service instance is achieved by recording and statistically analyzing the call data of that service. Based on the call data of each service, an internal service call topology diagram is generated, which essentially draws the traffic topology relationships of each microservice component in the cloud-native application. All services are then paired and combined, and these combinations are stored in a relational database to record the close relationships between services. For example, call chain data and graph relationships are recorded and saved in Elasticsearch. The process involves drawing the traffic topology relationships of each microservice component based on the call data, and generating a call chain topology diagram carrying close relationship values ​​between services. Specifically, the process of generating the call chain topology diagram carrying close relationship values ​​between services also includes recording the call frequency between services and generating close relationship values ​​between services based on the call frequency. Understandably, when a new access request is generated, the corresponding service associated with the access request is identified, and the affinity value between the corresponding services is increased. For example, the traffic topology relationship of each microservice component is drawn based on the call data, and then a call chain topology diagram is generated based on the traffic topology relationship. The affinity relationship between each pair of services in the call chain topology diagram is recorded in a relational database in a combined manner, and the affinity value is incremented each time a call request occurs.

[0045] Therefore, this application discloses a container rescheduling method, comprising: when a service instance triggers a container rescheduling operation, determining the associated service with the highest affinity value to the service instance as the target service from the call chain topology graph; determining whether both the service instance and the target service perform container rescheduling operations to obtain a corresponding determination result; if the determination result is that both perform container rescheduling operations, then using the destination node to perform container rescheduling on the service instance and the target service; if the determination result is not that both perform container rescheduling operations, then using the compute node where the target service is located as the destination node to perform container rescheduling on the service instance. It can be seen that when a container rescheduling operation is triggered, based on the actual call chain data between microservices in a modern microservice architecture application, associated services are determined, and then services with actual call relationships are prioritized to call compute nodes with the same or similar physical / network topology, reducing network access latency between services, increasing throughput, and improving application performance.

[0046] In some specific embodiments, the container rescheduling device includes: The topology graph generation module is used to collect call data from various services and generate a call chain topology graph between the various services based on the call data.

[0047] In some specific embodiments, the container rescheduling device includes: The service activation unit is used to deploy the description declarations containing resource declarations, deployment order declarations, and workload type declarations of cloud-native applications, and to enable service governance for the cloud-native applications.

[0048] In some specific embodiments, the topology graph generation module includes: The topology graph generation unit is used to draw the traffic topology relationship of each microservice component based on the call data, and generate a call chain topology graph carrying the affinity value between each service based on the traffic topology relationship.

[0049] In some specific embodiments, the container rescheduling device includes: A data generation unit is used to parse cloud-native applications to obtain the various microservice components of the cloud-native applications; A service governance traffic component is injected into the microservice component to record service traffic and generate basic data for accessing and calling data.

[0050] In some specific embodiments, the container rescheduling device includes: The relationship value generation unit is used to record the call frequency between various services and generate a closeness relationship value between various services based on the call frequency.

[0051] In some specific embodiments, the container rescheduling device includes: The relationship value increment unit is used to determine the corresponding service associated with the access request when a new access request is generated, and to increment the affinity value between the corresponding services.

[0052] Furthermore, embodiments of this application also disclose an electronic device, Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0053] Figure 5 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the container rescheduling method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0054] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0055] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0056] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0057] The operating system 221 manages and controls the various hardware devices and computer programs 222 on the electronic device 20 to enable the processor 21 to perform calculations and processing on the massive amounts of data 223 in the memory 22. The operating system 221 can be Windows Server, Netware, Unix, Linux, etc. The computer program 222, in addition to including a computer program capable of performing the container rescheduling method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, may further include computer programs capable of performing other specific tasks. The data 223 may include data received by the electronic device from external devices, as well as data collected by its own input / output interface 25.

[0058] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed container rescheduling method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0059] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0060] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in connection with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described functions using different methods for each specific application, but such implementation should not be considered beyond the scope of this application. The steps of the methods or algorithms described in connection with the embodiments disclosed herein can be implemented directly in hardware, software modules executed by a processor, or a combination of both. Software modules can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art.

[0061] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0062] The above provides a detailed description of the container rescheduling method, apparatus, device, and storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A container rescheduling method, characterized in that, include: When a service instance triggers a container rescheduling operation, the associated service with the highest affinity value to the service instance is determined from the call chain topology graph as the target service. Determine whether both the service instance and the target service have undergone container rescheduling operations to obtain the corresponding determination result; If the determination result is that container rescheduling operation is performed on both, then the service instance and the target service are rescheduled using the destination node. If the judgment result is not that all containers are rescheduled, then the compute node where the target service is located is used as the destination node, and the service instance is rescheduled. Before determining the service with the highest affinity value to the service instance as the target service from the call chain topology graph when a service instance triggers a container rescheduling operation, the process includes: collecting call data for each service instance through a service call chain collection device; collecting call data for the corresponding service by recording and statistically analyzing the call data for each service instance; drawing the traffic topology relationship of each microservice component based on the service call data; and generating a call chain topology graph carrying affinity values ​​between each service based on the traffic topology relationship. Each point in the call chain topology graph is combined to record the affinity relationship between each pair of services in a relational database. Determining whether both the service instance and the target service have undergone container rescheduling includes: determining whether both services have undergone rescheduling; the determination condition is whether the target service was manually rescheduled or triggered by a fault restart.

2. The container rescheduling method according to claim 1, characterized in that, Before collecting call data from various services, the process also includes: Deploy the descriptive declarations that include resource declarations, deployment order declarations, and workload type declarations for cloud-native applications, and enable service governance for the cloud-native applications.

3. The container rescheduling method according to claim 2, characterized in that, Before deploying the description declaration containing the resource declaration, deployment order declaration, and workload type declaration of cloud-native applications, the following is also included: Analyze the cloud-native application to obtain its various microservice components; A service governance traffic component is injected into the microservice component to record service traffic and generate basic data for accessing and calling data.

4. The container rescheduling method according to claim 1, characterized in that, The process of generating a call chain topology graph carrying the affinity values ​​between various services based on the traffic topology relationship also includes: Record the call frequency between each service, and generate a closeness value between each service based on the call frequency.

5. The container rescheduling method according to any one of claims 1 to 4, characterized in that, Also includes: When a new access request is generated, the corresponding service associated with the access request is identified, and the affinity value between the corresponding services is increased.

6. A container rescheduling device, characterized in that, include: The service determination module is used to determine the associated service with the highest affinity value to the service instance from the call chain topology graph when a service instance triggers a container rescheduling operation. The result judgment module is used to determine whether both the service instance and the target service have undergone container rescheduling operations, so as to obtain the corresponding judgment result. The first container scheduling module is used to perform container rescheduling on the service instance and the target service using the destination node if the judgment result is that both should be rescheduled. The second container scheduling module is used to perform container rescheduling on the service instance if the judgment result is not that all container rescheduling operations are performed. Before determining the service with the highest affinity value to the service instance as the target service from the call chain topology graph when a service instance triggers a container rescheduling operation, the process includes: collecting call data for each service instance through a service call chain collection device; collecting call data for the corresponding service by recording and statistically analyzing the call data for each service instance; drawing the traffic topology relationship of each microservice component based on the service call data; and generating a call chain topology graph carrying affinity values ​​between each service based on the traffic topology relationship. Each point in the call chain topology graph is combined to record the affinity relationship between each pair of services in a relational database. Determining whether both the service instance and the target service have undergone container rescheduling includes: determining whether both services have undergone rescheduling; the determination condition is whether the target service was manually rescheduled or triggered by a fault restart.

7. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the container rescheduling method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, Used to store computer programs; wherein, when the computer programs are executed by a processor, they implement the steps of the container rescheduling method as described in any one of claims 1 to 5.

Images