Kubernetes Resource Release Method and Device for Blue-Green Deployment

Abstract

The present application provides a method and device for releasing Kubernetes resources for blue-green deployment. By applying for temporary node nodes, it is possible to use the Kubernetes cluster to meet the double resource requirements during the blue-green deployment process. After the deployment is completed, the temporary node nodes can be removed to save resources. Moreover, before removing the temporary node nodes, through rolling updates, the new version of the application can be smoothly scheduled from the temporary node nodes to the fixed node nodes, and then the temporary node nodes are removed to avoid the application load jitter caused by resource release, achieving both resource savings and avoiding the application load jitter caused by resource release. In addition, the officially released application will ultimately remain on the fixed node nodes that have been purchased for a long time, which can maximize service stability. Also, setting the temporary node nodes to an invalid state can reduce cost expenditures.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a kubernetes resource release method and device for blue-green deployment. Background Art

[0002] During the application release process, the purpose of using the blue-green release process is generally to reduce the jitter of the application load during the release process and be able to quickly roll back in case of problems during the release process, minimizing the impact on the online system. However, the above method requires preparing double the resources, and the extra resources are not used usually, which is a waste.

[0003] Thus, it is impossible to save resources and reduce the jitter of the application load at the same time. Summary of the Invention

[0004] To solve the above technical problems, the technical solutions provided by the embodiments of this application are as follows:

[0005] A kubernetes resource release method for blue-green deployment, characterized by including:

[0006] If there is an application program of the current version in the kubernetes cluster used to execute the application blue-green deployment task, set the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application program of the current version;

[0007] Apply for a temporary node, and add the temporary node to the kubernetes cluster;

[0008] Set taints for the temporary node so that the temporary node does not accept the use of application programs that do not have taint toleration settings;

[0009] Set an affinity label for the temporary node;

[0010] Perform taint toleration settings for the application program of the new version and perform affinity settings for the affinity label so that the application program of the new version can be scheduled to the temporary node;

[0011] Modify the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application program of the new version;

[0012] Judge whether the application program of the new version on the temporary node meets the expectations;

[0013] If not, modify the traffic scheduling policy scheme again to schedule the requests of users accessing the application to the application program of the current version;

[0014] Delete the application of the new version;

[0015] Remove the temporary node from the kubernetes cluster;

[0016] If it meets the conditions, delete the application of the current version, roll out and update the application of the new version to the fixed nodes in the kubernetes cluster, and cancel the taint tolerance setting and affinity setting of the application of the new version;

[0017] Remove the temporary node from the kubernetes cluster.

[0018] Optionally, after removing the temporary node from the kubernetes cluster, it further includes:

[0019] Set the temporary node to an invalid state.

[0020] Optionally, the rolling out and updating the application of the new version to the fixed nodes in the kubernetes cluster includes:

[0021] Cancel the taint tolerance setting and affinity setting in the deployment object for managing the pod object corresponding to the application of the new version, redeploy the deployment object, and set the update policy of the redeployed deployment object, so that the redeployed deployment object rolls out and updates the pod object corresponding to the application of the new version to the fixed nodes in the kubernetes cluster based on the update policy.

[0022] Optionally, the rolling out and updating the application of the new version to the fixed nodes in the kubernetes cluster includes:

[0023] For the application of the new version, deploy a new deployment. Based on the update policy, delete the pod objects managed by the original deployment corresponding to the application of the new version, scale out the new deployment based on the deleted pod objects, so that the new deployment gets the pod objects corresponding to the application of the new version, and roll out and update the pod objects to the fixed nodes in the kubernetes cluster. The new deployment does not have taint tolerance setting and affinity setting.

[0024] A kubernetes resource release device for blue-green release, including:

[0025] The first setting module is used to set the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application of the current version if there is an application of the current version in the kubernetes cluster used to execute the blue-green release task of the application.

[0026] The application and joining module is used to apply for a temporary node and join the temporary node to the kubernetes cluster.

[0027] The second setting module is used to set taints for the temporary node so that the temporary node does not accept the use of applications that do not have taint toleration settings.

[0028] The third setting module is used to set an affinity label for the temporary node.

[0029] The fourth setting module is used to perform taint toleration settings on the application of the new version and perform affinity settings on the affinity label so that the application of the new version can be scheduled to the temporary node.

[0030] The first modification module is used to modify the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application of the new version.

[0031] The judgment module is used to judge whether the application of the new version on the temporary node meets the expectations.

