Application probe integration method and system based on cloud native environment

Abstract

The invention provides an application probe integration method and system based on a cloud native environment, and relates to the technical field of cloud native, and the method comprises the steps: intercepting a container creation request of a target application instance in the cloud native environment based on a triggering rule of a probe injection service; injecting the probe resource definition in the original resource definition of the target application instance by utilizing the probe injection service to obtain an integrated resource definition; and creating a target application container based on the integrated resource definition, and running the target application instance according to the target application container. Through a dynamic admission control mechanism of a cloud native environment, an application container resource request needing to be integrated with an application probe is automatically intercepted in an application container creation stage, and a self-defined probe resource definition is injected into an original resource definition of an application instance based on a pre-configured probe injection service; non-perceptual modification of application resource definition and decoupling integration of the probe and the application are achieved, and the invasiveness of installation of the probe to the application is effectively reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of cloud native technology, and in particular to an application probe integration method and system based on a cloud native environment. BACKGROUND

[0002] In the cloud native environment, applications are mostly deployed in the form of containers on an orchestration platform such as Kubernetes, and probes, as a core component of observability data collection, need to be integrated with each application container to realize performance data reporting. However, the current scheme for integrating probes in application containers in the cloud native environment is highly invasive to the application containers, and when the probe version is upgraded or the configuration is changed, the operation is complex and has a greater impact on the cloud native environment and the application. SUMMARY

[0003] The application embodiment provides an application probe integration method and system based on a cloud native environment to solve the problem of strong invasiveness of application probe integration in the prior art.

[0004] In a first aspect, the application embodiment provides an application probe integration method based on a cloud native environment, comprising: intercepting, based on a trigger rule of a probe injection service, a container creation request of a target application instance in the cloud native environment, the target application instance being an application instance that needs to install a probe; injecting, by the probe injection service, a probe resource definition into an original resource definition of the target application instance to obtain an integrated resource definition; creating a target application container based on the integrated resource definition, and running the target application instance according to the target application container.

[0005] In some embodiments, intercepting, based on the trigger rule of the probe injection service, the container creation request of the target application instance in the cloud native environment comprises: determining, for any resource request in the cloud native environment, whether the resource request is a container creation request of an application instance; if the resource request is the container creation request of the application instance, determining, according to a resource definition of the application instance, whether the application instance is the target application instance, and intercepting the resource request if the application instance is the target application instance.

[0006] In some embodiments, determining, according to the resource definition of the application instance, whether the application instance is the target application instance comprises: obtaining namespace information in the resource definition of the application instance, determining, based on the namespace information, whether the application instance is an application instance under a namespace associated with the probe; and if the application instance is the application instance under the namespace associated with the probe, determining whether there is a probe annotation in the resource definition of the application instance, and determining the application instance as the target application instance if there is the probe annotation.

[0007] In some embodiments, the probe injection service is used to inject probe resource definitions into the original resource definitions of a target application instance to obtain integrated resource definitions. This includes: sending the original resource definitions of the target application instance to the probe injection service; the probe injection service generating a difference patch for the original resource definitions based on pre-configured global probe parameters and the original resource definitions, and returning the difference patch; the global probe parameters including probe version information, development language information, and data upload address; and injecting the probe resource definitions into the original resource definitions based on the difference patch to obtain integrated resource definitions.

[0008] In some embodiments, the probe injection service generates a difference patch for the original resource definition based on pre-configured global probe parameters and the original resource definition, including: parsing and obtaining probe annotations from the original resource definition, the probe annotations including probe storage volume configuration information, environment variables, and container startup parameters; generating probe injection information based on the probe annotations and global probe parameters; modifying the original resource definition based on the probe injection information to obtain the modified resource definition; and generating a difference patch based on the differences between the modified resource definition and the original resource definition.

[0009] In some embodiments, after creating a target application container based on an integrated resource definition and running a target application instance based on the target application container, the method further includes: performing a consistency check on the probe version information in the integrated resource definition and the probe version information in the probe injection service; if the probe version information in the integrated resource definition is found to be inconsistent with the probe version information in the probe injection service, triggering a probe version update process for the target application instance.

[0010] In some embodiments, the probe version update process for the target application instance includes: recycling the target application container and re-requesting the application container of the target application instance; or, generating a probe version update query for the target application instance, and recycling the target application container and re-requesting the application container of the target application instance after receiving a confirmation instruction from the user for the probe version update query.

[0011] In some embodiments, the method further includes: monitoring the status of the target application instance; if the target application instance cannot run, recycling the target application container, creating an application container based on the original resource definition of the target application instance, and rerunning the target application instance based on the application container.

