Canary release method, device and readable storage medium

Abstract

The embodiment of the present invention provides a canary release method, device and readable storage medium, including: finding a designated Deployment for canary release in a Kubernetes system; generating configuration information of a canary Pod according to configuration information of a Pod managed by the designated Deployment, wherein a selection tag in the configuration information of the canary Pod is the same as a selection tag in the configuration information of the Pod managed by the designated Deployment; setting an image address in the configuration information of the canary Pod to an address of a designated target image; calling an interface of a Kubernetes system to directly generate a canary Pod according to the configuration information of the canary Pod; if it is determined that a business logic verification result of a service provided by the canary Pod is passed, setting the image address of the designated Deployment to an address of a designated target image, and completing the release and going online.

Description

Technical Field

[0001] The present invention relates to the field of computer application publishing, and in particular to a canary publishing method, device and readable storage medium. Background Art

[0002] In the prior art, when implementing canary release in the Kubernetes system, it is necessary to generate configuration information of the Pod for canary release in the Deployment that is expected to be released, and set the labels in the configuration information corresponding to the canary Pod to be different from the labels in the configuration information of other Pods managed by the Deployment, so that Pods with two configuration information can coexist in the same Deployment. This solution modifies the environment of the Deployment used to process the current online business, and there is a risk of affecting the current business processing.

[0003] Other third-party tools that implement canary release based on the Kubernetes system need to use the custom resource function of Kubernetes to introduce third-party custom resources into Kubernetes. The implemented canary release system is complex and cannot be easily and quickly applied.

[0004] In the process of implementing the present invention, the applicant discovered that there are at least the following problems in the prior art:

[0005] The canary release method implemented by the existing technology is complex and requires modifying the current online operating environment. Summary of the invention

[0006] The embodiments of the present invention provide a canary release method, device and readable storage medium, which solve the problem that the canary release method implemented in the prior art is complicated and needs to modify the current online operating environment.

[0007] To achieve the above objective, on the one hand, an embodiment of the present invention provides a canary release method, including:

[0008] Find the specified Deployment for canary release in the Kubernetes system;

[0009] Generate configuration information of the canary Pod according to the configuration information of the Pod managed by the specified Deployment, where the selection tag in the configuration information of the canary Pod is the same as the selection tag in the configuration information of the Pod managed by the specified Deployment; the selection tag is used by the Service instance corresponding to the specified Deployment to forward business requests to the canary Pod and the Pod managed by the specified Deployment;

[0010] Set the image address in the configuration information of the canary Pod to the address of the specified target image;

[0011] Calling the Kubernetes system interface to directly generate the canary Pod according to the configuration information of the canary Pod;

[0012] If it is determined that the business logic verification result of the service provided by the Canary Pod is passed, the image address of the specified Deployment is set to the address of the specified target image, and the release is completed.

[0013] Furthermore, before finding the specified Deployment for canary release in the Kubernetes system, the process further includes:

[0014] When a canary release request is received, a packaging tool is called to package the specified business code into the specified target image, and the specified target image is added to the image repository;

[0015] The canary release request includes the name of the specified Deployment, the namespace of the specified Deployment, the address of the image repository, and the name of the packaging tool.

[0016] Furthermore, it also includes:

[0017] If it is determined that the state of the canary Pod is not in operation, an abnormal alarm is issued;

[0018] The abnormal alarm indicates that the canary Pod is unavailable.

[0019] Furthermore, it also includes:

[0020] If it is determined that the business logic verification result of the service provided by the Canary Pod fails, the Canary Pod is taken offline.

[0021] Furthermore, the taking the canary Pod offline is specifically as follows:

[0022] Modify the selection label in the configuration information of the canary Pod to be different from the selection label in the configuration information of the Pod managed by the specified Deployment.

[0023] Furthermore, it also includes:

[0024] Before each canary release is re-executed, the canary Pod generated during the last canary release is deleted.

[0025] Furthermore, it also includes:

[0026] When a rollback request is received, the mirror address of the specified Deployment is set to the specified mirror address;

[0027] The specified image address is the address of any image file used by the specified Deployment before the execution of the canary release.

[0028] Furthermore, generating the configuration information of the canary Pod according to the configuration information of the Pod managed by the specified Deployment includes:

[0029] Select a Pod from the Pods managed by the specified Deployment as the specific Pod;

[0030] Clone the configuration information corresponding to the specific Pod to obtain the configuration information corresponding to the canary Pod;

[0031] Delete the status information, node information, IP information, and cascade relationship information in the configuration information corresponding to the canary Pod;

[0032] The cascade relationship information in the configuration information corresponding to the canary Pod is modified to be inherited from the specific Pod.

[0033] On the other hand, an embodiment of the present invention provides a canary publishing device, including:

[0034] Find the Deployment unit, which is used to find the specified Deployment for canary release in the Kubernetes system;

[0035] A canary Pod configuration information generating unit, configured to generate the configuration information of the canary Pod according to the configuration information of the Pod managed by the specified Deployment, wherein the selection tag in the configuration information of the canary Pod is the same as the selection tag in the configuration information of the Pod managed by the specified Deployment; the selection tag is used for the Service instance corresponding to the specified Deployment to forward the business request to the canary Pod and the Pod managed by the specified Deployment;

