A service processing method, device, equipment and medium are provided

By creating multiple node groups in a Kubernetes cluster and acquiring computing power, deploying applications on different architectures according to the replication requirements of cloud-native applications, and performing computing power equivalence conversion during operation, the problem of hybrid orchestration and computing power equivalence elastic scaling across processor architectures is solved, thus ensuring service quality.

CN115543543BActive Publication Date: 2026-05-29JINAN INSPUR DATA TECH CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
JINAN INSPUR DATA TECH CO LTD
Filing Date
2022-11-04
Publication Date
2026-05-29

Smart Images

  • Figure CN115543543B_ABST
    Figure CN115543543B_ABST
Patent Text Reader

Abstract

The application discloses an application service processing method and device, equipment and medium, and relates to the technical field of cloud services. A plurality of node groups of different architectures are created in a k8s cluster, and the computing power of each node group is obtained. The application is deployed on a plurality of current node groups according to the replica requirement of the application under different architectures, and a service corresponding to the number of replicas is created. The running condition of the application is monitored, and it is judged whether the preset condition is met. If not, the target number of replicas is obtained by equivalent replica calculation according to the computing power of the current node group, the number of replicas and the computing power of the target node group. Service replicas are created in the target node group according to the target number of replicas to provide equivalent services. The above scheme obtains the computing power of each architecture node group in advance. When the application service deployed on one architecture does not meet the preset condition, service replicas are created on other architectures according to the equivalent conversion method of the computing power, thereby preventing service degradation and reducing the difficulty of application cross-processor architecture deployment.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of cloud service technology, and in particular to an application service processing method, apparatus, device and medium. Background Technology

[0002] With the introduction of strategies such as "Internet Plus" and "New Infrastructure," open-source technology has served as a "nutrient solution," and various industries have witnessed a surge in IT infrastructure development through native applications such as microservices, containers, iteration, DevOps (Development and Operations), and Artificial Intelligence for IT Operations (AIOps). The adoption of cloud computing for centralized IT infrastructure development, providing out-of-the-box cloud services such as databases and middleware, has become increasingly popular, significantly reducing the cost of IT infrastructure development and making it more convenient for end-users to access IT services.

[0003] With the advancement of information technology application innovation and the diversification of processors, the "one cloud, multiple chips" scenario, where servers with multiple architectures coexist in the container cluster environment of cloud data centers, is becoming increasingly common. However, traditional cloud-native application orchestration controllers cannot achieve hybrid orchestration of applications across processor architecture servers and equivalent elastic scaling of computing power, which increases the difficulty for users to use multiple architectures.

[0004] Given the above issues, how to reduce the service level differences between different services for cloud-native applications and improve the service stability of applications is an urgent problem for technical personnel in this field to solve. Summary of the Invention

[0005] The purpose of this application is to provide an application service processing method, apparatus, device, and medium to reduce the service level differences between different services in cloud-native applications and improve the service stability of applications.

[0006] To address the aforementioned technical problems, this application provides an application service processing method applied to a Kubernetes cluster, the method comprising:

[0007] Multiple node groups are created in the Kubernetes cluster, and the computing power of each node group is obtained; wherein, the architecture of each node group is different.

[0008] Deploy the cloud-native application to multiple current node groups according to the replication requirements of the cloud-native application under different architectures, and create services with the corresponding number of replicas according to the replication requirements;

[0009] During the operation of the cloud-native application, the operation status of the cloud-native application is monitored and it is determined whether preset conditions are met;

[0010] If not, obtain the computing power of the target node group, and perform equivalent replica calculation based on the computing power of the current node group, the number of replicas, and the computing power of the target node group to obtain the target number of replicas;

[0011] Service replicas are created in the target node group according to the target number of replicas, so as to provide equivalent service provision for the cloud-native application through the service replicas.

[0012] Preferably, the step of creating multiple node groups in the Kubernetes cluster and obtaining the computing power of each node group includes:

[0013] Multiple initial node groups are created based on the architecture and configuration of each node in the Kubernetes cluster; wherein the architecture and configuration of each node in the initial node group are identical.

[0014] Obtain the computing power of each of the initial node groups;

[0015] The initial node groups with the same computing power are merged to generate multiple node groups.

[0016] Preferably, deploying the cloud-native application to multiple current node groups according to the replication requirements of the cloud-native application under different architectures includes:

[0017] Obtain the application description of the cloud-native application set by the user; wherein the application description includes resource type, architecture declaration, and architecture replica type;

[0018] The application description is parsed into multiple application description information based on the architecture replica type;

[0019] Each application description is rendered differently; wherein the architecture and the node group to which each application description belongs are different.

[0020] The cloud-native application is deployed to multiple eligible current node groups based on the architecture statement and the architecture replica type.

[0021] Preferably, monitoring the operation of the cloud-native application and determining whether preset conditions are met includes:

[0022] The operational status of the cloud-native application is monitored using a list-watch mechanism;

[0023] Based on the operational status, determine whether the application health of the cloud-native application meets the application declaration requirements;

[0024] If not, the preset conditions are not met, and the process proceeds to the step of acquiring the computing power of the target node group.

[0025] Preferably, the step of calculating equivalent replicas based on the computing power of the current node group, the number of replicas, and the computing power of the target node group includes:

[0026] Obtain the product of the computing power and the number of replicas of the current node group;

[0027] The quotient of the product and the computing power of the target node group is obtained to get the target number of replicas.

[0028] Preferably, creating service replicas in the target node group according to the target number of replicas includes:

[0029] The API Server creates service replicas in the target node group in a number equal to the target replica count.

[0030] Preferably, after providing the equivalent service provision of the cloud-native application through the service replica, the method further includes:

[0031] Output a notification message indicating that the equivalent service has been provided.

[0032] To address the aforementioned technical problems, this application also provides an application service processing device for use in a Kubernetes cluster, the device comprising:

[0033] A node group creation module is used to create multiple node groups in the Kubernetes cluster and obtain the computing power of each node group; wherein, each node group has a different architecture.

[0034] The application deployment module is used to deploy the cloud-native application to multiple current node groups according to the replication requirements of the cloud-native application under different architectures, and to create services with the corresponding number of replicas according to the replication requirements;

[0035] The monitoring and judgment module is used to monitor the operation of the cloud-native application and determine whether the preset conditions are met during the operation of the cloud-native application; if not, the equivalent replica calculation module is triggered.

[0036] The equivalent replica calculation module is used to obtain the computing power of the target node group, and perform equivalent replica calculation based on the computing power of the current node group, the number of replicas, and the computing power of the target node group to obtain the target number of replicas;

[0037] The service replica creation module is used to create service replicas in the target node group according to the target number of replicas, so as to provide equivalent service provision for the cloud-native application through the service replicas.

[0038] To address the aforementioned technical problems, this application also provides an application service processing device, comprising:

[0039] Memory, used to store computer programs;

[0040] A processor is used to implement the steps of the application service processing method described above when executing the computer program.

[0041] To address the aforementioned technical problems, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the application service processing method described above.

[0042] The application service processing method provided in this application involves creating multiple node groups in a Kubernetes cluster and acquiring the computing power of each node group. Each node group has a different architecture. The cloud-native application is deployed to multiple current node groups according to its replication requirements under different architectures, and services with the corresponding number of replicas are created based on these requirements. During the operation of the cloud-native application, its running status is monitored, and it is determined whether preset conditions are met. If not, the computing power of the target node group is acquired, and equivalent replication is calculated based on the computing power, replication count, and target node group's computing power to obtain the target number of replicas. Service replicas are created in the target node group based on the target number of replicas to provide equivalent services for the cloud-native application. Therefore, by knowing the computing power of each architecture node group in advance, when an application service deployed on one architecture fails due to not meeting preset conditions, service replicas are created on other architectures based on the equivalent computing power conversion, thereby ensuring the overall service quality of the application, preventing service degradation, and reducing the difficulty of deploying cloud-native applications across processor architectures.