[0012] Secondly, this application provides an application probe integration system based on a cloud-native environment, including cloud-native components, a container resource pool, and a probe injection service component. The cloud-native components include an API server, a dynamic admission controller, and a distributed storage module. The probe injection service component is communicatively connected to the API server and includes a probe definition management module and a certificate management module. The probe definition management module is used to create and maintain probe resource definitions. The probe resource definition includes global probe parameters, which include probe version information, development language information, and data upload address. The dynamic admission controller defines probe injection trigger rules, which are used to intercept container creation requests of target application instances in resource requests in the cloud-native environment according to the probe injection trigger rules. The container creation requests of target application instances are then forwarded to the probe injection service component through the API server. The probe injection service component injects probe resource definitions into the original resource definitions of the target application instance to obtain integrated resource definitions. The target application instance is the application instance that needs to install probes. Cloud-native components are used to store integrated resource definitions in a distributed storage module and create target application containers in a container resource pool based on the integrated resource definitions, so that target application instances can run on the target application containers; The certificate management module is used to generate or load TLS certificates, which are used to maintain secure communication between the API server and the probe injection service component.

[0013] In some embodiments, the probe injection service component further includes a probe injection module, a probe configuration management module, and a status monitoring and self-healing module. The probe configuration management module stores global probe parameters and synchronizes the updated global probe parameters to the probe injection module after detecting an update. The probe injection module obtains the original resource definition of the target application instance in the container creation request, generates a difference patch for the original resource definition based on the original resource definition and global probe parameters, and feeds back the difference patch to the cloud-native component through the API server. The cloud-native component also generates an integrated resource definition based on the difference patch and the original resource definition of the target application instance after receiving the difference patch. The status monitoring and self-healing module monitors the status of the target application instance and triggers an application restart when it detects that the target application instance cannot run. The status monitoring and self-healing module also performs consistency checks on the probe version information in the integrated resource definition and the probe version information in the probe injection service. If it detects that the probe version information in the integrated resource definition is inconsistent with the probe version information in the probe injection service, it triggers the target application instance to restart to update the probe version.

[0014] The method based on the embodiments of this application automatically intercepts application container resource requests that require the integration of application probes during the application container creation stage through the dynamic admission control mechanism of the cloud-native environment. Based on the pre-configured probe injection service, it injects custom probe resource definitions into the original resource definitions of the application instance, thereby realizing the seamless modification of the application resource definitions and injecting the probe configuration into the application container. This achieves decoupling integration between the probe and the application, effectively reducing the intrusiveness of installing probes on the application.

[0015] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0016] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this application. Wherein: Figure 1 This is a flowchart illustrating an exemplary embodiment of the application probe integration method based on a cloud-native environment provided in this application. Figure 1 ; Figure 2 This is a flowchart illustrating an exemplary embodiment of the application probe integration method based on a cloud-native environment provided in this application. Figure 2 ; Figure 3 This is a flowchart illustrating an exemplary embodiment of the application probe integration method based on a cloud-native environment provided in this application. Figure 3 ; Figure 4 This is a flowchart illustrating an exemplary embodiment of the application probe integration method based on a cloud-native environment provided in this application. Figure 4 ; Figure 5 This is a flowchart illustrating an exemplary embodiment of the application probe integration method based on a cloud-native environment provided in this application. Figure 5 ; Figure 6 This is a schematic diagram illustrating the process from creation to startup of a target application instance provided in an exemplary embodiment of this application; Figure 7 This is a schematic diagram of the system architecture of an application probe integration system based on a cloud-native environment provided in an exemplary embodiment of this application; Figure 8 This is a block diagram of an electronic device used to implement the embodiments of this application. Detailed Implementation

[0017] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0018] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0019] Terminology 1. Kubernetes: An open-source container orchestration platform used for automated deployment, scaling, and management of containerized applications. Its core functions include resource scheduling, service discovery, and self-healing capabilities, and it is the cornerstone of the cloud-native system.

[0020] 2. Application Operation Controller (Operator): An application lifecycle management tool based on the Kubernetes extension mechanism. It encapsulates the operation and maintenance knowledge of specific applications through code to achieve automated management.

[0021] 3. Dynamic Admission Control: An extension mechanism of Kubernetes that uses webhooks to intercept requests before resources are persisted, enabling dynamic modification of resource definitions or validation of their validity.

[0022] 4. Mutating Admission Webhook: A "mutated" hook in dynamic admission control, it is an HTTP callback interface used to dynamically modify resource definitions before resources are persisted.

[0023] 5. MutatingWebhookConfiguration: A resource object in Kubernetes used to configure MutatingAdmissionWebhook, defining the triggering rules (backend service address) and communication security configuration of the webhook. It is the "rule carrier" of MutatingAdmissionWebhook.

[0024] 6. Custom Resource Definition (CRD): A mechanism provided by Kubernetes to extend the API, allowing users to define new resource types.

[0025] 7. Custom Resource (CR): A specific resource instance created based on a CRD, which stores business configuration data, serves as the carrier of business logic, and is managed through the Kubernetes API.