[0036] A canary Pod image setting unit, used to set the image address in the configuration information of the canary Pod to the address of the specified target image;

[0037] A canary Pod generation unit, used to call an interface of a Kubernetes system to directly generate a canary Pod according to the configuration information of the canary Pod;

[0038] The formal launch unit is used to set the image address of the specified Deployment to the address of the specified target image if it is determined that the business logic verification result of the service provided by the Canary Pod is passed, so as to complete the release and launch.

[0039] Furthermore, it also includes:

[0040] A publishing request receiving unit, configured to, upon receiving a canary publishing request, call a packaging tool to package the specified business code into the specified target image, and add the specified target image to the image repository;

[0041] The canary release request includes the name of the specified Deployment, the namespace of the specified Deployment, the address of the image repository, and the name of the packaging tool.

[0042] Furthermore, it also includes:

[0043] an abnormality alarm unit, configured to issue an abnormality alarm if it is determined that the state of the canary Pod is a non-operating state;

[0044] The abnormal alarm indicates that the canary Pod is unavailable.

[0045] Furthermore, it also includes:

[0046] The canary Pod offline unit is used to take the canary Pod offline if it is determined that the business logic verification result of the service provided by the canary Pod is not passed.

[0047] Furthermore, the Canary Pod offline unit is specifically used to:

[0048] Modify the selection label in the configuration information of the canary Pod to be different from the selection label in the configuration information of the Pod managed by the specified Deployment.

[0049] Furthermore, it also includes:

[0050] The canary Pod deletion unit is used to delete the canary Pod generated during the last canary release before each re-execution of the canary release.

[0051] Furthermore, it also includes:

[0052] A rollback unit, configured to set the mirror address of the specified Deployment to the specified mirror address when a rollback request is received;

[0053] The specified image address is the address of any image file used by the specified Deployment before the execution of the canary release.

[0054] Furthermore, the canary Pod configuration information generating unit includes:

[0055] A Pod selection module, used to select a Pod from the Pods managed by the specified Deployment as a specific Pod;

[0056] A configuration information cloning module, used to clone the configuration information corresponding to the specific Pod to obtain the configuration information corresponding to the canary Pod;

[0057] A basic information clearing module, used to delete the status information, node information, IP information and cascade relationship information in the configuration information corresponding to the canary Pod;

[0058] The inheritance relationship setting module is used to modify the cascade relationship information in the configuration information corresponding to the canary Pod to be inherited from the specific Pod.

[0059] On the other hand, an embodiment of the present invention provides a readable storage medium storing a program code corresponding to the method for implementing any one of the above methods.

[0060] The above technical solution has the following beneficial effects: by directly using the interface of the Kubernetes system to create a canary Pod according to the configuration information of the Pod managed by the specified Deployment, the obtained Canary Pod is independent of any Deployment, and a simple and easy-to-use automatic canary release based on Kubernetes is achieved without changing the currently online specified Deployment and without introducing additional custom resources for the Kubernetes system, so as to achieve the technical effect of canary release of business services based on the Kubernetes environment without adding third-party custom resources and with minimal resource overhead; further, the created Canary Pod is independent of any Deployment, and automatic canary release is achieved without changing the currently online specified Deployment, so as to achieve the technical effect of having little impact on the original environment, only one Pod needs to be operated to complete the canary release, and other Kubernetes resources do not need to be modified. By making full use of the mechanism of the Kubernetes system's own Service component to distribute requests to Pods based on selected labels and the Deployment rollback mechanism, the canary release process can be repeated, traffic online, traffic offline, and rollback can be implemented with minimal development cost, significantly improving the efficiency of implementing the canary release function. At the same time, it makes full use of Kubernetes' existing proven stable and available functions to make the implemented canary release function more stable and reliable. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0062] Figure 1 This is a flow chart of a canary release method according to one embodiment of the present invention;

[0063] Figure 2 This is a schematic diagram of a canary publishing service process according to one embodiment of the present invention;

[0064] Figure 3 The present invention is an architectural diagram of a canary publishing device according to one embodiment of the present invention. DETAILED DESCRIPTION

[0065] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0066] First, the English names used below are explained appropriately:

[0067] The Kubernetes system is a portable, extensible, open source platform for managing containerized workloads and services that facilitates declarative configuration and automation.

[0068] Deployment is a component in the Kubernetes system used to manage Pods, providing declarative update capabilities for Pods and ReplicaSets;

[0069] Pod is the smallest deployable computing unit that can be created and managed in the Kubernetes system;

[0070] Ingress is a component in the Kubernetes system. It is an API object used to manage external access to services in the cluster. The typical access method is HTTP. It can provide load balancing, SSL termination, and name-based virtual hosting.

[0071] Service is a component in the Kubernetes system that exposes an application running on a set of Pods as an abstract method of network services; Service instance is an object instantiated by the Service component at runtime.

[0072] The API Server is responsible for providing HTTP APIs for users, different parts of the cluster, and external components of the cluster to communicate with each other;

[0073] Jenkins is a scalable continuous integration engine well known to those skilled in the art;

[0074] Gitlab Runner is another continuous integration tool well known to those skilled in the art.

[0075] The following describes the embodiments of the present invention:

[0076] On the one hand, if Figure 1 As shown, an embodiment of the present invention provides a canary release method, including:

[0077] Step S100, finding the specified Deployment for canary release in the Kubernetes system;

[0078] Step S101, generating configuration information of a canary Pod according to the configuration information of the Pod managed by the specified Deployment, wherein the selection tag in the configuration information of the canary Pod is the same as the selection tag in the configuration information of the Pod managed by the specified Deployment; the selection tag is used by the Service instance corresponding to the specified Deployment to forward the business request to the canary Pod and the Pod managed by the specified Deployment;

[0079] Step S102, setting the image address in the configuration information of the canary Pod to the address of the specified target image;

[0080] Step S103, calling the interface of the Kubernetes system to directly generate a canary Pod according to the configuration information of the canary Pod;

[0081] Step S104: If it is determined that the business logic verification result of the service provided by the Canary Pod is passed, the image address of the specified Deployment is set to the address of the specified target image, and the release is completed.

[0082] In some embodiments, a Deployment may be specified by giving a name of the Deployment and a namespace of the Deployment; and the specified Deployment may be found through an API Server in the Kubernetes system; configuration information of the Canary Pod may be generated according to the configuration information of the Pod managed by the specified Deployment, so that the operating environment of the Canary Pod is as consistent as possible with the Pod managed by the specified Deployment. For example, key items in the configuration information of the Canary Pod may be set according to the configuration information of the Pod managed by the specified Deployment. Preferably, the configuration information of the Pod managed by the specified Deployment may be cloned as the configuration information of the Canary Pod, and the obtained configuration information of the Canary Pod may be appropriately modified based on the cloning. The specific method of generating the configuration information of the Canary Pod may be implemented according to the specific situation; further, in order to ensure that requests for the Pod managed by the specified Deployment can also be evenly forwarded to the Canary Pod, the selection label in the configuration information of the Canary Pod is set to be the same as the selection label in the configuration information of the Pod managed by the specified Deployment. Set the image address in the configuration information of the Canary Pod to the address of the specified target image. The specified target image is the image of the version to be released in this Canary release. The specified target image can be a pre-generated image, or it can be a packaging tool that is called upon receiving a release request to package the specified business code into the specified target image and save it at the address of the specified target image; the specified target image can be saved in, including but not limited to, an image repository; call the interface of the Kubernetes system to directly generate the Canary Pod according to the configuration information of the Canary Pod. The Canary Pod is created by directly calling the relevant interface of the Kubernetes system, rather than through the controller inside the Deployment, so the Canary Pod is not managed by any Deployment; in the process of creating the Canary Pod, there is no impact on the specified Deployment, and there is no need to change the operation of the current version of the online business. One or more Canary Pods can be generated, depending on specific needs; preferably, a Canary Pod is generated, such as Figure 2As shown, since the selection label in the configuration information of the Canary Pod is the same as the selection label in the configuration information of the Pod managed by the specified Deployment, the terminal user's request is distributed to the Canary Pod and Pod01, Pod02, and Pod03 managed by the specified Deployment through the Ingress and Service of the Kubernetes system, so that the Pod managed by the specified Deployment runs on Version 1, and the Canary Pod runs on Version 2 to be upgraded or launched, thereby realizing Version 2 testing or launch of part of the traffic. If the business logic verification of the Version 2 service on the Canary Pod passes, it can be officially launched; the verification process can be through manual verification, or it can be through automatic testing or automated monitoring to track and verify various business indicators, and finally verify the business logic of the service; the result of manual or automatic verification can be sent to this embodiment, and when it is determined that the business logic verification result of the service provided by the Canary Pod is passed, the image address of the specified Deployment is set to the address of the specified target image, and the mechanism in the Kubernetes system will trigger the specified Deployment to perform the launch operation, so that each Pod managed by the specified Deployment is recreated, and the old Pod is deleted, thereby completing the official launch of the Canary release.

[0083] The embodiment of the present invention has the following technical effects: by directly using the interface of the Kubernetes system to create a canary Pod according to the configuration information of the Pod managed by the specified Deployment, the obtained canary Pod is independent of any Deployment, and a simple and easy-to-use automatic canary release based on Kubernetes is achieved without changing the currently online specified Deployment and without introducing additional custom resources for the Kubernetes system.

[0084] Furthermore, before finding the specified Deployment for canary release in the Kubernetes system, the process further includes:

[0085] When a canary release request is received, a packaging tool is called to package the specified business code into the specified target image, and the specified target image is added to the image repository;

[0086] The canary release request includes the name of the specified Deployment, the namespace of the specified Deployment, the address of the image repository, and the name of the packaging tool.

[0087] In some embodiments, the specified business code is pre-written by a developer and is ready to be released to the Pod managed by the specified Deployment through a canary release method, such as Figure 2 As shown, when a release request is received, the name of the specified Deployment and the namespace of the specified Deployment can be obtained from the request. According to the name of the specified Deployment and the namespace of the specified Deployment, the specified Deployment can be found in the Kubernetes system. This specified Deployment is the Deployment to be canary released; the packaging tool specified in the release request is called to package the specified business code into the specified target image, and the specified target image is added to the image repository specified in the request. Packaging tools include but are not limited to Jenkins and Gitlab Runner. If the packaging of the specified business code fails, the developer will be notified, and the developer will modify the specified business code and reissue the release request.

