Kubernetes elastic capacity expansion and contraction method and device based on traffic topology

Abstract

The invention provides a Kubernetes elastic capacity expansion and contraction method and device based on traffic topology. The method comprises the following steps: acquiring traffic topology elastic rule information and interface request quantity data configured by each micro-service; querying and calculating a service proportion of the interface request quantity data in link tracking by utilizing the link tracking according to the traffic topology elastic rule information and the interface request quantity data; and according to the service proportion, calculating a capacity expansion and contraction proportion, and carrying out capacity expansion and contraction processing on the corresponding micro-service. In the scheme provided by the embodiment of the invention, the flow distribution and the service load condition on the whole link are analyzed through the flow topology, the hotspot service in the link is identified, and the hotspot service is preferentially expanded, so that the performance of the whole system can be effectively improved, the bottleneck transfer can be avoided, the overall availability of the micro service can be ensured, and the user experience can be improved. The optimal allocation of resources is ensured, a more comprehensive and accurate capacity expansion and contraction decision is made accordingly, the business fluctuation can be flexibly dealt with, the resource allocation is optimized, and the operation and maintenance management is simplified.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a Kubernetes elastic scaling method, device, equipment, and computer-readable storage medium based on traffic topology. Background Art

[0002] Microservices are a popular architectural style for Internet applications at this stage; a monolithic application can be split into multiple small independent units, each of which provides a single and well-defined function, and they communicate with each other using synchronous or asynchronous technologies. Software containers are very suitable for the field of microservices and can effectively simplify the deployment and runtime management of microservices. Currently, the most popular cloud-native container orchestration framework is Kubernetes, which can automate container configuration, management, and communication.

[0003] The existing scaling strategies in Kubernetes (k8s) are usually implemented for a single service, which has certain limitations in the microservice architecture. In the microservice architecture, the call relationship between services is intricate, forming a traffic topology link. When a service needs to be expanded due to a surge in traffic, if the traffic distribution and load of the entire link are not considered, only expanding a single service may lead to resource waste or bottleneck transfer. In the microservice system, a request may pass through multiple services, and the existing scaling strategies fail to consider the service call relationship and traffic demand on the entire traffic topology link. Its defects are mainly reflected in:

[0004] K8s itself and its related derivative strategies all focus on the number of services themselves, without considering the dependencies between services, which may lead to poor expansion effects.

[0005] There is a lack of link-level scaling decision-making basis, and it is impossible to perform intelligent expansion based on the entire traffic topology.

[0006] Scaling decisions are usually based on historical data and forecasting models, which have limited accuracy and long adjustment cycles. Summary of the invention

[0007] Multiple aspects of the present application provide a Kubernetes elastic scaling method, apparatus, device and computer-readable storage medium based on traffic topology, which can intelligently adjust the number of instances of each service on the link according to the traffic conditions of the entire link and the service topology relationship of the entire link to achieve optimal resource utilization and maximize application performance.

[0008] To achieve the above technical effects, one aspect of the present application provides a Kubernetes elastic scaling method based on traffic topology, including:

[0009] Obtain the traffic topology elasticity rule information and interface request volume data configured for each microservice;

[0010] According to the traffic topology elasticity rule information and the interface request volume data, using link tracking to query and calculate the service ratio of the interface request volume data in the link tracking;

[0011] The expansion and contraction ratio is calculated according to the service ratio, and the corresponding microservices are expanded and contracted.

[0012] According to a preferred embodiment of the present invention, the obtaining of traffic topology elasticity rule information and interface request volume data configured for each microservice further includes:

[0013] Get the base pod number, request limit, and interface request data for each microservice configuration.

[0014] According to a preferred embodiment of the present invention, the querying and calculating the service proportion of the interface request volume data in the link tracking using the link tracking according to the traffic topology elasticity rule information and the interface request volume data further includes:

[0015] Obtain and record the request volume of each interface of the microservice;

[0016] Use link tracking to query the link call relationship tree corresponding to each interface service;

[0017] The request volume data of each microservice in the link call relationship tree is obtained, and the proportion of the request volume of each interface to the request volume of the microservice is calculated to obtain the interface request volume ratio.

