Helm application multi-cluster deployment method and system based on cluster federation

Abstract

The invention discloses a Helm application multi-cluster deployment method and system based on cluster federation, and the method comprises the steps: responding to a Helm application installation request, creating a target CRD resource, the target CRD resource comprising a HelmRelease object and a HelmRelocation object; determining a distribution configuration strategy according to the Helm application installation request, and performing cluster scheduling on the target CRD resource according to the distribution configuration strategy; when it is monitored that the CRD resources issued to the edge cluster change, Kubernetes resources of the Helm application are created according to the target CRD resources, and then the Kubernetes resources are scheduled to nodes of the edge cluster. The efficiency of Helm application multi-cluster deployment and the safety of a service system are improved, and the method can be widely applied to the technical field of information.

Description

Technical Field

[0001] The present invention relates to the field of information technology, and in particular to a cluster federation-based Helm application multi-cluster deployment method and system. Background Art

[0002] With the popularization and implementation of cloud-native technologies, more and more cloud-native applications require differentiated configurations to be deployed in different production environments. Since cloud-native applications are usually distributed based on the cloud, and Helm applications are usually called by multiple functional components to provide a complete service, each component may have its own independent iteration process, and different environments will also present differentiated configurations. In this complex scenario, how to configure components and manage differentiated versions of Helm applications in multiple Kubernetes clusters becomes extremely complex and cumbersome. If maintenance is only performed through manual configuration, it will not only be inefficient, but the business system will also face huge risks.

[0003] Terminology explanation:

[0004] Kubernetes cluster: A group of node computers used to run containerized applications.

[0005] Helm: A package management tool for Kubernetes applications.

[0006] Helm application: an application released in the form of a Helm chart package.

[0007] FluxCD: A set of tools that can support the implementation of GitOps. It is responsible for monitoring changes in configuration sources, values ​​parameter configuration, etc., comparing the actual running status of the current application with the expected running status, automatically pulling changes and synchronizing them to the cluster environment.

[0008] Karmada: Provides plug-and-play automation tools for multi-cluster application management in multi-cloud and hybrid cloud scenarios.

[0009] Kubernetes: is a portable and extensible open source platform, abbreviated as (k8s). Summary of the invention

[0010] The purpose of the present invention is to solve one of the technical problems existing in the prior art to at least a certain extent.

[0011] To this end, an object of an embodiment of the present invention is to provide a Helm application multi-cluster deployment method based on cluster federation, which improves the efficiency of Helm application multi-cluster deployment and the security of the business system.

[0012] Another object of an embodiment of the present invention is to provide a Helm application multi-cluster deployment system based on cluster federation.

[0013] In order to achieve the above technical objectives, the technical solutions adopted by the embodiments of the present invention include:

[0014] On the one hand, an embodiment of the present invention provides a Helm application multi-cluster deployment method based on cluster federation, comprising the following steps:

[0015] In response to the Helm application installation request, create a target CRD resource, wherein the target CRD resource includes a HelmRelease object and a HelmRepositry object;

[0016] Determine a distribution configuration strategy according to the Helm application installation request, and perform cluster scheduling on the target CRD resource according to the distribution configuration strategy;

[0017] When a change is detected in the CRD resource sent to the edge cluster, a Kubernetes resource of the Helm application is created according to the target CRD resource, and then the Kubernetes resource is scheduled to the node of the edge cluster.

[0018] Further, in one embodiment of the present invention, in response to the Helm application installation request, creating a target CRD resource specifically includes:

[0019] Receive the Helm application installation request from the user through Karmada-apiserver, and initiate a CRD resource creation request to Karmada-controller-manager;

[0020] The HelmRelease object and the HelmRepositry object are created by the Karmada-controller-manager according to a preset resource template, and the HelmRelease object and the HelmRepositry object are returned to the Karmada-apiserver.

[0021] Further, in one embodiment of the present invention, determining a distribution configuration strategy according to the Helm application installation request, and performing cluster scheduling on the target CRD resource according to the distribution configuration strategy specifically includes:

[0022] Parse the Helm application installation request through Karmada-apiserver to obtain the distribution configuration strategy, and send the target CRD resource and the distribution configuration strategy to Karmada-scheduler;

[0023] Sending the target CRD resource to the edge cluster according to the distribution configuration strategy through the Karmada-scheduler;

[0024] The distribution configuration policy is a PropagationPolicy policy or an OverridePolicy policy.