[0088] The embodiments of the present invention have the following technical effects: when a publishing request is received, a packaging tool is automatically called according to the information in the publishing request to automatically package the business code and store it in the image repository, further realizing the automation of canary publishing, reducing the developers' repeated packaging operations, allowing the developers to focus only on code writing, and improving the developers' development and testing efficiency.

[0089] Furthermore, it also includes:

[0090] If it is determined that the state of the canary Pod is not in operation, an abnormal alarm is issued;

[0091] The abnormal alarm indicates that the canary Pod is unavailable.

[0092] In some embodiments, if the Canary Pod does not run normally, since the Service component in the Kubernetes system has a detection mechanism, it is found that the status of the Canary Pod is not running, and the terminal request will not be sent to the Canary Pod, thereby achieving the effect of verifying the availability of the service provided by the Canary Pod.

[0093] Furthermore, it also includes:

[0094] If it is determined that the business logic verification result of the service provided by the Canary Pod fails, the Canary Pod is taken offline.

[0095] In some embodiments, Figure 2As shown in the figure, after the Canary Pod provides services together with the Pod managed by the specified Deploymentg, some terminal user requests will be distributed to the Canary Pod through Ingress and Service. The business logic of the service of Version2 version application on the Canary Pod will be verified through this part of traffic. If the verification fails, the Canary Pod will be taken offline. Since the Canary Pod and the specified Deployment are independent of each other, after the Canary Pod is taken offline, part of the traffic will be transferred back to the specified Deployment. The overall impact on the system is small, there is no need to interrupt the system service, and there is no impact on user experience.

[0096] Furthermore, the taking the canary Pod offline is specifically as follows:

[0097] Modify the selection label in the configuration information of the canary Pod to be different from the selection label in the configuration information of the Pod managed by the specified Deployment.

[0098] In some embodiments, Figure 2 As shown in the figure, if the Canary Pod runs normally, the end user's request can reach the Canary Pod, and then the service's business logic can be checked for problems. If a problem is found in the business logic under manual verification, the developer can issue a request to offline traffic, or under automated testing or monitoring, the automated testing or monitoring component can issue a request to offline traffic. When the verification fails through the lower limit traffic request, the API Server of the Kubernetes system can be called to operate the Canary Pod and modify the content of the selection label in the configuration information of the Canary Pod, so that the content of the selection label in the configuration information of the Canary Pod is different from the content of the selection label in the configuration information of the Pod managed by the specified Deployment, so that the Service instance corresponding to the specified Deployment cannot find the Canary Pod through the label, and the end user's request will not be requested to the Canary Pod. This can prevent the problem from expanding and realize the rapid traffic offline function of the Canary release.

[0099] Furthermore, it also includes:

[0100] Before each canary release is re-executed, the canary Pod generated during the last canary release is deleted.

[0101] In some embodiments, if the previous canary release fails, for example, after the offline traffic, the developer modifies the specified business code and needs to perform canary release again, then before re-executing the canary release, in order to make the configuration information of the canary Pod up to date when re-executing the release, the canary Pod created during the previous canary release needs to be deleted so that the canary Pod can be re-created when the release is re-executed. The embodiment of the present invention can ensure that the configuration information of the canary Pod is up to date each time the canary release is executed, and will not be interfered by the previous release, thereby ensuring the stability of each canary release.

[0102] Furthermore, it also includes:

[0103] When a rollback request is received, the mirror address of the specified Deployment is set to the specified mirror address;

[0104] The specified image address is the address of any image file used by the specified Deployment before the execution of the canary release.

[0105] In some embodiments, after the designated target image is officially launched, if a problem is found in the business logic of the service, the designated Deployment can be rolled back when a rollback request is received. The rolled back image can be defined by a designated image address, and the address of a known stable version of the image can be fixed, or the image address of the version to be rolled back can be specified in the rollback request. After receiving the rollback request, the image address of the designated Deployment is modified by calling the API Server. When the controller of the designated Deployment finds that the image address of the designated Deployment has been modified, it triggers a rolling update of the Pod managed by the designated Deployment to complete the business rollback.

[0106] The embodiments of the present invention have the following technical effects: the technical solution of the present invention makes full use of the existing mechanism provided by Kubernetes to achieve a quick and safe rollback after the business code is officially launched and a problem is found in the business logic of the service, thereby simplifying the reproducibility of the canary release method, and the canary release method is simple and easy to use.

[0107] Furthermore, generating the configuration information of the canary Pod according to the configuration information of the Pod managed by the specified Deployment includes:

[0108] Select a Pod from the Pods managed by the specified Deployment as the specific Pod;

[0109] Clone the configuration information corresponding to the specific Pod to obtain the configuration information corresponding to the canary Pod;

[0110] Delete the status information, node information, IP information, and cascade relationship information in the configuration information corresponding to the canary Pod;

[0111] The cascade relationship information in the configuration information corresponding to the canary Pod is modified to be inherited from the specific Pod.

