Gray scale upgrading method and device of resource tuner

By adopting a declarative tuning mechanism and a canary release strategy in the Kubernetes cluster, the automated scheduling and phased verification of the old and new versions of the resource tuner were achieved, which solved the problems of low resource utilization and business interruption risk, and ensured the optimization of resource scheduling and business continuity.

CN121832995APending Publication Date: 2026-04-10JINZHUAN INFORMATION TECHNOLOGY CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
JINZHUAN INFORMATION TECHNOLOGY CO LTD
Filing Date
2025-12-31
Publication Date
2026-04-10

AI Technical Summary

Technical Problem

Traditional Kubernetes resource scheduling suffers from uneven cluster node load and unreasonable resource allocation in complex business scenarios, resulting in low utilization of computing resources, business interruption risks during version upgrades, and a lack of automated support for canary upgrades of underlying resource tuners. When new and old versions of resource tuners coexist, resource contention and waste occur frequently, especially in scenarios with inconsistent CRD versions, where compatibility and adaptation cannot be achieved.

Method used

By adopting a method that integrates a declarative tuning mechanism and a canary deployment strategy, the adaptability of the new version of the resource tuner is verified through automated scheduling and phased verification. The front-end operation and maintenance interface and CRD of the old and new versions are deployed. The bidirectional conversion of the old and new versions of CRD is realized by using a CRD version converter. The isolation processing of the old and new versions of the resource tuner is ensured through a version tag filtering mechanism, thereby achieving resource utilization optimization and business continuity assurance.

Benefits of technology

It achieves seamless compatibility and canary upgrades between old and new versions of resource tuners in Kubernetes clusters, reducing the risk of business interruption, optimizing resource utilization, and ensuring business continuity and the controllability of canary upgrades.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121832995A_ABST
    Figure CN121832995A_ABST
Patent Text Reader

Abstract

The invention discloses a gray scale upgrading method and device of a resource tuner. After a gray scale upgrading request is received, the adaptability of a new version resource tuner is verified, and if the adaptation is passed, a new version front-end operation and maintenance interface, a CRD version conversion callback function, a new version CRD and the new version resource tuner are deployed in sequence to realize coexistence in a new and old version component cluster; when a gray level user initiates an operation and maintenance request through a new version front end, a callback function completes CR bidirectional conversion of a new version and an old version, then through a version label filtering mechanism, a new version resource tuner processes a corresponding request, an old version resource tuner performs automatic filtering, and finally gray level upgrading is achieved. According to the technical scheme provided by the invention, resource utilization rate optimization and service continuity guarantee are considered through automatic scheduling and staged verification by a method of fusing a declarative tuning mechanism and a gray strategy.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for grayscale upgrade of a resource tuner. Background Technology

[0002] With the rapid evolution of cloud-native technologies, Kubernetes has become a core supporting platform for container orchestration and resource scheduling, and is widely used in cloud platforms, distributed databases, and other scenarios. However, traditional Kubernetes resource scheduling faces bottlenecks in complex business scenarios, with issues such as uneven cluster node load and unreasonable resource allocation leading to low utilization of computing resources.

[0003] Version upgrades are a critical part of cloud-native application operations and maintenance, but traditional upgrade models have significant risks and a high probability of business interruption. Existing canary release solutions mostly focus on traffic control or service routing, relying on manual configuration or simple traffic splitting, which makes it difficult to balance flexibility and stability, and lacks automated support for canary upgrades of underlying resource tuners.

[0004] When old and new versions of resource tuners coexist, resource contention and waste occur frequently, especially in scenarios with inconsistent CRD versions, where existing solutions cannot achieve compatibility and adaptation. Therefore, there is an urgent need for a method that integrates declarative tuning mechanisms and canary deployment strategies, using automated scheduling and phased verification to balance resource utilization optimization and business continuity assurance. Summary of the Invention

[0005] This invention provides a method and apparatus for gray-scale upgrade of a resource tuner, which integrates a declarative tuning mechanism and a gray-scale strategy, and balances resource utilization optimization and business continuity assurance through automated scheduling and phased verification.

[0006] According to one aspect of the present invention, a method for canary upgrade of a resource tuner is provided, applied to a large-scale Kubernetes K8S cluster, wherein the K8S cluster deploys a first version resource tuner, a corresponding first version CRD, a first version front-end operation and maintenance interface, and an etcd database storing first version custom resources CRD; the method includes:

[0007] After receiving the resource tuner canary upgrade request, verify the canary upgrade adaptability of the second version of the resource tuner. If the adaptability conditions are met, deploy the second version of the front-end operation and maintenance interface in the K8S cluster.

[0008] Deploy the second version of CRD and update the storage version of the custom resources in the etcd database to the second version of CRD;

[0009] The gray user initiates an operation and maintenance request through a deployed second version front-end operation and maintenance interface, requests the second version CR from the K8S API Server through the second version front-end operation and maintenance interface, so that the K8S API Server reads the stored first version CR from the etcd database and returns the second version CR to the second version front-end operation and maintenance interface after conversion;

[0010] According to the operation and maintenance request, the second version CR is modified and a second version label is added, and the labeled second version CR is sent to the K8S API Server;

[0011] After the first version resource tuner listens to the change of the custom resource, the first version CR is requested from the K8S API Server, so that the K8S API Server returns the second version CR converted into the first version CR, the first version resource tuner identifies that the second version label is inconsistent with the version of itself, and performs exit processing;