[0043] In addition, this application embodiment also provides an application service processing device, equipment and medium, with the same effect as above. Attached Figure Description

[0044] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 A flowchart illustrating an application service processing method provided in this application embodiment;

[0046] Figure 2 A schematic diagram illustrating the cross-architecture cloud-native application service processing provided in the embodiments of this application;

[0047] Figure 3 A schematic diagram of an application service processing device provided in an embodiment of this application;

[0048] Figure 4 This is a schematic diagram of an application service processing device provided in an embodiment of this application. Detailed Implementation

[0049] 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 this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0050] The core of this application is to provide an application service processing method, apparatus, device, and medium.

[0051] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0052] Kubernetes (k8s) is a portable, scalable, open-source platform for managing containerized workloads and services, facilitating declarative configuration and automation. k8s boasts a large and rapidly growing ecosystem. k8s services, support, and tools are widely available.

[0053] A container is a portable, lightweight operating system-level virtualization technology. It uses namespaces to isolate different software runtime environments and creates a self-contained software runtime environment within an image, allowing containers to run easily anywhere. Because containers are small and start quickly, an application can be packaged within each container image. This one-to-one application image relationship offers many advantages. Containers are not tied to external infrastructure environments, perfectly solving the consistency problem from development to production. Containers are also more transparent than virtual machines, which facilitates monitoring and management, especially since the lifecycle of container processes is managed by the infrastructure. Since each application is encapsulated in a container, managing container deployments is equivalent to managing application deployments.

[0054] With the advancement of information technology application innovation and the diversification of processors, scenarios of multi-core servers with multiple architectures coexisting in cloud data center container cluster environments are becoming increasingly common. However, traditional cloud-native application orchestration controllers cannot achieve hybrid orchestration and equivalent elastic scaling of applications across servers with different processor architectures, thus increasing the difficulty for users to utilize multiple architectures. Therefore, this application provides an application service processing method. Figure 1 This is a flowchart illustrating an application service processing method provided in an embodiment of this application. The method is applied to a Kubernetes cluster, such as... Figure 1 As shown, the method includes:

[0055] S10: Create multiple node groups in the Kubernetes cluster and obtain the computing power of each node group.

[0056] The architecture of each node group is different.

[0057] Specifically, in a Kubernetes "one cloud, multiple chips" cluster environment, a node group consisting of multiple nodes is first created, and the computing power of each node group is acquired. It is important to note that the architecture and configuration of each node in a Kubernetes cluster are not entirely the same, therefore the architecture of the node groups will also be different.

[0058] Figure 2 This is a schematic diagram illustrating the principle of cross-architecture cloud-native application service processing provided in the embodiments of this application. Figure 2 As shown, Figure 2 The computing power measurement device primarily performs computing power measurement and storage for nodes, and provides a basis for computing power placement to ensure service levels during application elastic scaling. Specifically, to create node groups and obtain the computing power of each node group, as a preferred embodiment, multiple initial node groups are created based on the architecture and configuration of each node in the Kubernetes cluster; it is understood that the architecture and configuration of each node in the initial node group are identical. Further, a computing power measurement task is issued to each initial node group. This task performs computing power measurement on its respective initial node group, thereby obtaining the corresponding computing power index. After the measurement is completed, the computing power measurement task reports the computing power index of its initial node group to the control plane receiving component, thereby clustering and merging the received data, merging initial node groups with the same computing power to generate multiple node groups.

[0059] It's important to note that the computing power of the merged node groups is stored in ETCD in key-value pairs. ETCD is an open-source, highly available distributed key-value storage system developed in Go, used for configuration sharing and service registration and discovery.

[0060] S11: Deploy cloud-native applications to multiple current node groups according to the replication requirements of cloud-native applications under different architectures, and create services with the corresponding number of replicas according to the replication requirements.

