CN113900668A

CN113900668A - Canary publishing method, device and readable storage medium

Info

Publication number: CN113900668A
Application number: CN202111151382.4A
Authority: CN
Inventors: 贾永鹏; 马超; 揭震
Original assignee: Sina Technology China Co Ltd
Current assignee: Sina Technology China Co Ltd
Priority date: 2021-09-29
Filing date: 2021-09-29
Publication date: 2022-01-07

Abstract

The embodiment of the invention provides a canary release method, a canary release device and a readable storage medium, wherein the canary release method comprises the following steps: finding a designated Delployment to be issued by canaries in a Kubernetes system; generating configuration information of the canary Pod according to the configuration information of the Pod managed by the specified Deployment, wherein a selection label in the configuration information of the canary Pod is the same as that in the configuration information of the Pod managed by the specified Deployment; setting the mirror image address in the configuration information of the canary Pod as the address of the specified target mirror image; calling an interface of a Kubernetes system to directly generate the canary Pod according to the configuration information of the canary Pod; and if the service logic verification result of the service provided by the canary Pod is judged to be passed, setting the mirror image address of the specified Deployment as the address of the specified target mirror image, and finishing releasing the online.

Description

Canary publishing method, device and readable storage medium

Technical Field

The invention relates to the field of computer application program release, in particular to a canary release method, a canary release device and a readable storage medium.

Background

In the prior art, when canary release is implemented in a kubernets system, configuration information of a Pod for canary release needs to be generated in a release that wants to be released, and a tag in the configuration information corresponding to the canary Pod needs to be set to be different from tags in configuration information of other pods managed by the release, so that the pods of two types of configuration information can exist in the same release at the same time. This approach modifies the context of the Deployment for handling the current online business, with the risk of affecting the current business handling.

Other third-party tools for realizing the release of the canaries based on the Kubernetes system need to introduce third-party self-defined resources into the Kubernetes by utilizing the self-defined resource function of the Kubernetes, and the realized canaries release system is complex and cannot be simply and quickly applied.

In the process of implementing the invention, the applicant finds that at least the following problems exist in the prior art:

the canary release method realized in the prior art is complex and needs to modify the current online operating environment.

Disclosure of Invention

The embodiment of the invention provides a canary publishing method, a canary publishing device and a readable storage medium, and solves the problems that the canary publishing method realized in the prior art is complex and needs to modify the current online operating environment.

To achieve the above object, in one aspect, an embodiment of the present invention provides a canary releasing method, including:

finding a designated Delployment to be issued by canaries in a Kubernetes system;

generating configuration information of canary Pod according to the configuration information of Pod managed by the specified Deployment, wherein a selection label in the configuration information of canary Pod is the same as that in the configuration information of Pod managed by the specified Deployment; the selected label is used for the Service instance corresponding to the specified delivery element to forward the Service request to the canary Pod and the Pod managed by the specified delivery element;

setting the mirror image address in the configuration information of the canary Pod as an address of a specified target mirror image;

calling an interface of a Kubernetes system to directly generate the canary Pod according to the configuration information of the canary Pod;

and if the service logic verification result of the service provided by the canary Pod is judged to be passed, setting the mirror image address of the specified Deployment as the address of the specified target mirror image, and finishing releasing and uploading.

Further, before finding the designated Deployment to be issued by canaries in the kubernets system, the method further comprises the following steps:

when a request issued by a canary is received, calling a packaging tool to package a specified service code into the specified target mirror image, and adding the specified target mirror image into a mirror image warehouse;

the canary release request includes the name of the specified Deployment, the namespace of the specified Deployment, the address of the mirror repository, and the name of the packaging tool.

Further, still include:

if the state of the canary Pod is judged to be a non-running state, an abnormal alarm is sent out;

the abnormality alarm indicates that the canary Pod is unavailable.

Further, still include:

and if the business logic verification result of the service provided by the canary Pod is judged to be failed, taking the canary Pod off the line.

Further, the off-line of the canary Pod specifically comprises:

and modifying the selected label in the configuration information of the canary Pod to be different from the selected label in the configuration information of the Pod managed by the appointed Deployment.

Further, the method also comprises the following steps;

before each canary release is re-executed, the canary Pod generated when the canary release is executed last time is deleted.

Further, still include:

when a rollback request is received, setting the mirror image address of the specified Delpoyment as a specified mirror image address;

the specified mirror image address is the address of any mirror image file used by the specified Deployment before the current gold sparrow is released and executed.

Further, the generating of the configuration information of the canary Pod according to the configuration information of the Pod managed by the specified Deployment includes:

selecting one Pod from the pods managed by the specified Deployment as a specific Pod;

cloning the configuration information corresponding to the specific Pod to obtain the configuration information corresponding to the canary Pod;

deleting state information, node information, IP information and cascade relation information in configuration information corresponding to the canary Pod;

and modifying the cascade relation information in the configuration information corresponding to the canary Pod to inherit the specific Pod.

On the other hand, the embodiment of the invention provides a canary releasing device, which comprises:

searching a delivery unit for finding a specified delivery to be issued by canaries in a Kubernets system;

a canary Pod configuration information generating unit, configured to generate configuration information of the canary pods according to the configuration information of the pods managed by the specified Deployment, where a selection tag in the configuration information of the canary pods is the same as a selection tag in the configuration information of the pods managed by the specified Deployment; the selected label is used for the Service instance corresponding to the specified delivery element to forward the Service request to the canary Pod and the Pod managed by the specified delivery element;

the canary Pod mirror image setting unit is used for setting a mirror image address in the configuration information of the canary Pod as an address of a specified target mirror image;

the canary Pod generating unit is used for calling an interface of a Kubernetes system to directly generate the canary Pod according to the configuration information of the canary Pod;

and the formal online unit is used for setting the mirror image address of the specified Deployment as the address of the specified target mirror image to finish releasing online if the business logic verification result of the service provided by the canary Pod is judged to be passed.

Further, still include:

the system comprises a receiving and issuing request unit, a receiving and issuing request unit and a processing unit, wherein the receiving and issuing request unit is used for calling a packaging tool to package a specified service code into a specified target mirror image and adding the specified target mirror image into a mirror image warehouse when receiving a canary issuing request;

Further, still include:

the abnormal alarm unit is used for giving an abnormal alarm if the state of the canary Pod is judged to be a non-running state;

the abnormality alarm indicates that the canary Pod is unavailable.

Further, still include:

and the canary Pod offline unit is used for offline the canary Pod if the business logic verification result of the service provided by the canary Pod is judged to be failed.

Further, the canary Pod offline unit is specifically configured to:

Further, the method also comprises the following steps;

and the canary Pod deleting unit is used for deleting the canary Pod generated when the canary release is executed last time before the canary release is executed again each time.

Further, still include:

the rollback unit is used for setting the mirror image address of the specified Delployment as a specified mirror image address when a rollback request is received;

Further, the canary Pod configuration information generating unit includes:

a Pod selection module, configured to select a Pod from the pods managed by the specified Deployment as a specific Pod;

the configuration information cloning module is used for cloning the configuration information corresponding to the specific Pod to obtain the configuration information corresponding to the canary Pod;

the basic information clearing module is used for deleting state information, node information, IP information and cascade relation information in the configuration information corresponding to the canary Pod;

and the inheritance relationship setting module is used for modifying the cascade relationship information in the configuration information corresponding to the canary Pod to inherit from the specific Pod.

In another aspect, an embodiment of the present invention provides a readable storage medium, which stores program codes for implementing any one of the methods described in the foregoing.