[0112] In some embodiments, Figure 2 As shown in the figure, after the specified business code is packaged, the package information is returned, and the API Server is called to find the specified Deployment that needs to be released by the canary. After finding the corresponding specified Deployment, the three Pods managed by the specified Deployment are found according to the UID of the Deployment, and a Pod is randomly selected to obtain the configuration information of this Pod. Figure 2 As shown, the Pod obtained in this embodiment is Pod 03. A copy of the configuration information of Pod 03 is cloned to obtain the configuration information corresponding to the Canary Pod, and then the status information, node information, IP information, and cascade relationship information in the configuration information corresponding to the Canary Pod are deleted. Since the configuration information of the Canary Pod is cloned from the configuration information of the Pod managed by the specified Deployment, the label information in the configuration information of the Canary Pod is the same as the label information in the configuration information of the Pod managed by the specified Deployment, and the selection label in the configuration information is part or all of the label information in the configuration information, so it is naturally ensured that the selection label in the configuration information of the Canary Pod is the same as the selection label in the configuration information of the Pod managed by the specified Deployment, so that the Canary Pod and the Pod managed by the specified Deployment can be called evenly by the same Service instance. Modify the cascade relationship information in the configuration information corresponding to the Canary Pod to inherit from Pod03. Modify the mirror address of the Canary Pod to the mirror address of the newly released Version2 version. Through the Kubernetes system interface, the canary Pod is created according to the configuration information of the canary Pod. After the canary release is finally confirmed to be successful, it is officially launched, and the image address of the specified Deployment is updated to the address of the specified target image by calling the API Server. When the controller of the specified Deployment finds that the specified Deployment has been modified, it will trigger a rolling update of the Pod managed by the specified Deployment. That is, a new Pod is created again, and the old Pod is deleted after the new Pod runs normally. Figure 2As shown in the figure, the result of the rolling update is: the original Pod01, Pod02 and Pod03 will be deleted, and three new Pods will be created. Relying on the Kubernetes GC garbage collection mechanism, the association relationship of the canary Pod is set to inherit from Pod 03. Pod 03 has been deleted after the official launch. Kubernetes GC will trigger the garbage collection mechanism to delete the canary Pod. Ensure that after the final launch, the environment of the entire new version is exactly the same as the environment of the previous version.

[0113] The embodiment of the present invention has the following technical effects: Cloning the configuration information from the Pod managed by the specified Deployment can make the environment of the Canary Pod the same as the environment of the current online business running in the Pod managed by the specified Deployment, ensuring the accuracy of the business logic verification of the service during the Canary release process. The Canary Pod is set to inherit from the Pod managed by the specified Deployment. When the specified Deployment is officially launched, the garbage collection mechanism of Kubernetes GC can be used to delete the Canary Pod when the specified Deployment deletes the Pod inherited by the Canary Pod, so as to achieve the effect of not changing the specified Deployment after the official launch and not leaving the Canary Pod used for the Canary release in the system.

[0114] On the other hand, Figure 3 As shown, an embodiment of the present invention provides a canary publishing device, including:

[0115] Find Deployment unit 300 to find the specified Deployment for canary release in the Kubernetes system;

[0116] A canary Pod configuration information generating unit 301 is used to generate the configuration information of the canary Pod according to the configuration information of the Pod managed by the specified Deployment, wherein the selection tag in the configuration information of the canary Pod is the same as the selection tag in the configuration information of the Pod managed by the specified Deployment; the selection tag is used for the Service instance corresponding to the specified Deployment to forward the business request to the canary Pod and the Pod managed by the specified Deployment;

[0117] A Canary Pod image setting unit 302, configured to set the image address in the configuration information of the Canary Pod to the address of the specified target image;

[0118] A canary Pod generation unit 303 is used to call an interface of a Kubernetes system to directly generate a canary Pod according to the configuration information of the canary Pod;

[0119] The official launch unit 304 is used to set the image address of the specified Deployment to the address of the specified target image if it is determined that the business logic verification result of the service provided by the Canary Pod is passed, so as to complete the release and launch.

[0120] Furthermore, it also includes:

[0121] A publishing request receiving unit, configured to, upon receiving a canary publishing request, call a packaging tool to package the specified business code into the specified target image, and add the specified target image to the image repository;

[0122] The canary release request includes the name of the specified Deployment, the namespace of the specified Deployment, the address of the image repository, and the name of the packaging tool.

[0123] Furthermore, it also includes:

[0124] an abnormality alarm unit, configured to issue an abnormality alarm if it is determined that the state of the canary Pod is a non-operating state;

[0125] The abnormal alarm indicates that the canary Pod is unavailable.

[0126] Furthermore, it also includes:

[0127] The canary Pod offline unit is used to offline the canary Pod if it is determined that the business logic verification result of the service provided by the canary Pod is not passed.

[0128] Furthermore, the Canary Pod offline unit is specifically used to:

[0129] Modify the selection label in the configuration information of the canary Pod to be different from the selection label in the configuration information of the Pod managed by the specified Deployment.

[0130] Furthermore, it also includes:

[0131] The canary Pod deletion unit is used to delete the canary Pod generated during the last canary release before each re-execution of the canary release.

[0132] Furthermore, it also includes:

[0133] A rollback unit, configured to set the mirror address of the specified Deployment to the specified mirror address when a rollback request is received;

[0134] The specified image address is the address of any image file used by the specified Deployment before the execution of the canary release.