[0012] After the second version resource tuner listens to the change of the custom resource, the second version CR is requested from the K8S API Server, so that the K8S API Server returns the second version CR, the second version resource tuner identifies that the second version label is consistent with the version of itself, and performs the operation and maintenance request based on the second version CR, and the gray upgrade is completed.

[0013] Optionally, the K8S cluster is a production cluster in which a distributed database is deployed, the resource tuner is an operation and maintenance management Operator corresponding to the distributed database, the operation and maintenance request includes at least one of database instance expansion, parameter adjustment, backup strategy configuration, and fault self-healing triggering, and the gray user is a preset test user or a specified proportion of customer instances.

[0014] Optionally, the verification of the gray upgrade adaptability of the second version resource tuner includes:

[0015] Verify the version compatibility of the second version resource tuner and the existing K8S cluster, the syntax adaptability of the second version resource tuner and the second version CRD, and the data field mapping integrity of the first version CR and the second version CR;

[0016] When the above verifications are passed, it is determined that the second version resource tuner meets the adaptation condition.

[0017] Optionally, the K8S API Server implements conversion between the first version CR and the second version CR through a CR version converter webhook, wherein the webhook includes bidirectional conversion logic, forward conversion logic converts fields of the first version CR to corresponding fields of the second version CR according to a preset mapping rule, and fills in default values of newly added fields of the second version CR; reverse conversion logic restores fields of the second version CR to a compatible format of the first version CR, and deletes newly added fields not supported by the first version CR.

[0018] Optionally, the second version label adopts a key-value pair format and further includes a gray identification label for visual management and control of gray traffic by the K8S cluster; the first version resource tuner and the second version resource tuner both preset a label filtering rule, and only process custom resource requests in which a version field in the label matches the version of the resource tuner.

[0019] Optionally, the method further includes:

[0020] When the second version resource tuner executes an operation and maintenance request exception or a gray test fails, switching to the first version front-end operation and maintenance interface to receive a user operation and maintenance request initiated through the first version front-end operation and maintenance interface, the first version front-end operation and maintenance interface requests the first version CR from the K8S API Server, and adds a first version label to the modified first version CR;

[0021] The second version resource tuner exits processing when the label does not match the version of the second version resource tuner, and the first version resource tuner executes an operation and maintenance request based on the first version CR after the label matches.

[0022] Optionally, updating the storage version of the custom resource in the etcd database to the second version CR includes:

[0023] Configuring the etcd to support dual-version storage of the first version CR and the second version CR;

[0024] After the second version CRD is deployed and the webhook conversion function is verified, switching the default storage version of the etcd to the second version CR.

[0025] According to another aspect of the application, a resource tuner gray upgrade device is provided, including:

[0026] A front-end operation and maintenance interface deployment unit is configured to verify the gray upgrade adaptability of the second version resource tuner after receiving a resource tuner gray upgrade request, and if the adaptability condition is met, deploy a second version front-end operation and maintenance interface in the K8S cluster.

[0027] A custom resource version updating unit is configured to deploy the second version CRD and update a stored version of a custom resource in the etcd database to the second version CR;

[0028] An operation and maintenance request receiving unit is configured to receive an operation and maintenance request initiated by a gray user through a deployed second version front-end operation and maintenance interface, request the second version CR from the K8S API Server through the second version front-end operation and maintenance interface, and return the second version CR to the second version front-end operation and maintenance interface after the K8S API Server reads the stored first version CR from the etcd database and converts the first version CR to the second version CR;

[0029] An operation and maintenance request executing unit is configured to modify the second version CR according to the operation and maintenance request and add a second version label, and send the second version CR with the label to the K8S API Server;

[0030] An exiting executing unit is configured to request the first version CR from the K8S API Server after the first version resource tuner listens to a change in the custom resource, to make the K8S API Server return the second version CR converted to the first version CR, and to make the first version resource tuner identify that the second version label is inconsistent with the version of the first version resource tuner and perform exiting processing;

[0031] An operation and maintenance request executing unit is configured to request the second version CR from the K8S API Server after the second version resource tuner listens to a change in the custom resource, to make the K8S API Server return the second version CR, and to make the second version resource tuner identify that the second version label is consistent with the version of the second version resource tuner and perform the operation and maintenance request based on the second version CR to complete the gray upgrade.

[0032] According to another aspect of the present application, an electronic device is provided, which comprises:

[0033] at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform the gray upgrade method of the resource tuner according to any one of the embodiments of the present application.

[0034] According to another aspect of the present application, a computer readable storage medium is provided, which stores computer instructions for enabling a processor to perform the gray upgrade method of the resource tuner according to any one of the embodiments of the present application when the computer instructions are executed by the processor.

[0035] According to another aspect of the present application, there is provided a computer program product comprising a computer program which, when executed by a processor, implements the method for gray-scale upgrading of a resource tuner according to any of the embodiments of the present application.