The technical scheme has the following beneficial effects: the method has the advantages that the interface of the Kubernetes system is directly used for creating the canary Pod according to the configuration information of the Pod managed by the specified delivery, so that the obtained canary Pod is independent of any delivery, the simple and easy-to-use automatic canary release based on the Kubernetes is realized under the conditions that the specified delivery on the current line is not changed and the self-defined resource is not required to be additionally introduced into the Kubernetes system, the third-party self-defined resource is not added, and the technical effect of service canary release based on the Kubernetes environment is realized under the condition of minimum resource overhead; furthermore, the created canary Pod is independent of any Deployment, automatic canary release is realized under the condition that the designated Deployment on the current line is not changed, the technical effects that the influence on the original environment is small, the canary release can be completed only by operating one Pod, and other Kubernets resources do not need to be modified are achieved. The method has the advantages that the repeated release, flow online, flow offline and rollback in the canary release process are achieved with the minimum development cost by fully utilizing the Service component of the Kubernets system according to the mechanism of distributing the request to the Pod by the selected label and the rollback mechanism of the depolyymet, the efficiency of achieving the canary release function is remarkably improved, meanwhile, the existing verified, stable and available functions of the Kubernets are fully utilized, and the achieved canary release function is more stable and reliable.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a flowchart of a canary release method according to one embodiment of the present disclosure;

fig. 2 is a schematic view of a canary release business process according to one embodiment of the present invention;

fig. 3 is an architecture diagram of a canary releasing device according to one embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

First, the following english names will be explained as appropriate:

the Kubernetes system is a portable, extensible, open source platform well known to those skilled in the art for managing containerized workloads and services that facilitate declarative configuration and automation;

the Deployment is a component in the Kubernets system for managing Pod, and provides declarative update capability for Pods and ReplicaSets;

pod is the smallest deployable computing unit that can be created and managed in a kubernets system;

ingresses is a component in the Kubernetes system, is an API object for managing external access to services in a cluster, and a typical access mode is HTTP, which can provide load balancing, SSL termination, and name-based virtual hosting;

service is a component in the Kubernetes system, and discloses an application program running on a group of Pods as an abstract method of network Service; a Service instance is an object that a Service component instantiates at runtime.

The API Server is in charge of providing HTTP API for the user, different parts in the cluster and the external components of the cluster to communicate with each other;

jenkins is an extensible persistent integration engine well known to those skilled in the art;

gitlab Runner is another continuously integrated tool well known to those skilled in the art.

The following examples illustrate the invention:

in one aspect, as shown in fig. 1, an embodiment of the present invention provides a canary publishing method, including:

step S100, finding a designated Delpoyment to be issued by canaries in a Kubernets system;

step S101, generating configuration information of canary Pod according to the configuration information of Pod managed by the specified Deployment, wherein a selection label in the configuration information of canary Pod is the same as that in the configuration information of Pod managed by the specified Deployment; the selected label is used for the Service instance corresponding to the specified delivery element to forward the Service request to the canary Pod and the Pod managed by the specified delivery element;

step S102, setting the mirror image address in the configuration information of the canary Pod as the address of the appointed target mirror image;

step S103, calling an interface of a Kubernetes system to directly generate the canary Pod according to the configuration information of the canary Pod;

and step S104, if the service logic verification result of the service provided by the canary Pod is judged to be passed, setting the mirror image address of the specified depolyment as the address of the specified target mirror image, and completing releasing and online.