[0026] 8. API Server (Application Programming Interface Server): The sole API entry point for the Kubernetes cluster. It serves as the bus for all component interactions and is responsible for receiving, verifying, and processing all API requests.

[0027] 9. Pod: The smallest deployment unit in Kubernetes, consisting of one or more closely related containers. All containers share the Pod's network namespace and storage resources, and it is the "running carrier" of applications in Kubernetes.

[0028] 10. Probe: By embedding lightweight components into applications, it collects performance data such as distributed call chains, interface response times, error messages, and resource utilization in real time during application runtime. After preprocessing, the data is transmitted to the data collection platform, helping developers monitor application performance, locate bottlenecks, and diagnose faults, while maintaining low overhead to avoid affecting business operations. It is a key data bridge connecting applications and monitoring platforms.

[0029] Application Scenarios With the widespread adoption of cloud-native technologies, applications are commonly deployed in containerized form on orchestration platforms such as Kubernetes. Application probes, as a core component of observability data collection, need to be integrated with each application container to report performance data. However, current solutions for integrating application probes in cloud-native environments have significant technical shortcomings.

[0030] Existing Solution 1: Operations personnel add a command to copy the probe binary file to the application container's Dockerfile, for example, by adding `-java agent` to the Java startup parameters. This solution has the following technical drawbacks: (1) Highly invasive: It requires modification of the application's Dockerfile or POD configuration, and the probe is strongly coupled with the application deployment. When the probe version is upgraded or the configuration is changed, the application image needs to be rebuilt and the application container needs to be restarted, which can easily lead to business interruption and affect system availability.

[0031] (2) High operation and maintenance costs: For a cluster containing hundreds of microservices, the probe mounting path and startup parameters need to be configured separately for each application. When adding a new application or expanding the scale, the same operation needs to be repeated, and the probe version cannot be uniformly managed, which can easily lead to version confusion.

[0032] (3) High configuration error rate: Problems such as missing probe reporting address occur frequently, causing probes to fail to start normally, requiring a lot of time to troubleshoot.

[0033] (4) Poor cross-environment adaptability: In different environments such as development, testing, and production, probe configuration (such as reporting address and sampling rate) needs to be manually modified, which cannot achieve automatic adaptation to environmental differences and is prone to data collection abnormalities due to configuration confusion.

[0034] Existing Solution 2: This involves encapsulating the probe within a container image, creating a unified image containing both the application and the probe, and distributing it to various environments via an image repository. However, this solution still has the following technical drawbacks: (1) Complex image maintenance: When the probe version is upgraded, an integrated image of all applications needs to be rebuilt, which doubles the cost of image building and storage (each application needs to correspond to multiple probe version images), and the image retrieval time is extended, resulting in low deployment efficiency.

[0035] (2) Poor flexibility: The probe configuration (such as sampling rate and label) is fixed in the image. If the configuration needs to be adjusted, the image needs to be rebuilt and the application needs to be restarted. Dynamic configuration is not possible.

[0036] (3) Serious waste of resources: The integrated image contains the complete resources of the application and probe. All resources need to be loaded when the container starts, which increases the memory usage by 20%-30%. Furthermore, the entire application container needs to be restarted when the probe is abnormal, resulting in low resource utilization.

[0037] (4) Difficulty in multilingual adaptation: Different language applications (such as Java, Go, Python) require writing different image building scripts, resulting in high adaptation costs and the inability to unify and standardize.

[0038] Based on this, this application provides an application probe integration method based on a cloud-native environment. This method enables dynamic integration of probes and application containers without intruding on application code, effectively solving problems such as high invasiveness, high operation and maintenance costs, complex configuration, and poor cross-environment adaptability in existing solutions. This method utilizes the dynamic admission control mechanism of the cloud-native environment to automatically intercept application container resource requests that require application probe integration during the application container creation phase. Based on a pre-configured probe injection service, it injects custom probe resource definitions into the original resource definitions of the application instance, achieving seamless modification of application resource definitions. This injects the probe configuration into the application container, achieving decoupled integration between the probe and the application, effectively reducing the invasiveness of probe installation on the application.

[0039] Exemplary Methods Figure 1 This is a flowchart illustrating an exemplary embodiment of an application probe integration method based on a cloud-native environment provided in this application. This embodiment can be applied to electronic devices, such as... Figure 1 As shown, the method includes steps S110-S130: Step S110: Based on the triggering rules of the probe injection service, intercept the container creation request of the target application instance in the cloud-native environment. The target application instance is the application instance that needs to install the probe.

[0040] The cloud-native environment can be deployed on platforms such as Kubernetes. The probe injection service can be a service created by the user in the cloud-native environment by deploying an Operator. At the same time, the triggering rules for the probe injection service can be configured in the MutatingWebhookConfiguration of Kubernetes. These triggering rules can be configured based on conditions such as the namespace tag of the application instance, the application name prefix, or custom annotations. When a resource request that meets the triggering rules is detected in the cloud-native environment, the Mutating Admission Webhook is triggered to intercept the resource request.

