Gray scale publishing method, device and electronic equipment of controller

Abstract

This application discloses a method, apparatus, and electronic device for canary deployment of a controller. Relating to the field of computer technology, the method includes: calling an interface server to obtain attribute information of a change event from a target custom resource group; if the change event is a canary event, generating a canary event acquisition request based on the attribute information and a preset canary identifier, and sending the canary event acquisition request to the interface server; obtaining the success rate of the canary controller processing the canary event, and adjusting the preset canary deployment rules according to the success rate to obtain a target canary deployment rule; detecting any change event using the target canary deployment rule, and deploying the canary controller if all detection results indicate that the change event is a canary event. This application solves the problem of low resource utilization and execution efficiency in related technologies that use external flow control tools with an election mechanism for canary deployment.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a grayscale release method, apparatus, and electronic device for a controller. Background Technology

[0002] Canary releases in Kubernetes clusters are a strategy that uses technologies such as service mesh or tag selectors in a containerized environment to gradually roll out new versions of applications in a controlled manner while monitoring their performance, in order to achieve a smooth upgrade.

[0003] In the most basic canary release practice, the new version of the Operator is first deployed to the Kubernetes cluster, but it does not immediately participate in CR (Crash Response) event handling. Subsequently, by modifying the service or Ingress rules associated with the Operator, a traffic control tool is set up at the unified traffic entry point to intercept traffic. This allows a load balancer to direct a small portion of traffic (usually to specific users or test loads) to the new version of the Operator, thus testing its functionality and performance. Once the new version of the Operator passes testing and verifies its stability, traffic is gradually increased until it completely replaces the old version, completing the entire canary upgrade process. Traffic control is typically achieved using external traffic control tools, such as the Istio service mesh, which dynamically modifies routing rules to gradually guide traffic to the new version of the Operator.

[0004] Furthermore, when deploying multiple replicas, traditional Operators typically employ a LeaderElection mechanism, where only one replica (Leader) is active and responsible for handling all relevant custom resource (CR) events, while the other replicas remain in standby mode.

[0005] However, while the aforementioned canary release process provides a framework for incremental version iteration, it has some significant problems in practice. First, the introduction of external traffic control tools (such as Istio) increases system complexity and resource consumption, consuming additional CPU and memory resources. Especially in large-scale clusters, this resource overhead can become a significant cost. Furthermore, traffic control tools with a unified traffic entry point are more prone to single points of failure and performance bottlenecks.

[0006] Secondly, traffic control tools typically focus on service-level traffic management, making it difficult to achieve precise isolation and diversion of events. In other words, during canary upgrades, the old and new versions of Operator may need to process the same CR events simultaneously, increasing the uncertainty of event processing and the difficulty of managing data consistency between versions. Furthermore, the LeaderElection mechanism can also lead to single points of failure and performance bottlenecks.

[0007] There is currently no effective solution to the problem of low resource utilization and execution efficiency in the use of external traffic control tools for canary releases through election mechanisms in related technologies. Summary of the Invention

[0008] The main objective of this application is to provide a method, apparatus, and electronic device for canary deployment of a controller, in order to solve the problems of low resource utilization and execution efficiency in the related art where canary deployment is carried out through an election mechanism using external flow control tools.

[0009] To achieve the above objectives, according to one aspect of this application, a method for canary deployment of a controller is provided, applied to a proxy container of a target controller. The method includes: upon detecting a change event in a target custom resource group detected by the target controller, invoking an interface server to obtain attribute information of the change event from the target custom resource group; wherein the controller cluster includes a canary controller and at least one initial controller, the target controller is any controller in the controller cluster, and each controller in the controller cluster listens to resource events in its corresponding custom resource group; determining whether the change event is a canary event based on the attribute information and preset canary deployment rules; if the change event is a canary event, generating a canary event retrieval request based on the attribute information and a preset canary identifier, and sending the canary event retrieval request to the interface server; wherein the interface server sends the change event to the canary controller based on the preset canary identifier; obtaining the success rate of the canary controller processing the canary event, and adjusting the preset canary deployment rules based on the success rate to obtain target canary deployment rules; detecting any change event using the target canary deployment rules, and deploying the canary controller if all detection results indicate that the change event is a canary event.

[0010] Optionally, after determining whether a change event is a grayscale event based on attribute information and preset grayscale release rules, the method further includes: if the change event is not a grayscale event, generating an initial event acquisition request based on attribute information; sending the initial event acquisition request to an interface server, wherein the interface server, upon recognizing that the initial event acquisition request does not carry a preset grayscale identifier, sends the change event to an initial controller, and processes the initial event acquisition request through the initial controller.

[0011] Optionally, sending the change event to the initial controller includes: obtaining the operating data of each initial controller and determining the operating health value of each initial controller based on the operating data; obtaining the initial controller with the largest operating health value, obtaining the target initial controller, and sending the change event to the target initial controller.

[0012] Optionally, the custom resource group corresponding to each controller is set in the following way: obtain multiple resource events and obtain the first hash value of the event name of each resource event; obtain the group number of the custom resource group and divide the first hash value by the group number to obtain the remainder of each resource event; group the multiple resource events according to the remainder of the resource events to obtain multiple custom resource groups, and determine the custom resource group corresponding to each controller.

[0013] Optionally, determining the custom resource group corresponding to each controller includes: determining the load information of each controller, wherein the load information includes at least CPU utilization and event processing queue length; determining the load value of each controller based on the load information of each controller to obtain a load value sequence; obtaining the event trigger rate of each custom resource group to obtain an event trigger rate sequence, and determining the custom resource group corresponding to each controller according to the correspondence between the sequence number in the load value sequence and the sequence number in the event trigger rate sequence.

[0014] Optionally, determining the custom resource group corresponding to each controller includes: calculating the second hash value of each controller and adding each controller to a preset hash ring based on the second hash value; calculating the third hash value of the group name of each custom resource group and mapping each custom resource group to the preset hash ring based on the third hash value; starting from the third hash value on the preset hash ring, searching for the second hash value clockwise, and determining the controller to which the first second hash value belongs as the controller corresponding to the custom resource group.

[0015] Optionally, determining the custom resource group corresponding to each controller includes: determining the performance value of each controller based on the configuration information of each controller; determining the weight of each custom resource group based on the event trigger rate of each custom resource group; obtaining a preset mapping table, and determining the custom resource group corresponding to each controller based on the preset mapping table, wherein the preset mapping table includes a preset mapping relationship between weight and performance value.

[0016] Optionally, the preset canary release rules are configured in the rule customization resource. The rule customization resource is connected to the proxy container of each controller through the controller of the rule customization resource. Adjusting the preset canary release rules according to the success rate includes: obtaining the trend of success rate change; adding rule entries in the preset canary release rules when the trend is that the success rate is increasing; and reducing rule entries in the preset canary release rules when the trend is that the success rate is decreasing.

[0017] To achieve the above objectives, according to another aspect of this application, a canary deployment device for a controller is provided, applied to a proxy container of a target controller. The device includes: a calling unit, configured to, upon detecting that a change event has occurred in a target custom resource group, call an interface server to obtain attribute information of the change event from the target custom resource group; wherein the controller cluster includes a canary controller and at least one initial controller, the target controller is any controller in the controller cluster, and each controller in the controller cluster listens to resource events in its corresponding custom resource group; and a judging unit, configured to judge based on the attribute information and preset canary deployment rules. The system determines whether a change event is a grayscale event; a first generation unit is used to generate a grayscale event acquisition request based on attribute information and a preset grayscale identifier when the change event is a grayscale event, and send the grayscale event acquisition request to the interface server, wherein the interface server sends the change event to the grayscale controller based on the preset grayscale identifier; an adjustment unit is used to obtain the success rate of the grayscale controller in processing grayscale events, and adjust the preset grayscale release rules according to the success rate to obtain the target grayscale release rules; a release unit is used to detect any change event through the target grayscale release rules, and release the grayscale controller when the detection results all indicate that the change event is a grayscale event.