[0061] Furthermore, in the process of deploying cloud-native applications, it is necessary to deploy cloud-native applications to multiple current node groups according to the replication requirements of cloud-native applications under different architectures, and create services with the corresponding number of replicas according to the replication requirements.

[0062] As a preferred embodiment, the deployment of cloud-native applications is primarily undertaken by Figure 2The application orchestration appliance is implemented within the framework. It primarily orchestrates cloud-native applications across different architectures based on user requirements and declarations regarding resource types, architecture declarations, and architecture replica types. The application orchestration appliance supports resource declaration description methods such as HELM and YAML. HELM is a command-line client tool mainly used for creating, packaging, and publishing Kubernetes application charts, as well as creating and managing local and remote chart repositories. YAML, short for "Yet Another Markup Language," is a language specifically designed for writing configuration files.

[0063] Specifically, the system retrieves the application description of the user-configured cloud-native application. This application description file contains the resource type, architecture declaration, and architecture replica type of the cloud-native application, as well as the workload replicas corresponding to different architectures. The application orchestration device parses the application description into multiple application description messages based on the architecture replica type, each conforming to the Kubernetes specification. Further, the application orchestration device performs differentiated rendering for each application description message across different architectures and node groups. Finally, the application orchestration device performs application scheduling, deploying the cloud-native application to multiple eligible current node groups based on the architecture declaration and architecture replica type, and creating the corresponding number of service replicas, thus achieving the deployment of the cloud-native application.

[0064] S12: During the operation of the cloud-native application, monitor the operation status of the cloud-native application and determine whether the preset conditions are met; if not, proceed to step S13.

[0065] During the operation of cloud-native applications, their operational status needs to be monitored to handle faults and ensure normal service operation. Therefore, in this embodiment, the operation status of cloud-native applications is monitored to determine whether preset conditions are met. If the preset conditions are not met, subsequent steps are required to resolve the service fault. This embodiment does not limit the preset conditions; they can be that the number of application replicas in the current node group remains unchanged and the current node group meets the expansion requirements, or that the current node group containing the application is functioning normally, depending on the specific implementation. Correspondingly, when the number of application replicas in a node group decreases and the current node group cannot meet the expansion requirements, or when a node group completely crashes, the preset conditions are considered not met.

[0066] To monitor the operational status of cloud-native applications and determine whether preset conditions are met, as a preferred embodiment, this is specifically achieved through... Figure 2The elastic scaling mechanism is implemented in the application orchestration system. During application operation, the elastic scaling mechanism monitors the operation of cloud-native applications across different architectures frequently; when a service fails on one architecture, it creates service replicas on other architectures based on the equivalence of computing power. Specifically, the elastic scaling mechanism monitors the operation of cloud-native applications deployed by the application orchestration system on different architectures through a list-watch mechanism.

[0067] List-watch is Kubernetes' unified asynchronous message processing mechanism, ensuring the real-time performance, reliability, and order of messages. Kubernetes uses list-watch to facilitate collaboration among components, maintain data synchronization, and decouple the design and implementation of each component. Further, based on operational status, it determines whether the cloud-native application's health meets the application declaration requirements. These requirements may include specific requirements regarding the number of application replicas and other information. If the application declaration requirements are not met, the preset conditions are not met, and the process proceeds to acquiring the computing power of the target node group, initiating the subsequent process of creating service replicas on other architectures based on computing power equivalence conversion.

[0068] S13: Obtain the computing power of the target node group, and calculate the equivalent replicas based on the computing power and replica count of the current node group and the computing power of the target node group to obtain the target replica count.

[0069] In order to achieve equivalent computing power conversion, this embodiment obtains the computing power of the target node group and calculates the equivalent replicas based on the computing power, replica count, and computing power of the current node group and the target node group to obtain the target replica count.

[0070] It is understandable that the target node group is the node group used to create service replicas. As a preferred embodiment, to achieve equivalent replica calculation, the product of the computing power and the number of replicas of the current node group is obtained, and then the quotient of this product with the computing power of the target node group is obtained to arrive at the target number of replicas. The target number of replicas is the number of service replicas that need to be created in the target node group.

