Service grid stability guarantee method and device

Abstract

The invention discloses a service grid stability guarantee method and device, and belongs to the technical field of computers. The method comprises the following steps: creating a service grid version management rule based on a self-defined resource definition mechanism of Kubernetes, and declaring a binding relationship between a target Deployment and a side vehicle agent version; intercepting a Pod creation request through an access controller of Kubernetes, and triggering an injection process of a service grid control plane; the service grid control plane judges whether the Pod is associated with the target Deployment or not by analyzing the label of the Deployment to which the Pod belongs; and if the Pod is associated with the target Deployment, injecting the side vehicle agent of the corresponding version into the Pod. According to the invention, the version of the service grid can still be finely controlled under the condition that the service and the service grid are deployed and decoupled, so that the service container and the verified service grid version are always deployed together; and the self-healing of the service grid and the capability that the user can autonomously and emergently exit the service grid are realized under the condition of not influencing the service.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology and relates to a method and device for ensuring the stability of a service mesh. Background Art

[0002] Service Mesh is an important part of the microservices architecture. Its idea is to further sink the service governance capabilities, decouple from the business through traffic interception and proxy enhancement, and improve the standardization of service governance. However, during the implementation of Service Mesh in enterprises, due to the automatic injection mechanism at the start of Service Mesh, the mesh version in the business will be upgraded with the re-release of the business, but the compatibility between the upgrade of the mesh itself and the business version has not been verified. Therefore, there are certain stability risks. How to ensure the stability of the service mesh has become an urgent problem to be solved. When a fault occurs in the service mesh, the overall stability can be achieved by relying on the restart self-healing mechanism of the Pod. However, in some scenarios (such as financial services), restarting has an impact on business continuity. Therefore, there is a lack of means to achieve fault self-healing in the case of mesh crashes without affecting the business and provide the ability for users to independently and emergently exit the mesh. Summary of the Invention

[0003] The purpose of the present invention is to overcome the deficiencies in the prior art and provide a method and device for ensuring the stability of a service mesh, which enhance the stability of the service mesh from the perspectives of service mesh version management, mesh fault self-healing, and user emergency exit.

[0004] To achieve the above purpose, the present invention is implemented by the following technical solutions:

[0005] In a first aspect, the present invention provides a method for ensuring the stability of a service mesh, including:

[0006] Based on the custom resource definition mechanism of Kubernetes, create service mesh version management rules, including declaring the binding relationship between the target Deployment and the sidecar proxy version;

[0007] When a Pod creation request is triggered, intercept the Pod creation request through the admission controller of Kubernetes and trigger the injection process of the service mesh control plane;

[0008] The service mesh control plane determines whether the Pod is associated with the target Deployment by parsing the labels of the Deployment to which the Pod belongs;

[0009] If the Pod is associated with the target Deployment, inject the corresponding version of the sidecar proxy into the Pod.

[0010] Further, based on the custom resource definition mechanism of Kubernetes, create service mesh version management rules, including:

[0011] Create a custom resource, where the custom resource includes a label selection rule field and a service mesh image version field;

[0012] Create at least one instance of the custom resource in the Kubernetes cluster;

[0013] Among them, the instance of the custom resource matches the label of the target Deployment through the label selection rule field, and specifies the sidecar proxy version bound to the target Deployment through the mesh image version field.

[0014] Further, the service mesh control plane determines whether the Pod is associated with the target Deployment by parsing the label of the Deployment to which the Pod belongs, including:

[0015] Traverse all instances of the custom resource and check whether the label of the Deployment to which the Pod belongs matches the label selection rule field of any instance;

[0016] If the match is successful, extract the specified sidecar proxy version in the matched instance and generate a sidecar container configuration containing the sidecar proxy;

[0017] If the match fails, skip sidecar container injection or use the default sidecar proxy version of the service mesh control plane.

[0018] Further, the admission controller includes the MutatingAdmissionWebhook mechanism of Kubernetes.

[0019] Further, the service mesh control plane includes the Istiod component of Istio.

[0020] Further, it also includes:

[0021] Monitor the running status of the sidecar proxy injected into the Pod through the pilot-agent component of Istio;

[0022] When an anomaly is detected, clear the iptables traffic hijacking rules configured in the Pod, restore the original network communication path between the business container in the Pod and the external service; and report a sidecar anomaly event to the service mesh control plane to trigger a version disabling or version rollback operation of the associated custom resource instance.

[0023] Further, the instance of the custom resource includes a health monitoring policy field to define the monitoring interval, failure threshold, and recovery action;