[0018] To achieve the above objectives, according to another aspect of this application, an electronic device is provided, the electronic device including a memory storing an executable program; and a processor for running the program, wherein the grayscale release method of the controller described above is executed when the program is running.

[0019] To achieve the above objectives, according to another aspect of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the grayscale release method of the controller described above.

[0020] In this embodiment, a proxy container determines whether a change event is a gray-scale event based on the attribute information of the change time and preset gray-scale release rules. If it is a gray-scale event, a gray-scale event retrieval request is generated and sent to the interface server. The interface server can then send the request to the gray-scale controller based on the identifier in the request. The gray-scale controller then processes the gray-scale event. By configuring a proxy container for each controller, the proxy container identifies and distributes the event, and redistributes it to the corresponding controller for processing according to the event type. This allows multiple controllers to process the event simultaneously without different controllers processing the same event, thereby improving the resource utilization and event execution efficiency of the controller. This solves the problem of low resource utilization and execution efficiency in related technologies that use external traffic control tools with election mechanisms for gray-scale release. Attached Figure Description

[0021] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 A hardware block diagram of a computer terminal for implementing a grayscale release method for a controller is shown. Figure 2 This is a schematic diagram of a grayscale publishing system for a controller provided in Embodiment 1 of this application; Figure 3 This is a flowchart of the grayscale release method for the controller provided in Embodiment 1 of this application; Figure 4 This is a configuration flowchart based on the preset grayscale release rules provided in Embodiment 1 of this application; Figure 5 This is a schematic diagram of a grayscale publishing device for a controller according to Embodiment 2 of this application; Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0022] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0024] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] It should be noted that the grayscale release method, apparatus, and electronic device for the controller as defined in this disclosure can be used in the field of computer technology, or in any field other than computer technology. The application fields of the grayscale release method, apparatus, and electronic device for the controller as defined in this disclosure are not limited.

[0026] It should be noted that the information, user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) used in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary confidentiality measures have been taken, and they do not violate public order and good morals.

[0027] The embodiments or examples disclosed herein are not exhaustive, but merely illustrative of some embodiments or examples, and are not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment or example can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment or example can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment or example can be arbitrarily interchanged. Furthermore, optional methods or examples in a particular embodiment or example can be arbitrarily combined; moreover, embodiments or examples can be arbitrarily combined. For example, some or all steps of different embodiments or examples can be arbitrarily combined, and a particular embodiment or example can be arbitrarily combined with optional methods or examples of other embodiments or examples.

[0028] For ease of description, the following explains some of the nouns or terms used in the embodiments of this application: Pod: The smallest deployment unit in Kubernetes. It can be understood as a collection of containers that share storage, network resources, etc. It is the basic unit of Kubernetes scheduling. Operator and Proxy, as cooperating components, can be deployed together in the same Pod and run collaboratively.

[0029] Operator: A custom resource controller in Kubernetes, used to manage specific types of custom resources (CRs), automatically handling operations such as creation, updating, and deletion of these resources to achieve the user-defined desired state.

[0030] Sidecar Proxy: A sidecar proxy container, which is a proxy component deployed inside a Pod. It is used to intercept events sent from inside the Pod to the Operator. It can redirect, modify, or filter events to implement specific network policies.

[0031] API Server: The API server is a core component of a Kubernetes cluster. It provides a REST API service that allows users and controllers to create, read, update, or delete resource CRs in the cluster via API calls.

[0032] A Kubernetes cluster consists of a group of nodes (including one or more master nodes and multiple worker nodes) used to run, manage, and schedule containerized applications. The cluster interacts with various controllers through the Kubernetes API to automate resource management.

[0033] Ingress rules: In Kubernetes, resource objects are used to define rules for external access to services within the cluster. They can specify network access policies such as URL routing, SSL termination, and load balancing.

[0034] Istio: An open-source service mesh platform used to provide traffic management, security, and monitoring functions in microservice architectures. Istio implements its core functionality by deploying sidecar proxies (such as Envoy) between services.

[0035] CPU (Central Processing Unit): The core component of computer hardware, responsible for executing program instructions and processing data, and representing computing power. In Kubernetes, CPU resources are requested and limited by Pods and containers.

[0036] CR Group: Refers to a group of custom resources that are logically grouped by specific tags or annotations, used to implement the division of labor among multiple controllers in an Operator.

[0037] CR events: These are events triggered by the API Server when a custom resource (CR) changes in the Kubernetes cluster. These events are listened to and responded to by the Operator.

[0038] Rule CR: Rule Custom Resource. It is a custom resource type in Kubernetes clusters used to describe event brokering and interception rules.

[0039] Gray-Controller: The gray-scale rule controller is a custom Kubernetes controller whose main function is to listen for changes in Rule CR and dynamically adjust the proxy rules in the Sidecar Proxy according to the configuration of Rule CR, so that events are correctly intercepted and redirected according to the gray-scale release strategy.

[0040] iptables rules: iptables rules are firewall rules. iptables is a firewall tool that runs in the Linux kernel space and is used to set network packet filtering rules.

[0041] MAC address: Media Access Control address. A MAC address is a unique hardware address assigned to a network interface card (NIC) for network communication at the data link layer.

[0042] ACL or eBPF strategies: Access Control List or eBPF (Extended Berkeley Packet Filter) strategies. An ACL (Access Control List) is a set of rules on a network device used to control network flow, deciding whether or not a packet passes based on information such as source IP, destination IP, and port. eBPF is an advanced technology in the Linux kernel that allows programs to be loaded and executed into the kernel at runtime to achieve efficient network filtering, tracing, and fault diagnosis.

[0043] Bridge interface: Bridge network interface. A bridge interface is a virtual network device used to connect multiple physical or virtual network interfaces.

[0044] NodePort traffic: In a Kubernetes cluster, the NodePort service type allows external traffic to access services within the cluster through a specific port on the node.

[0045] REDIRECT operation: A redirection operation. In iptables rules, the REDIRECT operation redirects packets to a port on the local system. It is often used to implement service proxying or traffic inspection.

[0046] DNAT operation: Destination Network Address Translation. DNAT is used to change the destination IP address of a data packet, making it point to another IP within the local system or cluster. It is a key mechanism for achieving external accessibility of internal services and load balancing.

[0047] OUTPUT chain: The OUTPUT chain is used for data packets sent from the local system.

[0048] PREROUTING chain: The PREROUTING chain is used to process data packets entering the local system whose destination has not yet been determined.

[0049] VNI (Virtual Network Identifier) ​​or VLAN Tag: A Virtual Network Identifier or VLAN Tag is a unique identifier used to identify virtual networks in an overlay network, commonly found in VXLAN network technology. A VLAN Tag, on the other hand, is a label used to delineate virtual LANs in a traditional network environment. It is attached to Ethernet frames so that devices can identify and forward data packets belonging to different VLANs.

[0050] DROP rule: A DROP rule is a drop rule in iptables or the ACL of a network device. A DROP rule instructs the system to drop network packets that meet specific conditions. It is often used in security policies to prevent unauthorized access or specific types of network attacks.

[0051] Overlay: Overlay network is a virtual network built on top of a physical network, allowing logical connections to be created between different physical networks.

[0052] CNI configuration: Container Network Interface configuration, is a specification used in Kubernetes and container runtimes to define network plugin interfaces.

[0053] Calico: Calico Network Plugin is a network plugin for Kubernetes and other container environments that provides highly scalable and secure network policy enforcement.