In some embodiments, a Deployment can be specified by a given Deployment name and the namespace of the Deployment; and finding the appointed Delployment through an API Server in a Kubernetes system; generating configuration information of the canary Pod according to the configuration information of the Pod managed by the specified Deployment, so that the operating environment of the canary Pod is consistent with the Pod managed by the specified Deployment as much as possible, for example, a key item in the configuration information of the canary Pod can 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 can be cloned to serve as the configuration information of the canary Pod, and the obtained configuration information of the canary Pod can be modified appropriately on the basis of cloning; the specific method for generating the configuration information of the canary Pod can be realized according to specific conditions; further, in order to enable the request for the Pod managed by the designated Deployment to be evenly forwarded to the canary Pod, the selection tag in the configuration information of the canary Pod is set to be the same as the selection tag in the configuration information of the Pod managed by the designated Deployment. Setting a mirror image address in the configuration information of the canary Pod as an address of a specified target mirror image, wherein the specified target mirror image is a mirror image of a version to be issued by the canary at this time, and the specified target mirror image can be a pre-generated mirror image or can be a mirror image which is generated in advance, and when an issuing request is received, calling a packaging tool to package a specified service code into the specified target mirror image and storing the specified target mirror image at the address of the specified target mirror image; the specified target image may be stored in an image repository including, but not limited to; calling an interface of a Kubernetes system to directly generate the canary Pod according to the configuration information of the canary Pod, wherein the canary Pod is created by directly calling a related interface of the Kubernetes system instead of a controller inside the Deployment, so that the canary Pod is not managed by any Deployment; in the process of creating the canary Pod, no influence is generated on the specified Deployment, and the operation of the online service of the current version does not need to be changed. One or more canary Pod can be generated, which can be determined according to specific requirements; preferably, a canary Pod is generated, as shown in fig. 2, since 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 specified to be managed by the depolyment, the request of the end user is processed by the Ingress and Service of the kubernets system, which is distributed to the canary Pod and the Pod01, Pod02 and Pod03 specified to be managed by the depolyment, so that the Pod specified to be managed by the depolyment runs on Version of Version1 and the canary Pod runs on Version2 to be upgraded or online, which realizes the Version2 test or online of the partial flow. If the business logic verification aiming at the services of Version2 on the canary Pod passes, formal online can be carried out; the verification process can be manual verification, or tracking and checking of various service indexes can be realized through automatic testing or automatic monitoring, and finally the service logic of the service is verified; the result of manual or automatic verification can be sent to this embodiment, and when the result of the service logic verification of the service provided by the canary Pod is judged to pass, the mirror image address of the specified delivery is set as the address of the specified target mirror image, and a mechanism in the kubernets system triggers the specified delivery to execute an online operation, so that each Pod managed by the specified delivery is created again, and the old Pod is deleted, thereby completing the formal online of the canary release.

The embodiment of the invention has the following technical effects: the interface of the Kubernets system is directly used for creating the canary Pod according to the configuration information of the Pod managed by the specified delivery, so that the obtained canary Pod is independent of any delivery, and the simple and easy-to-use automatic canary release based on the Kubernets is realized under the conditions that the specified delivery on the current line is not changed and the self-defined resource is not required to be additionally introduced into the Kubernets system.

In some embodiments, the specified service code is a service code that is prepared to be issued to a Pod managed by a specified delivery by canary in advance, and as shown in fig. 2, when an issue request is received, a name of the specified delivery and a namespace of the specified delivery can be obtained from the request, the specified delivery can be found in a kubernets system according to the name of the specified delivery and the namespace of the specified delivery, and the specified delivery is the delivery to be issued by canary; and calling a packaging tool specified by the request to package the specified service codes into the specified target mirror image, and adding the specified target mirror image into the mirror image warehouse specified in the request. Packaging tools include, but are not limited to Jenkins and Gitlab Runner. If packaging for the specified service code fails, the developer is informed, and the developer can re-send the release request after modifying the specified service code.

The embodiment of the invention has the following technical effects: when the release request is received, a packaging tool is automatically called according to the information in the release request to automatically package the service codes and store the service codes in the mirror image warehouse, so that the automation of canary release is further realized, the repeated packaging operation of developers is reduced, the developers only need to pay attention to code writing, and the development and test efficiency of the developers is improved.

Further, still include:

the abnormality alarm indicates that the canary Pod is unavailable.

In some embodiments, if the canary Pod does not operate normally, since the Service component in the kubernets system has a detection mechanism, the state of the canary Pod is found not to be the operating state, and the terminal request will not be sent to the canary Pod, so that the effect of checking the availability of the Service provided by the canary Pod is achieved.

Further, still include:

In some embodiments, as shown in fig. 2, after the canary Pod provides services together with the Pod managed by the specified delivery, part of the end user request is distributed to the canary Pod through Ingress and Service, the Service logic of the Service applied by Version2 on the canary Pod is verified through the part of the traffic, and if the verification fails, the canary Pod is taken off line.

Further, the off-line of the canary Pod specifically comprises:

In some embodiments, as shown in fig. 2, if the canary Pod is operating normally, the end user's request may arrive above the canary Pod, at which point it may be detected whether there is a problem with the business logic of the service. If a problem of Service logic is found in a manual verification mode, a developer can send a offline flow request, or an automatic testing or monitoring component sends the offline flow request in an automatic testing or monitoring mode, when the verification is judged not to pass through the lower limit flow request, the API Server of the Kubernetes system can be called to operate the canary Pod, the content of a selection tag in the configuration information of the canary Pod is modified, the content of the selection tag in the configuration information of the canary Pod is different from the content of the selection tag in the configuration information of the Pod managed by a specified delivery, so that a Service instance corresponding to a delivery cannot find the canary Pod through the tag, and an end user does not request the top of the canary Pod. Therefore, the problem expansion can be avoided, and the quick flow offline function issued by the gold sparrows is realized.

Further, the method also comprises the following steps;

In some embodiments, if the foregoing canary release fails, for example, after the offline flow rate is reached, and the developer modifies the specified service code, and needs to perform the canary release again, before the canary release is re-executed, in order to update the configuration information of the canary Pod when the release is re-executed, the canary Pod created during the foregoing canary release needs to be deleted, so that the canary Pod is created again when the release is re-executed this time. The embodiment of the invention can ensure that the configuration information of the canary Pod is the latest when the canary is issued each time, the interference of the previous issuance can not be received, and the stability of the canary issuance each time is ensured.

Further, still include:

In some embodiments, after the designated target image is formally online, if a service logic of the service is found to be problematic, the designated delivery element may be rolled back when a roll-back request is received, the rolled-back image may be defined by an address of the designated image, an address of a known stable version of the image may be used fixedly, or an address of the image of a version to be rolled back may be specified in the roll-back request. After receiving the rollback request, the mirror address of the specified Delpoyment is modified by calling the API Server. When finding that the mirror image address of the designated Deployment is modified, the controller of the designated Deployment triggers the rolling update of the Pod managed by the designated Deployment to complete service rollback.

The embodiment of the invention has the following technical effects: the technical scheme of the invention fully utilizes the existing mechanism provided by Kubernets to realize rapid and safe rollback after business logic of service is found to have problems after business codes are formally online, thereby simplifying the reproducibility of the canary publishing method, and the canary publishing method is simple and easy to use.

In some embodiments, as shown in fig. 2, after the specified service code is packaged, the packaging information is returned, the API Server is called, the specified delivery element that needs to be issued by canaries is searched, after the corresponding specified delivery element is found, three pods managed by the specified delivery element are found according to the UID of the delivery element, one Pod is randomly selected, and the configuration information of the Pod is obtained. As shown in fig. 2, Pod03 is obtained in this embodiment. Cloning a copy of configuration information of the Pod03 to obtain configuration information corresponding to the canary Pod, and deleting state information, node information, IP information and cascade relation information in the configuration information corresponding to the canary Pod. Because the configuration information of the canary Pod is the configuration information cloned from the Pod managed by the specified delivery, the tag information in the configuration information of the canary Pod is the same as the tag information in the configuration information of the Pod managed by the specified delivery, and the selection tag in the configuration information is a part or all of the tag information in the configuration information, so that the selection tag in the configuration information of the canary Pod can be naturally ensured to be the same as the selection tag of the configuration information of the Pod managed by the specified delivery, and the canary Pod and the Pod managed by the specified delivery can be called by the same Service instance in a balanced manner. And modifying the cascade relation information in the configuration information corresponding to the gold sparrow Pod into inheriting from Pod 03. The mirror address of the canary Pod is modified to be the newly released Version of Version 2. The method comprises the steps of establishing the canary Pod according to configuration information of the canary Pod through an interface of a Kubernetes system, starting to be on-line formally after the fact that the canary is successfully released is finally confirmed, and updating a mirror image address of a designated Deployment into an address of a designated target mirror image through calling an API Server. The controller of the specified delivery finds that the specified delivery is modified, and triggers a rolling update of the Pod managed by the specified delivery. Namely: and (4) newly creating a new Pod, and deleting the old Pod after the new Pod operates normally. As shown in fig. 2, the result of the rolling update is: the original Pod01, Pod02, and Pod03 will all be deleted, and three new pods will be created. Depending on a Kubernetes GC garbage recycling mechanism, the association relation of the canary Pod is set to inherit from the Pod03, the Pod03 is deleted after formal online completion, and the Kubernetes GC triggers the garbage recycling mechanism to delete the canary Pod. After the final online completion is ensured, the environment of the whole new version is completely the same as the environment of the previous version.