[0032] The second modification module is used to, if the application of the new version does not meet the expectations, re-modify the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application of the current version.

[0033] The first deletion module is used to delete the application of the new version.

[0034] The removal module is used to remove the temporary node from the kubernetes cluster.

[0035] The second deletion module is used to, if the application of the new version meets the expectations, delete the application of the current version.

[0036] The update module is used to roll out and update the application of the new version to the fixed nodes in the kubernetes cluster.

[0037] The cancellation module is used to cancel the taint toleration settings and affinity settings of the application of the new version and trigger the execution of the removal module.

[0038] Optionally, the device further includes:

[0039] A fifth setting module, configured to set the temporary node node to an invalid state.

[0040] Optionally, the update module is specifically configured to:

[0041] Cancel the taint tolerance setting and affinity setting in the deployment object for managing the pod object corresponding to the new version of the application, redeploy the deployment object, and set the update policy of the redeployed deployment object, so that the redeployed deployment object rolls updata the pod object corresponding to the new version of the application to the fixed node nodes in the kubernetes cluster based on the update policy.

[0042] Optionally, the update module is specifically configured to:

[0043] For the new version of the application, deploy a new deployment. Based on the update policy, delete the pod objects managed by the original deployment corresponding to the new version of the application, scale out the new deployment based on the deleted pod objects, so that the new deployment obtains the pod objects corresponding to the new version of the application, and roll updata the pod objects to the fixed node nodes in the kubernetes cluster. The new deployment does not have taint tolerance settings and affinity settings.

[0044] A control node includes: a control component and a storage component;

[0045] The storage component is configured to store at least a set of instruction sets;

[0046] The control component is configured to call and execute the instruction sets in the first storage component, and execute the kubernetes resource release method for blue-green release as described in any one of the above by executing the instruction sets.

[0047] A storage medium stores a computer program for implementing the kubernetes resource release method for blue-green release as described in any one of the above. The computer program is executed by a processor to implement the kubernetes resource release for blue-green release as described in any one of the above.

[0048] Compared with the prior art, the beneficial effects of the present application are:

[0049] In this application, by applying for a temporary node, the kubernetes cluster is utilized to meet the double resource requirements during the blue-green release. After the release is completed, the temporary node can be removed to save resources. Moreover, before removing the temporary node, the new version of the application can be smoothly scheduled from the temporary node to the fixed node through rolling updates, and then the temporary node is removed to avoid the application load jitter caused by resource release, achieving both resource savings and avoiding application load jitter during resource release. Description of the Drawings

[0050] In combination with the drawings and with reference to the following specific embodiments, the above and other features, advantages and aspects of the various embodiments of the present disclosure will become more apparent. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the original parts and elements are not necessarily drawn to scale.

[0051] Figure 1 is a flowchart of a kubernetes resource release method for blue-green release provided in Embodiment 1 of the present application;

[0052] Figure 2 is a schematic diagram of the resource structure of a kubernetes cluster provided by the present application;

[0053] Figure 3 is a flowchart of a kubernetes resource release method for blue-green release provided in Embodiment 2 of the present application;

[0054] Figure 4 is a schematic diagram of the structure of a kubernetes resource release device for blue-green release provided by the present application. Detailed Description of the Embodiments

[0055] The embodiments of the present disclosure will be described in more detail below with reference to the drawings. Although some embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. On the contrary, these embodiments are provided to more thoroughly and completely understand the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not used to limit the protection scope of the present disclosure.

[0056] As used herein, the term "including" and its variations are open-ended, that is, "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0057] It should be noted that the concepts such as "first", "second", etc. mentioned in this disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or mutual dependence relationship of the functions performed by these devices, modules or units.

[0058] It should be noted that the modifications of "one" and "multiple" mentioned in this disclosure are illustrative rather than restrictive. Those skilled in the art should understand that unless otherwise clearly specified in the context, it should be understood as "one or more".

[0059] Next, the kubernetes resource release method for blue-green deployment disclosed in the embodiments of this application will be introduced. As Figure 1 shown, it is a flowchart of a kubernetes resource release method for blue-green deployment provided by Embodiment 1 of this application. This method may include but is not limited to the following steps:

[0060] Step S11: If there is an application program of the current version in the kubernetes cluster used to execute the application blue-green deployment task, set the traffic scheduling policy scheme to schedule the requests of users to access the application to the application program of the current version.