[0135] Furthermore, the canary Pod configuration information generating unit 301 includes:

[0136] A Pod selection module, used to select a Pod from the Pods managed by the specified Deployment as a specific Pod;

[0137] A configuration information cloning module, used to clone the configuration information corresponding to the specific Pod to obtain the configuration information corresponding to the canary Pod;

[0138] A basic information clearing module, used to delete the status information, node information, IP information and cascade relationship information in the configuration information corresponding to the canary Pod;

[0139] The inheritance relationship setting module is used to modify the cascade relationship information in the configuration information corresponding to the canary Pod to be inherited from the specific Pod.

[0140] Those skilled in the art can understand an embodiment corresponding to a canary publishing device based on the description of an embodiment of a canary publishing method, which will not be described in detail here.

[0141] On the other hand, an embodiment of the present invention provides a readable storage medium storing a program code corresponding to the method for implementing any one of the above methods.

[0142] The embodiment of the present invention has the following beneficial effects: by directly using the interface of the Kubernetes system to create a canary Pod according to the configuration information of the Pod managed by the specified Deployment, the obtained Canary Pod is independent of any Deployment, and a simple and easy-to-use automatic canary release based on Kubernetes is achieved without changing the currently online specified Deployment and without introducing additional custom resources for the Kubernetes system, so as to achieve the technical effect of achieving canary release of business services based on the Kubernetes environment without adding third-party custom resources and with minimal resource overhead; further, the created Canary Pod is independent of any Deployment, and automatic canary release is achieved without changing the currently online specified Deployment, so as to achieve the technical effect of having little impact on the original environment, only needing to operate one Pod to complete the canary release, and other Kubernetes resources do not need to be modified. By making full use of the Kubernetes system's own Service mechanism for distributing requests to Pods based on selected labels and the Deployment rollback mechanism, the canary release process can be repeated, traffic online, traffic offline, and rollback can be implemented with minimal development cost, significantly improving the efficiency of implementing the canary release function. At the same time, it makes full use of Kubernetes' existing proven stable and available functions to make the implemented canary release function more stable and reliable.

[0143] The above technical solution of the embodiment of the present invention is described in detail below in conjunction with specific application examples. For technical details not introduced during the implementation process, please refer to the relevant description in the previous text.

[0144] API Server is the API interface provided by Kubernetes. The logic processing module operates various resources on Kubernetes through this service, such as Ingress, Service, Deployment, Pod, Canary Pod, etc.

[0145] The packaging module is mainly used to package the business code, that is, the specified business code, into an image file and push the image file to the image repository. Here, the logic processing module is only responsible for calling the interface of the packaging tool (such as Jenkins, Gitlab Runner) to package the code, and the packaging result will be returned to the logic processing module to determine whether the packaging is successful.

[0146] Logical processing module (i.e. canary release device):

[0147] like Figure 2As shown in the figure, when the developer needs to perform a canary release, he needs to provide the business Deployment name, the namespace where the Deployment is located, the address of the image repository, the name of the packaging module, and send an HTTP request to the logic processing module;

[0148] After receiving the request, the logic processing module will call the packaging module's interface to trigger the packaging tool (Jenkins or Gitlab Runner) to package the code. After packaging is completed, the packaged image will be pushed to the image repository. For example, the image version packaged this time is Version 2.

[0149] After packaging is completed, the packaging information is returned. If the packaging is successful, the logic processing module will call the API Server to find the Deployment (that is, the specified Deployment) that the developer needs to release the canary. After finding the corresponding Deployment (that is, the specified Deployment), it will find the three Pods (that is, the specified Deployment) managed by the specified Deployment according to the UID of the specified Deployment. Figure 2 Pod01, Pod02, Pod03 in the example), randomly select a Pod, and obtain the configuration information of the Pod. The Pod obtained in the embodiment of the present invention is Pod 03. If the packaging fails, the logic processing module will return to the developer to inform him of the packaging failure. The developer can modify his own code and then perform the canary release again.

[0150] After obtaining the configuration information of Pod 03, clone a copy of the configuration information of Pod 03, and then delete the status information, node information, IP information, and cascade relationship information of the configuration information.

[0151] After the Pod configuration information is modified, the cascade relationship information will be added again. This cascade relationship is the cascade relationship between Pod 03 and Canary Pod. This is to let Canary Pod know that Canary Pod is cloned from Pod 03.

[0152] Change the image address of the canary Pod to the image address of the newly released Version 2, instead of the image address of Version 1 in Pod 03.

[0153] After the end user requests a service through the domain name, the request will first reach Ingress. Ingress finds the Service through the configured Service name. The Service then finds the Pod managed by the specified Deployment by selecting the label. Finally, Pod01, Pod02, and Pod03 process the request. Since the label configuration of the Canary Pod is the same as that of Pod 03, the Service can also select the Canary Pod, so the request will also be assigned to the Canary Pod.

[0154] If the Canary Pod does not run normally, the Service has a detection mechanism that finds that the Canary Pod is not in the running state, and the request will not be sent to the Canary Pod. This achieves one of the purposes of Canary release, which is to verify the availability of the service.