[0036] The technical solution of the embodiment of the present application is that in the Kubernetes cluster, an old version resource tuner, an old version custom resource definition, an old version front-end operation and maintenance interface and an etcd database storing the old version custom resource are pre-deployed; after receiving a gray-scale upgrading request, the adaptability of a new version resource tuner is verified first, and if the adaptation is passed, a new version front-end operation and maintenance interface, a CRD version conversion callback function, a new version CRD and a new version resource tuner are deployed in sequence, so that the new and old version components coexist in the cluster; when a gray-scale user initiates an operation and maintenance request through the new version front-end, the new and old version CRs are converted bidirectionally by the callback function, and then the version label filtering mechanism is used to make the new version resource tuner process the corresponding request and the old version resource tuner is automatically filtered, so that the gray-scale upgrading is finally realized. The technical solution of the embodiment of the present application uses a method of combining a declarative tuning mechanism and a gray-scale strategy, and through automatic scheduling and phased verification, the optimization of resource utilization and the guarantee of business continuity are taken into account.

[0037] It should be understood that the content described in this part is not intended to identify key or important features of the embodiments of the present application, nor is it used to limit the scope of the present application. Other features of the present application will become apparent through the following description. BRIEF DESCRIPTION OF DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.

[0039] Figure 1 is a flowchart of a gray-scale upgrading method of a resource tuner provided by the first embodiment of the present application;

[0040] Figure 2 is a schematic diagram of a K8S cluster to which the embodiment of the present application is applicable;

[0041] Figure 3 is an architectural schematic diagram of a gray-scale upgrading method of a resource tuner to which the embodiment of the present application is applicable;

[0042] Figure 4 is a structural schematic diagram of a gray-scale upgrading device of a resource tuner provided by the embodiment of the present application;

[0043] Figure 5 is a structural schematic diagram of an electronic device implementing a gray scale upgrading method of a resource tuner of an embodiment of the present application. DETAILED DESCRIPTION

[0044] In order to make the personnel in the technical field better understand the present application scheme, the technical scheme in the embodiment of the present application will be described clearly and completely in the following by combining the drawings in the embodiment of the present application. Obviously, the described embodiment is only a part of the embodiment of the present application, not all. Based on the embodiment in the present application, all other embodiments obtained by the person skilled in the art without creative labor should belong to the scope of protection of the present application.

[0045] It should be noted that the terms "first", "second" and the like in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily have to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0046] Figure 1 is a flow chart of a gray scale upgrading method of a resource tuner provided by an embodiment of the present application. The embodiment can be applicable to the case of upgrading the gray scale of the resource tuner. The method can be executed by a gray scale upgrading device of the resource tuner. The gray scale upgrading device of the resource tuner can be realized in the form of hardware and / or software. The gray scale upgrading device of the resource tuner can be configured in an electronic device. Figure 2is a schematic diagram of a K8S cluster to which an embodiment of the present application is applicable. The method is applied to a large-scale Kubernetes K8S cluster, and the K8S cluster is deployed with a first version of a resource tuner Operator, a first version of a custom resource definition (CRD), a first version of a front-end operation interface, and an etcd database storing a first version of a custom resource (CR). K8S is an open-source container orchestration and resource scheduling core platform, mainly used for managing containerized applications on multiple hosts in a cloud platform, and is also the basic running environment of the present application. The resource tuner is used to listen to the custom resource corresponding to the CRD and achieve the target state described by the CR through specific logic, such as performing database operation. The CRD is a built-in resource type of Kubernetes, used to determine the structure and rules of user-defined resources, and different versions of CRD correspond to different structures of CR. The front-end operation interface provides visual page services, and users generate CR requests corresponding to the business by clicking operations, and send the requests to the K8S APIServer, which is divided into different versions to adapt to the corresponding version of CR and resource tuner. The custom resource is a specific instance created according to the CRD, carrying the configuration information and target state of the business scenario, such as database expansion parameters, backup strategies, etc., and is the basis for the resource tuner to perform operation. The etcd database is a key-value storage system used as the background database of all data of the Kubernetes cluster, and is also a storage carrier for data such as CR. As shown in Figure 1 the method comprises:

[0047] S110, after receiving the resource tuner gray upgrade request, verifying the gray upgrade adaptability of the second version of the resource tuner, and if the adaptation condition is met, deploying the second version of the front-end operation interface in the K8S cluster.

[0048] In the embodiment of the present application, the K8S cluster is a production cluster deployed with a distributed database, the resource tuner is an operation and management Operator corresponding to the distributed database, the operation request includes at least one of database instance expansion, parameter adjustment, backup strategy configuration, and fault self-healing triggering, and the gray user is a preset test user or a specified proportion of customer instances.

[0049] Specifically, after receiving the resource tuner gray scale upgrade request, the adaptability of the second version resource tuner needs to be verified to ensure its compatibility with the existing K8S cluster environment, old components (i.e. the first version resource tuner, the first version CRD, etc.), avoid business interruption, resource conflict or data conversion exception during the upgrade process. Confirm that the second version resource tuner supports the API interface specification, data storage access rules and resource scheduling mechanism of the current K8S cluster, to ensure that it can normally access the cluster data bus K8S API Server without interface incompatibility, insufficient permissions, etc. Verify that the second version resource tuner can correctly identify the field structure, rule constraints and target state description of the second version CRD, to avoid the inability to listen or process the second version CR due to CR syntax mismatch. Evaluate the resource requirements of CPU, memory, network bandwidth, etc. of the second version resource tuner, confirm that the remaining resources of the current K8S cluster can meet its deployment and operation, and will not cause resource contention with the first version resource tuner, cloud database cluster and other existing components, to ensure that the normal operation of the existing business is not affected.