[0061] In this embodiment, it is possible to check the deployment in the kubernetes cluster used to execute the application blue-green deployment task to determine whether there is a pod object of the application program of the current version that is running normally. If there is a pod object of the application program of the current version that is running normally, it is determined that there is an application program of the current version in the kubernetes cluster used to execute the application blue-green deployment task.

[0062] And confirm the version of the pod object. If the version of the pod object is the version of the deployment, service can be used to bind the deployment for traffic scheduling; if the version of the pod object is the version of the application program, gateway can be used for traffic scheduling of the application version.

[0063] The traffic scheduling policy scheme may include but is not limited to: the traffic scheduling scheme using gateway or service.

[0064] Step S12: Apply for a temporary node and add the temporary node to the Kubernetes cluster.

[0065] In this embodiment, the temporary node can be applied for according to the resource usage or the short-term ECS instance resources. Also, use the kubeadm join command to add the temporary node to the Kubernetes cluster.

[0066] The Kubernetes cluster with the added temporary node includes fixed cluster resources and temporary cluster resources. The nodes included in the fixed cluster resources are the original nodes, and the temporary cluster resources include the temporary node, as Figure 2 shown. It should be noted that Figure 2 This is only one example and does not limit the number of original nodes and temporary nodes in this application.

[0067] Step S13: Set taints for the temporary node so that the temporary node does not accept applications that do not have taint toleration settings.

[0068] In this embodiment, it is possible but not limited to use kubectl taint nodes node1 key=value:NoExecute to set taints for the temporary node.

[0069] Step S14: Set an affinity label for the temporary node.

[0070] In this embodiment, kubectl label nodes node key=value can be used to set an affinity label for the temporary node.

[0071] Step S15: Perform taint toleration settings on the new version of the application and affinity settings on the affinity label so that the new version of the application can be scheduled to the temporary node.

[0072] In the deployment, taint toleration settings on the new version of the application and affinity settings on the affinity label can be performed in various ways (such as kubectl, helm, or calling the master api with javaClient, etc.). The following is a setting example for a simple explanation of taint toleration settings and affinity settings on the affinity label:

[0073] Taint toleration settings:

[0074] tolerations[0].key=key

[0075] tolerations[0].operator = Equal

[0076] tolerations[0].value = value

[0077] tolerations[0].effect = NoExecute

[0078] Affinity setting:

[0079] affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[0].key = key

[0080] affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[0].operator = In

[0081] affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[0].values[0] = value

[0082] Step S16, modify the traffic scheduling policy plan to schedule the requests of users accessing the application to the new version of the application program.

[0083] Specifically, the traffic scheduling policy plan using the gateway can be modified, such as {weight: 1, version: v0.1}, to direct all traffic to the new version of the application program; or, the traffic scheduling policy plan using the service can be modified, such as setting service spec selector version: v0.1 to direct the service traffic to the pod objects of the newly deployed deployment corresponding to the temporary node.

[0084] Step S17, determine whether the new version of the application program on the temporary node meets the expectations.

[0085] If not, execute step S18; if so, execute step S111.

[0086] Step S18: Modify the traffic scheduling policy again to schedule the requests of users accessing the application to the application of the current version.

[0087] In this embodiment, the traffic scheduling policy can be modified again in the same way as in step S16 to schedule the requests of users accessing the application to the application of the current version, which will not be elaborated here.

[0088] Step S19: Delete the application of the new version.

[0089] Step S110: Remove the temporary node from the kubernetes cluster.

[0090] Step S111: Delete the application of the current version, roll out and update the application of the new version to the fixed nodes in the kubernetes cluster, and cancel the taint tolerance setting and affinity setting of the application of the new version.

[0091] In this embodiment, the rolling out and updating the application of the new version to the fixed nodes in the kubernetes cluster may include, but are not limited to:

[0092] S1111: Cancel the taint tolerance setting and affinity setting in the deployment object for managing the pod object corresponding to the application of the new version, redeploy the deployment object, and set the update policy of the redeployed deployment object, so that the redeployed deployment object rolls out and updates the pod object corresponding to the application of the new version to the fixed nodes in the kubernetes cluster based on the update policy.

[0093] Of course, the rolling out and updating the application of the new version to the fixed nodes in the kubernetes cluster also includes, but are not limited to:

[0094] S1112. For the application program corresponding to the new version, deploy a new deployment. Based on the update policy, delete the pod objects managed by the original deployment corresponding to the application program of the new version. Expand the new deployment based on the deleted pod objects, so that the new deployment obtains the pod objects corresponding to the application program of the new version, and roll-update the pod objects to the fixed node nodes in the kubernetes cluster. The new deployment does not perform taint tolerance settings and affinity settings.