[0054] YAML file: YAML (YAML Ain't Markup Language) file, YAML format file, is a human-readable data serialization format, often used for configuration files and data exchange.

[0055] JSON: JavaScriptObject Notation. JavaScript is a lightweight data interchange format based on JavaScript syntax, but it serves as a language-independent, universal data format for data storage and transmission.

[0056] GPU: Graphics Processing Unit.

[0057] Example 1

[0058] According to an embodiment of this application, an embodiment of a canary release method for a controller is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0059] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing a canary release method for a controller is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, processing devices such as microprocessors or programmable logic devices), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface, a universal serial bus port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0060] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0061] Under the aforementioned operating environment, this application provides the following: Figure 2 The controller shown is a grayscale release system. Figure 2 This is a schematic diagram of a grayscale publishing system for a controller according to Embodiment 1 of this application, as shown below. Figure 2As shown, the aforementioned canary release method of the controller is executed using an optional controller canary release system as the execution entity. This controller canary release system includes at least: multiple cluster container Pods, an API server, and multiple custom resource groups (CR groups). The controller can include at least one canary controller (canary operator) and at least one initial controller (non-canary operator). Each controller is configured with a sidecar proxy container, and each controller and a proxy container are encapsulated within a container Pod. Multiple container Pods connect to the API server and, through the API server, connect to the corresponding custom resource groups to identify whether any change events have occurred in the custom resource groups. These change events can be operations such as modification, deletion, or addition. Upon detecting a change event, the corresponding controller needs to execute the event content carried in the event.

[0062] In the aforementioned system and operating environment, this application provides the following: Figure 3 The grayscale release method of the controller is shown. Figure 3 This is a flowchart of the canary release method for the controller according to Embodiment 1 of this application, as follows: Figure 3 As shown, the method includes: Step S301: When the target controller detects that a change event has occurred in the target custom resource group, the interface server is called to obtain the attribute information of the change event from the target custom resource group. The controller cluster includes a grayscale controller and at least one initial controller. The target controller is any controller in the controller cluster. Each controller in the controller cluster listens to the resource events in the corresponding custom resource group.

[0063] It should be noted that the execution entity in this embodiment is the proxy container Sidecar Proxy in the above system. The target controller can be the controller Operator in any Pod in the cluster. This controller can be a canary controller or an initial controller. The target custom resource group is the CR group corresponding to the target controller. The target controller needs to listen to whether CR events are generated in the target CR group, that is, whether change events are generated.

[0064] Optionally, when the target controller listens for resource events in the target custom resource group, once a change event (such as the creation, update, or deletion of a CR event) is detected, it will trigger an interaction with the interface server through the proxy container Sidecar Proxy to obtain the attribute information of the change event.

[0065] For example, suppose the target controller is the Operator of the grayscale version. It listens for changes to all CRs tagged with app:myapp under the namespace ns-gray. Once it detects these CR changes, it sends a request to the interface server through the proxy container Sidecar Proxy to obtain detailed information about the change events, such as CR name, version, event type, etc., thereby capturing the CR changes required for grayscale testing and providing a basis for subsequent processing and decision-making.

[0066] It should be noted that by setting up the Sidecar Proxy container, the core logic of the canary controller Operator that performs canary upgrades can be implemented through the Sidecar Proxy container without any changes.

[0067] Step S302: Determine whether the change event is a gray-scale event based on the attribute information and the preset gray-scale release rules.

[0068] It should be noted that, Figure 4 This is a configuration flowchart based on the preset grayscale release rules provided in Embodiment 1 of this application, as follows: Figure 4 As shown, preset canary release rules allow users to flexibly configure the Proxy's event handling strategy by creating custom rule resources (Rule CRs). Rule CRs define the Proxy's proxy rules, and users can configure preset canary release rules within them. These rules determine which events are canary release events and which are regular events. The preset canary release rules configured in Rule CRs can be distributed to the Proxy by the Gray-Controller, enabling real-time event control. It's important to note that the Gray-Controller is a crucial mechanism for implementing canary version Operator deployments and older version decommissioning. It also acts as the Operator's Sidecar configuration manager, a core component for achieving non-intrusive canary upgrades of the Operator.

[0069] The workflow of the Gray-Controller, a grayscale rule controller, is briefly described in Table 1: Table 1

[0070] The structural design table for Rule CR is shown in Table 2: Table 2

[0071] Optionally, upon receiving the attribute information, the Sidecar Proxy container can determine whether a change event belongs to a gray-scale event based on preset gray-scale release rules. This can be done by analyzing the CR tags of CR events, such as checking for the presence of tags like "version: gray". If the event conforms to the gray-scale rules, it will be treated as a gray-scale event; otherwise, it will be processed according to the normal process, thus distinguishing the type of CR event and ensuring that the gray-scale controller only processes gray-scale events.

[0072] Step S303: When the change event is a grayscale event, a grayscale event acquisition request is generated based on the attribute information and the preset grayscale identifier, and the grayscale event acquisition request is sent to the interface server. The interface server sends the change event to the grayscale controller based on the preset grayscale identifier.

[0073] Optionally, after confirming that the change event is a grayscale event, the target controller generates a grayscale event retrieval request based on the event's attribute information and then sends it to the interface server. Upon receiving the request, the interface server routes the grayscale event to the grayscale controller according to the rules for grayscale identification (e.g., checking if the CR contains the `version: gray` tag). For example, for a CR update event named `myCR` with version `gray`, the target controller generates a request containing detailed information about the CR and sends it to the interface server, which then forwards the event to the grayscale version's Operator according to preset rules. This step ensures that the grayscale event is correctly directed to the grayscale controller, providing a precise data flow for grayscale testing.

[0074] Step S304: Obtain the success rate of the grayscale controller in processing grayscale events, and adjust the preset grayscale release rules according to the success rate to obtain the target grayscale release rules.

[0075] Optionally, as the number of grayscale events increases, the success rate of the grayscale controller in handling grayscale events can be statistically analyzed, and the grayscale release rules can be dynamically adjusted based on this indicator, so that the number of events handled by the grayscale controller continues to increase until it can handle all events, thereby completing the smooth deployment operation of the grayscale controller. At this point, other initial controllers can be replaced with grayscale controllers based on the grayscale controllers that have completed testing, thereby completing the deployment operation of the grayscale controller.

[0076] Optionally, when calculating the success rate of the canary controller in handling canary events, the success rate can be calculated by analyzing data such as the canary controller's logs, health check results, and fault recovery status. For example, if the canary controller exhibits a high success rate (e.g., above 98%) when handling canary events of myCR, the scope of canary identification can be gradually expanded, allowing more CR events to be marked as canary events and processed by the canary controller. This allows for the use of more CR events as canary events to verify the stability and performance of the canary controller, enabling timely feedback and adjustments, and ensuring smooth canary deployment.

[0077] Step S305: Detect any change event using the target grayscale release rules, and release the grayscale controller if all detection results indicate that the change event is a grayscale event.

[0078] Optionally, under the adjusted canary release rules, any change event is detected and determined to be a canary event. Only when all change events are confirmed to fall within the scope of canary testing is the canary controller officially released, allowing it to process events as a formal controller, thus completing the canary controller release operation.

[0079] For example, through multiple iterations and adjustments, the grayscale indicator has been expanded from the initial small-scale test objects to a certain proportion of production environment CR events. At this point, the grayscale controller has verified that its reliability and performance meet the online requirements, and can officially start grayscale operation. This allows the grayscale controller to be seamlessly connected to the production environment after sufficient testing, avoiding potential risks and maintaining service quality.