[0155] If the Canary Pod runs normally, the request can reach the Canary Pod, and then we can check whether there is a problem with the service's business logic. If we find a problem with the business logic, we can send a request to offline traffic to the logic processing module. The logic processing module calls the API Server, operates the Canary Pod, and modifies its label information. After the label is modified, the Service cannot find the Canary Pod through the label, and the end user's request will not be sent to the Canary Pod. This can prevent the problem from expanding and achieve another purpose of Canary release, which is to quickly offline the traffic.

[0156] After the offline traffic is removed and the code is modified, the canary release can be performed again. In this release, the logic processing module will delete the previously created canary Pod to ensure that the configuration of the canary Pod is the latest, and then re-create the canary Pod.

[0157] After the final development confirms that the canary release is successful, the logic processing module is officially launched. The logic processing module will call the API Server to update the mirror address of the specified Deployment. After the specified Deployment controller finds that the specified Deployment has been modified, it will trigger a rolling update of the Pod managed by the specified Deployment. That is, a new Pod is created again, and the old Pod is deleted after the new Pod runs normally. The result of the rolling update is: Pod 01, Pod02, and Pod03 will all be deleted, and three new Pods will be created.

[0158] Relying on the Kubernetes GC garbage collection mechanism, the association relationship of the canary Pod points to Pod 03. Pod03 has been deleted after the official launch. The Kubernetes GC will trigger the garbage collection mechanism to delete the canary Pod. This ensures that after the final launch, the environment of the entire new version is exactly the same as the environment of the previous version.

[0159] At this point, the entire canary release is complete. The service requested by the user changes from Version 1 to Version 2.

[0160] If you find that there is a problem with the business logic of the service after the development is officially launched, you can send a rollback request to the logic processing module, and the request specifies the version to be rolled back. After receiving the request, the logic processing module calls the API Server to modify the mirror address of the specified Deployment. When the specified Deployment controller finds that the specified Deployment has been modified, it triggers a rolling update of the Pod to complete the business rollback.

[0161] The embodiment of the present invention has the following technical effects: canary release based on Kubernetes services can be achieved without using the custom resource function of the Kubernetes system to introduce custom resources; the impact on the original environment is small, only one Pod needs to be operated to complete the canary release, and other Kubernetes resources do not need to be modified. The canary release process can be repeated, traffic can be online, traffic can be offline, and rolled back.

[0162] It should be understood that the specific order or hierarchy of steps in the disclosed process is an example of an exemplary method. Based on design preferences, it should be understood that the specific order or hierarchy of steps in the process can be rearranged without departing from the scope of protection of the present disclosure. The attached method claims present the elements of the various steps in an exemplary order and are not intended to be limited to the specific order or hierarchy described.

[0163] In the above detailed description, various features are grouped together in a single embodiment to simplify the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the embodiments of the claimed subject matter require more features than are clearly stated in each claim. On the contrary, as reflected in the appended claims, the invention is in a state of having less than all the features of the disclosed individual embodiments. Therefore, the appended claims are hereby expressly incorporated into the detailed description, with each claim standing on its own as a separate preferred embodiment of the invention.

[0164] The disclosed embodiments are described above to enable any person skilled in the art to implement or use the present invention. Various modifications of these embodiments are obvious to those skilled in the art, and the general principles defined herein may also be applied to other embodiments without departing from the spirit and scope of the present disclosure. Therefore, the present disclosure is not limited to the embodiments given herein, but is consistent with the broadest scope of the principles and novel features disclosed in this application.

[0165] The above description includes examples of one or more embodiments. Of course, it is impossible to describe all possible combinations of components or methods for the purpose of describing the above embodiments, but it should be recognized by those skilled in the art that the various embodiments may be further combined and arranged. Therefore, the embodiments described herein are intended to cover all such changes, modifications and variations that fall within the scope of protection of the appended claims. In addition, with respect to the term "comprising" used in the specification or claims, the word is covered in a manner similar to the term "including", as explained by "including:" used as a transitional word in the claims. In addition, any term "or" used in the specification of the claims is intended to mean "non-exclusive or".

[0166] Those skilled in the art may also understand that the various illustrative logical blocks, units, and steps listed in the embodiments of the present invention may be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly demonstrate the interchangeability of hardware and software, the various illustrative components, units, and steps described above have generally described their functions. Whether such functions are implemented by hardware or software depends on the specific application and the design requirements of the entire system. Those skilled in the art may use various methods to implement the described functions for each specific application, but such implementation should not be understood as exceeding the scope of protection of the embodiments of the present invention.

[0167] The various illustrative logic blocks or units described in the embodiments of the present invention can be implemented or operated by a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, a discrete gate or transistor logic, a discrete hardware component, or any combination of the above. The general-purpose processor can be a microprocessor, and optionally, the general-purpose processor can also be any conventional processor, controller, microcontroller or state machine. The processor can also be implemented by a combination of computing devices, such as a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a digital signal processor core, or any other similar configuration.

[0168] The steps of the method or algorithm described in the embodiments of the present invention can be directly embedded in hardware, a software module executed by a processor, or a combination of the two. The software module can be stored in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or other storage media of any form in the art. Exemplarily, the storage medium can be connected to the processor so that the processor can read information from the storage medium and can write information to the storage medium. Optionally, the storage medium can also be integrated into the processor. The processor and the storage medium can be arranged in an ASIC, and the ASIC can be arranged in a user terminal. Optionally, the processor and the storage medium can also be arranged in different components in the user terminal.