[0024] The service mesh control plane generates corresponding sidecar monitoring configurations according to the health monitoring policy of the instance and distributes them to the pilot-agent component.

[0025] Further, it further includes:

[0026] Configure a service mesh degradation flag in the annotation of the Pod, and the degradation flag is used to indicate whether to enable the service mesh traffic hijacking function;

[0027] The pilot-agent component listens to changes in the Pod annotation in real time. When it detects that the degradation flag is activated, it performs the following operations:

[0028] If it is short connection traffic, clear the iptables traffic hijacking rules configured in the Pod and restore the original network communication path between the business container and the external service;

[0029] If it is long connection traffic, send a degradation instruction to the service mesh data plane. After receiving the instruction, the service mesh data plane actively disconnects the long connection, and the business container rebuilds the communication connection with the external service.

[0030] Further, for long connection traffic, the service mesh data plane performs the following operations according to the degradation instruction:

[0031] For high-frequency active connections, immediately send a TCP RST packet to forcibly disconnect the connection when a new request is received;

[0032] For low-frequency idle connections, start a periodic check timer. When it detects that the service mesh is in an exit state, actively send a FIN packet to close the connection.

[0033] In a second aspect, the present invention also provides a service mesh stability guarantee device, and the device includes:

[0034] A service mesh version management rule creation module, which is used to create service mesh version management rules based on the custom resource definition mechanism of Kubernetes, including declaring the binding relationship between the target Deployment and the sidecar proxy version;

[0035] A Pod creation request interception module, which is used to intercept the Pod creation request through the admission controller of Kubernetes when the Pod creation request is triggered, and trigger the injection process of the service mesh control plane;

[0036] A Pod parsing module is used for the service mesh control plane to determine whether a Pod is associated with the target Deployment by parsing the labels of the Deployment to which the Pod belongs;

[0037] A sidecar proxy injection module is used to inject the corresponding version of the sidecar proxy into the Pod if the Pod is associated with the target Deployment.

[0038] Compared with the prior art, the beneficial effects achieved by the present invention are as follows:

[0039] The service mesh stability guarantee method provided by the present invention, on the one hand, through the matching at the Deployment dimension, realizes the differential management of the service mesh image versions, enabling the business to identify the tested service versions. When deploying and updating next time, the corresponding service mesh image will be pulled according to the target version expected by the user; on the other hand, in the face of possible failure scenarios, the present invention realizes the degradable ability of the business under the service mesh architecture from the perspectives of grid fault self-healing and user emergency exit. By monitoring the status of the sidecar container in the Pod through the pilot-agent component, when it is detected that the sidecar proxy runs abnormally, the traffic is not hijacked through the iptables rule cleaning, and the original network communication path between the business container in the Pod and the external service is restored; when the business traffic is abnormal due to service mesh faults or anomalies, the user can choose to exit the service mesh, and the exit process has little impact on the business process. For the short connections of the business, they can be restored after the service mesh exits. For the active long connections, the service mesh will actively disconnect the connection. For the inactive long connections, the service mesh will disconnect them through the timer mechanism. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 It is a schematic flowchart of a service mesh stability guarantee method provided by an embodiment of the present invention;

[0041] Figure 2 It is a schematic structural diagram of a service mesh stability guarantee device provided by an embodiment of the present invention;

[0042] Figure 3 It is an internal structure diagram of a computer device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0043] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. The same reference numerals in the drawings denote the same or similar components or parts. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. The embodiments of the present application and the specific features in the embodiments are detailed descriptions of the technical solution of the present application, rather than limitations on the technical solution of the present application. Without conflict, the technical features in the embodiments of the present application and the embodiments can be combined with each other.

[0044] As used herein, the term "and / or" is merely a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this article generally represents an "or" relationship between the associated objects before and after.

[0045] Embodiment 1:

[0046] As Figure 1 shown, an embodiment of the present invention provides a method for ensuring the stability of a service mesh. Figure 1 For the process schematic diagram of the method for ensuring the stability of the service mesh, this flow chart only shows the logical order of the method described in this embodiment. On the premise of not conflicting with each other, in other possible embodiments of the present invention, it can be different from Figure 1 the order shown to complete the steps shown or described.

[0047] The method for ensuring the stability of the service mesh provided in this embodiment can be applied to a terminal and can be executed by a device for ensuring the stability of the service mesh. This device can be implemented in a software and / or hardware manner and can be integrated in the terminal.

[0048] See Figure 1 , the method of the embodiment of the present invention is specifically as follows, where:

[0049] Step 11: Based on the custom resource definition mechanism of Kubernetes, create service mesh version management rules, including declaring the binding relationship between the target Deployment and the sidecar proxy version.

[0050] Kubernetes (abbreviated as K8s) is an open-source container orchestration platform, and its core capability is to manage the lifecycle of containerized applications. Kubernetes has built-in resource types such as Pod, Deployment, and Service, which are used to describe basic capabilities such as application deployment, networking, and storage. A Pod is the smallest scheduling unit in Kubernetes and contains one or more containers (usually application containers and sidecar containers) that share network and storage resources. A Deployment is a controller used to deploy containerized applications and is used to manage the declarative lifecycle of Pods, including operations such as creation, scaling, rolling updates, and rollbacks.

[0051] The Custom Resource Definition mechanism (CRD) is an API extension mechanism provided by Kubernetes that allows users to define new resource types, thereby expanding the functional boundaries of Kubernetes.

[0052] The present invention utilizes the Custom Resource Definition mechanism of Kubernetes to create custom resources, thereby binding the target Deployment to a verified service mesh sidecar proxy version.

[0053] Specifically, the created custom resources include a label selection rule field and a service mesh image version field. The label selection rule field spec.selector.matchLabels is in the form of key-value pairs and is used to match the labels of the target Deployment; the mesh image version field spec.sidecarVersion is of string type and is used to declare the image version of the service mesh sidecar proxy bound to the target Deployment.

[0054] Create at least one instance of the custom resource in the Kubernetes cluster. A custom resource instance is a specific implementation of a custom resource. The resource type is defined through CRD, and the instance carries specific configurations. Among them, the instance of the custom resource matches the labels of the target Deployment through the label selection rule field and specifies the sidecar proxy version bound to the target Deployment through the mesh image version field.

[0055] Step 12: When a Pod creation request is triggered, intercept the Pod creation request through the admission controller of Kubernetes and trigger the injection process of the service mesh control plane.

[0056] In the embodiments of the present invention, the admission controller uses the MutatingAdmissionWebhook mechanism native to Kubernetes.

[0057] Step 13: The service mesh control plane determines whether the Pod is associated with the target Deployment by parsing the labels of the Deployment to which the Pod belongs.

[0058] In the embodiments of the present invention, the service mesh control plane uses the Istiod component of Istio. Istiod is the core component of the Istio control plane, responsible for the configuration management, secure communication, service discovery, and dynamic injection of sidecar proxies in the service mesh.

[0059] The service mesh control plane traverses all instances of custom resources, checks whether the labels of the Deployment to which the Pod belongs match the label selection rule fields of any instance; if the match is successful, it proves that the Pod is associated with the target Deployment, and then extracts the specified sidecar proxy version in the matched instance to generate a sidecar container configuration containing the sidecar proxy; if the match is not successful, it proves that the Pod is not associated with the target Deployment, and then skips sidecar container injection or uses the default sidecar proxy version of the service mesh control plane.

[0060] Step 14: If the Pod is associated with the target Deployment, inject the corresponding version of the sidecar proxy into the Pod.

[0061] If the Pod is associated with the target Deployment, inject the generated sidecar container configuration into the Pod and configure traffic hijacking rules.

[0062] The present invention further includes:

[0063] Step 21: Monitor the running status of the sidecar proxy injected into the Pod through the pilot-agent component of Istio.

[0064] Among them, pilot-agent is an important component in Istio, mainly responsible for managing and controlling functions such as traffic routing, load balancing, and fault recovery in the service mesh.

[0065] Integrate a health monitoring agent (pilot-agent) into the sidecar container of the Pod to periodically check the survival status of the sidecar process and the port listening ability.

[0066] Step 22: When an anomaly is detected, clear the iptables traffic hijacking rules configured in the Pod to restore the original network communication path between the business containers in the Pod and external services; and report the sidecar anomaly event to the service mesh control plane to trigger the version disabling or version rollback operation of the associated custom resource instance.

[0067] To cooperate with the above-mentioned grid self-healing function, the instance of the custom resource needs to include a health monitoring policy field spec.healthPolicy to define the monitoring interval, failure threshold, and recovery actions of the pilot-agent; the service mesh control plane generates corresponding sidecar monitoring configurations according to the health monitoring policy of the instance and distributes them to the pilot-agent. When a version rollback is triggered, the most recent stable version in the healthy historical versions can be automatically selected for replacement.

[0068] The present invention further includes:

[0069] Step 31: Configure a service mesh downgrade flag in the annotation of the Pod, where the downgrade flag is used to indicate whether to enable the service mesh traffic hijacking function;