[0050] After confirming that the adaptability meets the standards, deploy the second version front-end operation interface inside the K8S cluster. The second version front-end operation interface and the first version front-end operation interface exist in parallel in the same K8S cluster, share the access rights of the K8S API Server, but each independently provides page services. The first version front-end operation interface can still be used to initiate old operation requests, and the gray scale users can operate through the second version interface. The two do not interfere with each other. The second version front-end operation interface matches the new functions of the second version resource tuner and supports generating operation request data according to the field structure of the second version CR.

[0051] The second version front-end operation interface is used to isolate existing users and gray scale users, avoid the impact of gray scale testing on existing business, reduce the gray scale testing threshold through a visual page, and facilitate test personnel to quickly initiate a function trial request of the second version resource tuner.

[0052] S120, deploy the second version CRD, and update the storage version of the custom resource in the etcd database to the second version CR.

[0053] Specifically, the second version CRD is deployed, that is, a custom resource template adapted to the second version resource tuner is added to the K8S cluster, the field structure, rule constraints and target state description of the second version custom resource CR are determined, and the basis for the creation and identification of the second version CR is provided.

[0054] The storage version of the custom resource in the etcd database is updated to the second version CR. First, configure etcd to support dual-version storage of the first version and the second version CR, ensure that the read and write operations of the first version CR are not affected, and after the second version CRD is deployed and the version conversion callback function is verified, switch the default storage version of etcd to the second version CR, and provide data storage media for the second version resource tuner to read the corresponding version CR and perform operation and maintenance.

[0055] S130, receiving the operation and maintenance request initiated by the gray user through the deployed second version front-end operation and maintenance interface, requesting the second version CR from the K8S API Server through the second version front-end operation and maintenance interface, so that the K8S API Server reads the stored first version CR from the etcd database and converts it into the second version CR and returns it to the second version front-end operation and maintenance interface.

[0056] Specifically, the gray user, i.e. the test personnel or the designated customer, has initiated an operation and maintenance request by clicking the new version operation and maintenance function through the deployed second version front-end operation and maintenance interface. After receiving the user request, the second version front-end operation and maintenance interface will initiate a specific request to the K8S API Server, i.e. to obtain the second version CR. Because the user is operating the new version function, it needs to rely on the field structure of the second version CR to carry the operation and maintenance configuration information, so as to adapt to the second version resource tuner.

[0057] Since only the first version CR is stored in the etcd database at the initial stage of the gray upgrade, the old data has not been completely replaced, and the K8S API Server reads the first version CR from the etcd. At this time, the K8S API Server will convert the first version CR into the second version CR, and after the conversion is completed, the K8S API Server will return the second version CR to the second version front-end operation and maintenance interface. Without changing the first version CR data, the second version front-end operation and maintenance interface obtains the adapted second version CR, realizing seamless compatibility of new and old version data.

[0058] S140, modifying the second version CR according to the operation and maintenance request and adding a second version label, and sending the second version CR with the label to the K8S API Server.

[0059] Specifically, after the second version CR is converted, the second version front-end operation and maintenance interface will modify the corresponding fields of the second version CR according to the specific operation and maintenance request initiated by the gray user, so as to ensure that the configuration information in the CR matches the user demand. After the modification is completed, the front end adds a special version label version:v2 to the second version CR, which is used to distinguish the request attribution, implement gray shunting, and inform the two version resource tuners coexisting in the cluster that this request belongs to the second version exclusive processing range. The front end sends the second version CR with completed configuration modification and version label to the K8S API Server, and the etcd database stores the updated second version CR, and on the other hand, triggers the two version resource tuners to listen to the CR change.

[0060] S150, after the first version resource tuner listens to the change of the custom resource, the first version CR is requested from the K8S API Server, so that the K8S API Server converts the second version CR into the first version CR and returns it, and the first version resource tuner identifies that the second version label is inconsistent with the version of itself, and executes the exit processing.

[0061] Specifically, when the second version CR with the second version label version:v2 submitted by the gray user is sent to the K8S API Server, the first version resource tuner will listen to the change of the CR in real time. At this time, the K8S API Server stores the updated second version CR. In order to adapt to the reading requirement of the first version resource tuner, the second version CR is converted into the first version CR, so as to ensure that the data structure matches the processing logic of the first version resource tuner. Subsequently, the converted first version CR is returned to the tuner.

[0062] After the first version resource tuner receives and reads the returned first version CR, it will identify the second version label version:v2 carried on the CR. Since the second version corresponding to the label is inconsistent with the first version of itself, and the tuner only processes the CR request whose version label matches the version of itself, it will determine that the request does not belong to the processing range of itself, and execute the exit processing, and no longer perform subsequent operations on the operation and maintenance request corresponding to the CR.

[0063] S160, after the second version resource tuner listens to the change of the custom resource, the second version CR is requested from the K8S API Server, so that the K8S API Server returns the second version CR, and the second version resource tuner identifies that the second version label is consistent with the version of itself, and executes the operation and maintenance request based on the second version CR, and completes the gray upgrade.

[0064] Specifically, after the second version CR submitted by the gray user with the version label No. 2 is sent to the K8S APIServer, the second version resource tuner will listen to the changes of the custom resource CR in real time. Since the second version resource tuner only supports processing the second version CR, it will actively initiate a request to the K8S API Server to obtain the second version CR. At this time, the K8S API Server has read the second version CR stored in the etcd database and returned to the second version resource tuner, ensuring that the data structure is fully compatible with the tuner's processing logic.