[0041] In some embodiments, such as Figure 2 As shown, step S110 intercepts the container creation request of the target application instance in the cloud-native environment based on the triggering rules of the probe injection service, including steps S201-S202: Step S201: For any resource request in the cloud-native environment, determine whether the resource request is a container creation request for an application instance.

[0042] Here, the triggering rules for the probe injection service may include operation type interception rules. The operation type can be defined as the container creation operation of the application instance. When a resource request is detected as a container creation request of the application instance, it is further checked whether the resource request meets other rules in the triggering rules.

[0043] Step S202: If the resource request is a container creation request for an application instance, determine whether the application instance is the target application instance based on the resource definition of the application instance, and intercept the resource request if the application instance is the target application instance.

[0044] For example, when creating an application instance that requires the installation of probes, users can add tags and probe annotations to the application POD template, thereby defining the application instance as an application instance under the namespace associated with the probe, and writing the probe annotations required for probe injection in the resource definition of the application instance.

[0045] Specifically, step S202, which determines whether an application instance is a target application instance based on the resource definition of the application instance, includes: obtaining namespace information from the resource definition of the application instance, determining whether the application instance is an application instance under the namespace associated with the probe based on the namespace information; if the application instance is an application instance under the namespace associated with the probe, determining whether there is a probe annotation in the resource definition of the application instance, and determining the application instance as the target application instance if there is a probe annotation.

[0046] It can be understood that the triggering rules of the probe injection service may also include restrictions on the resource definition of the application instance. Only when the resource definition of the application instance meets both the namespace association condition and the probe annotation existence condition will it be determined as the target application instance and the resource request interception will be triggered, thereby ensuring the accuracy and security of probe injection and avoiding unnecessary interference to non-target application instances.

[0047] Step S120: Use the probe injection service to inject the probe resource definition into the original resource definition of the target application instance to obtain the integrated resource definition.

[0048] In some embodiments, such as Figure 3 As shown, in step S120, the probe resource definition is injected into the original resource definition of the target application instance using the probe injection service to obtain the integrated resource definition, including steps S301-S303: Step S301: Send the original resource definition of the target application instance to the probe injection service; Step S302: The probe injection service generates a difference patch for the original resource definition based on the pre-configured global probe parameters and the original resource definition, and returns the difference patch. Step S303: Based on the difference patch, inject the probe resource definition into the original resource definition to obtain the integrated resource definition.

[0049] For example, after Mutating Admission Webhook intercepts the container creation request of the target application instance, the API server can initiate a communication request to the probe injection service based on the HTTPS (Hypertext Transfer Protocol Secure) protocol and carry the original resource definition of the target application instance. The probe injection service can verify the TLS (Transport Layer Security) certificate in the communication request and receive the original resource definition of the target application instance after successful verification.

[0050] When creating a probe injection service, users configure global probe parameters, which include basic configurations such as probe version information, development language information, and data upload address. After receiving the original resource definition of the target application instance, the probe injection service can perform the following processing based on the original resource definition and global probe parameters: (1) Parse and obtain probe annotations from the original resource definition. The probe annotations include probe storage volume configuration information, environment variables and container startup parameters; (2) Generate probe injection information based on probe annotations and global probe parameters; (3) Modify the original resource definition based on the probe injection information to obtain the modified resource definition; (4) Generate a difference patch based on the differences between the modified resource definition and the original resource definition.

[0051] Specifically, the probe storage volume configuration information includes the probe mount path, which defines the storage location of the probe files in the application POD, used to isolate and distinguish probe files from application files within the application POD. Environment variables and container startup parameters are used to define the probe's startup configuration in the application POD based on the application type of the target application instance. For example, Java applications load the probe package through the JAVA_TOOL_OPTIONS environment variable; Python applications specify the probe module path through the PYTHONPATH environment variable, which is automatically imported when the application starts; Go applications enable the probe through the GODEBUG environment variable, combined with SW_AGENT_PATH to specify the probe library path, etc.

[0052] In step (2), the probe injection service actually generates probe injection information adapted to the target application instance through global probe parameters and probe annotations in the original resource definition of the target application instance; in step (3), when modifying the original resource definition based on the probe injection information, it only adds the relevant configuration of the probe to the original resource definition, without modifying the original definition in the original resource definition, which can ensure that the core logic of the application is not affected.

[0053] It is understandable that after modifying the original resource definition in step (3), the modified resource definition obtained is essentially the integrated resource definition that needs to be obtained. In order to avoid the resource consumption caused by transmitting the complete integrated resource definition, the probe injection service can generate a difference patch based on the JSON Patch specification in step (4) by using the difference between the modified resource definition and the original resource definition, and then feed the difference patch back to the API server.