[0080] In other words, this embodiment introduces a SidecarProxy container associated with the controller Operator within the Pod, allowing all CR events to flow through the proxy container of each controller for distribution and filtering. During the canary release, the old version of the Operator continues to run online, only receiving and processing CR events tagged with "old version," ensuring that live services are unaffected. The canary version of the Operator coexists with the old version, only intercepting and processing CR events tagged with "new version," achieving precise isolation of canary events. Testers only need to create CR resources tagged with "new version" in the CR Group to trigger the business logic of the canary Operator, thereby completing functional verification in a real environment without interrupting live services, improving the controllability and security of canary releases.

[0081] After the gray-scale test is passed, the gray-scale version is officially launched by switching events. At this time, the gray-scale version Operator will take over the event handling of all CRs, and the old version Operator will be taken offline. This makes the gray-scale version Operator release process non-intrusive to the Operator itself and avoids modification of the core logic.

[0082] The canary release method for controllers provided in this application embodiment sets up a proxy container for the controller. The proxy container determines whether a change event is a canary event based on the attribute information of the change time and preset canary release rules. If it is a canary event, it generates a canary event acquisition request and sends it to the interface server. The interface server can then send the request to the canary controller based on the identifier in the canary event acquisition request. The canary controller then processes the canary event. By configuring a proxy container for each controller, the proxy container identifies and distributes the event, and then redistributes it to the corresponding controller for processing according to the event type. This allows multiple controllers to process the event simultaneously without different controllers processing the same event. This improves the resource utilization and event execution efficiency of the controller, and solves the problem of low resource utilization and execution efficiency in related technologies that use external flow control tools with election mechanisms for canary release.

[0083] Optionally, in the canary release method for the controller provided in this application embodiment, after determining whether a change event is a canary event based on attribute information and preset canary release rules, the method further includes: if the change event is not a canary event, generating an initial event acquisition request based on attribute information; sending the initial event acquisition request to an interface server, wherein the interface server, upon recognizing that the initial event acquisition request does not carry a preset canary identifier, sends the change event to the initial controller and processes the initial event acquisition request through the initial controller.

[0084] It's important to note that change events refer to any state changes of custom resources (CRs) in a Kubernetes cluster, such as creation, updates, or deletions. The initial event retrieval request is a request generated by the initial controller and sent to the interface server to retrieve details of CR change events that are not marked as canary (i.e., regular). A default canary identifier can be a specific tag or attribute embedded in the CR event to identify whether the CR change event is part of a canary test. The initial controller is the Operator instance, as opposed to the canary controller, used to handle regular CR events.

[0085] Optionally, if it is determined that the change event does not belong to the category of grayscale events, then the change event needs to be processed by the initial controller. In this case, the proxy container Sidecar Proxy will generate an initial event retrieval request. For example, suppose the initial controller listens for an update event named myCR in the namespace ns-prod. If myCR is not marked as a grayscale event (i.e., it does not have a tag such as version: gray), then the initial controller will generate an initial event retrieval request based on the attribute information of myCR.

[0086] Furthermore, after generating the initial event retrieval request, the proxy container Sidecar Proxy sends it to the API server. Upon receiving the request, the API server checks if it carries a preset grayscale indicator. If it determines that the initial event retrieval request does not carry a preset grayscale indicator, the API server directly forwards the change event to the initial controller, i.e., the current stable version of the Operator. During this forwarding process, the API server maintains the original attribute information of the event, enabling the initial controller to make the correct processing decision based on accurate event information.

[0087] Furthermore, after receiving the change event forwarded by the interface server, the initial controller begins to execute the business logic related to regular event handling. This allows the initial controller to handle non-grayscale change events, avoiding the grayscale controller from handling change-related business logic and ensuring that change events are accurately distributed.

[0088] This embodiment generates an initial event acquisition request for non-grayscale events, enabling the interface server to send the change event to the initial controller for processing based on the initial event acquisition request, thereby improving the accuracy of event allocation.

[0089] In order to enable the initial controller to process events under load balancing conditions, optionally, in the canary release method of the controller provided in the embodiments of this application, sending the change event to the initial controller includes: obtaining the running data of each initial controller and determining the running health value of each initial controller based on the running data; obtaining the initial controller with the largest running health value, obtaining the target initial controller, and sending the change event to the target initial controller.

[0090] It should be noted that since there is an initial controller in the cluster, if the change event is determined to be a non-canary event, it is necessary to determine which initial controller to assign the change event to, so as to make the running state of the entire cluster optimal and thus improve the resource utilization of the entire cluster.

[0091] Optionally, in a Kubernetes environment, each initial controller runs within its corresponding Pod and continuously reports runtime status data through various means (such as Prometheus monitoring, health check probes, log analysis, etc.). This runtime status data includes, but is not limited to, CPU utilization, memory consumption, network I / O, event processing latency, number of successfully processed events, number of failed events, and error category statistics. This runtime data is collected from each initial controller periodically (e.g., every minute) or when events are triggered (e.g., when a change event occurs) to prepare for subsequent health value calculations.

[0092] It should be noted that the operational health value is a comprehensive score calculated based on a series of operational data. It reflects the initial controller's operational status and capacity at a given moment. The formula for calculating the health value can vary depending on requirements and resource management strategies, such as a weighted summation of key performance indicators (KPIs).

[0093] Optionally, after calculating the runtime health value, the controller with the highest health value is selected as the target initial controller by comparing the runtime health values ​​of all initial controllers, and the change event is sent to the target initial controller. The target initial controller then starts processing the change event through the Kubernetes API.

[0094] This embodiment calculates the operational health value of each initial controller and selects the target initial controller based on the operational health value, thereby making the entire cluster operate in the optimal state and improving the resource utilization of the entire cluster.

[0095] To ensure a high degree of matching between the controller and the custom resource group, optionally, in the canary release method for the controller provided in this application embodiment, the custom resource group corresponding to each controller is set in the following manner: obtaining multiple resource events and obtaining the first hash value of the event name of each resource event; obtaining the group number of the custom resource group and dividing the first hash value by the group number to obtain the remainder of each resource event; grouping the multiple resource events according to the remainder of the resource events to obtain multiple custom resource groups, and determining the custom resource group corresponding to each controller.

[0096] It should be noted that since there may be a large number of resource events (CRs), the resource events need to be grouped into multiple custom resource groups. Different controllers can then listen to the resource events in different custom resource groups. By automatically and evenly grouping and processing the resource events, the resource control capabilities and cluster management efficiency under the multi-controller architecture are improved.

[0097] Alternatively, when grouping, all resource events can be retrieved first, and the name of each resource event can be hashed to generate a numeric value. The choice of hash function should ensure a uniform distribution of results and avoid hotspot issues.

[0098] Furthermore, it is necessary to determine the number of custom resource groups, divide the first hash value by the number of groups, and use the remainder as the basis for grouping resource events. Based on the remainder obtained by dividing the first hash value of the resource event by the number of groups, the resource events are assigned to different custom resource groups.

[0099] After all resource events have been successfully grouped, it can be determined which custom resource groups each controller instance will handle. For example, controller instance controller-1 might be assigned to handle custom resource groups 1, 3, and 5, while controller-2 might handle 2, 4, and 6, and so on, thus balancing the workload across all controller instances.

[0100] It should be noted that, in this embodiment, other methods can also be used to group CR events, for example: 1. Grouping method based on CR name: Hash the "metadata.name" of each CR event, and then take the modulo of the number of Operators to determine which group the CR belongs to.

[0101] 2. Grouping based on CR tags or annotations: Add specific tags or annotations to CR events to identify the group they belong to, such as "sharding.example.com / group: "1".

[0102] 3. Namespace-based grouping: All CR events under the same namespace are grouped into one group.

[0103] This embodiment improves resource control capabilities and cluster management efficiency in a multi-controller architecture by grouping resource events.

