Method and system for automatically triggering updating of K8s Pod

By building a Webhook service and Kubernetes API to automatically trigger Pod updates, the operational burden and update failure issues caused by manual updates in Kubernetes are solved, realizing an efficient and secure automated Pod update process, and improving the stability and efficiency of the CI/CD process.

CN121541901APending Publication Date: 2026-02-17INSPUR COMM TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511615478.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-11-06
Publication Date
2026-02-17

AI Technical Summary

Technical Problem

In a Kubernetes environment, existing technologies require manual updates to Pods, which increases the operational burden and makes it easy for services to be interrupted or delayed due to human error. In particular, it is difficult to meet the business needs for speed and accuracy in CI/CD processes. At the same time, the problem of update failure when the image label remains unchanged has not been resolved.

Method used

By building a Webhook service to receive image repository events, performing security verification and filtering, extracting image content summaries and comparing them with historical summaries, and using the Kubernetes API to modify Pod template annotations, rolling updates are automatically triggered, ensuring that image content changes can be updated even if the image tags remain unchanged.

Benefits of technology

It has implemented an automated Pod update process, reducing operational complexity, minimizing repetitive operations, improving deployment speed and development efficiency, and ensuring system security and seamless integration.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121541901A_ABST
    Figure CN121541901A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of container management, in particular to a method and system for automatically triggering K8s Pod updating. The method for automatically triggering K8s Pod update comprises the following steps: receiving a Webhook event from a mirror image warehouse, performing security verification, extracting a mirror image content abstract from the Webhook event passing the verification, and comparing the mirror image content abstract with a historical mirror image content abstract stored in a persistent database in real time; when it is found that the mirror image content abstract changes, a Kubernetes API is called to modify a Pod template annotation of the target Deployment, so that an annotation representing a new mirror image content abstract is injected; and a rolling updating process is automatically triggered to gradually replace the old Pod instance, so that zero-shutdown deployment is realized. According to the method and system for automatically triggering the updating of the K8s Pod, a content awareness updating mechanism is utilized, the problem of updating failure caused by unchanged mirror image labels is thoroughly solved, a Kubernetes updating mechanism is triggered by utilizing annotation injection, the operation and maintenance complexity is greatly reduced, and repeated operations generated by frequently changing packets in a development stage are reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of container management technology, and in particular to a method and system for automatically triggering Kubernetes Pod updates. Background Technology

[0002] In existing Kubernetes (K8s) development environments, Pod updates often require manual intervention. This not only increases the workload of operations personnel but also increases the risk of service interruptions or delays due to human error. Especially in continuous integration / continuous deployment (CI / CD) processes, frequent application version iterations demand rapid and accurate Pod updates, making traditional manual methods insufficient to meet the demands of efficient and stable business operations.

[0003] In Kubernetes, Deployments or other controllers trigger a rolling update mechanism when they detect changes to the Pod template. However, when using unchanging image tags, Kubernetes assumes no actual changes have occurred and skips the update operation that should have been performed. This means that even if the application code or configuration inside the container changes, as long as the image tag remains unchanged, these changes will not be automatically applied to the running Pod, resulting in the so-called "update failure" phenomenon.

[0004] To address the aforementioned issues, this invention proposes a method and system for automatically triggering K8s Pod updates. Summary of the Invention

[0005] To overcome the shortcomings of the prior art, this invention provides a simple and efficient method and system for automatically triggering K8s Pod updates.

[0006] This invention is achieved through the following technical solution:

[0007] A method for automatically triggering Kubernetes Pod updates includes the following steps:

[0008] Step S1: Receive Webhook events from the mirror repository;

[0009] Step S2: Perform security verification on the received Webhook events, including signature verification and event filtering;

[0010] Step S3: Extract the image content summary from the verified Webhook events;

[0011] Step S4: Compare the image content summary with the historical image content summaries stored in the persistent database in real time;