[0018] According to a preferred embodiment of the present invention, the step of calculating the expansion and contraction ratio according to the service ratio and performing expansion and contraction processing on the corresponding microservices further includes:

[0019] Calculate the expansion and contraction ratio of each microservice in the link call relationship tree in turn;

[0020] It is determined whether the scaling ratio meets the preset scaling requirements, and the microservices that meet the scaling requirements are scaled according to the scaling ratio.

[0021] According to a preferred embodiment of the present invention, sequentially calculating the expansion and contraction ratio of each microservice in the link call relationship tree further includes:

[0022] According to the formula: scaling ratio = (total number of requests / upper limit of the number of requests that can be accepted under the baseline number) / (current number of pods / base number of pods), calculate the scaling ratio of the first microservice in the link call relationship tree;

[0023] The scaling ratio of each microservice in the link call relationship tree is calculated according to the scaling ratio of the first microservice.

[0024] According to a preferred embodiment of the present invention, the step of determining whether the scaling ratio meets the preset scaling requirement and scaling the microservices that meet the scaling requirement according to the scaling ratio further includes:

[0025] When the expansion / contraction ratio is greater than 1, expansion is performed; when the expansion / contraction ratio is less than 0.5, contraction is performed; otherwise, no processing is performed;

[0026] Kubernetes adjusts the number of base pods of microservices according to the expansion and contraction ratio to achieve expansion and contraction.

[0027] Another aspect of the present application provides a Kubernetes elastic expansion and contraction device based on traffic topology, including:

[0028] The data acquisition module is used to obtain the traffic topology elasticity rule information and interface request volume data configured for each microservice;

[0029] A link tracking module, used to query and calculate the service proportion of the interface request volume data in the link tracking according to the traffic topology elasticity rule information and the interface request volume data by using link tracking;

[0030] The expansion and contraction processing module is used to calculate the expansion and contraction ratio according to the service ratio and perform expansion and contraction processing on the corresponding microservices.

[0031] Another aspect of the present application provides an electronic device for a Kubernetes elastic expansion and contraction method based on traffic topology, the device comprising:

[0032] at least one processor; and

[0033] a memory communicatively connected to the at least one processor; wherein,

[0034] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method described above.

[0035] In another aspect of the present application, a computer-readable storage medium is provided, on which computer program instructions are stored. The computer program instructions can be executed by a processor to implement the above method.

[0036] Another aspect of the present application provides a computer program product, including a computer program, wherein the computer program implements the above method when executed by a processor.

[0037] In the solution provided in the embodiment of the present application, the traffic distribution and service load on the entire link are analyzed through traffic topology, hot services in the link are identified, and these hot services are expanded preferentially, which can effectively improve the performance of the entire system, avoid the transfer of bottlenecks, ensure the overall availability of microservices, and ensure the optimal allocation of resources. Based on this, more comprehensive and accurate expansion and contraction decisions can be made, which can flexibly respond to business fluctuations, optimize resource allocation, and simplify operation and maintenance management. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present application, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0039] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0040] Figure 1 A flow chart of a Kubernetes elastic expansion and contraction method based on traffic topology provided in one embodiment of the present application;

[0041] Figure 2 A schematic diagram of the principle of a Kubernetes elastic expansion and contraction method based on traffic topology provided in one embodiment of the present application;

[0042] Figure 3 A schematic diagram of a Kubernetes elastic expansion and contraction device based on traffic topology provided in one embodiment of the present application;

[0043] Figure 4 The present invention is a schematic diagram of the structure of a device suitable for implementing the solution in the embodiment of the present application.

[0044] The same or similar reference numerals in the drawings represent the same or similar components. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, 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 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 are within the scope of protection of this application.

[0046] In a typical configuration of the present application, the terminal and the equipment of the service network each include one or more processors (CPU), input / output interface, network interface and memory.

[0047] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0048] Computer readable media include permanent and non-permanent, removable and non-removable media, and can be implemented by any method or technology to store information. Information can be computer program instructions, data structures, modules of programs or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0049] In actual scenarios, the execution subject of the method can be a user device, or a device formed by integrating a user device and a network device through a network, or an application running on the above device. The user device includes but is not limited to various terminal devices such as computers, mobile phones, tablet computers, smart watches, and bracelets. The network device includes but is not limited to network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, which can be used to implement some processing functions when setting an alarm. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing, where cloud computing is a type of distributed computing, a virtual computer composed of a group of loosely coupled computer sets.