[0095] After canceling the taint tolerance settings and affinity settings of the application program of the new version, execute step S110.

[0096] In this embodiment, by applying for temporary node nodes, the kubernetes cluster is utilized to meet the double resource requirements during the blue-green release process. After the release is completed, the temporary node nodes can be removed to save resources. And before removing the temporary node nodes, through rolling update, the application program of the new version can be smoothly scheduled from the temporary node nodes to the fixed node nodes, and then the temporary node nodes are removed to avoid the application load jitter caused by resource release, realizing resource savings while avoiding the application load jitter caused by resource release.

[0097] Moreover, the officially released application will finally be retained on the fixed node nodes that have been purchased for a long time, which can maximize the service stability.

[0098] As another alternative embodiment of the present application, refer to Figure 3 , which is a flowchart of Embodiment 2 of a kubernetes resource release method for blue-green release provided by the present application. This embodiment is mainly an extended solution for the kubernetes resource release method for blue-green release described in the above Embodiment 1. As Figure 3 shown, the method may include but is not limited to the following steps:

[0099] Step S21. If there is an application program of the current version in the kubernetes cluster used to execute the blue-green release task of the application, set the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application program of the current version.

[0100] Step S22. Apply for temporary node nodes and add the temporary node nodes to the kubernetes cluster.

[0101] Step S23: Set taints for the temporary node so that the temporary node does not accept applications that have not been set with taint toleration.

[0102] Step S24: Set an affinity label for the temporary node.

[0103] Step S25: Set taint toleration for the new version of the application and perform affinity settings for the affinity label so that the new version of the application can be scheduled to the temporary node.

[0104] Step S26: Modify the traffic scheduling policy plan to schedule requests from users accessing the application to the new version of the application.

[0105] Step S27: Determine whether the new version of the application on the temporary node meets the expectations.

[0106] If not, execute Step S28; if so, execute Step S212.

[0107] Step S28: Re-modify the traffic scheduling policy plan to schedule requests from users accessing the application to the current version of the application.

[0108] Step S29: Delete the new version of the application.

[0109] Step S210: Remove the temporary node from the kubernetes cluster.

[0110] For the detailed processes of Steps S21 - S210, reference can be made to the relevant descriptions of Steps S11 - S110 in Embodiment 1, which will not be elaborated here.

[0111] Step S211: Set the temporary node to an invalid state.

[0112] Setting the temporary node to an invalid state means returning the temporary node to reduce cost expenditure.

[0113] Step S212: Delete the current version of the application, perform a rolling update of the new version of the application to the fixed nodes in the kubernetes cluster, and cancel the taint toleration settings and affinity settings for the new version of the application.

[0114] For the detailed process of Step S212, reference can be made to the relevant description of Step S111 in Embodiment 1, which will not be elaborated here.

[0115] After canceling the taint toleration settings and affinity settings for the new version of the application, execute Step S210 and Step S211.

[0116] In this embodiment, by applying for a temporary node, the kubernetes cluster is utilized to meet the double resource requirements during the blue-green release. After the release is completed, the temporary node can be removed to save resources. Moreover, before removing the temporary node, the new version of the application can be smoothly scheduled from the temporary node to the fixed node through rolling updates, and then the temporary node is removed to avoid the application load jitter caused by resource release, thus saving resources while avoiding the application load jitter caused by resource release.

[0117] Furthermore, the officially released application will ultimately remain on the fixed nodes that have been purchased for a long time, which can maximize service stability. In addition, the temporary node is set to an invalid state to reduce cost expenditure.

[0118] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only for illustrative purposes and do not limit the scope of these messages or information.

[0119] Although the operations are depicted in a particular order, this should not be construed as requiring that the operations be performed in the particular order shown or in sequential order. In certain circumstances, multitasking and parallel processing may be advantageous.

[0120] It should be understood that the various steps recited in the method embodiments of the present disclosure may be executed in a different order and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this regard.

[0121] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages or combinations thereof. The above-mentioned programming languages include, but are not limited to, object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., by connecting through an Internet service provider using the Internet).

[0122] Next, the kubernetes resource release device provided by this application for blue-green release will be introduced. The kubernetes resource release device for blue-green release introduced below can be correspondingly referred to the kubernetes resource release method for blue-green release introduced above.