[0065] After the second version resource tuner receives and reads the returned second version CR, it will identify the version label No. 2 version:v2 carried on it and find that the version corresponding to the label is fully consistent with its own version, determining that the request belongs to its exclusive processing range. Based on the configuration information recorded in the second version CR, the corresponding operation and maintenance operation is performed to realize the landing of the new version function. At this time, the operation and maintenance request of the gray user is only processed by the second version resource tuner, and the first version resource tuner has exited the processing through label filtering, which not only guarantees that the existing business is not disturbed, but also completes the gray trial verification of the second version resource tuner.

[0066] In the embodiment of the present application, the gray upgrade adaptability of the second version resource tuner is verified, which includes:

[0067] The version compatibility of the second version resource tuner with the existing K8S cluster, the syntax adaptability of the second version resource tuner with the second version CRD, and the data field mapping integrity of the first version CR and the second version CR are verified.

[0068] When the above verifications are passed, it is determined that the second version resource tuner meets the adaptation conditions.

[0069] Specifically, the version compatibility is to ensure that the second version resource tuner can adapt to the running environment of the existing K8S cluster. The compatibility of the second version resource tuner to the API interface specification of the existing K8S cluster is checked to ensure that it supports the HTTP Rest interface protocol of the current version of the cluster and can normally interact with the K8S API Server.

[0070] The syntax adaptability is to ensure that the second version resource tuner can correctly identify and parse the definition rules of the second version CRD, including: checking whether the tuner can identify the field structure defined in the second version CRD; verifying the adaptability of the tuner to the rule constraints in the second version CRD, including the field mandatory requirement, value range limitation, association definition, etc., to ensure that the tuner can follow the rule specification of the CRD when processing the second version CR based on the CRD; confirming that the tuner can correctly interpret the target state logic described in the second version CRD.

[0071] The data field mapping integrity is to ensure that the business data of the two versions of CR can be converted bidirectionally, to sort out the core business fields of the first version CR and the second version CR, and to verify whether the field mapping relationship of the two is complete; to check the adaptation logic of the new field, to confirm that the newly added field of the second version CR has configured a reasonable default value or mapping rule, to ensure that the field can be automatically completed when converting from the first version CR, without affecting the tuner processing; to verify the processing rule of the redundant field, to confirm that the first version CR field discarded in the second version CR or the second version CR newly added field not supported by the first version CR can be reasonably discarded or compatible processed when reverse conversion, to avoid conversion failure due to field mismatch.

[0072] When the verification of the above three dimensions is normal, it is determined that the second version resource tuner meets the gray upgrade adaptation condition, if any dimension verification fails, the second version resource tuner, the second version CRD or the field mapping rule needs to be optimized, until all verification dimensions meet the standard.

[0073] In the embodiment of the application, the K8S API Server realizes the conversion between the first version CR and the second version CR through the CRD version converter webhook, wherein the webhook includes bidirectional conversion logic, the forward conversion logic converts the fields of the first version CR into the corresponding fields of the second version CR according to the preset mapping rule, and fills in the default values of the newly added fields of the second version CR; the reverse conversion logic restores the fields of the second version CR to the compatible format of the first version CR, and deletes the newly added fields not supported by the first version CR.

[0074] Specifically, the K8S API Server calls the CRD version converter webhook when receiving or forwarding read and write requests of different versions of CR, and completes data format adaptation through the built-in bidirectional conversion logic. The forward conversion logic is used to convert the first version CR to the second version CR, and according to the pre-set field mapping rule, all core business fields of the old version CR are accurately mapped to the corresponding fields of the new version CR. At the same time, if the second version CR adds fields that the old version CR does not have, the default values of these new fields are automatically completed to ensure that the converted second version CR field is complete and the format is compliant, and can be normally parsed by the second version resource tuner. The reverse conversion logic is used to convert the second version CR to the first version CR. When the first version resource tuner requests to read the CR, the field structure of the second version CR is restored to a compatible format that the first version CR can recognize. For fields that are added in the second version CR and are not supported by the first version CR, the fields are directly deleted to avoid parsing failure of the first version resource tuner due to field incompatibility. At the same time, the core business fields required by the first version CR are retained to ensure that the converted first version CR can still accurately carry the core operation and maintenance requirements and does not affect the normal work of the first version resource tuner.

[0075] In the embodiment of the application, the second version label adopts a key-value pair format and further includes a gray identification label for visual management and control of the K8S cluster on gray traffic.

[0076] Specifically, the second version label version:v2 adopts a key-value pair format, and a gray identification label is additionally added, wherein the version label is used to distinguish the version of the request, and the gray identification label is used for visual management and control of the K8S cluster. The cluster administrator can quickly identify which CR corresponds to a gray operation and maintenance request through the label, which facilitates real-time monitoring of the size, distribution and running state of the gray traffic and can flexibly adjust the gray range according to the demand, thereby improving the operability and controllability of the gray upgrade.

[0077] In addition, the first version resource tuner and the second version resource tuner only process CR requests whose version field in the label is consistent with the version of the tuner. Through the version label and the gray identification label, strict isolation of gray requests and inventory requests is realized, the new and old version resource tuners are prevented from competing for requests or processing abnormities, and the stability of the inventory business is ensured. In addition, the gray identification label provides visual management and control capabilities at the cluster level.