[0071] S14: Create service replicas in the target node group based on the target number of replicas to provide equivalent service provisioning for cloud-native applications through the service replicas.

[0072] Finally, service replicas are created in the target node group according to the target number of replicas. As a preferred embodiment, the number of service replicas is created in the target node group through the Kubernetes API Server to ensure equivalent service supply and achieve service elasticity without degradation.

[0073] In this embodiment, multiple node groups are created in the Kubernetes cluster, and the computing power of each node group is obtained. Each node group has a different architecture. The cloud-native application is deployed to multiple current node groups according to its replication requirements under different architectures, and services with the corresponding number of replicas are created based on these requirements. During the operation of the cloud-native application, its running status is monitored, and it is determined whether preset conditions are met. If not, the computing power of the target node group is obtained, and equivalent replication is calculated based on the computing power, replication count, and target node group's computing power to obtain the target number of replicas. Service replicas are created in the target node group based on the target number of replicas to provide equivalent services for the cloud-native application. Therefore, this solution, by knowing the computing power of each architecture node group in advance, ensures the overall service quality of the application and prevents service degradation when an application service deployed on one architecture fails due to unmet preset conditions. This reduces the difficulty of deploying cloud-native applications across processor architectures.

[0074] In addition, as a preferred embodiment, after providing equivalent services for cloud-native applications through service replicas, the method further includes:

[0075] Output a notification message indicating that an equivalent service has been provided.

[0076] In practice, to notify users of the occurrence of equivalent service provision and to view and maintain the replaced node group, after providing equivalent service provision for cloud-native applications through service replicas, a notification message indicating that equivalent service provision has occurred is further output, thereby notifying users that the current node group deployed in the cloud-native application has been replaced.

[0077] In the above embodiments, the application service processing method has been described in detail. This application also provides embodiments corresponding to the application service processing apparatus.

[0078] Figure 3 This is a schematic diagram of an application service processing device provided in an embodiment of this application. The device is applied to a Kubernetes cluster, such as... Figure 3 As shown, the application service processing device includes:

[0079] The node group creation module 10 is used to create multiple node groups in a Kubernetes cluster and obtain the computing power of each node group. Each node group has a different architecture.

[0080] Application deployment module 11 is used to deploy cloud-native applications to multiple current node groups according to the replication requirements of cloud-native applications under different architectures, and to create services with the corresponding number of replicas according to the replication requirements.

[0081] The monitoring and judgment module 12 is used to monitor the operation of the cloud-native application and determine whether the preset conditions are met during the operation of the cloud-native application; if not, the equivalent replica calculation module 13 is triggered.

[0082] The equivalent replica calculation module 13 is used to obtain the computing power of the target node group and perform equivalent replica calculation based on the computing power, number of replicas of the current node group and the computing power of the target node group to obtain the target number of replicas.

[0083] The service replica creation module 14 is used to create service replicas in the target node group according to the target number of replicas, so as to provide equivalent service provision for cloud-native applications through service replicas.

[0084] In this embodiment, the application service processing device includes a node group creation module, an application deployment module, a monitoring and judgment module, an equivalent replica calculation module, and a service replica creation module. Multiple node groups are created in the Kubernetes cluster, and the computing power of each node group is obtained. Each node group has a different architecture. The cloud-native application is deployed to multiple current node groups according to its replica requirements under different architectures, and services with the corresponding number of replicas are created according to the replica requirements. During the operation of the cloud-native application, the running status of the cloud-native application is monitored, and it is determined whether preset conditions are met. If not, the computing power of the target node group is obtained, and equivalent replica calculation is performed based on the computing power, number of replicas, and computing power of the target node group to obtain the target number of replicas. Service replicas are created in the target node group according to the target number of replicas to provide equivalent services for the cloud-native application through these service replicas. Therefore, the above solution, by knowing the computing power of each architecture node group in advance, will create service replicas on other architectures when the application service deployed on one architecture fails due to non-compliance with preset conditions. This ensures the overall service quality of the application, prevents service degradation, and reduces the difficulty of deploying cloud-native applications across processor architectures.