The embodiment of the invention has the following technical effects: the configuration information is cloned from the Pod managed by the designated Deployment, so that the environment of the canary Pod and the environment of the current online service running in the Pod managed by the designated Deployment can be kept the same, and the accuracy of service logic verification in the process of releasing the canary is ensured. The canary Pod is set to inherit from the Pod managed by the specified delivery, when the specified delivery is put on line formally, a garbage recycling mechanism of Kubernets GC can be utilized, when the specified delivery deletes the Pod inherited by the canary Pod, the canary Pod is deleted at the same time, and the effect that the specified delivery is not changed and the canary Pod for releasing canaries is not left in the system after the specified delivery is put on line formally is achieved.

On the other hand, as shown in fig. 3, an embodiment of the present invention provides a canary releasing device, including:

a depolyment unit 300 is searched for finding a designated depolyment to be issued by canaries in a kubernets system;

a canary Pod configuration information generating unit 301, configured to generate configuration information of canary pods according to the configuration information of pods managed by the specified Deployment, where a selection tag in the configuration information of canary pods is the same as a selection tag in the configuration information of pods managed by the specified Deployment; the selected label is used for the Service instance corresponding to the specified delivery element to forward the Service request to the canary Pod and the Pod managed by the specified delivery element;

a canary Pod mirror setting unit 302, configured to set a mirror address in the configuration information of the canary Pod as an address of a specified target mirror;

the canary Pod generating unit 303 is configured to invoke an interface of a Kubernetes system to directly generate the canary Pod according to the configuration information of the canary Pod;

and a formal online unit 304, configured to set the image address of the specified Deployment as the address of the specified target image if it is determined that the service logic verification result of the service provided by the canary Pod passes, and complete online publishing.

Further, still include:

the abnormality alarm indicates that the canary Pod is unavailable.

Further, still include:

Further, the canary Pod offline unit is specifically configured to:

Further, the method also comprises the following steps;

Further, still include:

Further, the canary Pod configuration information generating unit 301 includes:

The corresponding embodiments of a canary dispensing device can be understood by those skilled in the art from the description of the embodiments related to a canary dispensing method, and will not be described in detail herein.

The embodiment of the invention has the following beneficial effects: the method has the advantages that the interface of the Kubernetes system is directly used for creating the canary Pod according to the configuration information of the Pod managed by the specified delivery, so that the obtained canary Pod is independent of any delivery, the simple and easy-to-use automatic canary release based on the Kubernetes is realized under the conditions that the specified delivery on the current line is not changed and the self-defined resource is not required to be additionally introduced into the Kubernetes system, the third-party self-defined resource is not added, and the technical effect of service canary release based on the Kubernetes environment is realized under the condition of minimum resource overhead; furthermore, the created canary Pod is independent of any Deployment, automatic canary release is realized under the condition that the designated Deployment on the current line is not changed, the technical effects that the influence on the original environment is small, the canary release can be completed only by operating one Pod, and other Kubernets resources do not need to be modified are achieved. The method has the advantages that the repeated release, flow online, flow offline and rollback in the canary release process are achieved with the minimum development cost by fully utilizing the Service of the Kubernets system per se according to the mechanism of distributing the request to the Pod by the selected label and the rollback mechanism of the depolyymet, the efficiency of achieving the canary release function is remarkably improved, meanwhile, the existing verified, stable and available functions of the Kubernets are fully utilized, and the achieved canary release function is more stable and reliable.

The above technical solutions of the embodiments of the present invention are described in detail below with reference to specific application examples, and reference may be made to the foregoing related descriptions for technical details that are not described in the implementation process.