[0070] Step 32: The pilot-agent component listens for changes in the Pod annotation in real time. When it detects that the downgrade flag is activated, it performs the following operations:

[0071] If it is short-connection traffic, clear the iptables traffic hijacking rules configured in the Pod to restore the original network communication path between the business containers and external services;

[0072] If it is long-connection traffic, send a downgrade instruction to the service mesh data plane. After receiving the instruction, the service mesh data plane actively disconnects the long connection, and the business container reconstructs the communication connection with the external service;

[0073] Prohibit the injection of subsequent service mesh configurations until the downgrade flag is lifted.

[0074] Among them, for long-connection traffic, the service mesh data plane performs the following operations according to the downgrade instruction:

[0075] For high-frequency active connections, immediately send a TCP RST packet to forcibly disconnect the connection when a new request is received;

[0076] For low-frequency idle connections, start a periodic check timer. When it detects that the service mesh is in an exit state, actively send a FIN packet for graceful shutdown.

[0077] In addition, the metadata of the disconnected connection (source IP, destination port, protocol type) can be recorded and reported to the service mesh control plane for analysis.

[0078] In the face of possible fault scenarios, from the perspectives of grid fault self-healing and users' ability to exit urgently, the present invention realizes the degradable ability of services under the service mesh architecture. On the one hand, the present invention actively monitors the sidecar proxy, and when a fault occurs in the service mesh, it restores the original network communication path between the business containers in the Pod and external services, realizing the self-healing of the service mesh; on the other hand, the present invention provides a mechanism for users to log off actively. When users find that the business traffic is abnormal due to service mesh faults or anomalies, they can independently choose to exit the service mesh through the grid console, and their own services do not need to be restarted, which has little impact on the business process.

[0079] Embodiment 2:

[0080] Based on the same inventive concept as Embodiment 1, an embodiment of the present invention further provides a service mesh stability guarantee device for implementing the above service mesh stability guarantee method. The implementation solutions provided by this device to solve problems are similar to those recorded in the above method. Therefore, the specific limitations in the following embodiments of the service mesh stability guarantee device can refer to the limitations on the service mesh stability guarantee method in the above text, and will not be repeated here.

[0081] As Figure 2 shown, an embodiment of the present invention provides a service mesh stability guarantee device, including:

[0082] A service mesh version management rule creation module, configured to create service mesh version management rules based on the custom resource definition mechanism of Kubernetes, including declaring the binding relationship between the target Deployment and the sidecar proxy version;

[0083] A Pod creation request interception module, configured to intercept the Pod creation request through the admission controller of Kubernetes when the Pod creation request is triggered, and trigger the injection process of the service mesh control plane;

[0084] A Pod parsing module, configured for the service mesh control plane to judge whether the Pod is associated with the target Deployment by parsing the labels of the Deployment to which the Pod belongs;

[0085] A sidecar proxy injection module, configured to inject the corresponding version of the sidecar proxy into the Pod if the Pod is associated with the target Deployment.

[0086] Embodiment 3:

[0087] An embodiment of the present invention further provides a computer device, which may be a server, and its internal structure diagram may be as Figure 3As shown in the figure. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O), and a communication interface. Among them, the processor, the memory, and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with external terminals through a network connection. When the computer program is executed by the processor, it implements the service mesh stability guarantee method in the foregoing embodiments.

[0088] Those skilled in the art can understand that Figure 3 the structure shown in the figure is only a block diagram of some structures related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0089] Embodiment 4:

[0090] The embodiment of the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, it implements the steps of the following method:

[0091] Based on the custom resource definition mechanism of Kubernetes, create service mesh version management rules, including declaring the binding relationship between the target Deployment and the sidecar proxy version;

[0092] When a Pod creation request is triggered, intercept the Pod creation request through the admission controller of Kubernetes and trigger the injection process of the service mesh control plane;

[0093] The service mesh control plane determines whether the Pod is associated with the target Deployment by parsing the labels of the Deployment to which the Pod belongs;

[0094] If the Pod is associated with the target Deployment, inject the corresponding version of the sidecar proxy into the Pod.

[0095] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) that contain computer-usable program code.

[0096] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate means for realizing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0097] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including instruction means, and the instruction means realizes the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0098] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process. Thus, the instructions executed on the computer or other programmable device provide steps for realizing the functions specified in Figure 1 one flow or multiple flows and / or blocks Figure 1 one block or multiple blocks.