[0085] Figure 4 This is a schematic diagram of an application service processing device provided in an embodiment of this application. Figure 4 As shown, the application service processing device includes:

[0086] Memory 20 is used to store computer programs.

[0087] The processor 21 is configured to implement the steps of the application service processing method as described in the above embodiments when executing a computer program.

[0088] The application service processing device provided in this embodiment may include, but is not limited to, smartphones, tablets, laptops, or desktop computers.

[0089] 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 of the following hardware forms: Digital Signal Processor (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), 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 Graphics Processing Unit (GPU), 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 Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0090] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of the application service processing method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary storage or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, the data involved in the application service processing method.

[0091] In some embodiments, the application service processing device may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0092] In this embodiment, the application service processing device includes a memory and a processor. The memory stores computer programs, and the processor executes the computer programs to implement the steps of the application service processing method mentioned in the above embodiments. Multiple node groups are created in the Kubernetes cluster, and the computing power of each node group is obtained; wherein each node group has a different architecture; cloud-native applications are deployed to multiple current node groups according to the replication requirements of cloud-native applications under different architectures, and services with the corresponding number of replicas are created according to the replication requirements; during the operation of the cloud-native application, the operation status of the cloud-native application is monitored and it is determined whether preset conditions are met; if not, the computing power of the target node group is obtained, and equivalent replication is calculated based on the computing power, replication number, and computing power of the current node group and the target node group to obtain the target number of replicas; service replicas are created in the target node group according to the target number of replicas to provide equivalent service supply for the cloud-native application through the service replicas. Therefore, the above solution, by knowing the computing power of each architecture node group in advance, will create service replicas on other architectures when the application service deployed on one architecture fails due to non-compliance with preset conditions. This ensures the overall service quality of the application, prevents service degradation, and reduces the difficulty of deploying cloud-native applications across processor architectures.

[0093] Finally, this application also provides an embodiment corresponding to a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiments.

[0094] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0095] In this embodiment, a computer program is stored on a computer-readable storage medium. When the computer program is executed by a processor, it implements the steps described in the above method embodiment. Multiple node groups are created in the Kubernetes cluster, and the computing power of each node group is obtained. Each node group has a different architecture. The cloud-native application is deployed to multiple current node groups according to the replication requirements of the cloud-native application under different architectures, and services with the corresponding number of replicas are created according to the replication requirements. During the operation of the cloud-native application, the running status of the cloud-native application is monitored, and it is determined whether preset conditions are met. If not, the computing power of the target node group is obtained, and equivalent replication is calculated based on the computing power, replication number, and computing power of the target node group to obtain the target number of replicas. Service replicas are created in the target node group according to the target number of replicas to provide equivalent services for the cloud-native application through these service replicas. Therefore, the above solution, by knowing the computing power of each architecture node group in advance, ensures the overall service quality of the application and prevents service degradation when an application service deployed on one architecture fails due to not meeting preset conditions. This reduces the difficulty of deploying cloud-native applications across processor architectures.

[0096] The foregoing provides a detailed description of an application service processing method, apparatus, device, and medium provided in this application. The various embodiments in the 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. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0097] It should also be noted that, in this specification, 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.

Claims