[0054] It should be noted that step (4) is not a necessary step to implement the solution of this application. The probe injection service can also directly return the modified resource definition obtained in step (3) to the API server, so that the modified resource definition can be directly used as the integrated resource definition of the target application instance to build a container and run the application instance. This application is not limited to this.

[0055] Step S130: Create a target application container based on the integrated resource definition, and run the target application instance according to the target application container.

[0056] After receiving the differential patch, the API server can generate an integrated resource definition (i.e., the final POD configuration of the target application instance) based on the differential patch and the original resource definition. Then, it can create a target application container containing probes. When the target application container starts, it can automatically load the mounted probe files and environment variables, so that the probes and applications can start and run at the same time without manual intervention.

[0057] The method in this embodiment can accurately identify applications that need to integrate probes when a container creation request for a target application instance is detected, through pre-configured triggering rules, and automatically start the probe injection process. Through the automated parsing and fusion of the probe injection service, the problem of high configuration error rate of manual probe configuration is avoided. By only adding probe configuration to the resource definition of the target application instance without changing the original resource definition of the application, the intrusiveness of installing probes to the application can be reduced, and the independence and stability of the application's core logic can be guaranteed.

[0058] Furthermore, the combination of unified configuration of global probe parameters and flexible adaptation of probe annotations not only achieves standardized integration across environments and multiple languages, but also meets the personalized needs of different application instances. This effectively reduces the operational costs for operations and maintenance personnel in probe version management, configuration adjustment, and multi-environment deployment, providing efficient and reliable technical support for the construction of application observability systems in cloud-native environments.

[0059] In some embodiments, such as Figure 4 As shown, after creating the target application container based on the integrated resource definition in step S130 and running the target application instance according to the target application container, steps S401-S402 are also included: Step S401: Perform consistency checks on the probe version information in the integrated resource definition and the probe version information in the probe injection service; Step S402: If the probe version information in the integrated resource definition is found to be inconsistent with the probe version information in the probe injection service, the probe version update process of the target application instance is triggered.

[0060] The probe version update process for the target application instance may include: recycling the target application container and re-requesting the application container of the target application instance.

[0061] Understandably, when a user modifies or updates the global probe parameters in the probe injection service, the probe version information will change. In this case, for the target application instance that needs to be monitored using the probe, its application container can be reclaimed and a new request for the target application instance's application container can be made. When a request to create the target application instance's application container is generated, the Mutating Admission Webhook will still intercept the request based on the triggering rules of the probe injection service, and then the API server will send the original resource definition of the target application instance to the probe injection service.

[0062] Since the global probe parameters in the probe injection service have been modified, the probe injection service will use the original resource definition of the target application instance and the new version of the global probe parameters to... Figure 3 In steps S301-S303, a new difference patch is generated. After receiving the new difference patch, the API server can generate a new integrated resource definition corresponding to the target application instance based on the new difference patch and the original resource definition. Based on the new integrated resource definition, an application container containing the new version probe is created. After the application container starts, it can automatically load and start running the new version probe, realizing seamless update of probe version and avoiding abnormal monitoring data or functional failure due to probe version differences.

[0063] In some embodiments, the probe version update process for the target application instance may also be as follows: generating a probe version update query for the target application instance, and recycling the target application container after receiving the user's confirmation instruction for the probe version update query, and re-requesting the application container of the target application instance.

[0064] Understandably, updating a probe version does not mean that the older version of the probe has lost its monitoring capabilities; in some scenarios, the older version can still collect basic operational data normally. Therefore, the query mechanism allows operations personnel to determine whether to execute the update immediately based on actual business needs. For example, for core transaction systems, updates can be triggered during off-peak hours to minimize the impact on online services; for non-critical applications, the update process can be automated, balancing system stability and operational efficiency. This flexible version management strategy further enhances the adaptability and practicality of the probe integration solution in complex cloud-native environments, ensuring that probes always support the application's observability requirements in optimal condition.

[0065] Compared to existing probe integration solutions, the method in this embodiment eliminates the need for manual intervention to modify the application's original resource definitions during the probe version update process. The entire process is automatically completed through the dynamic access control mechanism of the cloud-native environment, ensuring the timeliness and accuracy of updates and further improving the automation level and operational efficiency of probe management.

[0066] In some embodiments, such as Figure 5 As shown, after creating the target application container based on the integrated resource definition and running the target application instance according to the target application container, steps S501-S502 are also included: Step S501: Monitor the status of the target application instance; Step S502: If the target application instance cannot run, the target application container is recycled, and an application container is created based on the original resource definition of the target application instance, and the target application instance is rerun based on the application container.

[0067] In practical applications, when a target application instance fails to start or run normally due to probe injection, the system can automatically identify and trigger a rollback mechanism. Specifically, by continuously monitoring the health check status, log output, and resource usage of the target application container, once issues such as application instance startup failure, frequent restarts, or abnormal business functions are detected, it is determined to be a compatibility failure caused by probe injection.