[0104] To accurately match the custom resource group corresponding to each controller, optionally, in the canary release method for controllers provided in this application embodiment, determining the custom resource group corresponding to each controller includes: determining the load information of each controller, wherein the load information includes at least CPU utilization and event processing queue length; determining the load value of each controller based on the load information of each controller to obtain a load value sequence; obtaining the event trigger rate of each custom resource group to obtain an event trigger rate sequence, and determining the custom resource group corresponding to each controller according to the correspondence between the sequence number in the load value sequence and the sequence number in the event trigger rate sequence.

[0105] It should be noted that when determining the custom resource group corresponding to each controller, the controller's load information can be matched with the event trigger rate of the custom resource group to determine the custom resource group corresponding to each controller. The event trigger rate is the frequency of resource events triggered in each custom resource group, used to measure the group's activity level and resource requirements. Load information includes multiple key metrics covering the controller instance, such as CPU utilization and event processing queue length, used to assess its current processing capacity and status.

[0106] Optionally, load information for each controller instance can be collected periodically or in real-time through monitoring and data analysis. Load information includes at least CPU utilization and event processing queue length. For example, for controller instance Operator-01, using Kubernetes' built-in resource usage monitoring tools (such as Metrics Server) and a custom monitoring agent, its average CPU utilization over the past 10 minutes can be obtained as 35%, and the average event processing queue length as 10 events.

[0107] Furthermore, based on the acquired load information, it is necessary to calculate the load value for each controller. The load value can be a composite metric that comprehensively considers CPU utilization and event queue length, such as through mathematical models like weighted averaging or exponential decay. The resulting load value sequence is arranged sequentially for easy comparison and selection later.

[0108] At the same time, it is also necessary to analyze the activity level of each custom resource group. By calculating the ratio of the number of resource events triggered in the group to the time window over a period of time, the event trigger rate is determined, thereby reflecting the intensity and rate of change of resource demand in the custom resource group through the event trigger rate.

[0109] Furthermore, the system integrates the load value sequence and the event trigger rate sequence, and uses an algorithm to determine the matching relationship between controllers and custom resource groups. For example, controllers with high load values ​​should be assigned to groups with low event trigger rates to avoid overload; conversely, controllers with low load values ​​should handle groups with high event trigger rates, thereby completing the matching operation between controllers and custom resource groups, avoiding single-point overload, and improving overall resource utilization efficiency and system stability.

[0110] For example, if the load value of Operator-02 is less than that of Operator-01, and the event trigger rate of Group-Y is lower than that of Group-X, then Operator-02 is more suitable to handle Group-Y in order to achieve the goal of load balancing.

[0111] This embodiment improves the load balancing of the controller and the rationality of resource allocation by dynamically analyzing the load of the controller instance and the event trigger rate of the custom resource group, thereby avoiding single-point overload to the greatest extent and improving the overall resource utilization efficiency and system stability.

[0112] To accurately match the custom resource group corresponding to each controller, optionally, in the canary release method for controllers provided in this application embodiment, determining the custom resource group corresponding to each controller includes: calculating the second hash value of each controller, and adding each controller to a preset hash ring according to the second hash value; calculating the third hash value of the group name of each custom resource group, and mapping each custom resource group to the preset hash ring according to the third hash value; starting from the third hash value on the preset hash ring, searching for the second hash value clockwise, and determining the controller to which the first second hash value belongs as the controller corresponding to the custom resource group.

[0113] It should be noted that the default hash ring is a virtual ring structure used to store and locate controller instances. The hash ring can be used to achieve balanced resource grouping and controller allocation based on consistent hashing.

[0114] Optionally, when determining the custom resource group corresponding to each controller, a hash calculation can be performed on the unique identifier (such as the Operator name or namespace) of each running controller instance to generate a value, namely the second hash value. Then, this second hash value is located on a preset hash ring, and the corresponding controller instance identifier is added to that position.

[0115] For each custom resource group, the same hash function can be used to calculate the hash value of its group name, resulting in a third hash value. Then, the controller instance identifier corresponding to this third hash value is searched on a preset hash ring, realizing the dynamic binding between the resource group and the controller.

[0116] When determining the controller instance identifier corresponding to the third hash value, it is necessary to start from the third hash value of each custom resource group and search clockwise on the preset hash ring until the second hash value of the first controller is encountered, at which point the controller is considered to be the controller corresponding to that custom resource group. If the clockwise search starts from the third hash value and does not find the second hash value of a controller (that is, the end of the hash ring has been reached), the search will start again from the beginning of the ring (i.e., the smallest hash value) until a controller is found.

[0117] Once the relationship between each resource group and the controller is determined, the controller's configuration and cluster state can be updated so that change events can be listened to by the controller, and in turn, events in each custom resource group can be listened to by the controller.

[0118] This embodiment achieves dynamic and balanced matching between the controller and custom resource groups through a consistent hashing mechanism, thereby solving the single-node bottleneck and resource waste problem in the traditional Leader Election mechanism.

[0119] To accurately match the custom resource group corresponding to each controller, optionally, in the canary release method for controllers provided in this application embodiment, determining the custom resource group corresponding to each controller includes: determining the performance value of each controller based on the configuration information of each controller; determining the weight of each custom resource group based on the event trigger rate of each custom resource group; obtaining a preset mapping table, and determining the custom resource group corresponding to each controller based on the preset mapping table, wherein the preset mapping table includes a preset mapping relationship between the weight and the performance value.

[0120] Optionally, when determining the custom resource group corresponding to each controller, the deployment description file of each controller instance can be parsed to extract resource limits and requests (such as CPU and memory limits and requests), as well as configuration parameters related to event handling (such as maximum concurrent event handling, processing latency threshold, etc.). Based on this information, a pre-defined algorithm is used to calculate the performance value of each controller.

[0121] Furthermore, it is necessary to continuously monitor the activity of each custom resource group and calculate the event trigger rate for each group, which is the frequency of events occurring within a certain time window (e.g., within one hour). Based on the event trigger rate, the weight of each resource group is further calculated, and the weight reflects the estimated performance consumption of the custom resource group on the controller.

[0122] Furthermore, based on the calculated controller performance value and group weights, a preset mapping table needs to be consulted to find the most suitable allocation scheme. For example, the mapping table might specify that when the controller performance value is 20, it should handle custom resource groups with weights not exceeding 10. According to this specification, Group-1 (with a weight of 8), which has a lower weight, is assigned to Operator-1 for processing, avoiding overloading and resource waste. The preset mapping table stores the relationship between performance values ​​and weights to guide the allocation between the controller and custom resource groups.

[0123] Finally, once the allocation relationship between the controller and the custom resource group is determined, the controller's configuration and cluster state can be updated so that the controller only listens to events of the resource group whose performance matches its own, thereby achieving dynamic and balanced matching between the controller and the custom resource group.

[0124] This embodiment achieves reasonable allocation and load balancing of controller resources in a Kubernetes cluster by intelligently calculating performance values ​​and weights and using a preset mapping table to dynamically match controllers with custom resource groups.

[0125] It's important to note that when assigning controllers to each custom resource group, each Operator is assigned one or more group identifiers upon startup. This can be done through environment variables, startup parameters, or dynamic configuration injection via the coordinating controller. Each Operator only listens to and processes CR events within the group assigned to it. The assignment process can also be performed as follows: 1. Environment variable-based grouping: In the YAML file defined by the Operator container, the resource group that the current Operator needs to process can be explicitly specified by setting the environment variable GROUP_ASSIGNMENTS or a similar field.