[0123] Please refer to Figure 4 , the kubernetes resource release device for blue-green release includes: a first setting module 10, an application and joining module 20, a second setting module 30, a third setting module 40, a fourth setting module 50, a first modification module 60, a judgment module 70, a second modification module 80, a first deletion module 90, a removal module 100, a second deletion module 110, an update module 120, and a cancellation module 130.

[0124] The first setting module 10 is used to set the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application of the current version if there is an application of the current version in the kubernetes cluster for executing the blue-green release task of the application;

[0125] The application and joining module 20 is used to apply for a temporary node and join the temporary node to the kubernetes cluster;

[0126] The second setting module 30 is used to perform taint settings on the temporary node so that the temporary node does not accept the use of applications that have not been set with taint toleration;

[0127] The third setting module 40 is used to set an affinity label for the temporary node;

[0128] The fourth setting module 50 is used to perform taint toleration settings on the application of the new version and perform affinity settings on the affinity label so that the application of the new version can be scheduled to the temporary node;

[0129] The first modification module 60 is used to modify the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application of the new version;

[0130] The judgment module 70 is used to judge whether the application of the new version on the temporary node meets the expectations;

[0131] The second modification module 80 is used to, if the application of the new version does not meet the expectations, re-modify the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application of the current version;

[0132] The first deletion module 90 is used to delete the application of the new version;

[0133] The removal module 100 is used to remove the temporary node from the Kubernetes cluster;

[0134] The second deletion module 110 is used to delete the current version of the application if the new version of the application meets the expectations;

[0135] The update module 120 is used to roll out and update the new version of the application to the fixed nodes in the Kubernetes cluster;

[0136] The cancellation module 130 is used to cancel the taint tolerance setting and affinity setting of the new version of the application, and trigger the execution of the removal module.

[0137] The above device may further include:

[0138] The fifth setting module is used to set the temporary node to an invalid state.

[0139] The update module 120 may specifically be used for:

[0140] Cancel the taint tolerance setting and affinity setting in the deployment object for managing the pod object corresponding to the new version of the application, redeploy the deployment object, and set the update policy of the redeployed deployment object, so that the redeployed deployment object rolls out and updates the pod object corresponding to the new version of the application to the fixed nodes in the Kubernetes cluster.

[0141] The update module 120 may specifically be used for:

[0142] For the new version of the application, deploy a new deployment. Based on the update policy, delete the pod object managed by the original deployment corresponding to the new version of the application, scale out the new deployment based on the deleted pod object, so that the new deployment obtains the pod object corresponding to the new version of the application, and roll out and update the pod object to the fixed nodes in the Kubernetes cluster. The new deployment does not have the taint tolerance setting and affinity setting.

[0143] In another embodiment of the present application, a control node is provided, including: a control component and a storage component;

[0144] The storage component is used to store at least a set of instruction sets;

[0145] A control component for invoking and executing an instruction set in a first storage component, and executing the kubernetes resource release method for blue-green deployment as described in Embodiment 1 or 2 above by executing the instruction set.

[0146] In another embodiment of the present application, a storage medium is provided, which stores a computer program for implementing the kubernetes resource release method for blue-green deployment as described in Embodiment 1 or 2 above. The computer program is executed by a processor to implement the kubernetes resource release for blue-green deployment as described in Embodiment 1 or 2 above.

[0147] Although the subject matter has been described in language specific to structural features and / or methodological act logical acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. On the contrary, the specific features and acts described above are merely example forms for implementing the claims.

[0148] Although a number of specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the present disclosure. Certain features described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments.

[0149] The above description is only a preferred embodiment of the present disclosure and an explanation of the applied technical principles. Those skilled in the art should understand that the scope of the disclosure involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above technical features, and should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosure concept. For example, the technical solutions formed by mutually replacing the above features with the technical features (but not limited to) having similar functions disclosed in the present disclosure.

Claims

1. A kubernetes resource release method for blue-green deployment, characterized in that, Including: If there is an application of the current version in the kubernetes cluster used to execute the blue-green release task of the application, set the traffic scheduling policy plan to schedule the requests of users accessing the application to the application of the current version; Apply for a temporary node and add the temporary node to the kubernetes cluster; Set taints for the temporary node so that the temporary node does not accept the use of application programs that do not have taint toleration settings; Set an affinity label for the temporary node; Perform taint toleration settings on the new version of the application program and perform affinity settings on the affinity label so that the new version of the application program can be scheduled to the temporary node; Modify the traffic scheduling policy plan to schedule the requests of users accessing the application to the new version of the application program; Judge whether the new version of the application program on the temporary node meets the expectations; If not, re-modify the traffic scheduling policy plan to schedule the requests of users accessing the application to the application of the current version; Delete the new version of the application program; Remove the temporary node from the kubernetes cluster; If it meets the requirements, delete the application of the current version, roll update the new version of the application program to the fixed nodes in the kubernetes cluster, and cancel the taint toleration settings and affinity settings of the new version of the application program; Remove the temporary node from the kubernetes cluster.