[0012] Step S5: When a change is detected in the image content summary, even if the image tag has not changed, directly call the Kubernetes API to modify the Pod template annotation of the target Deployment to inject the annotation representing the new image content summary;

[0013] Step S6: After Kubernetes detects a change in the Pod template annotation, it automatically triggers a rolling update process to gradually replace the old Pod instances, achieving zero-downtime deployment.

[0014] In step S1, an independent Webhook service is built and deployed in a Kubernetes cluster or external environment to receive Webhook event notifications from the image repository.

[0015] Webhook event types include image push and image delete, with image push being the primary trigger.

[0016] In step S2, the received Webhook event is processed for security, including verifying the digital signature to ensure the legitimacy of the event source and the integrity of the data.

[0017] At the same time, irrelevant or malicious events are excluded through an event filtering mechanism.

[0018] In step S3, the image content digest is the SHA256 hash value of the image.

[0019] In step S4, the persistent database is a key-value store or a relational database, used to record historical mirror content summaries associated with the Deployment;

[0020] When the persistent database records the image content summary associated with the Kubernetes Deployment, the initial value is obtained from the image repository or the Kubernetes environment initialization.

[0021] In step S5, when calling the Kubernetes API to modify the Pod template annotation of the target Deployment, the modification only involves metadata fields and does not change the image tag or other configurations, ensuring compatibility with the native Kubernetes mechanism.

[0022] In step S6, the Pod update status is monitored through asynchronous tasks, and the results are fed back to the external system through a callback mechanism when the update is completed or fails, so as to achieve end-to-end observability.

[0023] A system for automatically triggering Kubernetes Pod updates to implement the above method includes:

[0024] The Webhook service module is responsible for receiving Webhook events from the mirror repository and performing security verification on the received Webhook events, including signature verification and event filtering.

[0025] The mirror content summary extraction and comparison module is responsible for extracting the mirror content summary from the verified Webhook events and comparing the mirror content summary with the historical mirror content summary stored in the persistent database in real time.

[0026] The Pod template annotation modification module is responsible for directly calling the Kubernetes API to modify the Pod template annotation of the target Deployment when a change in the image content summary is detected, so as to inject annotations representing the new image content summary;

[0027] The rolling update module is responsible for automatically triggering the rolling update process when Kubernetes detects a change in the Pod template annotation, gradually replacing the old Pod instances to achieve zero-downtime deployment.

[0028] A computing device that automatically triggers Kubernetes Pod updates includes:

[0029] One or more processors, one or more memories, and one or more programs, wherein the one or more programs are stored in the one or more memories and configured to be executed by the one or more processors, and the one or more programs include instructions for performing any of the methods described above.

[0030] A computer-readable storage medium storing one or more programs, the one or more programs including instructions that, when executed by a computing device that automatically triggers a K8s Pod update, cause the computing device that automatically triggers the K8s Pod update to perform any of the methods described above.

[0031] The beneficial effects of this invention are: the method and system for automatically triggering K8s Pod updates utilize a content-aware update mechanism, which completely solves the problem of update failure caused by unchanged image tags, and utilizes annotation injection to trigger the Kubernetes update mechanism, which greatly reduces the complexity of operation and maintenance and reduces repetitive operations caused by frequent package changes during the development phase. Attached Figure Description

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

[0033] Appendix Figure 1 This is a schematic diagram illustrating the method for automatically triggering K8s Pod updates according to the present invention. Detailed Implementation

[0034] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions in the embodiments of this invention will be clearly and completely described below in conjunction with the embodiments of this invention. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0035] The method for automatically triggering Kubernetes Pod updates includes the following steps:

[0036] Step S1: Receive Webhook events from the mirror repository;

[0037] Step S2: Perform security verification on the received Webhook events, including signature verification and event filtering;

[0038] Step S3: Extract the image content summary from the verified Webhook events;