[0068] At this point, the system immediately terminates and reclaims the current target application container. Simultaneously, it retrieves the original resource definition of the uninjected probe from the cache or version control system and recreates the application container based on this definition. During recreation, the interception process of the probe injection service is automatically skipped, ensuring the application instance starts with its original configuration and quickly restores business continuity. Furthermore, the system records the fault information and rollback operation in the audit log and notifies operations personnel through an alert mechanism. This allows for subsequent analysis of probe-application compatibility issues, optimization of probe injection strategies, or adaptation adjustments to the probes to prevent similar faults from recurring. This automatic fault recovery mechanism effectively reduces the potential risks of probe integration to business stability and ensures the reliability and fault tolerance of application deployments in cloud-native environments.

[0069] Figure 6 This is a schematic diagram illustrating the process from creation to startup of a target application instance provided in an exemplary embodiment of this application, including the following steps: 1) Define the resource definitions for the application Pod. Users or systems predefine the resource configuration of application Pods, including container images, resource limits, environment variables, startup commands, and other information. This is the basic configuration template for creating application Pods. In the resource definition, users can selectively add probe annotations according to actual needs, such as specifying the specific version of the probe, the data collection frequency, or custom configuration parameters, to meet the monitoring needs of different application scenarios.

[0070] 2) Send application container creation request Once the application Pod's resources are defined, the user submits a request to the Kubernetes cluster to create the application Pod, triggering the cluster's resource creation process.

[0071] 3) Interception of probe injection trigger rules The Kubernetes API Server determines whether the Pod creation request needs to trigger probe injection based on the triggering rules (such as namespace tags, tag annotations, operation types, etc.) in the pre-configured MutatingWebhookConfiguration. If the triggering rules are met, proceed to step 4) to forward the original resource definition of the Pod to the probe injection service; otherwise, proceed directly to step 6) the resource storage stage and skip the probe injection process.

[0072] 4) Probe injection service returns differential patch After receiving the original resource definition of a Pod, the probe injection service parses the original resource definition, extracts probe annotations, and integrates global probe configurations to generate a probe injection scheme. Then, based on the probe injection scheme, it modifies the Pod resource definition, adds probe-related configurations (such as storage volume mounting, environment variables, startup parameters, etc.), and finally generates a difference patch based on the modified Pod resource definition, which only contains the "difference between the original definition and the modified definition", and returns it to the Kubernetes API Server.

[0073] 5) Modify the resource definition of the application Pod. Based on the received difference patch, the Kubernetes API Server modifies the resource definition of the application Pod and integrates the probe configuration into the Pod definition.

[0074] 6) Resource Storage The Pod resource definition is persistently stored in Kubernetes distributed storage. If the Pod resource definition has not been injected with a probe definition, proceed directly to step 9. If the Pod resource definition has been injected with a probe definition, proceed to step 7.

[0075] 7) Install probes Based on the modified Pod resource definition, the probe is automatically installed when the application Pod is created, including mounting the probe binary file, injecting environment variables, configuring startup parameters, etc., so that the application Pod can load the probe and collect data after startup.

[0076] 8) Probe anomaly detection The system continuously monitors the status of application Pods with installed probes. If a probe malfunctions and triggers the probe removal process, the probe configuration of the application Pod is removed, and the application proceeds to step 9 based on the original resource definition to ensure that the core business of the application is not affected. If the probe is normal, the application Pod remains in the state with the probe, and the application proceeds to step 9 based on the modified Pod resource definition.

[0077] 9) Create application Pods and provide services. If the initial Pod creation request does not meet the triggering rules, an application Pod without probes will be created directly and the service will be provided. If the probe is removed after an error, an application Pod without probes will be recreated to ensure business continuity. If the probe is normal, an application Pod will be created based on the modified Pod resource definition and the service will be provided.

[0078] The specific settings and implementation methods of the embodiments of this application have been described above from different perspectives. Using the methods provided in the above embodiments, automated and low-intrusion integration of probes can be achieved in a cloud-native environment, effectively solving problems such as low efficiency, high error rate, and difficulty in cross-environment adaptation under traditional manual configuration methods. The combination of dynamic access control mechanisms and differential patching technology ensures both the real-time performance and accuracy of probe integration while minimizing interference with the original application deployment process. The collaborative configuration mode of global parameters and local annotations enables probe management to meet the standardization requirements of large-scale clusters while flexibly adapting to the personalized monitoring needs of different applications, laying a solid foundation for building a unified and efficient cloud-native application observability platform. Simultaneously, the introduction of automatic version updates and automatic fault rollback mechanisms further enhances the stability and fault tolerance of the solution, ensuring that probes continue to function reliably throughout their entire lifecycle, helping operations and maintenance personnel to promptly grasp the application's operating status, optimize resource scheduling, and improve the overall availability and performance of the system.