[0025] Further, in one embodiment of the present invention, the sending of the target CRD resource to the edge cluster according to the distribution configuration strategy specifically includes:

[0026] When the distribution configuration strategy is the PropagationPolicy strategy, multiple available edge clusters are determined according to the target CRD resources, and the available edge clusters are scored and sorted to obtain multiple target edge clusters, and then the target CRD resources are sent to the target edge clusters;

[0027] When the distribution configuration policy is the OverridePolicy policy, the target edge cluster is determined according to the OverridePolicy policy, and the target CRD resource is sent to the target edge cluster.

[0028] Further, in one embodiment of the present invention, when a change in the CRD resource sent to the edge cluster is detected, a Kubernetes resource of the Helm application is created according to the target CRD resource, which specifically includes:

[0029] When Helm-controller detects that the CRD resource sent to the edge cluster has changed, it obtains the target CRD resource and parses the target CRD resource to obtain application configuration information, and then initiates a Kubernetes resource creation request to Kube-apiserver according to the application configuration information;

[0030] Calling Kube-controller-manager through the Kube-apiserver to create the corresponding Kubernetes resources according to the application configuration information;

[0031] The application configuration information includes namespace, custom resources, Kubernetes role permissions, and released Helm applications.

[0032] Further, in one embodiment of the present invention, scheduling the Kubernetes resources to the nodes of the edge cluster specifically includes:

[0033] Sending the Kubernetes resources to Kube-scheduler through the Kube-apiserver;

[0034] The Kube-scheduler determines multiple schedulable nodes of the edge cluster according to the Kubernetes resources, scores and sorts the schedulable nodes to obtain multiple target nodes, and then schedules the Kubernetes resources to the target nodes.

[0035] Furthermore, in one embodiment of the present invention, the cluster federation-based Helm application multi-cluster deployment method further includes the following steps:

[0036] Return resource scheduling results to Kube-apiserver through Kube-scheduler;

[0037] Return the Helm Release status message to Helm-controller through the Kube-apiserver;

[0038] Return the Helm application deployment result to Karmada-scheduler through the Helm-controller;

[0039] Return the Karmada scheduling result to the Karmada-apiserver service through the Karmada-scheduler;

[0040] The Helm application installation event is returned to the user end through the Karmada-apiserver.

[0041] On the other hand, an embodiment of the present invention provides a Helm application multi-cluster deployment system based on cluster federation, including:

[0042] A target CRD resource creation module, used to create a target CRD resource in response to a Helm application installation request, wherein the target CRD resource includes a HelmRelease object and a HelmRepositry object;

[0043] A target CRD resource scheduling module, used to determine a distribution configuration strategy according to the Helm application installation request, and perform cluster scheduling on the target CRD resource according to the distribution configuration strategy;

[0044] The Kubernetes resource scheduling module is used to create Kubernetes resources of the Helm application according to the target CRD resources when changes are detected in the CRD resources sent to the edge cluster, and then schedule the Kubernetes resources to the nodes of the edge cluster.

[0045] Furthermore, in one embodiment of the present invention, the Kubernetes resource scheduling module includes:

[0046] The request unit is used to obtain the target CRD resource when the Helm-controller detects that the CRD resource sent to the edge cluster has changed, and parse the target CRD resource to obtain application configuration information, and then initiate a Kubernetes resource creation request to the Kube-apiserver according to the application configuration information;

[0047] A resource creation unit, configured to create the corresponding Kubernetes resources according to the application configuration information by calling Kube-controller-manager through the Kube-apiserver;

[0048] The application configuration information includes namespace, custom resources, Kubernetes role permissions, and released Helm applications.

[0049] Furthermore, in one embodiment of the present invention, the Kubernetes resource scheduling module further includes:

[0050] A resource sending unit, used to send the Kubernetes resources to Kube-scheduler through the Kube-apiserver;

[0051] A resource scheduling unit is used to determine multiple schedulable nodes of the edge cluster according to the Kubernetes resources through the Kube-scheduler, score and sort the schedulable nodes to obtain multiple target nodes, and then schedule the Kubernetes resources to the target nodes.

[0052] The advantages and beneficial effects of the present invention will be partly given in the following description, partly become apparent from the following description, or be understood through the practice of the present invention:

[0053] In response to the Helm application installation request, the embodiment of the present invention creates a target CRD resource, the target CRD resource includes a HelmRelease object and a HelmRepositry object, determines the distribution configuration strategy according to the Helm application installation request, and performs cluster scheduling on the target CRD resource according to the distribution configuration strategy. When the CRD resource sent to the edge cluster is monitored to change, the Kubernetes resource of the Helm application is created according to the target CRD resource, and the Kubernetes resource is then scheduled to the node of the edge cluster. In the embodiment of the present invention, a HelmRepository object and a HelmRelease object are defined in the central cluster control plane, and they are used as CRD resources for edge cluster distribution, so that there is no need to modify the native Helm chart package, reduce the complexity of operation and maintenance, and support the batch and differentiated configuration iteration update of the Helm application, so as to achieve out-of-the-box and flexible application; by introducing cluster federation technology, in the multi-cluster application scenario, the Helm application can be reasonably scheduled to the edge cluster according to the cluster resource status and strategy, which can ensure the high availability of the Helm application while maximizing the saving of cluster resources, and improve the efficiency of multi-cluster deployment of the Helm application and the security of the business system. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] In order to more clearly illustrate the technical solution in the embodiments of the present invention, the following introduction is made to the drawings required for use in the embodiments of the present invention. It should be understood that the drawings introduced below are only for the convenience of clearly describing some embodiments of the technical solution of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0055] Figure 1 A flowchart of a multi-cluster deployment method of Helm application based on cluster federation provided in an embodiment of the present invention;

[0056] Figure 2 A data interaction diagram of a Helm application multi-cluster deployment method based on cluster federation provided in an embodiment of the present invention;

[0057] Figure 3 A step flow chart of step S101 provided in an embodiment of the present invention;

[0058] Figure 4 A schematic diagram of the data structure of a HelmRelease object provided in an embodiment of the present invention;

[0059] Figure 5 A schematic diagram of the data structure of a HelmRepositry object provided in an embodiment of the present invention;

[0060] Figure 6 A step flow chart of step S102 provided in an embodiment of the present invention;

[0061] Figure 7 A schematic diagram of the data structure of the PropagationPolicy strategy provided in an embodiment of the present invention;

[0062] Figure 8 A schematic diagram of the data structure of the OverridePolicy strategy provided in an embodiment of the present invention;

[0063] Fig. 9 A step flow chart of step S1022 provided in an embodiment of the present invention;

[0064] Fig.10 A step flow chart of step S103 provided in an embodiment of the present invention;

[0065] Fig.11 Another step flow chart of step S103 provided in an embodiment of the present invention;

[0066] Fig.12 A schematic diagram of the structure of a Helm application multi-cluster deployment system based on cluster federation provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0067] Embodiments of the present invention are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be understood as limitations on the present application. It should be noted that, although the functional module division is performed in the system schematic diagram and the logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order from the module division in the system schematic diagram or the flow chart. For the step numbers in the following embodiments, they are only set for the convenience of explanation, and the order between the steps is not limited in any way. The execution order of each step in the embodiment can be adaptively adjusted according to the understanding of those skilled in the art.

[0068] In the description of the present invention, the meaning of "a plurality" is two or more. If there is a description of the first or the second, it is only for the purpose of distinguishing the technical features, and it cannot be understood as indicating or implying the relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features. In addition, unless otherwise defined, all technical and scientific terms used in this document have the same meaning as those commonly understood by technicians in the technical field of this application. The terms used in this document are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0069] The multi-cluster deployment method of Helm application based on cluster federation provided in the embodiment of the present application can be applied to the terminal, can also be applied to the server side, and can also be software running in the terminal or the server side. In some embodiments, the terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a set-top box, etc.; the server side can be configured as an independent physical server, or a server cluster or a distributed system composed of multiple physical servers, and can also be configured as a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application that implements the multi-cluster deployment method of Helm application based on cluster federation, etc., but is not limited to the above forms.

[0070] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments, in which tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computers including storage devices.

[0071] It should be noted that in each specific implementation of the present application, when it comes to the need to perform relevant processing based on data related to user identity or characteristics such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first, and the collection, use, and processing of these data will comply with the relevant laws, regulations, and standards of the relevant countries and regions. In addition, when the embodiment of the present application needs to obtain the user's sensitive personal information, the user's separate permission or consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary user-related data for the normal operation of the embodiment of the present application will be obtained.