[0050] The invention relates to a Kubernetes (k8s) elastic scaling method based on traffic topology. The current scaling strategy in Kubernetes is usually carried out for a single service, which has certain limitations in the microservice architecture. In a microservice system, a request may pass through multiple services, and the existing scaling strategy fails to consider the service call relationship and traffic demand on the entire traffic topology link. Therefore, the present invention aims to provide a method that can automatically perform elastic scaling based on the entire traffic topology link, so as to more effectively utilize resources and improve the performance and reliability of applications.

[0051] Figure 1 A flowchart of a Kubernetes elastic expansion and contraction method based on traffic topology provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the Kubernetes elastic expansion and contraction method based on traffic topology includes at least the following steps:

[0052] S101. Obtain traffic topology elasticity rule information and interface request volume data configured for each microservice.

[0053] Specifically, the traffic topology elasticity rule information configured for each microservice includes: the cardinality pod number, request limit, and interface request data configured for each microservice. For example, in a system including microservice A, microservice B, microservice C, and microservice D, obtain the cardinality pod number, interface number, and request limit of each interface of these four microservices respectively.

[0054] S102: According to the traffic topology elasticity rule information and the interface request volume data, link tracking is used to query and calculate the service proportion of the interface request volume data in link tracking.

[0055] Specifically, the following steps are included: S1021, obtaining and recording the request volume of each interface of the microservice.

[0056] When a microservice receives a request, the current request volume for each interface of the microservice is obtained.

[0057] S1022. Query the link call relationship tree corresponding to each interface service by using link tracking.

[0058] For example, Figure 2 A schematic diagram of the principle of a Kubernetes elastic expansion and contraction method based on traffic topology provided in an embodiment of the present application. HPA (Horizontal Pod Autoscaler) is a key component in Kubernetes, which has an automatic expansion mechanism for automatically adjusting the number of Pods according to the CPU or memory usage of the Pods. HPA monitors the average resource usage of the Pods and dynamically adjusts the number of replicas to optimize resource utilization and system performance.

[0059] like Figure 2 As shown in the figure, HPA uses link tracking to query microservice A, microservice B, microservice C, microservice D and three links, among which:

[0060] Microservice A provides three interfaces: A1, A2, and A3;

[0061] Microservice B provides two interfaces, B1 and B2;

[0062] Microservice C provides two interfaces, C1 and C2;

[0063] Microservice D provides an interface D1.

[0064] The first link tracking is - interface A1-microservice A-interface B1-microservice B-interface D1-microservice D;

[0065] The second link tracking is - interface A2-microservice A-interface B2-microservice B-interface C1-microservice C;

[0066] The third link tracking is - interface A3 - microservice A - interface C2 - microservice C.

[0067] This forms a link call relationship tree.

[0068] S1023. Obtain request volume data for each microservice in the link call relationship tree, and calculate the proportion of the request volume of each interface to the request volume of the microservice.

[0069] After obtaining the current interface request volume data of each microservice, the current interface request volume is calculated using the formula: current interface request volume / total number of requests of all interfaces of the microservice to calculate the ratio of the current interface request volume to the microservice request volume, and obtain the interface request volume ratio. For example, microservice B has two interfaces, B1 and B2, with request volumes of 51000 and 50000 respectively. 51000 / (51000+50000)=0.505 is calculated, that is, the request volume of interface B1 accounts for 0.505 of microservice B.

[0070] S103: Calculate the expansion and contraction ratio according to the service ratio, and perform expansion and contraction processing on the corresponding microservices.

[0071] Specifically, the following steps are included: S1031, sequentially calculating the expansion and contraction ratio of each microservice in the link call relationship tree.

[0072] The scaling ratio of the first microservice in the link call relationship tree is calculated using the formula: scaling ratio = (total number of requests / upper limit of the number of requests that can be accepted under the baseline number) / (current number of pods / base number of pods). For example, microservice A sets the base number of pods to 50, the upper limit of the number of requests for interface A1 is 50,000, and the hpa component continuously checks the traffic of interface A1 of microservice A. If the current number of requests is 51,000, the scaling ratio is calculated as: (51,000 / 50,000) / (50 / 50) = 1.02; if the current number of requests is 5,000, the scaling ratio is calculated as: (5,000 / 50,000) / (50 / 50) = 0.1.