[0079] Exemplary Systems Figure 7 This is a schematic diagram of the system architecture of an application probe integration system based on a cloud-native environment provided in an exemplary embodiment of this application. For example... Figure 7 As shown, the system includes a cloud-native component 701, a container resource pool 702, and a probe injection service component 703. The cloud-native component 701 includes an API server, a dynamic admission controller, and a distributed storage module. The probe injection service component 703 communicates with the API server and includes a probe definition management module and a certificate management module. The probe definition management module is used to create and maintain probe resource definitions. The probe resource definition includes global probe parameters, which include probe version information, development language information, and data upload address.

[0080] The dynamic admission controller defines probe injection trigger rules, which are used to intercept container creation requests of target application instances in resource requests in the cloud-native environment according to the probe injection trigger rules. The container creation requests of target application instances are then forwarded to the probe injection service component through the API server. The probe injection service component injects probe resource definitions into the original resource definitions of the target application instance to obtain integrated resource definitions. The target application instance is the application instance that needs to install probes.

[0081] Cloud-native components are used to store integrated resource definitions in a distributed storage module and create target application containers in a container resource pool based on the integrated resource definitions, so that target application instances can run on the target application containers.

[0082] The certificate management module is used to generate or load TLS certificates, which are used to maintain secure communication between the API server and the probe injection service component 703.

[0083] In some embodiments, the probe injection service component further includes a probe injection module, a probe configuration management module, and a status monitoring and self-healing module.

[0084] The probe configuration management module stores global probe parameters and synchronizes the updated global probe parameters to the probe injection module after detecting an update.

[0085] The probe injection module is used to obtain the original resource definition of the target application instance in the container creation request, generate a difference patch for the original resource definition based on the original resource definition and global probe parameters, and feed back the difference patch to the cloud-native component through the API server.

[0086] Cloud-native components are also used to generate an integrated resource definition based on the difference patch and the original resource definition of the target application instance after receiving a difference patch.

[0087] The status monitoring and self-healing module is used to monitor the status of the target application instance and trigger an application restart when it is detected that the target application instance cannot run.

[0088] The status monitoring and self-healing module is also used to perform consistency checks between the probe version information in the integrated resource definition and the probe version information in the probe injection service. If the probe version information in the integrated resource definition is found to be inconsistent with the probe version information in the probe injection service, the target application instance is triggered to restart to update the probe version.

[0089] In some embodiments, the probe injection module includes a definition parsing unit, a definition modification unit, and a patch generation unit. The definition parsing unit is used to parse and obtain probe annotations from the original resource definition. The probe annotations include probe storage volume configuration information, environment variables, and container startup parameters.

[0090] The definition modification unit is used to generate probe injection information based on probe annotations and global probe parameters, and modify the original resource definition based on the probe injection information to obtain the modified resource definition.

[0091] The patch generation unit is used to generate difference patches based on the differences between the modified resource definition and the original resource definition.

[0092] The functions of each unit, module, or sub-module in the various devices of this application embodiment can be found in the corresponding descriptions in the above method embodiments, and they have corresponding beneficial effects, which will not be repeated here.

[0093] Exemplary Electronic Devices and Computer-Readable Storage Media Figure 8 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 8 As shown, the electronic device includes a memory 801 and a processor 802. The memory 801 stores a computer program that can run on the processor 802. When the processor 802 executes the computer program, it implements the method described in the above embodiments. The number of memories 801 and processors 802 can be one or more.

[0094] The electronic device also includes: The communication interface 803 is used to communicate with external devices and exchange and transmit data.

[0095] If the memory 801, processor 802, and communication interface 803 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0096] Optionally, in a specific implementation, if the memory 801, processor 802, and communication interface 803 are integrated on a single chip, then the memory 801, processor 802, and communication interface 803 can communicate with each other through an internal interface.

[0097] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0098] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in this application.

[0099] It should be understood that the aforementioned processor can be a CPU, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), FPGAs, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0100] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0101] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0102] In addition to the methods and apparatus described above, embodiments of this application may also provide a computer program product, including computer program instructions, which, when executed by a processor, cause the processor to perform the steps of the methods in the various embodiments of this application described in the "Exemplary Methods" section above.

[0103] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. These programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0104] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0105] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0106] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0107] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0108] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0109] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0110] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A cloud-native environment based application probe integration method, characterized in that, The method comprises the following steps: A trigger rule based on a probe injection service intercepts a container creation request of a target application instance in a cloud native environment, the target application instance being an application instance requiring installation of a probe; A probe resource definition is injected into an original resource definition of the target application instance by using the probe injection service, to obtain an integrated resource definition; A target application container is created based on the integrated resource definition, and the target application instance is run according to the target application container.