[0039] Step S4: Compare the image content summary with the historical image content summaries stored in the persistent database in real time;

[0040] Step S5: When a change is detected in the image content digest, even if the image tag has not changed, directly call the Kubernetes API to modify the Pod template annotation of the target Deployment, for example, inject image-digest:sha256:new_digest to inject an annotation representing the new image content digest;

[0041] Step S6: After Kubernetes detects a change in the Pod template annotation, it automatically triggers a rolling update process to gradually replace the old Pod instances, achieving zero-downtime deployment.

[0042] In step S1, an independent Webhook service is built and deployed in a Kubernetes cluster or external environment to receive Webhook event notifications from image repositories (such as Docker Hub, Harbor, etc.).

[0043] Webhook event types include image push and image delete, with image push being the primary trigger.

[0044] In step S2, the received Webhook events are processed for security, including verifying digital signatures (such as HMAC) to ensure the legitimacy of the event source and the integrity of the data.

[0045] At the same time, irrelevant or malicious events are excluded through event filtering mechanisms (such as whitelist verification).

[0046] In step S3, the image content digest is the SHA256 hash value of the image.

[0047] In step S4, the persistent database is a key-value store or a relational database, used to record historical mirror content summaries associated with the Deployment;

[0048] When the persistent database records the image content summary associated with the Kubernetes Deployment, the initial value is obtained from the image repository or the Kubernetes environment initialization.

[0049] In step S5, when calling the Kubernetes API to modify the Pod template annotations of the target Deployment, the modification only involves metadata fields and does not change the image tags or other configurations, ensuring compatibility with the native Kubernetes mechanism.

[0050] In step S6, the Pod update status is monitored through asynchronous tasks, and the results are fed back to the external system through a callback mechanism when the update is completed or fails, so as to achieve end-to-end observability.

[0051] This system, which automatically triggers Kubernetes Pod updates, is used to implement the above methods, including:

[0052] The Webhook service module is responsible for receiving Webhook events from the mirror repository and performing security verification on the received Webhook events, including signature verification and event filtering.

[0053] The mirror content summary extraction and comparison module is responsible for extracting the mirror content summary from the verified Webhook events and comparing the mirror content summary with the historical mirror content summary stored in the persistent database in real time.

[0054] The Pod template annotation modification module is responsible for directly calling the Kubernetes API to modify the Pod template annotation of the target Deployment when a change in the image content summary is detected, so as to inject annotations representing the new image content summary;

[0055] The rolling update module is responsible for automatically triggering the rolling update process when Kubernetes detects a change in the Pod template annotation, gradually replacing the old Pod instances to achieve zero-downtime deployment.

[0056] The computing devices that automatically trigger Kubernetes Pod updates include:

[0057] One or more processors, one or more memories, and one or more programs, wherein the one or more programs are stored in the one or more memories and configured to be executed by the one or more processors, and the one or more programs include instructions for performing any of the methods described above.

[0058] The computer-readable storage medium stores one or more programs, the one or more programs including instructions that, when executed by a computing device that automatically triggers a K8s Pod update, cause the computing device that automatically triggers the K8s Pod update to perform any of the methods described above.

[0059] This method for automatically triggering Kubernetes Pod updates establishes a content-driven, secure pass-through Kubernetes rolling update architecture. Compared to existing technologies, it has the following characteristics:

[0060] First, by comparing the image with the Digest, changes in the image content can be directly perceived, which completely solves the problem of update failure when the image tags remain unchanged, and avoids deployment delays caused by human negligence or development habits.

[0061] Secondly, by leveraging Webhook event-driven mechanisms and Kubernetes native mechanisms, fully automated rolling updates were achieved, reducing manual intervention, significantly lowering operational complexity and repetitive operations during the development phase (such as frequent package changes), and improving deployment speed and development efficiency.

[0062] Third, by using signature verification and event filtering, updates are prevented from being triggered by unauthorized or malicious events, thus ensuring system security.