[0126] The operator reads the contents of this environment variable at startup, parses it to obtain multiple logical group names (such as group-a, group-b), and registers an event filter internally to listen only for CRs with the following characteristics: 1) The CR metadata contains the tag group:group-a or group:group-b; 2) The namespace, name prefix, etc., of the CR conform to the matching conditions defined by the group strategy. There are two types of matching conditions: A. Namespace-based partitioning: For example, GROUP_ASSIGNMENTS="ml-ns-a,ml-ns-b" means that the CR will only be processed by the current Operator if the namespace it is in is ml-ns-a or ml-ns-b.

[0127] B. Matching based on resource name or prefix: Groups can be defined via regular expressions or prefixes, such as GROUP_ASSIGNMENTS="job-alpha- job-beta- The resource with CR name job-alpha-001 will be matched with job-alpha- The strategy is processed by the current Operator.

[0128] Optionally, the system supports defining default behavior: if the environment variable is missing, the Operator processes all CRs; if a group strategy is defined, strict filtering is performed.

[0129] 2. Grouping based on startup parameters: Operator binaries or Entrypoint scripts support passing task grouping information via startup parameters. For example: operator-controller--group=group-a--group=group-b; This method applies to Operators deployed via Helm or Operator Lifecycle Manager (OLM), where parameters are injected by the template during installation. At system startup, group identifiers are extracted from the parameters, similar to the environment variable method, and used to construct the filtering conditions for the CR listener.

[0130] In addition, it supports controlling the priority order of multiple groups through priority parameters, for example: operator-controller--group=group-a:1--group=group-b:2; This indicates that group-a has a high priority and will be processed first.

[0131] 3. Dynamic Injection Based on Coordinator Controller: In more complex deployment environments, a Coordinator Controller can be introduced to dynamically allocate group information. Its operation process is as follows: 1) The Coordinator Controller listens for the startup events of all Operators; 2) Grouping is performed based on factors such as node topology, load, and number of CRs; 3) Patch the allocation results to the Operator Pod's environment variables via the Kubernetes API, or mount them via Config Map or Volume injection; 4) When the Operator starts, it reads the group identifier from the mount configuration and applies it.

[0132] Furthermore, there may be situations where the number of Operators changes, requiring a redistribution of CR groups to achieve dynamic load balancing. This automatic allocation mechanism can recalculate the mapping relationship between CR groups and Operators, and achieve smooth migration without interrupting service, ensuring that the amount of resources processed by each Operator is roughly balanced, thereby improving the system's throughput and fault tolerance.

[0133] The methods for triggering the reallocation of CR groups can be as follows: 1. Change in the number of Operators; 2. Any Operator fails a health check, goes offline voluntarily, or exits abnormally; 3. The resource utilization rate of a certain operator is consistently higher than the set threshold (e.g., CPU > 80%). 4. Periodic rebalancing scheduling (e.g., assessing whether the allocation is balanced every 5 minutes).

[0134] To improve the accuracy of the CR group reallocation process, a lightweight GroupCoordinator can be introduced into the system to specifically handle the following process: Step 1: Discover currently online Operators; Step 2: Obtain grouping information and event load for all CR resources; Step 3: Based on the scheduling strategy, calculate the new mapping relationship between the Operator and the group; Step 4: Send the new group list to each Operator; Step 5: Trigger the reload of the listening rules within the Operator to achieve task takeover and release.

[0135] The scheduling strategy used can be: Strategy 1: Prioritize allocation based on minimum load; calculate the number of CRs currently allocated (or the number of events being processed) for each Operator; sort all groups and prioritize allocating unassigned or pending reallocation groups to the Operator with the fewest currently processed CRs; if multiple Operators have the same load, the balance can be broken by sorting by Pod name, hash results, etc.

[0136] Strategy 2: Consistent Hash Scheduling: Each group ID is mapped to a hash value; all operators are also mapped to nodes on the hash ring; groups are assigned to the first operator their hash value encounters in a clockwise direction on the ring; when an operator goes offline or online, only a small number of groups need to be remapped, providing stability and scalability.

[0137] Strategy 3: Weighted Round Robin or Static Label Aware Scheduling: If some Operators run on nodes with higher performance (such as those configured with GPUs), they can be assigned higher weights; groups are preferentially assigned to high-weight Operators, or based on the labels of the CR itself (such as group=latency-critical) are assigned only to specific Operators; it supports combining nodeAffinity and Pod labels to achieve business-level binding between groups and Operators.

[0138] Optionally, in the canary release method for controllers provided in this application embodiment, preset canary release rules are configured in a rule-defined resource. The rule-defined resource is connected to the proxy container of each controller through the controller of the rule-defined resource. Adjusting the preset canary release rules according to the success rate includes: obtaining the trend of success rate change; when the trend is that the success rate is increasing, adding rule entries in the preset canary release rules; when the trend is that the success rate is decreasing, reducing rule entries in the preset canary release rules.

[0139] Optionally, canary release rules can include event filtering conditions (such as version identifier, namespace, tags, etc.). Canary release rules can be written as configuration files in JSON or YAML format and stored in the rule custom resource. The rule custom resource is managed by a specific controller, which listens for Rule CR change events and updates the rule configuration in SidecarProxy in real time.

[0140] To allow the number of events that the grayscale controller can handle to change, the content of the rules can be adjusted according to the trend of success rate. If the success rate shows an upward trend (i.e., the performance of handling grayscale CR events gradually improves), the system automatically increases the number of rule entries that match grayscale CR events in the preset grayscale release rules, thereby gradually expanding the processing scope of the grayscale version controller.

[0141] Conversely, if the success rate decreases (i.e., the performance in handling grayscale CR events declines), the system reduces the number of rule entries matching grayscale CR events in the preset grayscale release rules, narrowing the processing scope of the grayscale version controller to reduce potential risks to the business.

[0142] This embodiment achieves intelligent expansion and rollback of the event handling scope of the grayscale version controller by dynamically adjusting the preset grayscale release rules, thereby improving the reliability and efficiency of grayscale upgrades and enabling a smooth business transition.

[0143] The following is a canary release process provided according to an embodiment of this application, including a testing phase and a release phase: Testing phase: (1) Deploying the new version of Operator: Users deploy the new version of Operator in the Kubernetes environment. The new version of Operator will coexist with the existing production version, but will not process production events for the time being. The purpose of deploying the new version of Operator is to perform functional verification and performance testing in a real cluster environment, and to improve its stability and reliability in the production environment.

[0144] (2) Configuring Sidecar Proxy in Gray-Controller: Gray-Controller is a custom controller that continuously monitors Operator deployments in the cluster. When a new Operator deployment is detected, Gray-Controller automatically injects a Proxy container as a Sidecar into the Pod where this Operator resides. These two containers share the same network namespace, enabling the Proxy to intercept and manage all events flowing to the Operator.

[0145] (3) Proxy Event Interception: After the Proxy container starts, it uses iptables to intercept events. For example, the following command redirects all events accessing the Kubernetes API Server to port 10000 within the Pod. This command redirects all events that would otherwise access the API Server to the port the Proxy is listening on. The Proxy processes these events according to the configuration rules in Rule CR, thereby controlling which requests are forwarded to the new version of the Operator and which continue to use the old version.

[0146] (4) Create a gray-scale Rule CR: The user creates a gray-scale Rule CR (rule custom resource). This resource describes the specific event proxy rules. Gray-Controller will detect this new Rule CR and configure the proxy rules defined in it into the corresponding Proxy service.

[0147] (5) Create a Canary Test CR: The tester creates a canary test CR, which describes the test operations to be performed. These canary test CRs are only processed by the new version of the Operator, and the old version of the Operator will not respond to them. This step allows the functionality and performance of the new version of the Operator to be verified in a real environment without affecting the existing production environment.