1. An application service processing method, characterized in that, Applied to a Kubernetes cluster, the method includes: Multiple node groups are created in the Kubernetes cluster, and the computing power of each node group is obtained; wherein, the architecture of each node group is different. Deploy the cloud-native application to multiple current node groups according to the replication requirements of the cloud-native application under different architectures, and create services with the corresponding number of replicas according to the replication requirements; During the operation of the cloud-native application, the operation status of the cloud-native application is monitored and it is determined whether preset conditions are met; If not, obtain the computing power of the target node group, and perform equivalent replica calculation based on the computing power of the current node group, the number of replicas, and the computing power of the target node group to obtain the target number of replicas; Service replicas are created in the target node group according to the target number of replicas, so as to provide equivalent service provision for the cloud-native application through the service replicas; The step of creating multiple node groups in the Kubernetes cluster and obtaining the computing power of each node group includes: Multiple initial node groups are created based on the architecture and configuration of each node in the Kubernetes cluster; wherein the architecture and configuration of each node in the initial node group are identical. Obtain the computing power of each of the initial node groups; The initial node groups with the same computing power are merged to generate multiple node groups; The monitoring of the cloud-native application's operation and determination of whether preset conditions are met includes: The operational status of the cloud-native application is monitored using a list-watch mechanism; Based on the operational status, determine whether the application health of the cloud-native application meets the application declaration requirements; If not, the preset conditions are not met, and the process proceeds to the step of acquiring the computing power of the target node group. The step of calculating equivalent replicas based on the computing power of the current node group, the number of replicas, and the computing power of the target node group includes: Obtain the product of the computing power and the number of replicas of the current node group; The quotient of the product and the computing power of the target node group is obtained to get the target number of replicas.

2. The application service processing method according to claim 1, characterized in that, The step of deploying the cloud-native application to multiple current node groups according to the replication requirements of the cloud-native application under different architectures includes: Obtain the application description of the cloud-native application set by the user; wherein the application description includes resource type, architecture declaration, and architecture replica type; The application description is parsed into multiple application description information based on the architecture replica type; Each application description is rendered differently; wherein the architecture and the node group to which each application description belongs are different. The cloud-native application is deployed to multiple eligible current node groups based on the architecture statement and the architecture replica type.

3. The application service processing method according to claim 1, characterized in that, The step of creating service replicas in the target node group according to the target number of replicas includes: The API Server creates service replicas in the target node group in a number equal to the target replica count.

4. The application service processing method according to any one of claims 1 to 3, characterized in that, After providing the equivalent service provision of the cloud-native application through the service replica, the method further includes: Output a notification message indicating that the equivalent service has been provided.

5. An application service processing device, characterized in that, The device, applied to a Kubernetes cluster, includes: A node group creation module is used to create multiple node groups in the Kubernetes cluster and obtain the computing power of each node group; wherein, each node group has a different architecture. The application deployment module is used to deploy the cloud-native application to multiple current node groups according to the replication requirements of the cloud-native application under different architectures, and to create services with the corresponding number of replicas according to the replication requirements; The monitoring and judgment module is used to monitor the operation of the cloud-native application and determine whether the preset conditions are met during the operation of the cloud-native application; if not, the equivalent replica calculation module is triggered. The equivalent replica calculation module is used to obtain the computing power of the target node group, and perform equivalent replica calculation based on the computing power of the current node group, the number of replicas, and the computing power of the target node group to obtain the target number of replicas; The service replica creation module is used to create service replicas in the target node group according to the target number of replicas, so as to provide equivalent service supply for the cloud-native application through the service replicas; The step of creating multiple node groups in the Kubernetes cluster and obtaining the computing power of each node group includes: Multiple initial node groups are created based on the architecture and configuration of each node in the Kubernetes cluster; wherein the architecture and configuration of each node in the initial node group are identical. Obtain the computing power of each of the initial node groups; The initial node groups with the same computing power are merged to generate multiple node groups; The monitoring of the cloud-native application's operation and determination of whether preset conditions are met includes: The operational status of the cloud-native application is monitored using a list-watch mechanism; Based on the operational status, determine whether the application health of the cloud-native application meets the application declaration requirements; If not, the preset conditions are not met, and the process proceeds to the step of acquiring the computing power of the target node group. The step of calculating equivalent replicas based on the computing power of the current node group, the number of replicas, and the computing power of the target node group includes: Obtain the product of the computing power and the number of replicas of the current node group; The quotient of the product and the computing power of the target node group is obtained to get the target number of replicas.

6. An application service processing device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the application service processing method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the application service processing method as described in any one of claims 1 to 4.