[0078] In the embodiment of the application, the method can further include the following steps:

[0079] When the second version resource tuner executes an operation and maintenance request exception or a gray test fails, the first version front-end operation and maintenance interface is switched to, a user initiates an operation and maintenance request through the first version front-end operation and maintenance interface, the first version front-end operation and maintenance interface requests the first version CR from the K8S API Server, and a first version label is added to the modified first version CR;

[0080] The second version resource tuner exits the processing when the label is inconsistent with the version of the second version resource tuner, and the first version resource tuner executes the operation and maintenance request based on the first version CR after the label is matched.

[0081] Specifically, when the second version resource tuner executes an operation and maintenance request of a gray user and an exception occurs, or the second version resource tuner cannot meet the business requirements in the gray test process, the first version front-end operation and maintenance interface that has been running continuously is switched to, after the user initiates an operation and maintenance request through the first version front-end operation and maintenance interface, the interface requests the first version CR from the K8S API Server, and the configuration information of the first version CR is modified according to the specific operation and maintenance requirements of the user, and a first version label is added to the modified first version CR, and the label is used to determine the request attribution and avoid confusion with the gray request.

[0082] The first version CR with the first version label is sent to the K8S API Server, the second version resource tuner reads the first version label after listening to the CR change, finds that the label corresponds to a version that is inconsistent with the second version resource tuner, directly exits the processing according to a preset label filtering rule, and the first version resource tuner reads the label after listening to the CR change, finds that the label is completely matched with the first version resource tuner, and executes the corresponding operation and maintenance request based on the configuration information in the first version CR.

[0083] The whole rollback process does not need to stop cluster services or migrate data, and only the front-end interface switching and the label filtering mechanism are used, so that the stable running state of the first version resource tuner can be quickly restored, and the risk of gray upgrade is reduced.

[0084] In the embodiment of the application, the storage version of the self-defined resource in the etcd database is updated to the second version CR, including:

[0085] The etcd supports the dual-version storage of the first version CR and the second version CR;

[0086] After the second version CRD is deployed and the webhook conversion function is verified, the default storage version of the etcd is switched to the second version CR.

[0087] Specifically, the storage adaptation rule of etcd is adjusted to enable it to identify, store and read the data format of two versions of CR at the same time, and not to reject data reading and writing due to version difference. The inventory of the first version of CR can still be normally read and modified, ensuring that the first version of the resource tuner can continuously process old version operation and maintenance requests without affecting the operation of existing businesses. Space is reserved for the storage of the second version of CR to avoid the situation that the new version of CR cannot be written due to storage incompatibility.

[0088] Two prerequisite conditions need to be met for switching the default storage version of etcd to the second version of CR: the second version of CRD has been deployed, ensuring that the definition template of the second version of CR exists in the cluster and can be identified by the second version of the resource tuner; and the webhook conversion function is verified, which confirms that the webhook can reliably realize the bidirectional conversion of the first version of CR and the second version of CR without data loss, format error and other problems, ensuring the data compatibility of the new and old versions of CR after switching. When both prerequisites are met, the default storage version of etcd is switched to the second version of CR. After that, the newly generated or modified CR will be stored in the second version by default, while the inventory of the first version of CR will still be retained in etcd and can be converted to the required version by webhook for use by the corresponding resource tuner, reducing the risk of version transition, realizing the version upgrade of data storage, and ensuring the stability of the inventory business and the compatibility of the new and old versions during the gray upgrade process.

[0089] Figure 3 is a schematic diagram of a resource tuner gray upgrade method according to an embodiment of the application. Taking the resource tuner Operator corresponding to the gray upgrade of the cloud database as an example, the application running process of the patent technology is described.

[0090] 1. Deploy CRD-V2, Operator-V2, and front-end page-V2.

[0091] 2. Deploy webhook.

[0092] 3. The tester or gray user clicks the new function in the front-end page-V2 to initiate a new operation and maintenance request.

[0093] 4. The front-end page-V2 first initiates a request to the K8S API SERVER to obtain CR (v2). The K8S API SERVER requests CR (v2) from ETCD. Because CR (v1) is originally stored in ETCD, the K8S API SERVER will realize the conversion of CR (v1) to CR (v2) through webhook and return it to the front-end page-V2.

[0094] 5. Front page - V2 modifies the CR (v2) obtained on the basis of the customer request, and gives the CR a version label: version: v2, and sends it to the K8S API SERVER after modification.

[0095] 6. Operator-v1 listens to the change of CR, requests CR (v1) from K8S API SERVER, K8S API SERVER reads CR (v2) from etcd, and converts CR (v2) into CR (v1) through webhook, K8S API SERVER returns CR (v1) to Operator-v1, Operator-v1 reads the label version: v2, finds that v1!=v2, and exits this processing.

[0096] 7. Operator-v2 listens to the change of CR, requests CR (v2) from K8S API SERVER, K8S API SERVER reads CR (v2) from etcd, and K8S API SERVER returns CR (v2) to Operator-v2, Operator-v2 reads the label version: v2, finds that v2==v2, and processes this operation and maintenance request according to the CR.

[0097] 8. In summary, the high-version resource tuner Operator-v2 processes this request, and realizes the gray upgrade capability of the resource tuner.

[0098] Figure 4 is a structural schematic diagram of a resource tuner gray upgrade device provided by an embodiment of the application. As shown in the figure, Figure 4 the device comprises:

[0099] A front-end operation and maintenance interface deployment unit 410 is configured to, after receiving a resource tuner gray upgrade request, verify the gray upgrade adaptability of the second-version resource tuner, and if the adaptability condition is met, deploy a second-version front-end operation and maintenance interface in the K8S cluster.

[0100] A custom resource version updating unit 420 is configured to deploy a second-version CRD, and update the storage version of the custom resource in the etcd database to the second-version CR.

[0101] An operation and maintenance request receiving unit 430 is configured to receive an operation and maintenance request initiated by a gray user through the deployed second-version front-end operation and maintenance interface, request a second-version CR from the K8S API Server through the second-version front-end operation and maintenance interface, so that the K8S API Server reads the stored first-version CR from the etcd database and returns the second-version CR to the second-version front-end operation and maintenance interface after conversion.

[0102] The operation and maintenance request execution unit 440 is configured to modify the second version CR according to the operation and maintenance request and add a second version label, and send the second version CR with the label to the K8S API Server.

[0103] The exit execution unit 450 is configured to, after the first version resource tuner listens to the change of the custom resource, request the first version CR from the K8S API Server, so that the K8S API Server returns the second version CR converted into the first version CR, the first version resource tuner identifies that the second version label is inconsistent with the version of the first version resource tuner, and performs exit processing.

[0104] The operation and maintenance request execution unit 460 is configured to, after the second version resource tuner listens to the change of the custom resource, request the second version CR from the K8S API Server, so that the K8S API Server returns the second version CR, the second version resource tuner identifies that the second version label is consistent with the version of the second version resource tuner, and performs the operation and maintenance request based on the second version CR to complete the gray upgrade.

[0105] The gray upgrade device of the resource tuner provided in the embodiments of the present application can execute the gray upgrade method of the resource tuner provided in any of the embodiments of the present application, and has the function modules and beneficial effects corresponding to the execution method.

[0106] Figure 5 A structural schematic diagram of an electronic device 10 that can be used to implement embodiments of the present application is shown. The electronic device is intended to represent various forms of digital computers, such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular telephones, smart phones, wearable devices (e.g., headsets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not intended to limit the implementations of the present application described and / or claimed in this document.

[0107] As Figure 5As shown, the electronic device 10 includes at least one processor 11, and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., communicatively connected to the at least one processor 11, where the memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes according to the computer programs stored in the read-only memory (ROM) 12 or loaded from the storage unit 18 into the random access memory (RAM) 13. Various programs and data required for the operation of the electronic device 10 can also be stored in the RAM 13. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0108] Various components in the electronic device 10 are connected to the I / O interface 15, including an input unit 16, such as a keyboard, a mouse, etc., an output unit 17, such as various types of displays, a speaker, etc., a storage unit 18, such as a magnetic disk, an optical disk, etc., and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunication networks.

[0109] The processor 11 can be various general and / or special purpose processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 performs various methods and processes described above, such as the gray scale upgrade method of the resource tuner.

[0110] In some embodiments, the gray scale upgrade method of the resource tuner can be implemented as a computer program tangibly embodied in a computer readable storage medium, such as the storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the gray scale upgrade method of the resource tuner described above can be performed. Alternatively, in other embodiments, the processor 11 can be configured to perform the gray scale upgrade method of the resource tuner by any other appropriate means, such as by means of firmware.

[0111] The various embodiments of the systems and techniques described above can be implemented in digital electronic circuitry, integrated circuitry, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on a chip (SOC), a load programmable logic device (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0112] Computer programs used to implement the processes of the application can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the computer program, when executed, can cause instructions defined in the flow charts and / or block diagrams to be implemented. The computer program can be executed entirely on a machine, partially on a machine, partially on a machine as a standalone software package and partially on a remote machine or entirely on a remote machine or server.

[0113] In the context of the present application, a computer-readable storage medium can be a tangible medium that can contain or store computer programs for use by or in connection with an instruction execution system, apparatus, or device. Computer-readable storage media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of the machine-readable storage medium will include one or more lines of electrical connections, portable computer disks, hard disk drives, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), optical fibers, portable compact disc read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0114] To provide for interaction with a user, the systems and techniques described here can be implemented on an electronic device having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the electronic device. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0115] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0116] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. A server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system, to solve the defects of large management difficulty and weak business scalability in traditional physical host and VPS service.

[0117] It should be understood that the various forms of flow shown above can be re-ordered, added to, or deleted from without departing from the scope of the present disclosure. For example, the steps recited in the present disclosure can be executed in parallel, executed in sequence, or executed in a different order, as long as the desired results of the present disclosure are achieved, and the present disclosure is not limited herein.

[0118] The specific embodiments described above are not intended to be limiting, and persons skilled in the art will appreciate that various modifications, combinations, sub-combinations and alternatives can be made to the specific embodiments without departing from the spirit and principles of the disclosure. Accordingly, the disclosure is not limited to the specific embodiments described above, but only by the scope of the appended claims.

Claims