[0072] In view of the problems of large workload of iterative update of Helm applications, difficult maintenance of differentiated configurations, and prone configuration errors in current multi-cluster scenarios, the present invention proposes a fully automated management solution for Helm application resources in multi-cluster scenarios based on cluster federation technology and GitOps tools. This solution can realize differentiated configuration distribution and multi-strategy scheduling of Helm applications in multiple clusters, as well as full life cycle management such as deployment, update, rollback, and uninstallation of Helm applications. At the same time, it is compatible with native chart packages, truly realizing the plug-and-play nature of Helm applications in multi-cloud and multi-cluster scenarios.

[0073] like Figure 1 FIG. 1 is a flowchart of a multi-cluster deployment method for Helm applications based on cluster federation provided by an embodiment of the present invention. Figure 1 The embodiment of the present invention provides a Helm application multi-cluster deployment method based on cluster federation, which specifically includes the following steps:

[0074] S101. In response to a Helm application installation request, create a target CRD resource, where the target CRD resource includes a HelmRelease object and a HelmRepositry object;

[0075] S102. Determine the distribution configuration strategy according to the Helm application installation request, and perform cluster scheduling on the target CRD resources according to the distribution configuration strategy;

[0076] S103. When it is detected that the CRD resources sent to the edge cluster have changed, a Kubernetes resource of the Helm application is created according to the target CRD resource, and then the Kubernetes resource is scheduled to the node of the edge cluster.

[0077] like Figure 2The figure shows a data interaction diagram of a Helm application multi-cluster deployment method based on cluster federation provided in an embodiment of the present invention. The embodiment of the present invention deploys a Helm application full life cycle management module and a Helm application multi-cluster scheduling management module. The Helm application full life cycle management module and the Helm application multi-cluster scheduling management module in the embodiment of the present invention are introduced and explained below.

[0078] The Helm application lifecycle management module mainly includes three sub-modules: Helm-controller, Source-controller and Notification-controller.

[0079] Helm-controller is essentially a Kubernetes operator that allows Helm chart releases to be managed declaratively using Kubernetes manifests. It provides an automated operator that can perform Helm operations (such as install, upgrade, uninstall, rollback, test) and continuously coordinate the status of Helm Releases.

[0080] Source-controller mainly provides other components with a tool to continuously pull the Helm application package list from Git, Harbor, and Chartmuseumy source repositories.

[0081] Notification-controller is mainly responsible for handling inbound and outbound events. On the one hand, it handles events from external systems (Git / Harbor / Chartmuseumy), and on the other hand, it handles event notifications from Helm-controller about Helm application deployment, update, rollback and other operations, and forwards them to external systems according to the severity of the events.

[0082] The Helm application multi-cluster scheduling management module mainly includes Karmada-apiserver, Kube-controller-manager, Karmada-controller-manager, Karmada-scheduler and other sub-modules, among which:

[0083] Karmada-apiserver is a component of the cluster federation control plane. It is mainly responsible for exposing Karmada-apiserver and Kubernetes native APIs to other components for calling.

[0084] Kube-controller-manager selects some controllers from Kubernetes and keeps them for running controller processes of different resources.

[0085] Karmada-controller-manager is also a component of the cluster federation control plane. It is mainly used to run various custom controller processes, monitor Karmada objects, and communicate with the api-server of the underlying cluster to create native Kubernetes resources.

[0086] Karmada-scheduler is responsible for scheduling Kubernetes native API resource objects (as well as CRD resources) to member clusters. The scheduler determines which clusters are available for resources in the scheduling queue based on policy constraints and available resources. The scheduler then scores and sorts each available cluster and binds resources to the most appropriate cluster.

[0087] In addition, the embodiment of the present invention introduces cluster federation technology, and broadcasts edge nodes by defining PropagationPolicy and OverridePolicy policies, wherein the PropagationPolicy policy is used to distribute the same Helm version application to multiple clusters, and the OverridePolicy policy is used to distribute specific Helm application configurations to a specific cluster. The embodiment of the present invention installs Karmada in the central cluster, and installs the FluxCD controller in the central cluster and the edge cluster. By centrally managing the Helm application component configuration in the central cluster, the central cluster will actively push differentiated configurations to the edge through Karmada, schedule them to available edge clusters, and monitor the status of the Helm application in the edge cluster to achieve the expected effect of the customized parameter configuration.

[0088] Combine the following Figure 2 The method steps of the embodiment of the present invention are further described.

[0089] like Figure 3 FIG. 1 is a flowchart of step S101 provided in an embodiment of the present invention, referring to FIG. Figure 3 As an optional implementation, in response to the Helm application installation request, a target CRD resource is created, which specifically includes:

[0090] S1011. Receive the Helm application installation request from the user through Karmada-apiserver, and initiate a CRD resource creation request to Karmada-controller-manager;

[0091] S1012. Create a HelmRelease object and a HelmRepositry object according to a preset resource template through Karmada-controller-manager, and return the HelmRelease object and the HelmRepositry object to Karmada-apiserver.

[0092] Specifically, the user initiates a Helm application installation request to the system; after receiving the request, the federated cluster control plane component Karmada-apiserver initiates a request to create HelmRelease and HelmRepositry objects to the component Karmada-controller-manager. In the embodiment of the present invention, the data structures of the created CRD resource objects HelmRelease and HelmRepositry are respectively as follows: Figure 4 and Figure 5 shown.

[0093] like Figure 6 FIG. 1 is a flow chart of step S102 provided in an embodiment of the present invention, referring to FIG. Figure 6 As an optional implementation, a distribution configuration strategy is determined according to the Helm application installation request, and cluster scheduling is performed on the target CRD resource according to the distribution configuration strategy, which specifically includes:

[0094] S1021. Parse the Helm application installation request through Karmada-apiserver to obtain the distribution configuration strategy, and send the target CRD resource and the distribution configuration strategy to Karmada-scheduler;

[0095] S1022. Send the target CRD resources to the edge cluster according to the distribution configuration strategy through Karmada-scheduler;

[0096] The distribution configuration policy is the PropagationPolicy policy or the OverridePolicy policy.

[0097] Specifically, the Karmada-controller-manager component returns a resource creation message; the Karmada-apiserver provides the PropagationPolicy or OverridePolicy configured in the Helm deployment request initiated by the user to the Karmada-scheduler component, and the Karmada-scheduler component performs cluster scheduling of target CRD resources according to the policy. In the embodiment of the present invention, the PropagationPolicy policy is a global federated cluster resource distribution configuration policy, and the OverridePolicy policy is a personalized specific federated cluster resource coverage distribution configuration policy. The data structures of the PropagationPolicy policy and the OverridePolicy policy are as follows: Figure 7 and Figure 8 shown.

[0098] like Fig. 9 FIG. 1 is a flow chart of step S1022 provided in an embodiment of the present invention, referring to FIG. Fig. 9 As an optional implementation, the target CRD resource is sent to the edge cluster according to the distribution configuration strategy, which specifically includes:

[0099] S10221. When the distribution configuration policy is the PropagationPolicy policy, multiple available edge clusters are determined according to the target CRD resources, and the available edge clusters are scored and sorted to obtain multiple target edge clusters, and then the target CRD resources are sent to the target edge clusters;

[0100] S10222. When the distribution configuration policy is the OverridePolicy policy, determine the target edge cluster according to the OverridePolicy policy, and send the target CRD resource to the target edge cluster.

[0101] like Fig.10 FIG. 1 is a flow chart of step S103 provided in an embodiment of the present invention, referring to FIG. Fig.10 As an optional implementation, when a change is detected in the CRD resource sent to the edge cluster, a Kubernetes resource of the Helm application is created according to the target CRD resource, which specifically includes:

[0102] S1031. When Helm-controller detects that the CRD resource sent to the edge cluster has changed, it obtains the target CRD resource and parses the target CRD resource to obtain the application configuration information, and then initiates a Kubernetes resource creation request to Kube-apiserver according to the application configuration information.

[0103] S1032. Call Kube-controller-manager through Kube-apiserver to create corresponding Kubernetes resources according to application configuration information;

[0104] The application configuration information includes namespaces, custom resources, Kubernetes role permissions, and released Helm applications.

[0105] Specifically, the Helm-controller component monitors changes in the CRD resources sent to the edge cluster, and initiates a request to the Kube-apiserver service to create corresponding namespaces, custom resources, k8s role permissions, and released Helm applications based on the configuration defined in the CRD; the Kube-apiserver service receives the request and calls the Kube-controller-manager to create the corresponding Kubernetes resources; the Kube-controller-manager service receives the call request from the Kube-apiserver service and creates a thread to create resources.

[0106] like Fig.11 FIG. 1 is another step flow chart of step S103 provided in an embodiment of the present invention, referring to FIG. Fig.11 As an optional implementation, Kubernetes resources are scheduled to the nodes of the edge cluster, which specifically includes:

[0107] S1033, send Kubernetes resources to Kube-scheduler through Kube-apiserver;

[0108] S1034. Determine multiple schedulable nodes of the edge cluster according to Kubernetes resources through Kube-scheduler, score and sort the schedulable nodes, obtain multiple target nodes, and then schedule Kubernetes resources to the target nodes.

[0109] Specifically, the downstream service returns the message of creating k8s resources to the Kube-apiserver service; the Kube-scheduler service schedules the created Kubernetes resources to the appropriate nodes.

[0110] As an optional implementation, the Helm application multi-cluster deployment method based on cluster federation further includes the following steps:

[0111] Return resource scheduling results to Kube-apiserver through Kube-scheduler;

[0112] Return the Helm Release status message to Helm-controller through Kube-apiserver;

[0113] Return the Helm application deployment results to Karmada-scheduler through Helm-controller;

[0114] Return Karmada scheduling results to Karmada-apiserver service through Karmada-scheduler;

[0115] Returns the Helm application installation event to the user through Karmada-apiserver.

[0116] like Figure 2 As shown, a complete process of the Helm application multi-cluster deployment method based on cluster federation in an embodiment of the present invention is as follows:

[0117] Step S01: The user initiates a Helm application installation request to the system.

[0118] Step S02: After receiving the request, the federated cluster control plane component Karmada-apiserver initiates a request to create HelmRelease and HelmRepositry objects to the component Karmada-con troller-manager.

[0119] Step S03: The Karmada-controller-manager component returns a resource creation message.

[0120] Step S04: Karmada-apiserver provides the PropagationPolicy or OverridePolicy configured in the Helm deployment request initiated by the user to the Karmada-scheduler component, and performs cluster scheduling according to the strategy to create the resources in step S02.

[0121] Step S05: The Helm-controller component detects changes in the CRD resources sent to the edge cluster, and initiates a request to the Kube-apiserver service to create the corresponding namespace, custom resources, k8s role permissions, and released Helm applications according to the configuration defined by the CRD.

[0122] Step S06: The Kube-apiserver service receives the request of step S05 and calls Kube-controller-manager to create corresponding Kubernetes resources.

[0123] Step S07: The Kube-controller-manager service receives the Kube-apiserver service and creates a thread to create resources.

[0124] Step S08: The downstream service returns the message of creating k8s resources to the Kube-apiserver service.

[0125] Step S09: The Kube-scheduler service schedules the resources created in step S07 to the appropriate nodes.

[0126] Step S10: The Kube-scheduler service returns a resource scheduling message to the Kube-apiserver service.

[0127] Step S11: The Kube-apiserver service returns the Helm release application status message to the Helm-controller component.

[0128] Step S12: The Helm-controller component returns the edge cluster result information of the Helm release application deployment to the Karmada-scheduler component.

[0129] Step S13: The returned Karmada scheduling message is given to the Karmada-apiserver service.

[0130] Step S14: The Karmada-apiserver service returns the event message of installing the Helm application to the user.

[0131] The above is an explanation of the method steps of the embodiment of the present invention. It can be recognized that the embodiment of the present invention defines a HelmRepository object and a HelmRelease object in the central cluster control plane, and distributes them to the edge cluster as CRD resources, so that there is no need to modify the native Helm chart package, which reduces the complexity of operation and maintenance while supporting the batch and differentiated configuration iterative update of Helm applications, achieving out-of-the-box use and flexible application; by introducing cluster federation technology, in multi-cluster application scenarios, the Helm application can be reasonably scheduled to the edge cluster according to the cluster resource status and strategy, which can ensure the high availability of the Helm application while maximizing the saving of cluster resources, and improve the efficiency of multi-cluster deployment of the Helm application and the security of the business system.

[0132] like Fig.12FIG. 1 is a schematic diagram of a Helm application multi-cluster deployment system based on cluster federation provided in an embodiment of the present invention. Fig.12 The embodiment of the present invention provides a Helm application multi-cluster deployment system based on cluster federation, including:

[0133] The target CRD resource creation module is used to create a target CRD resource in response to a Helm application installation request. The target CRD resource includes a HelmRelease object and a HelmRepositry object.

[0134] The target CRD resource scheduling module is used to determine the distribution configuration strategy according to the Helm application installation request, and perform cluster scheduling on the target CRD resources according to the distribution configuration strategy;