The API Server is an API interface externally provided by Kubernets, and the logic processing module operates various resources on the Kubernets through the Service, such as Ingress, Service, delivery, Pod, canary Pod and the like.

The packaging module is mainly used for packaging the service codes, namely the designated service codes into the mirror image file and pushing the mirror image file to the mirror image warehouse. The logic processing module is only responsible for calling the interface of a packing tool (such as Jenkins and Gitlab Runner) to pack codes, and a packing result is returned to the logic processing module to judge whether the packing is successful or not.

Logic processing module (i.e. canary release device):

as shown in fig. 2, when a canary needs to be released during development, the name of the depolyment that needs to provide a service, the name space where the depolyment is located, the address of the mirror image warehouse, and the name information of the packing module, and sends an HTTP request to the logic processing module;

after receiving the request, the logic processing module calls an interface of the packing module to trigger a packing tool (Jenkins or Gitlab Runner) to carry out packing operation of codes, and packed mirror images are pushed to a mirror image warehouse after packing is completed. Such as: the mirrored Version of this packaging is Version 2.

And returning packaging information after packaging is finished, if the packaging is successful, calling an API Server, searching and developing a demand delivery agent (namely, a specified delivery agent) which needs to be issued by canaries, finding a corresponding delivery agent (namely, a specified delivery agent), finding three Pod (namely, Pod01, Pod02 and Pod03 in the figure 2) managed by the specified delivery agent according to the UID of the specified delivery agent, and randomly selecting one Pod to obtain configuration information of the Pod. The Pod obtained in the embodiment of the invention is Pod 03. If packaging fails, the logic processing module returns to development to inform packaging failure, and the development can modify own codes and then re-issue canaries.

After the configuration information of the Pod03 is acquired, a copy of the configuration information of the Pod03 is cloned, and then state information, node information, IP information and cascade relation information of the configuration information are deleted.

The modified Pod configuration information is added with cascade relation information again, the cascade relation is the cascade relation of Pod03 and canary Pod, and in order to enable the canary Pod, the canary Pod is known to be cloned from Pod 03.

The mirror address of the canary Pod is modified to be the mirror address of the newly released Version2 instead of the mirror address of Version1 in Pod 03.

After a terminal user requests Service through a domain name, the request can reach Ingress firstly, the Ingress finds Service through the configured Service name, the Service finds a Pod managed by the designated delivery through the selected tag, and finally the request is processed through Pod01, Pod02 and Pod 03.

If the canary Pod does not normally operate, the Service has a detection mechanism, finds that the state of the canary Pod is not an operating state, and the request is not sent to the canary Pod, so that the purpose of releasing canary is achieved, and the availability of the Service is checked.

If the canary Pod is operating normally, the request can reach the upper side of the canary Pod, and whether the service logic of the service has a problem or not can be detected. If the Service logic is found to be in a problem, the development can send a offline flow request to the logic processing module, the logic processing module calls the API Server, the canary Pod is operated, the tag information of the canary Pod is modified, the Service cannot find the canary Pod through the tag after the tag is modified, and the end user does not request the canary Pod. Therefore, the problem can be avoided from being enlarged, the other purpose of the canary release is achieved, and the rapid flow offline function is achieved.

After the modified codes are developed after the offline flow, the canary can be released again. In this release, the logic processing module deletes the canary Pod created before, ensures that the configuration of the canary Pod is up-to-date, and then recreates the canary Pod.

And finally, after the development confirms that the golden peacock is successfully released, the logic processing module starts to formally go online, and the logic processing module calls the API Server to update the mirror image address of the specified Delpoyment. The specified delivery controller, upon discovering that the specified delivery is modified, triggers a rolling update of the Pod managed by the specified delivery. Namely: and (4) newly creating a new Pod, and deleting the old Pod after the new Pod operates normally. The result of the rolling update is: pod01, Pod02, Pod03 will all be deleted, and three new pods will be created.