[0063] Fourth, the direct access to the Kubernetes API ensures seamless integration with existing platforms and avoids introducing additional dependencies.

[0064] The embodiments described above are merely one specific implementation of the present invention. Ordinary changes and substitutions made by those skilled in the art within the scope of the technical solution of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for automatically triggering K8s Pod updates, characterized in that: The method comprises the following steps: Step S1, receiving a webhook event from a mirror warehouse; Step S2, performing security check on the received webhook event, including signature verification and event filtering; Step S3, extracting the image content digest from the passed webhook event; Step S4, comparing the image content digest with the historical image content digest stored in the persistent database in real time; Step S5, when the image content digest is found to be changed, directly calling the Kubernetes API to modify the Pod template annotation of the target Deployment to inject an annotation representing the new image content digest; Step S6, after the Kubernetes detects the change of the Pod template annotation, automatically triggering the rolling update process to replace the old Pod instance gradually, realizing zero downtime deployment.

2. The method of automatically triggering K8s Pod updates of claim 1, wherein: In step S1, a separate webhook service is constructed and deployed in the Kubernetes cluster or external environment to receive webhook event notifications from the image warehouse. The webhook event types include image pushing and image deletion.

3. The method of automatically triggering K8s Pod updates of claim 1, wherein: In step S2, the received webhook event is processed for security, including verifying the digital signature to ensure the legality of the event source and the integrity of the data; At the same time, irrelevant or malicious events are filtered out through the event filtering mechanism.

4. The method of automatically triggering K8s Pod updates of claim 1, wherein: In step S3, the image content digest is the SHA256 hash value of the image.

5. The method of automatically triggering K8s Pod updates of claim 1, wherein: In step S4, the persistent database is a key-value store or a relational database used to record the historical image content digest associated with the Deployment; When the persistent database records the image content digest associated with the Kubernetes Deployment, the initial value is obtained from the image warehouse or the Kubernetes environment.

6. The method of automatically triggering K8s Pod updates of claim 1, wherein: In step S5, when the Kubernetes API is called to modify the Pod template annotation of the target Deployment, the modification only involves metadata fields and does not change the image tag or other configurations, ensuring compatibility with the native mechanism of Kubernetes.

7. The method of automatically triggering K8s Pod updates of claim 1, wherein: In step S6, the asynchronous task is used to monitor the Pod update status, and when the update is completed or failed, the callback mechanism is used to feedback the result to the external system, realizing end-to-end observability.

8. A system for automatically triggering K8s Pod updates, characterized in that: The method comprises the following steps: A webhook service module is responsible for receiving webhook events from an image warehouse and performing security check on the received webhook events, including signature verification and event filtering; An image content digest extraction and comparison module is responsible for extracting the image content digest from the passed webhook event and comparing the image content digest with the historical image content digest stored in the persistent database in real time; An image content digest extraction and comparison module is responsible for extracting the image content digest from the passed webhook event and comparing the image content digest with the historical image content digest stored in the persistent database in real time; The pod template annotation modification module is responsible for directly calling the Kubernetes API to modify the pod template annotation of the target Deployment to inject an annotation representing the new image content digest when a change in the image content digest is detected; The rolling update module is responsible for automatically triggering a rolling update process to gradually replace old pod instances and achieve zero-downtime deployment when the Kubernetes detects a change in the pod template annotation.

9. A computing device to automatically trigger K8s Pod updates, characterized in that: comprise: one or more processors, one or more memories, and one or more programs, wherein the one or more programs are stored in the one or more memories and configured to be executed by the one or more processors, and the one or more programs comprise instructions for performing the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing one or more programs, the one or more programs comprising instructions for: The one or more programs comprise instructions that, when executed by a computing device that automatically triggers K8s pod updates, cause the computing device that automatically triggers K8s pod updates to perform the method according to any one of claims 1 to 7.