[0135] The Kubernetes resource scheduling module is used to create Kubernetes resources for the Helm application based on the target CRD resources when changes are detected in the CRD resources sent to the edge cluster, and then schedule the Kubernetes resources to the nodes of the edge cluster.

[0136] As an optional implementation, the Kubernetes resource scheduling module includes:

[0137] The request unit is used to obtain the target CRD resource when Helm-controller detects changes in the CRD resource sent to the edge cluster, parse the target CRD resource, obtain the application configuration information, and then initiate a Kubernetes resource creation request to Kube-apiserver based on the application configuration information;

[0138] The resource creation unit is used to call Kube-controller-manager through Kube-apiserver to create corresponding Kubernetes resources according to application configuration information;

[0139] The application configuration information includes namespaces, custom resources, Kubernetes role permissions, and released Helm applications.

[0140] As an optional implementation, the Kubernetes resource scheduling module further includes:

[0141] Resource sending unit, used to send Kubernetes resources to Kube-scheduler through Kube-apiserver;

[0142] The resource scheduling unit is used to determine multiple schedulable nodes of the edge cluster according to Kubernetes resources through Kube-scheduler, score and sort the schedulable nodes, obtain multiple target nodes, and then schedule Kubernetes resources to the target nodes.

[0143] The contents of the above method embodiments are all applicable to the present system embodiments. The functions specifically implemented by the present system embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0144] In some selectable embodiments, the function / operation mentioned in the block diagram may not occur in the order mentioned in the operation diagram. For example, depending on the function / operation involved, the two boxes shown in succession can actually be executed substantially simultaneously or the above-mentioned boxes can sometimes be executed in reverse order. In addition, the embodiment presented and described in the flow chart of the present invention is provided by way of example, for the purpose of providing a more comprehensive understanding of technology. The disclosed method is not limited to the operation and logic flow presented herein. Selectable embodiments are expected, wherein the order of various operations is changed and the sub-operation of a part for which is described as a larger operation is performed independently.

[0145] In addition, although the present invention is described in the context of functional modules, it should be understood that, unless otherwise specified to the contrary, one or more of the above-mentioned functions and / or features can be integrated into a single physical device and / or software module, or one or more functions and / or features can be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the present invention. More specifically, in view of the properties, functions and internal relationships of the various functional modules in the device disclosed herein, the actual implementation of the module will be understood within the conventional skills of the engineer. Therefore, those skilled in the art can implement the present invention set forth in the claims without excessive experimentation using ordinary techniques. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the present invention, which is determined by the full scope of the appended claims and their equivalents.

[0146] If the above functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a terminal device. Based on this understanding, the technical solution of the present invention can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a terminal device and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the above methods of each embodiment of the present invention. The edge node mentioned in the present invention may refer to an edge terminal, which is generally a hardware terminal device that can transmit data through a network, including but not limited to terminal devices such as cameras, optical modem boxes, switches, servers, etc.

[0147] In the above description of this specification, the description with reference to the terms "one embodiment / example", "another embodiment / example" or "certain embodiments / examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0148] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the claims and their equivalents.

[0149] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the above embodiments. Those skilled in the art may make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of this application.

Claims

1. A Helm application multi-cluster deployment method based on cluster federation, characterized in that: The following steps are involved: In response to the Helm application installation request, create a target CRD resource, wherein the target CRD resource includes a HelmRelease object and a HelmRepositry object; Determine a distribution configuration strategy according to the Helm application installation request, and perform cluster scheduling on the target CRD resource according to the distribution configuration strategy; When a change is detected in the CRD resource sent to the edge cluster, a Kubernetes resource of the Helm application is created according to the target CRD resource, and then the Kubernetes resource is scheduled to the node of the edge cluster.

2. According to a cluster federation-based Helm application multi-cluster deployment method according to claim 1, it is characterized in that: In response to the Helm application installation request, the target CRD resource is created, which specifically includes: Receive the Helm application installation request from the user through Karmada-apiserver, and initiate a CRD resource creation request to Karmada-controller-manager; The HelmRelease object and the HelmRepositry object are created by the Karmada-controller-manager according to a preset resource template, and the HelmRelease object and the HelmRepositry object are returned to the Karmada-apiserver.

3. According to a cluster federation-based Helm application multi-cluster deployment method according to claim 1, it is characterized in that: The determining of the distribution configuration strategy according to the Helm application installation request, and cluster scheduling of the target CRD resource according to the distribution configuration strategy, specifically includes: Parse the Helm application installation request through Karmada-apiserver to obtain the distribution configuration strategy, and send the target CRD resource and the distribution configuration strategy to Karmada-scheduler; Sending the target CRD resource to the edge cluster according to the distribution configuration strategy through the Karmada-scheduler; The distribution configuration policy is a PropagationPolicy policy or an OverridePolicy policy.