[0099] The embodiments of the present invention have been described above in conjunction with the accompanying drawings. However, the present invention is not limited to the above specific embodiments. The above specific embodiments are merely illustrative and not restrictive. Those of ordinary skill in the art, under the inspiration of the present invention, can also make many forms without departing from the spirit and scope protected by the present invention and the claims. All of these are within the protection scope of the present invention.

Claims

1. A method for ensuring stability of a service grid, characterized in that: include: Based on Kubernetes' custom resource definition mechanism, create service mesh version management rules, including declaring the binding relationship between the target Deployment and the sidecar proxy version; When a Pod creation request is triggered, the Pod creation request is intercepted by the Kubernetes admission controller, and the injection process of the service mesh control plane is triggered; The service grid control plane determines whether the Pod is associated with the target Deployment by parsing the label of the Deployment to which the Pod belongs; If the Pod is associated with the target Deployment, the corresponding version of the sidecar proxy is injected into the Pod.

2. The service grid stability assurance method according to claim 1, characterized in that: Based on the custom resource definition mechanism of Kubernetes, create service mesh version management rules, including: Create a custom resource, wherein the custom resource includes a label selection rule field and a service grid image version field; Create at least one instance of the custom resource in the Kubernetes cluster; The instance of the custom resource matches the label of the target Deployment through the label selection rule field, and specifies the sidecar proxy version bound to the target Deployment through the grid image version field.

3. The service grid stability assurance method according to claim 2, characterized in that: The service mesh control plane determines whether the Pod is associated with the target Deployment by parsing the label of the Deployment to which the Pod belongs, including: Traverse all instances of custom resources and check whether the label of the Deployment to which the Pod belongs matches the label selection rule field of any instance; If the match is successful, the sidecar proxy version specified in the matched instance is extracted, and a sidecar container configuration containing the sidecar proxy is generated; If no match is found, the sidecar container injection is skipped or the default sidecar proxy version of the service mesh control plane is used.

4. The service grid stability assurance method according to claim 1, characterized in that: The admission controller includes the MutatingAdmissionWebhook mechanism of Kubernetes.

5. The service grid stability assurance method according to claim 1, characterized in that: The service mesh control plane includes the Istiod component of Istio.

6. The service grid stability assurance method according to claim 3, characterized in that: Also includes: Use Istio's pilot-agent component to monitor the running status of the sidecar proxy injected into the Pod; When an abnormality is detected, the iptables traffic hijacking rules configured in the Pod are cleared to restore the original network communication path between the business container in the Pod and the external service; and the sidecar abnormal event is reported to the service mesh control plane to trigger the version disabling or version rollback operation of the associated custom resource instance.

7. The service grid stability assurance method according to claim 6, characterized in that: The instance of the custom resource includes a health monitoring policy field to define monitoring intervals, failure thresholds, and recovery actions; The service mesh control plane generates a corresponding sidecar monitoring configuration according to the health monitoring strategy of the instance, and sends it to the pilot-agent component.

8. The service grid stability assurance method according to claim 6, characterized in that: Also includes: A service mesh degradation flag is configured in the annotation of the Pod, where the degradation flag is used to indicate whether to enable a service mesh traffic hijacking function; The pilot-agent component monitors changes in Pod annotations in real time, and when it detects that the downgrade flag is activated, it performs the following operations: If it is short-connection traffic, clear the iptables traffic hijacking rules configured in the Pod and restore the original network communication path between the business container and the external service; If it is a long connection traffic, a degradation instruction is sent to the service mesh data plane. After receiving the instruction, the service mesh data plane actively disconnects the long connection, and the business container rebuilds the communication connection with the external service.

9. The service grid stability assurance method according to claim 8, characterized in that: For persistent connection traffic, the service mesh data plane performs the following operations according to the downgrade instruction: For high-frequency active connections, a TCP RST packet is immediately sent to force disconnection when a new request is received; For low-frequency idle connections, a periodic check timer is started. When the service grid is detected to be in the exit state, a FIN packet is actively sent to close it.

10. A service grid stability assurance device, characterized in that: include: The service mesh version management rule creation module is used to create service mesh version management rules based on the custom resource definition mechanism of Kubernetes, including declaring the binding relationship between the target Deployment and the sidecar proxy version; The Pod creation request interception module is used to intercept the Pod creation request through the Kubernetes admission controller when the Pod creation request is triggered, and trigger the injection process of the service grid control plane; The Pod parsing module is used for the service grid control plane to determine whether the Pod is associated with the target Deployment by parsing the label of the Deployment to which the Pod belongs; The sidecar proxy injection module is used to inject the corresponding version of the sidecar proxy into the Pod if the Pod is associated with the target Deployment.

Images