[0169] In one or more exemplary designs, the above functions described in the embodiments of the present invention can be implemented in hardware, software, firmware or any combination of the three. If implemented in software, these functions can be stored on a computer-readable medium, or transmitted in the form of one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media that facilitate the transfer of computer programs from one place to another. The storage medium can be any available medium that can be accessed by any general or special computer. For example, such computer-readable media can include but are not limited to RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store program codes in the form of instructions or data structures and other forms that can be read by general or special computers, or general or special processors. In addition, any connection can be appropriately defined as a computer-readable medium, for example, if the software is transmitted from a website site, server or other remote resource through a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wirelessly, such as infrared, wireless and microwave, it is also included in the defined computer-readable medium. The disk and disc include compact disk, laser disk, optical disk, DVD, floppy disk and blue-ray disk. Disks usually copy data magnetically, while discs usually copy data optically with lasers. The above combination can also be included in computer readable media.

[0170] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A canary release method, It is characterized in that include: Find the specified Deployment for canary release in the Kubernetes system; Generate configuration information of the canary Pod according to the configuration information of the Pod managed by the specified Deployment, where the selection tag in the configuration information of the canary Pod is the same as the selection tag in the configuration information of the Pod managed by the specified Deployment; the selection tag is used by the Service instance corresponding to the specified Deployment to forward business requests to the canary Pod and the Pod managed by the specified Deployment; Set the image address in the configuration information of the canary Pod to the address of the specified target image; Calling the Kubernetes system interface to directly generate the canary Pod according to the configuration information of the canary Pod; If the business logic verification result of the service provided by the Canary Pod is determined to be passed, the image address of the specified Deployment is set to the address of the specified target image, and the release is completed; The generating the configuration information of the canary Pod according to the configuration information of the Pod managed by the specified Deployment includes: Select a Pod from the Pods managed by the specified Deployment as the specific Pod; Clone the configuration information corresponding to the specific Pod to obtain the configuration information corresponding to the canary Pod; Delete the status information, node information, IP information, and cascade relationship information in the configuration information corresponding to the canary Pod; The cascade relationship information in the configuration information corresponding to the canary Pod is modified to be inherited from the specific Pod.

2. The canary release method according to claim 1, It is characterized in that Before finding the specified Deployment for canary release in the Kubernetes system, it also includes: When a canary release request is received, a packaging tool is called to package the specified business code into the specified target image, and the specified target image is added to the image repository; The canary release request includes the name of the specified Deployment, the namespace of the specified Deployment, the address of the image repository, and the name of the packaging tool.

3. The canary release method according to claim 1, It is characterized in that Also includes: If it is determined that the state of the canary Pod is not in operation, an abnormal alarm is issued; The abnormal alarm indicates that the canary Pod is unavailable.

4. The canary release method according to claim 1, It is characterized in that Also includes: If it is determined that the business logic verification result of the service provided by the Canary Pod fails, the Canary Pod is taken offline.

5. The canary release method according to claim 4, It is characterized in that The step of taking the canary Pod offline is as follows: Modify the selection label in the configuration information of the canary Pod to be different from the selection label in the configuration information of the Pod managed by the specified Deployment.

6. The canary release method according to claim 1, It is characterized in that Also includes; Before each canary release is re-executed, the canary Pod generated during the last canary release is deleted.

7. The canary release method according to claim 1, It is characterized in that Also includes: When a rollback request is received, the mirror address of the specified Deployment is set to the specified mirror address; The specified image address is the address of any image file used by the specified Deployment before the execution of the canary release.

8. A canary publishing device, It is characterized in that include: Find the Deployment unit, which is used to find the specified Deployment for canary release in the Kubernetes system; A canary Pod configuration information generating unit, configured to generate the configuration information of the canary Pod according to the configuration information of the Pod managed by the specified Deployment, wherein the selection tag in the configuration information of the canary Pod is the same as the selection tag in the configuration information of the Pod managed by the specified Deployment; the selection tag is used for the Service instance corresponding to the specified Deployment to forward the business request to the canary Pod and the Pod managed by the specified Deployment; A canary Pod image setting unit, used to set the image address in the configuration information of the canary Pod to the address of the specified target image; A canary Pod generation unit, used to call an interface of a Kubernetes system to directly generate a canary Pod according to the configuration information of the canary Pod; The official launch unit is configured to set the image address of the specified Deployment to the address of the specified target image if the business logic verification result of the service provided by the Canary Pod is determined to be passed, thereby completing the release and launch; The canary Pod configuration information generating unit includes: A Pod selection module, used to select a Pod from the Pods managed by the specified Deployment as a specific Pod; A configuration information cloning module, used to clone the configuration information corresponding to the specific Pod to obtain the configuration information corresponding to the canary Pod; A basic information clearing module, used to delete the status information, node information, IP information and cascade relationship information in the configuration information corresponding to the canary Pod; The inheritance relationship setting module is used to modify the cascade relationship information in the configuration information corresponding to the canary Pod to be inherited from the specific Pod.

9. A readable storage medium, It is characterized in that It stores program codes corresponding to the method for implementing any one of claims 1-7.

Images