1. A method for grayscale upgrade of a resource tuner, characterized in that, The method is applied to a large-scale Kubernetes K8S cluster in which a first version resource tuner, a first version custom resource definition CRD, a first version front-end operation and maintenance interface and an etcd database storing a first version custom resource cr are deployed; the method comprises the following steps: After receiving a resource tuner gray-scale upgrade request, verifying the gray-scale upgrade adaptability of the second version resource tuner, if the adaptation conditions are met, deploying a second version front-end operation and maintenance interface in the K8S cluster; Deploying the second version CRD and updating the storage version of the custom resource in the etcd database to the second version CR; Receiving an operation and maintenance request initiated by a gray-scale user through the deployed second version front-end operation and maintenance interface, requesting the second version CR from the K8S API Server through the second version front-end operation and maintenance interface, so that the K8S API Server reads the stored first version CR from the etcd database and returns it to the second version front-end operation and maintenance interface after converting it to the second version CR; According to the operation and maintenance request, modifying the second version CR and adding a second version label, and sending the labeled second version CR to the K8S API Server; After the first version resource tuner listens to the custom resource change, it requests the first version CR from the K8S API Server, so that the K8S API Server returns the second version CR converted to the first version CR, and the first version resource tuner identifies that the second version label is inconsistent with its own version, and performs exit processing; After the second version resource tuner listens to the custom resource change, it requests the second version CR from the K8S API Server, so that the K8S API Server returns the second version CR, and the second version resource tuner identifies that the second version label is consistent with its own version, and executes the operation and maintenance request based on the second version CR, completing the gray-scale upgrade.

2. The method of claim 1, wherein, The K8S cluster is a production cluster with a distributed database deployed, the resource tuner is an operation and maintenance management Operator corresponding to the distributed database, the operation and maintenance request includes at least one of database instance expansion, parameter adjustment, backup strategy configuration, and fault self-healing triggering, and the gray-scale user is a preset test user or a specified proportion of customer instances.

3. The method of claim 1, wherein, The method comprises the following steps: Verifying the version compatibility of the second version resource tuner with the existing K8S cluster, the syntax adaptability of the second version resource tuner with the second version CRD, and the data field mapping integrity of the first version CR and the second version CR; When the above verifications are passed, it is determined that the second version resource tuner meets the adaptation conditions.

4. The method of claim 1, wherein, The K8S API Server converts between the first version CR and the second version CR through a CR version converter webhook, wherein the webhook includes bidirectional conversion logic, forward conversion logic converts fields of the first version CR to corresponding fields of the second version CR according to a preset mapping rule, and fills in default values of newly added fields of the second version CR; reverse conversion logic restores fields of the second version CR to a compatible format of the first version CR and deletes newly added fields not supported by the first version CR.

5. The method of claim 1, wherein, The second version label adopts a key-value pair format and further includes a gray identification label for visual management and control of gray traffic by the K8S cluster; the first version resource tuner and the second version resource tuner both preset a label filtering rule, and only process custom resource requests in which the version field in the label matches the version of the tuner.

6. The method of claim 1, wherein, The method further includes: When the second version resource tuner executes an operation and maintenance request exception or a gray test fails, switching to the first version front-end operation and maintenance interface to receive a user operation and maintenance request initiated through the first version front-end operation and maintenance interface, the first version front-end operation and maintenance interface requesting the first version CR from the K8S API Server, and adding a first version label to the modified first version CR; The second version resource tuner exits the processing when the label does not match the version of the tuner, and the first version resource tuner executes an operation and maintenance request based on the first version CR after the label matches.

7. The method of claim 4, wherein, The method further includes: Configuring the etcd to support dual-version storage of the first version CR and the second version CR; After the second version CRD is deployed and the webhook conversion function is verified, switching the default storage version of the etcd to the second version CR.

8. A resource tuner gray scale upgrade device according to the gray scale upgrade device of any of claims 1-7, characterized by The method further includes: A front-end operation and maintenance interface deployment unit configured to verify the gray upgrade adaptability of the second version resource tuner after receiving a resource tuner gray upgrade request, and deploy a second version front-end operation and maintenance interface in the K8S cluster if the adaptability condition is met; A custom resource version updating unit configured to deploy the second version CRD and update the storage version of the custom resource in the etcd database to the second version CR; An operation and maintenance request receiving unit configured to receive an operation and maintenance request initiated by a gray user through the deployed second version front-end operation and maintenance interface, request the second version CR from the K8S API Server through the second version front-end operation and maintenance interface, so that the K8S API Server reads the stored first version CR from the etcd database and converts it to the second version CR and returns it to the second version front-end operation and maintenance interface; An operation and maintenance request execution unit configured to modify the second version CR according to the operation and maintenance request and add a second version label, and send the second version CR with the label to the K8S API Server; The exit execution unit is configured to request the first version CR from the K8S API Server after the first version resource tuner listens to the custom resource change, so that the K8S API Server returns the second version CR converted into the first version CR, the first version resource tuner identifies that the second version label is inconsistent with the version of the first version resource tuner, and performs exit processing; The operation and maintenance request execution unit is configured to request the second version CR from the K8S API Server after the second version resource tuner listens to the custom resource change, so that the K8S API Server returns the second version CR, the second version resource tuner identifies that the second version label is consistent with the version of the second version resource tuner, and performs the operation and maintenance request based on the second version CR to complete the gray upgrade.

9. An electronic device, comprising: The electronic device comprises: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the gray upgrade method of the resource tuner according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for causing the processor to execute the gray upgrade method of the resource tuner according to any one of claims 1-7.

11. A computer program product, characterised in that, The computer program product comprises a computer program, which, when executed by the processor, implements the gray upgrade method of the resource tuner according to any one of claims 1-7.