[0148] Release phase: (1) Change rule CR: After the gray-scale test is passed and the stability of the new version of Operator is verified, users will update the existing rule CR to modify the event proxy rules of the Proxy. This update operation will increase the CR event share of the new version of Operator, and gradually redirect more requests to the new version of Operator.

[0149] (2) Gray-Controller responds to rule CR changes: Gray-Controller continuously monitors for changes in the rule CR. Once an update to the rule CR is detected, Gray-Controller pushes the latest proxy rules to the corresponding Proxy container. In this way, the Proxy can adjust event distribution according to the new rules.

[0150] (3) Hot update of proxy rules: After receiving new proxy rules, the proxy container will immediately perform a hot update to switch the event configuration. Through hot update, the proxy can dynamically adjust the event distribution and switch more or all events to the new version of the Operator without restarting the container, thus maintaining a smooth event switching process and avoiding service interruption.

[0151] (4) Taking the old version of the Operator offline: Once the new version of the Operator has been running stably and has taken over all events, users can choose to take the old version of the Operator offline. This step includes deleting the old version of the Deployment and related resources, releasing cluster resources, and thus completing the deployment of the new version of the Operator.

[0152] It should be noted that the Sidecar Proxy container is a network proxy component with dynamic rule configuration capabilities. It is used to rewrite the request path sent by the Operator to the API Server, thereby enabling the filtering and processing of CR events. At the same time, the Proxy is also the execution unit for event interception. The Proxy has the following functions: 1. Adaptive Network Awareness: Before executing iptables rule settings, the proxy possesses adaptive network awareness, dynamically sensing the network structure and existing network configurations in the current container network namespace. This includes the following aspects: 1) IP Address and Subnet Awareness: The proxy can proactively read the IPv4 / IPv6 address information bound to each container within the current Pod and identify its subnet range, thereby avoiding the setting of rules that overwrite loopback, cluster internal service subnets, or local container communication. Furthermore, when performing REDIRECT or DNAT operations, the proxy ensures that the target address does not conflict with the IP segment of the current Pod.

[0153] 2) MAC address and interface identification: In the environment of supported container network plugins (such as Calico and Cilium), the Proxy can identify the MAC address of virtual network interfaces (such as veth pairs), avoiding triggering the MACSpoof detection mechanism when setting rules, so as not to conflict with MAC-based ACL or eBPF policies.

[0154] 3) Virtual Interface and Bridged Network Structure Awareness: The Proxy can enumerate network interfaces in the current namespace (such as eth0, cni0, docker0, etc.) and identify their binding relationships with the upper-layer bridged network. When inserting rules on the OUTPUT or PREROUTING chain, it can selectively skip bridge interfaces or established forwarding paths, so as not to block inter-Pod communication or NodePort events.

[0155] 4) Overlay network architecture support: For multi-tenant environments built on overlay networks, the proxy can be aware of the VNI or VLAN tag to which the current container belongs and avoids disrupting the overlay encapsulation and decapsulation logic when setting iptables rules. For example, the proxy will not set DROP rules before encapsulating VXLAN tunnel packets, thereby maintaining the integrity of cross-node overlay events.

[0156] 5) Integration of existing iptablesChain and rules: The Proxy supports scanning and analyzing the nat, filter, and mangle tables of iptables in the current network namespace to identify existing custom chains (such as chains inserted by sidecars like Envoy and Istio). Based on this, the Proxy will create independent chains and use the -j option for redirection to avoid issues such as chain overwriting, priority conflicts, or infinite loops with existing rules.

[0157] 6) CNI Configuration and Policy Compatibility: The Proxy can parse network configuration files in the / etc / cni / net.d directory on the host node and adapt rule policies based on the enabled plugin types (such as Calico, Flannel, and Cilium). For example, when Calico's GlobalNetworkPolicy enables namespace- and tag-based Egress control, the Proxy can dynamically insert rules to maintain uninterrupted communication with the Controller address.

[0158] 2. Event coordination with business containers: The proxy can use specific iptables rules to prevent events sent from business containers to the proxy's own management port or health check port from being intercepted, thereby maintaining the normal operation and observability of the proxy itself.

[0159] 3. Annotation-based auto-injection and configuration: Combined with Kubernetes' Admission Controller, auto-injection of the Proxy Sidecar can be achieved. When a user deploys a Pod, the Admission Controller can automatically modify the Pod definition based on the Pod's annotations, inject the Proxy container, and configure its startup parameters, including informing the Proxy of the types of events to be intercepted and the address of the Controller, thereby simplifying the user experience.

[0160] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0161] Example 2

[0162] This application also provides a grayscale deployment device for a controller. It should be noted that the grayscale deployment device for a controller in this application can be used to execute the grayscale deployment method for the controller provided in the above embodiments. The grayscale deployment device for a controller provided in this application will be described below.

[0163] According to an embodiment of this application, an apparatus for implementing the grayscale release method of the above-described controller is also provided. Figure 5 This is a schematic diagram of a grayscale publishing device for a controller according to Embodiment 2 of this application, as shown below. Figure 5 As shown, the device includes: Calling unit 51 is used to call the interface server to obtain the attribute information of the change event from the target custom resource group when the target controller detects that a change event has appeared in the target custom resource group. The controller cluster includes a grayscale controller and at least one initial controller. The target controller is any controller in the controller cluster. Each controller in the controller cluster listens to the resource events in the corresponding custom resource group.

[0164] Judgment unit 52 is used to determine whether a change event is a gray-scale event based on attribute information and preset gray-scale release rules.

[0165] The first generation unit 53 is used to generate a grayscale event acquisition request based on attribute information and a preset grayscale identifier when the change event is a grayscale event, and send the grayscale event acquisition request to the interface server. The interface server sends the change event to the grayscale controller based on the preset grayscale identifier.

[0166] The adjustment unit 54 is used to obtain the success rate of the grayscale controller in processing grayscale events, and adjust the preset grayscale release rules according to the success rate to obtain the target grayscale release rules.

[0167] The release unit 55 is used to detect any change event according to the target grayscale release rules, and release the grayscale controller when the detection results all indicate that the change event is a grayscale event.

[0168] Optionally, in the grayscale release device for the controller provided in the embodiments of this application, the device further includes: a second generation unit, used to generate an initial event acquisition request based on attribute information when the change event is not a grayscale event; and a sending unit, used to send the initial event acquisition request to an interface server, wherein the interface server, when it recognizes that the initial event acquisition request does not carry a preset grayscale identifier, sends the change event to the initial controller and processes the initial event acquisition request through the initial controller.

[0169] Optionally, in the grayscale release device for the controller provided in this application embodiment, the sending unit includes: a first acquisition module, used to acquire the running data of each initial controller and determine the running health value of each initial controller based on the running data; and a second acquisition module, used to acquire the initial controller with the largest running health value, obtain the target initial controller, and send the change event to the target initial controller.

[0170] Optionally, in the canary release device for the controller provided in this application embodiment, the custom resource group corresponding to each controller is set through the following device: a first acquisition unit, used to acquire multiple resource events and acquire the first hash value of the event name of each resource event respectively; a second acquisition unit, used to acquire the group number of the custom resource group and divide the first hash value by the group number to obtain the remainder of each resource event; and a determination unit, used to group the multiple resource events according to the remainder of the resource events to obtain multiple custom resource groups and determine the custom resource group corresponding to each controller.

[0171] Optionally, in the canary deployment device for controllers provided in this application embodiment, the determining unit includes: a first determining module, used to determine the load information of each controller, wherein the load information includes at least CPU utilization and event processing queue length; a second determining module, used to determine the load value of each controller based on the load information of each controller, and obtain a load value sequence; and a third determining module, used to obtain the event trigger rate of each custom resource group, obtain an event trigger rate sequence, and determine the custom resource group corresponding to each controller according to the correspondence between the sequence number in the load value sequence and the sequence number in the event trigger rate sequence.