[0073] The scaling ratio of each microservice in the link call relationship tree is calculated according to the scaling ratio of the first microservice, and the scaling ratio required by the first microservice is multiplied by the proportion of interface requests of each microservice in the link to obtain the scaling ratio of each microservice in the link call relationship tree.

[0074] For example, for the first link in step S1022 - interface A1 - microservice A - interface B1 - microservice B - interface D1 - microservice D, microservice B has two interfaces B1 and B2, and the request volumes of interfaces B1 and B2 are 51,000 and 50,000 respectively. It is calculated that the proportion of interface B1 to the request volume of microservice B is 0.505. When the proportion of microservice A that needs to be expanded is 0.02, the proportion of microservice B that needs to be expanded is 0.505*0.02=0.01.

[0075] S1032: Determine whether the scaling ratio meets the preset scaling requirement, and perform scaling processing on the microservices that meet the scaling requirement according to the scaling ratio.

[0076] Set the expansion / contraction ratio threshold as needed. For example, when the expansion / contraction ratio is greater than 1, expansion is performed, and when the expansion / contraction ratio is less than 0.5, contraction is performed. Otherwise, no processing is performed.

[0077] For example, when the scaling ratio of interface A1 is 1.02>1, microservice A needs to scale up by 0.02;

[0078] Kubernetes adjusts the number of base pods of microservices according to the expansion and contraction ratio to achieve expansion and contraction.

[0079] For the first link in step S1022, microservice A needs to be expanded by 50*0.02=1 pod; the cardinality pod number of microservice B is obtained, for example, 40, then according to the proportion of microservice B that needs to be expanded 0.01 calculated in step S1031, microservice B needs to be expanded by 40*0.01=1 pod (rounded up); then for microservice D in the first link, microservice D has only one interface D1, the current request volume of interface D1 is obtained, 51000, and the proportion of interface request volume is calculated to be 1. In the scenario where the expansion ratio of microservice A is 0.02, the proportion of microservice D that needs to be expanded is 1*0.02=0.02, and the cardinality pod number of microservice D is obtained, for example, 1000, then 1000*0.02=20 pods need to be expanded.

[0080] For the second link in step S1022: - Interface A2 - Microservice A - Interface B2 - Microservice B - Interface C1 - Microservice C, first obtain the upper limit of the request volume of the current interface A2 of microservice A, which is 50,000. The number of base pods is 50, and the current request volume is 52,000. Calculate the scaling ratio: (52,000 / 50,000) / (50 / 50)=1.04>1. The capacity needs to be expanded by 0.04. Microservice A needs to expand by 50*0.04=2 pods. According to microservice A and interface A2, the corresponding Link call relationship tree, deeply traverse the entire tree structure, microservice B has two interfaces B1 and B2, and the request volume is 51000 and 50000 respectively. 50000 / (51000+50000)=0.495 is calculated, that is, the request volume of interface B1 accounts for 0.495 of microservice B; when the proportion of microservice A to be expanded is 0.04, the proportion of microservice B to be expanded is 0.495*0.04=0.0198; therefore, microservice B needs to expand 40*0.0198=1 pod (rounded up).

[0081] Then, for microservice C in the second link, microservice C has only one interface C1. The current request volume of interface C1 is 52,000, and the interface request volume ratio is calculated to be 1. In the scenario where the expansion ratio of microservice A is 0.04, the ratio of microservice C that needs to be expanded is 1*0.04=0.04. The cardinality pod number of microservice C is obtained, for example, it is 1500, then 1500*0.04=60 pods need to be expanded.

[0082] For the same microservice in different links, the expansion and contraction processing results of different interfaces are added together to obtain the final processing result of the microservice. For example, interface A1 of microservice A needs to expand 1 pod for microservice A, and interface A2 needs to expand 2 pods for microservice A. In the end, microservice A needs to expand 3 pods; interface B1 of microservice B needs to expand 1 pod for microservice B, and interface B2 needs to expand 1 pod for microservice B. In the end, microservice B needs to expand 2 pods.