4. According to a cluster federation-based Helm application multi-cluster deployment method according to claim 3, it is characterized in that: The sending the target CRD resource to the edge cluster according to the distribution configuration strategy specifically includes: When the distribution configuration strategy is the PropagationPolicy strategy, multiple available edge clusters are determined according to the target CRD resources, and the available edge clusters are scored and sorted to obtain multiple target edge clusters, and then the target CRD resources are sent to the target edge clusters; When the distribution configuration policy is the OverridePolicy policy, the target edge cluster is determined according to the OverridePolicy policy, and the target CRD resource is sent to the target edge cluster.

5. According to a cluster federation-based Helm application multi-cluster deployment method according to claim 1, it is characterized in that: When a change is detected in the CRD resource sent to the edge cluster, a Kubernetes resource of the Helm application is created according to the target CRD resource, which specifically includes: When Helm-controller detects that the CRD resource sent to the edge cluster has changed, it obtains the target CRD resource and parses the target CRD resource to obtain application configuration information, and then initiates a Kubernetes resource creation request to Kube-apiserver according to the application configuration information; Calling Kube-controller-manager through the Kube-apiserver to create the corresponding Kubernetes resources according to the application configuration information; The application configuration information includes namespace, custom resources, Kubernetes role permissions, and released Helm applications.

6. According to a cluster federation-based Helm application multi-cluster deployment method according to claim 5, it is characterized in that: The step of scheduling the Kubernetes resources to the nodes of the edge cluster specifically includes: Sending the Kubernetes resources to Kube-scheduler through the Kube-apiserver; The Kube-scheduler determines multiple schedulable nodes of the edge cluster according to the Kubernetes resources, scores and sorts the schedulable nodes to obtain multiple target nodes, and then schedules the Kubernetes resources to the target nodes.

7. A Helm application multi-cluster deployment method based on cluster federation according to any one of claims 1 to 6, characterized in that: The cluster federation-based Helm application multi-cluster deployment method further includes the following steps: Return resource scheduling results to Kube-apiserver through Kube-scheduler; Return the Helm Release status message to Helm-controller through the Kube-apiserver; Return the Helm application deployment result to Karmada-scheduler through the Helm-controller; Return the Karmada scheduling result to the Karmada-apiserver service through the Karmada-scheduler; The Helm application installation event is returned to the user end through the Karmada-apiserver.

8. A Helm application multi-cluster deployment system based on cluster federation, characterized in that: include: A target CRD resource creation module, used to create a target CRD resource in response to a Helm application installation request, wherein the target CRD resource includes a HelmRelease object and a HelmRepositry object; A target CRD resource scheduling module, used to determine a distribution configuration strategy according to the Helm application installation request, and perform cluster scheduling on the target CRD resource according to the distribution configuration strategy; The Kubernetes resource scheduling module is used to create Kubernetes resources of the Helm application according to the target CRD resources when changes are detected in the CRD resources sent to the edge cluster, and then schedule the Kubernetes resources to the nodes of the edge cluster.

9. According to claim 8, a Helm application multi-cluster deployment system based on cluster federation is characterized in that: The Kubernetes resource scheduling module includes: The request unit is used to obtain the target CRD resource when the Helm-controller detects that the CRD resource sent to the edge cluster has changed, and parse the target CRD resource to obtain application configuration information, and then initiate a Kubernetes resource creation request to the Kube-apiserver according to the application configuration information; A resource creation unit, configured to create the corresponding Kubernetes resources according to the application configuration information by calling Kube-controller-manager through the Kube-apiserver; The application configuration information includes namespace, custom resources, Kubernetes role permissions, and released Helm applications.

10. A Helm application multi-cluster deployment system based on cluster federation according to claim 9, characterized in that: The Kubernetes resource scheduling module also includes: A resource sending unit, used to send the Kubernetes resources to Kube-scheduler through the Kube-apiserver; A resource scheduling unit is used to determine multiple schedulable nodes of the edge cluster according to the Kubernetes resources through the Kube-scheduler, score and sort the schedulable nodes to obtain multiple target nodes, and then schedule the Kubernetes resources to the target nodes.

Images