[0172] Optionally, in the grayscale release device for the controller provided in this application embodiment, the determining unit includes: a first calculation module, used to calculate a second hash value for each controller and add each controller to a preset hash ring according to the second hash value; a second calculation module, used to calculate a third hash value for the group name of each custom resource group and map each custom resource group to the preset hash ring according to the third hash value; and a fourth determining module, used to search for the second hash value clockwise on the preset hash ring starting from the third hash value, and determine the controller to which the first second hash value belongs as the controller corresponding to the custom resource group.

[0173] Optionally, in the grayscale release device for the controller provided in this application embodiment, the determining unit includes: a fifth determining module, used to determine the performance value of each controller based on the configuration information of each controller; a sixth determining module, used to determine the weight of each custom resource group based on the event trigger rate of each custom resource group; and a seventh determining module, used to obtain a preset mapping table and determine the custom resource group corresponding to each controller based on the preset mapping table, wherein the preset mapping table includes a preset mapping relationship between weight and performance value.

[0174] Optionally, in the grayscale release device for the controller provided in this application embodiment, the preset grayscale release rules are configured in the rule customization resource. The rule customization resource is connected to the proxy container of each controller through the controller of the rule customization resource. The adjustment unit 54 includes: a third acquisition module, used to acquire the trend of success rate change; an addition module, used to add rule entries in the preset grayscale release rules when the trend is that the success rate is increasing; and a reduction module, used to reduce rule entries in the preset grayscale release rules when the trend is that the success rate is decreasing.

[0175] It should be noted that the aforementioned calling unit 51, judging unit 52, first generating unit 53, adjusting unit 54, and publishing unit 55 correspond to steps S301 to S305 in Embodiment 1. The instances and application scenarios implemented by each of these units and their corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should also be noted that the aforementioned modules or units can be hardware or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). These modules can also run as part of a device in the computer terminal 10 provided in Embodiment 1.

[0176] Example 3

[0177] Embodiments of this application may provide an electronic device. Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 6 As shown, the electronic device may include: one or more ( Figure 6 (Only one is shown) processor 1002, memory 1004, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0178] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0179] Those skilled in the art will understand that Figure 6 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 6 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0180] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0181] Example 4

[0182] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the canary release method of the controller provided in Embodiment 1.

[0183] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0184] Embodiments of this application also provide a computer program product, which, when executed on a data processing device, is adapted to perform the steps of a controller's grayscale release method.

[0185] Embodiments of this application also provide a computer-readable storage medium, which includes a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to execute the above-described grayscale release method of the controller.

[0186] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0187] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0188] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0189] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0190] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0191] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0192] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method of gray scale publishing for a controller, characterized by, The proxy container applied to the target controller includes: When the target controller detects that a change event has occurred in the target custom resource group, the interface server is invoked to obtain the attribute information of the change event from the target custom resource group. The controller cluster includes a grayscale controller and at least one initial controller. The target controller is any controller in the controller cluster. Each controller in the controller cluster listens to resource events in the corresponding custom resource group. Determine whether the change event is a gray-scale event based on the attribute information and the preset gray-scale release rules; When the change event is the grayscale event, a grayscale event acquisition request is generated based on the attribute information and the preset grayscale identifier, and the grayscale event acquisition request is sent to the interface server, wherein the interface server sends the change event to the grayscale controller based on the preset grayscale identifier; The success rate of the grayscale controller in processing the grayscale event is obtained, and the preset grayscale release rule is adjusted according to the success rate to obtain the target grayscale release rule; The grayscale release rule is used to detect any change event, and if the detection results all indicate that the change event is the grayscale event, the grayscale controller is released.

2. The method of claim 1, wherein, After determining whether the change event is a gray-scale event based on the attribute information and preset gray-scale release rules, the method further includes: If the change event is not the grayscale event, an initial event acquisition request is generated based on the attribute information; The initial event acquisition request is sent to the interface server. If the interface server detects that the initial event acquisition request does not carry the preset grayscale identifier, it sends the change event to the initial controller and processes the initial event acquisition request through the initial controller.

3. The method of claim 2, wherein, Sending the change event to the initial controller includes: Obtain the operating data of each initial controller, and determine the operating health value of each initial controller based on the operating data; Obtain the initial controller with the highest operating health value, obtain the target initial controller, and send the change event to the target initial controller.

4. The method of claim 1, wherein, Each controller's custom resource group is configured in the following way: Retrieve multiple resource events, and obtain the first hash value of the event name for each resource event; Obtain the group number of the custom resource group, and divide the first hash value by the group number to obtain the remainder for each resource event; The multiple resource events are grouped according to the remainder of the resource events to obtain multiple custom resource groups, and the custom resource group corresponding to each controller is determined.

5. The method of claim 4, wherein, Determining the custom resource group corresponding to each controller includes: Determine the load information for each controller, wherein the load information includes at least CPU utilization and event processing queue length; The load value of each controller is determined based on the load information of each controller, resulting in a load value sequence; Obtain the event trigger rate for each custom resource group to get the event trigger rate sequence, and determine the custom resource group corresponding to each controller according to the correspondence between the sequence number in the load value sequence and the sequence number in the event trigger rate sequence.

6. The method according to claim 4, characterized in that, Determining the custom resource group corresponding to each controller includes: Calculate a second hash value for each controller, and add each controller to a preset hash ring based on the second hash value; Calculate the third hash value of the group name of each custom resource group, and map each custom resource group to the preset hash ring according to the third hash value; Starting from the third hash value on the preset hash ring, the second hash value is searched clockwise, and the controller to which the first second hash value belongs is determined as the controller corresponding to the custom resource group.

7. The method according to claim 4, characterized in that, Determining the custom resource group corresponding to each controller includes: The performance value of each controller is determined based on its configuration information; The weight of each custom resource group is determined based on its event trigger rate. Obtain a preset mapping table and determine the custom resource group corresponding to each controller based on the preset mapping table, wherein the preset mapping table includes a preset mapping relationship between the weight and the performance value.

8. The method according to claim 1, characterized in that, The preset canary release rules are configured in the rule-defined resource. The rule-defined resource is connected to the proxy containers of each controller through the controller of the rule-defined resource. Adjusting the preset canary release rules according to the success rate includes: Obtain the trend of the success rate; If the trend indicates an increasing success rate, add a rule entry to the preset grayscale release rule; If the trend indicates a decrease in success rate, reduce the number of rule entries in the preset grayscale release rules.

9. A grayscale publishing device for a controller, characterized in that, The proxy container applied to the target controller includes: The calling unit is used to call the interface server to obtain the attribute information of the change event from the target custom resource group when the target controller detects that a change event has occurred in the target custom resource group. The controller cluster includes a grayscale controller and at least one initial controller. The target controller is any controller in the controller cluster. Each controller in the controller cluster listens to resource events in the corresponding custom resource group. The judgment unit is used to determine whether the change event is a gray-scale event based on the attribute information and the preset gray-scale release rules; The first generation unit is configured to, when the change event is the grayscale event, generate a grayscale event acquisition request based on the attribute information and a preset grayscale identifier, and send the grayscale event acquisition request to the interface server, wherein the interface server sends the change event to the grayscale controller based on the preset grayscale identifier; An adjustment unit is used to obtain the success rate of the grayscale controller in processing the grayscale event, and adjust the preset grayscale release rule according to the success rate to obtain the target grayscale release rule; The publishing unit is used to detect any change event according to the target grayscale publishing rule, and to publish the grayscale controller if the detection results all indicate that the change event is the grayscale event.

10. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program executes the canary release method of the controller according to any one of claims 1 to 8 when it runs.

Images