[0083] If the current request volume of A1 in the first link is 5000, the expansion ratio is calculated as follows: (5000 / 50000) / (50 / 50)=0.1<0.5, and the reduction ratio of microservice A is 0.4, so microservice A needs to reduce 50*0.4=20 pods.

[0084] The request volumes of interfaces B1 and B2 are 5000 and 50000 respectively. The calculated ratio of interface B1 to the request volume of microservice B is (5000) / (5000+50000)=0.091. In the scenario where microservice A needs to be scaled down by 0.4, the ratio that microservice B needs to be scaled down is 0.091*0.4=0.0364. The cardinality pod number of microservice B is obtained. For example, if it is 40, it needs to be scaled down by 40*0.0 364 = 1 pod (rounded down); then for microservice D in the link, microservice D has only one interface D1, and the request volume of interface D1 is obtained as 5000. The interface request volume ratio is calculated as 1. When the scale-down ratio of microservice A is 0.4, the scale-down ratio of microservice D is 1*0.4=0.4. The cardinality pod number of microservice D is obtained, for example, 1000, then 1000*0.4=400 pods need to be scaled down.

[0085] If the current request volume of A2 in the second link is 5500, the expansion ratio is calculated as follows: (5500 / 50000) / (50 / 50)=0.11<0.5, and the reduction ratio of microservice A is 0.39. Microservice A needs to reduce the number of pods by 50*0.39=19 (rounded down).

[0086] The request volumes of interfaces B1 and B2 are 5000 and 50000 respectively. The proportion of interface B2 to the request volume of microservice B is calculated to be (50000) / (5000+50000)=0.909. In the scenario where microservice A needs to be scaled down by 0.39, the proportion of microservice B that needs to be scaled down is 0.909*0.39=0.355. The cardinality pod number of microservice B is obtained. For example, if it is 40, it needs to be scaled down by 40*0.3 55=14 pods (rounded down); then for microservice C in the link, microservice C has only one interface C1. The request volume of interface C1 is 5000, and the interface request volume ratio is calculated to be 1. When the shrinking ratio of microservice A is 0.39, the shrinking ratio of microservice C is 1*0.39=0.39. The cardinality pod number of microservice C is obtained, for example, 800, then 800*0.39=312 pods need to be shrunk.

[0087] Interface A1 of microservice A needs to shrink 20 pods for microservice A, and interface A2 needs to shrink 19 pods for microservice A. In the end, microservice A needs to shrink 39 pods. Interface B1 of microservice B needs to shrink 1 pod for microservice B, and interface B2 needs to shrink 14 pods for microservice B. In the end, microservice B needs to shrink 15 pods.

[0088] The method for scaling the third link is the same as that for the first and second links, and will not be repeated here.

[0089] The link call relationship tree is traversed in a loop until all microservices in the link call relationship tree are scaled up or down.

[0090] In the solution provided by the embodiment of the present method, the service call topology is obtained by using routing rules and link tracking technology, and the service that needs to be expanded is decided based on the topological relationship, which can effectively avoid bottleneck transfer and complex expansion judgment decisions in microservices. The service on the entire request link is expanded or reduced through the traffic topology to ensure the overall availability of the microservice. This is because the traffic topology analysis can reveal the bottleneck on the entire link, give priority to the hot services and bottlenecks on the link, ensure the optimal allocation of resources, and make more comprehensive and accurate expansion and reduction decisions based on this.

[0091] Scaling capacity based on request ratio rather than resource usage. Resource usage may change with changes in business, demand, technical literacy of R&D personnel and technical implementation, while the request ratio is relatively fixed when the business form does not change significantly. Scaling capacity based on ratio rather than specific quantity: By introducing proportional scaling instead of specific values ​​when scaling capacity, the number of service instances can be dynamically adjusted to flexibly respond to business fluctuations, optimize resource allocation, and simplify operation and maintenance management, because resource management is based on actual business needs rather than fixed resource usage.

[0092] Figure 3 A schematic diagram of a Kubernetes elastic expansion and contraction device based on traffic topology provided in an embodiment of the present application is shown in FIG. Figure 3 As shown, the device comprises:

[0093] The data acquisition module 11 is used to obtain the traffic topology elasticity rule information and interface request volume data configured for each microservice;

[0094] The link tracking module 22 is used to query and calculate the service proportion of the interface request volume data in the link tracking according to the traffic topology elasticity rule information and the interface request volume data by using the link tracking;

[0095] The expansion and contraction processing module 33 is used to calculate the expansion and contraction ratio according to the service ratio and perform expansion and contraction processing on the corresponding microservices.

[0096] The above-mentioned device can execute the Kubernetes elastic scaling method based on traffic topology in the aforementioned embodiment, wherein the data acquisition module 11 executes step S101 to obtain the base pod number, request quantity upper limit and interface request quantity data of each microservice configuration.

[0097] The link tracking module 22 executes step S102, including: a request volume acquisition unit, used to obtain and record the request volume of each interface of the microservice; a link tracking unit, used to use link tracking to query the link call relationship tree corresponding to each interface service; an interface request volume ratio calculation unit, used to obtain the request volume data of each microservice in the link call relationship tree, calculate the ratio of the request volume of each interface to the request volume of the microservice, and obtain the interface request volume ratio.

[0098] The scaling processing module 33 executes step S103, including a scaling ratio calculation unit, which is used to calculate the scaling ratio of each microservice in the link call relationship tree in turn, and calculate the scaling ratio of the first microservice in the link call relationship tree according to the formula: scaling ratio = (total number of requests / upper limit of the number of requests that can be accepted under the baseline number) / (current number of pods / base number of pods); calculate the scaling ratio of each microservice in the link call relationship tree according to the scaling ratio of the first microservice; the scaling processing unit is used to determine whether the scaling ratio meets the preset scaling requirements, and scale the microservices that meet the scaling requirements according to the scaling ratio. When the scaling ratio is greater than 1, expansion is performed, and when the scaling ratio is less than 0.5, reduction is performed, otherwise, no processing is performed; scaling is achieved by adjusting the base pod number of microservices according to the scaling ratio through Kubernetes.

[0099] Based on the same inventive concept, an electronic device is also provided in an embodiment of the present application, and the method corresponding to the electronic device may be the Kubernetes elastic scaling method based on traffic topology in the aforementioned embodiment, and its principle of solving the problem is similar to that of the method. The electronic device provided in an embodiment of the present application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the methods and / or technical solutions of the aforementioned multiple embodiments of the present application.

[0100] The electronic device may be a user device, or a device formed by integrating a user device and a network device through a network, or may be an application running on the above device. The user device includes but is not limited to various terminal devices such as computers, mobile phones, tablet computers, smart watches, and bracelets. The network device includes but is not limited to network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, which can be used to implement some processing functions when setting an alarm. Here, the cloud is composed of a large number of hosts or network servers based on cloud computing, where cloud computing is a type of distributed computing, a virtual computer composed of a group of loosely coupled computer sets.

[0101] Figure 4 The structure of a device suitable for implementing the method and / or technical solution in the embodiment of the present application is shown, and the device 1200 includes a central processing unit (CPU, Central Processing Unit) 1201, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM, Read Only Memory) 1202 or the program loaded from the storage part 1208 to the random access memory (RAM, Random Access Memory) 1203. In RAM1203, various programs and data required for system operation are also stored. CPU 1201, ROM 1202 and RAM 1203 are connected to each other through bus 1204. Input / output (I / O, Input / Output) interface 1205 is also connected to bus 1204.

[0102] The following components are connected to the I / O interface 1205: an input section 1206 including a keyboard, a mouse, a touch screen, a microphone, an infrared sensor, etc.; an output section 1207 including a cathode ray tube (CRT), a liquid crystal display (LCD), an LED display, an OLED display, etc., and a speaker, etc.; a storage section 1208 including one or more computer-readable media such as a hard disk, an optical disk, a magnetic disk, a semiconductor memory, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1209 performs communication processing via a network such as the Internet.

[0103] In particular, the methods and / or embodiments in the embodiments of the present application may be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program code for executing the method shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 1201, the above functions defined in the method of the present application are executed.

[0104] Another embodiment of the present application further provides a computer-readable storage medium having computer program instructions stored thereon, wherein the computer program instructions can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of the present application described above.