Depending on a kubernets GC garbage recycling mechanism, the association relation of canary Pod points to Pod03, Pod03 is deleted after formal online completion, and the kubernets GC triggers the garbage recycling mechanism to delete canary Pod. After the final online completion is ensured, the environment of the whole new version is completely the same as the environment of the previous version.

By this, the entire canary release was complete. The service requested by the user changes from Version1 to Version 2.

If the service logic of the service is found to have problems after formal online development is completed, a rollback request can be sent to the logic processing module, and the version to be rolled back is indicated in the request. And the logic processing module calls the API Server after receiving the request and modifies the mirror image address of the specified Delpoyment. And after the designated delivery controller finds that the designated delivery is modified, the designated delivery controller triggers the rolling update of the Pod to complete service rollback.

The embodiment of the invention has the following technical effects: under the condition that the user-defined resource is not required to be introduced by using the user-defined resource function of the Kubernetes system, the canary release based on the Kubernetes service can be realized; the influence on the original environment is small, the release of the peacock can be completed only by operating one Pod, and other Kubernets resources do not need to be modified. The canary releasing process can be repeated, and the flow can be repeatedly released, the flow can be on-line, the flow can be off-line and rolled back.

It should be understood that the specific order or hierarchy of steps in the processes disclosed is an example of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged without departing from the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not intended to be limited to the specific order or hierarchy presented.

In the foregoing detailed description, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments of the subject matter require more features than are expressly recited in each claim. Rather, as the following claims reflect, invention lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby expressly incorporated into the detailed description, with each claim standing on its own as a separate preferred embodiment of the invention.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. To those skilled in the art; various modifications to these embodiments will be readily apparent, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the aforementioned embodiments, but one of ordinary skill in the art may recognize that many further combinations and permutations of various embodiments are possible. Accordingly, the embodiments described herein are intended to embrace all such alterations, modifications and variations that fall within the scope of the appended claims. Furthermore, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising: as interpreted by the use of "in the claims as a conjunction. Furthermore, any use of the term "or" in the specification of the claims is intended to mean a "non-exclusive or".

Those of skill in the art will further appreciate that the various illustrative logical blocks, units, and steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate the interchangeability of hardware and software, various illustrative components, elements, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design requirements of the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present embodiments.

The various illustrative logical blocks, or elements, described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor, an Application Specific Integrated Circuit (ASIC), a field programmable gate array or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other similar configuration.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may be stored in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. For example, a storage medium may be coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC, which may be located in a user terminal. In the alternative, the processor and the storage medium may reside in different components in a user terminal.

In one or more exemplary designs, the functions described above in connection with the embodiments of the invention may be implemented in hardware, software, firmware, or any combination of the three. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media that facilitate transfer of a computer program from one place to another. Storage media may be any available media that can be accessed by a general purpose or special purpose computer. For example, such computer-readable media can include, but is not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store program code in the form of instructions or data structures and which can be read by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Additionally, any connection is properly termed a computer-readable medium, and, thus, is included if the software is transmitted from a website, server, or other remote source via a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wirelessly, e.g., infrared, radio, and microwave. Such discs (disk) and disks (disc) include compact disks, laser disks, optical disks, DVDs, floppy disks and blu-ray disks where disks usually reproduce data magnetically, while disks usually reproduce data optically with lasers. Combinations of the above may also be included in the computer-readable medium.

The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims

1. A canary release method is characterized by comprising the following steps:

2. The canary release method of claim 1, further comprising, prior to finding the designated release to be issued by canaries in the kubernets system:

3. The canary releasing method of claim 1, further comprising:

the abnormality alarm indicates that the canary Pod is unavailable.

4. The canary releasing method of claim 1, further comprising:

5. The canary releasing method of claim 4, wherein taking the canary Pod off-line specifically comprises:

6. The canary releasing method of claim 1, further comprising;

7. The canary releasing method of claim 1, further comprising:

8. The canary releasing method of claim 1, wherein the generating the configuration information of the canary Pod according to the configuration information of the Pod managed by the specified delivery comprises:

9. A canary dispensing device, comprising:

10. A readable storage medium, characterized in that it stores a corresponding program code for implementing the method according to any one of claims 1-8.