2. The method of claim 1, wherein, The trigger rule based on the probe injection service intercepts the container creation request of the target application instance in the cloud native environment, comprising: For any resource request in the cloud native environment, it is determined whether the resource request is a container creation request of an application instance; If the resource request is a container creation request of an application instance, it is determined whether the application instance is a target application instance according to a resource definition of the application instance, and the resource request is intercepted if the application instance is a target application instance.

3. The method of claim 2, wherein, The determination whether the application instance is a target application instance according to the resource definition of the application instance comprises: Namespace information is obtained from the resource definition of the application instance, and it is determined whether the application instance is an application instance in a namespace associated with a probe based on the namespace information; If the application instance is an application instance in a namespace associated with a probe, it is determined whether there is a probe annotation in the resource definition of the application instance, and the application instance is determined to be a target application instance if the probe annotation exists.

4. The method of claim 1, wherein, The injection of the probe resource definition into the original resource definition of the target application instance by using the probe injection service to obtain the integrated resource definition comprises: The original resource definition of the target application instance is sent to the probe injection service; The probe injection service generates a difference patch of the original resource definition based on a pre-configured global probe parameter and the original resource definition, and returns the difference patch, the global probe parameter including probe version information, development language information and data uploading address; The probe resource definition is injected into the original resource definition based on the difference patch to obtain the integrated resource definition.

5. The method of claim 4, wherein, The generation of the difference patch of the original resource definition by the probe injection service based on the pre-configured global probe parameter and the original resource definition comprises: A probe annotation is parsed from the original resource definition, the probe annotation including probe storage volume configuration information, environment variables and container startup parameters; Probe injection information is generated according to the probe annotation and the global probe parameter; The original resource definition is modified based on the probe injection information to obtain a modified resource definition; The difference patch is generated according to the difference between the modified resource definition and the original resource definition.

6. The method according to claim 4 or 5, characterized in that, After the target application container is created based on the integrated resource definition, and the target application instance is run according to the target application container, the method further comprises: Consistency detection is performed on the probe version information in the integrated resource definition and the probe version information in the probe injection service; If it is detected that the probe version information in the integrated resource definition is inconsistent with the probe version information in the probe injection service, a probe version update process of the target application instance is triggered.

7. The method of claim 6, wherein, The probe version update process of the target application instance comprises: The target application container is recycled, and an application container of the target application instance is re-requested; Or, a probe version update inquiry of the target application instance is generated, and after receiving a confirmation instruction of the user on the probe version update inquiry, the target application container is recycled, and the application container of the target application instance is re-requested.

8. The method according to any one of claims 1-5, characterized in that, Further comprising: The state of the target application instance is monitored; If the target application instance cannot run, the target application container is recycled, an application container is created based on the original resource definition of the target application instance, and the target application instance is re-run based on the application container. 9.A cloud-native environment based application probe integration system, characterized in that, The cloud native component, the container resource pool and the probe injection service component are included, the cloud native component includes an API server, a dynamic admission controller and a distributed storage module, the probe injection service component is in communication connection with the API server, and includes a probe definition management module and a certificate management module; The probe definition management module is used for creating and maintaining a probe resource definition, and the probe resource definition includes global probe parameters, the global probe parameters include probe version information, development language information and data uploading address; The dynamic admission controller defines a probe injection trigger rule, which is used for intercepting a container creation request of a target application instance in a resource request of a cloud native environment according to the probe injection trigger rule, and forwarding the container creation request of the target application instance to the probe injection service component through the API server, so as to inject the probe resource definition into the original resource definition of the target application instance by using the probe injection service component, to obtain an integrated resource definition; wherein the target application instance is an application instance that needs to install a probe; The cloud native component is used for storing the integrated resource definition in the distributed storage module, and creating a target application container in the container resource pool based on the integrated resource definition, so that the target application instance runs based on the target application container; The certificate management module is used for generating or loading a TLS certificate, and the TLS certificate is used for maintaining communication security between the API server and the probe injection service component.

10. The system of claim 9, wherein, The probe injection service component further comprises a probe injection module, a probe configuration management module and a state monitoring and self-healing module; The probe configuration management module is used for storing the global probe parameters, and synchronizing the updated global probe parameters to the probe injection module after detecting that the global probe parameters are updated; The probe injection module is used for obtaining the original resource definition of the target application instance in the container creation request, generating a difference patch of the original resource definition based on the original resource definition and the global probe parameters, and feeding back the difference patch to the cloud native component through the API server. The cloud-native component is further configured to generate the integrated resource definition based on the difference patch and an original resource definition of the target application instance after receiving the difference patch; The state monitoring and self-recovery module is configured to monitor a state of the target application instance, and trigger application restart when detecting that the target application instance cannot run; The state monitoring and self-recovery module is further configured to perform consistency detection on probe version information in the integrated resource definition and probe version information in the probe injection service, and trigger the target application instance to restart to update the probe version if it is detected that the probe version information in the integrated resource definition is inconsistent with the probe version information in the probe injection service.

Images