[0105] Specifically, the present embodiment may adopt any combination of one or more computer-readable media. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, device, or device.

[0106] Computer readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer readable signal media may also be any computer readable medium other than a computer readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0107] The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0108] Computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

[0109] The flow chart or block diagram in the accompanying drawings shows the possible architecture, function and operation of the equipment, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated system for hardware that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0110] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0111] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or page 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 an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0112] 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 network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0113] 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 hardware plus software functional units.

[0114] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform some steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), disk or optical disk and other media that can store program codes.

[0115] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

[0116] In addition, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices stated in a device claim can also be implemented by one unit or device through software or hardware. The words first, second, etc. are used to indicate names, and do not indicate any particular order.

Claims

1. A Kubernetes elastic expansion and contraction method based on traffic topology, characterized in that: include: Obtain the traffic topology elasticity rule information and interface request volume data configured for each microservice; According to the traffic topology elasticity rule information and the interface request volume data, using link tracking to query and calculate the service ratio of the interface request volume data in the link tracking; The expansion and contraction ratio is calculated according to the service ratio, and the corresponding microservices are expanded and contracted.

2. According to claim 1, the Kubernetes elastic expansion and contraction method based on traffic topology is characterized in that: The obtaining of the traffic topology elasticity rule information and interface request volume data configured for each microservice further includes: Get the base pod number, request limit, and interface request data for each microservice configuration.

3. The Kubernetes elastic expansion and contraction method based on traffic topology according to claim 2 is characterized in that: The querying and calculating the service proportion of the interface request volume data in the link tracking using the link tracking according to the traffic topology elasticity rule information and the interface request volume data further includes: Obtain and record the request volume of each interface of the microservice; Use link tracking to query the link call relationship tree corresponding to each interface service; The request volume data of each microservice in the link call relationship tree is obtained, and the proportion of the request volume of each interface to the request volume of the microservice is calculated to obtain the interface request volume ratio.

4. The Kubernetes elastic expansion and contraction method based on traffic topology according to claim 3 is characterized in that: The calculating the expansion and contraction ratio according to the service ratio and performing expansion and contraction processing on the corresponding microservices further includes: Calculate the expansion and contraction ratio of each microservice in the link call relationship tree in turn; It is determined whether the scaling ratio meets the preset scaling requirements, and the microservices that meet the scaling requirements are scaled according to the scaling ratio.

5. According to claim 4, the Kubernetes elastic expansion and contraction method based on traffic topology is characterized in that: The sequentially calculating the expansion and contraction ratio of each microservice in the link call relationship tree further includes: According to the formula: scaling ratio = (total number of requests / upper limit of the number of requests that can be accepted under the baseline number) / (current number of pods / base number of pods), calculate the scaling ratio of the first microservice in the link call relationship tree; The scaling ratio of each microservice in the link call relationship tree is calculated according to the scaling ratio of the first microservice.

6. According to claim 4, the Kubernetes elastic expansion and contraction method based on traffic topology is characterized in that: The determining whether the scaling ratio meets the preset scaling requirement, and scaling the microservices that meet the scaling requirement according to the scaling ratio further includes: When the expansion / contraction ratio is greater than 1, expansion is performed; when the expansion / contraction ratio is less than 0.5, contraction is performed; otherwise, no processing is performed; Kubernetes adjusts the number of base pods of microservices according to the expansion and contraction ratio to achieve expansion and contraction.

7. A Kubernetes elastic expansion and contraction device based on traffic topology, characterized in that: include: The data acquisition module is used to obtain the traffic topology elasticity rule information and interface request volume data configured for each microservice; A link tracking module, used to query and calculate the service proportion of the interface request volume data in the link tracking according to the traffic topology elasticity rule information and the interface request volume data by using link tracking; The expansion and contraction processing module is used to calculate the expansion and contraction ratio according to the service ratio and perform expansion and contraction processing on the corresponding microservices.

8. An electronic device using a Kubernetes elastic expansion and contraction method based on traffic topology, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 6.

9. A computer readable medium having computer program instructions stored thereon, characterized in that: The computer program instructions can be executed by a processor to implement the method according to any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images