2. The method according to claim 1, characterized in that, After removing the temporary node from the kubernetes cluster, it further includes: Set the temporary node to an invalid state.

3. The method according to claim 1, wherein The rolling update of the new version of the application program to the fixed nodes in the kubernetes cluster includes: Cancel the taint toleration settings and affinity settings in the deployment object used to manage the pod objects corresponding to the new version of the application program, redeploy the deployment object, and set the update policy of the redeployed deployment object so that the redeployed deployment object rolls updata the pod objects corresponding to the new version of the application program to the fixed nodes in the kubernetes cluster based on the update policy.

4. The method according to claim 1, characterized in that The rolling update of the new version of the application program to the fixed nodes in the kubernetes cluster includes: For the application corresponding to the new version, deploy a new deployment. Based on the update policy, delete the pod objects managed by the original deployment corresponding to the application of the new version. Scale out the new deployment based on the deleted pod objects so that the new deployment obtains the pod objects corresponding to the application of the new version, and roll update the pod objects to the fixed node nodes in the Kubernetes cluster. The new deployment does not have taint tolerance settings and affinity settings.

5. A kubernetes resource release device for blue-green deployment, characterized in that, Including: The first setting module is used to, if there is an application of the current version in the Kubernetes cluster for executing the application blue-green release task, set the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application of the current version; The application and joining module is used to apply for a temporary node and join the temporary node to the Kubernetes cluster; The second setting module is used to perform taint settings on the temporary node so that the temporary node does not accept the use of applications without taint tolerance settings; The third setting module is used to set an affinity label for the temporary node; The fourth setting module is used to perform taint tolerance settings on the application of the new version and perform affinity settings on the affinity label so that the application of the new version can be scheduled to the temporary node; The first modification module is used to modify the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application of the new version; The judgment module is used to judge whether the application of the new version on the temporary node meets the expectations; The second modification module is used to, if the application of the new version does not meet the expectations, re-modify the traffic scheduling policy scheme to schedule the requests of users accessing the application to the application of the current version; The first deletion module is used to delete the application of the new version; The removal module is used to remove the temporary node from the Kubernetes cluster; The second deletion module is used to, if the application of the new version meets the expectations, delete the application of the current version; The update module is used to roll update the application of the new version to the fixed node nodes in the Kubernetes cluster; The cancellation module is used to cancel the taint tolerance settings and affinity settings of the application of the new version and trigger the execution of the removal module.

6. The device according to claim 5, characterized in that, The device further includes: The fifth setting module is used to set the temporary node to an invalid state.

7. The device according to claim 5, wherein the update module is specifically used for: Cancel the taint toleration settings and affinity settings in the deployment object that manages the pod objects corresponding to the application for the new version, redeploy the deployment object, and set the update policy for the redeployed deployment object so that the redeployed deployment object rolls out and updates the pod objects corresponding to the application for the new version to the fixed node nodes in the Kubernetes cluster.

8. The device according to claim 5, wherein the update module is specifically configured to: For the application corresponding to the new version, deploy a new deployment, delete the pod objects managed by the original deployment corresponding to the application for the new version based on the update policy, scale out the new deployment based on the deleted pod objects so that the new deployment obtains the pod objects corresponding to the application for the new version, and roll out and update the pod objects to the fixed node nodes in the Kubernetes cluster, and the new deployment does not have taint toleration settings and affinity settings.

9. A control node, It is characterized in that It includes: a control component and a storage component; The storage component is used to store at least a set of instruction sets; The control component is used to call and execute the instruction sets in the first storage component, and execute the Kubernetes resource release method for blue-green release as described in any one of claims 1-4 by executing the instruction sets.

10. A storage medium, characterized in that, It stores a computer program that implements the Kubernetes resource release method for blue-green release as described in any one of claims 1-4, and the computer program is executed by a processor to implement the Kubernetes resource release for blue-green release as described in any one of claims 1-4.

Images