From d65dfd118f52e5552e0b95ee4163ee33a596add7 Mon Sep 17 00:00:00 2001 From: yeyeye2333 <3229833855@qq.com> Date: Wed, 24 Jul 2024 10:49:06 +0800 Subject: [PATCH 1/2] proposal:Single cluster deployment application Signed-off-by: yeyeye2333 <3229833855@qq.com> --- .../single_cluster_deployment_application.md | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 docs/proposals/application/single_cluster_deployment_application.md diff --git a/docs/proposals/application/single_cluster_deployment_application.md b/docs/proposals/application/single_cluster_deployment_application.md new file mode 100644 index 00000000..0cae04b0 --- /dev/null +++ b/docs/proposals/application/single_cluster_deployment_application.md @@ -0,0 +1,68 @@ +--- +title: Single cluster deployment application +authors: +- @yeyeye2333 +reviewers: +approvers: + +creation-date: 2024-07-24 + +--- + +## Single Cluster Deployment Application + +### Summary + +This proposal aims to modify the application API to allow setting the application's destination to a cluster, reducing the operational steps required for Kurator in a single-cluster environment and increasing Kurator's flexibility. + +### Motivation + +Kurator leverages Fleet for multi-cluster management. However, this has resulted in the current application deployment being tightly coupled with Fleet, even requiring Fleet creation for single-cluster usage. Therefore, we aim to decouple the single-cluster client from Fleet. + +#### Goals + +- Modify the application API to support setting the application's destination to a cluster. +- Simplify the deployment process for single-cluster environments by eliminating the need for Fleet. + +### Proposal + +Currently, the application registration is handled in the fleet-manager. The proposal is to move the application registration to the cluster-operator to support setting the application's destination to a cluster. + +### Design Details + +We will delve into the API design required to support setting the application's destination to a cluster. The following are the specific changes to the application: + +```go +// ApplicationDestination defines the configuration to dispatch an artifact to a fleet or specific clusters. +// Fleet and cluster are mutually exclusive. +type ApplicationDestination struct { + // Fleet defines the fleet to dispatch the artifact. + // +optional + Fleet *FleetInfo `json:"fleetInfo,omitempty"` + + // Cluster specifies a cluster to dispatch the artifact to. + // +optional + Cluster *corev1.ObjectReference `json:"clusters,omitempty"` +} + +type FleetInfo struct { + // Name identifies the name of the fleet. + // +required + Name string `json:"name"` + // ClusterSelector specifies the selectors to select the clusters within the fleet. + // If unspecified, all clusters in the fleet will be selected. + // +optional + ClusterSelector *ClusterSelector `json:"clusterSelector,omitempty"` +} +``` + +The preliminary discussion results are as follows: + +- The destination can only be either a fleet or a cluster. The `ApplicationWebhook.validate()` will check if only one of fleet or cluster is specified. +- When updating the destination configuration, no actions will be taken on applications deployed in the old clusters (no deletion). + +In the specific code, replace all `fleet *fleetapi.Fleet` type parameters in the `Reconcile` method with `destinationObject interface{}`. In functions like `fetchClusterList` (previously `fetchFleetClusterList`) that need to parse `destinationObject`, use a `switch destinationObject.(type)` statement for different logical processing to improve code reusability. + +#### Test Plan + +During the coding phase, add unit tests covering core functionalities and edge cases. After completing the coding work, design integration tests to ensure the proper deployment of applications in a single cluster, and subsequently, provide examples of deploying applications in a single cluster. From b095fb686ebda4ceeee9be8450c4328af5d9b561 Mon Sep 17 00:00:00 2001 From: yeyeye2333 <3229833855@qq.com> Date: Fri, 26 Jul 2024 17:59:13 +0800 Subject: [PATCH 2/2] update ./docs/proposals/application/single_cluster_deployment_application.md Signed-off-by: yeyeye2333 <3229833855@qq.com> --- .../single_cluster_deployment_application.md | 46 +++++-------------- 1 file changed, 12 insertions(+), 34 deletions(-) diff --git a/docs/proposals/application/single_cluster_deployment_application.md b/docs/proposals/application/single_cluster_deployment_application.md index 0cae04b0..57cad7c0 100644 --- a/docs/proposals/application/single_cluster_deployment_application.md +++ b/docs/proposals/application/single_cluster_deployment_application.md @@ -13,7 +13,7 @@ creation-date: 2024-07-24 ### Summary -This proposal aims to modify the application API to allow setting the application's destination to a cluster, reducing the operational steps required for Kurator in a single-cluster environment and increasing Kurator's flexibility. +This proposal aims to allow setting the application's destination to a cluster, reducing the operational steps and enabling users to seamlessly use Kurator in a single-cluster, thereby increasing Kurator's flexibility. ### Motivation @@ -21,47 +21,25 @@ Kurator leverages Fleet for multi-cluster management. However, this has resulted #### Goals -- Modify the application API to support setting the application's destination to a cluster. -- Simplify the deployment process for single-cluster environments by eliminating the need for Fleet. +- Add a new feature to support setting the application's destination to a cluster. +- Enable users to seamlessly use Kurator in a single-cluster environment, thus eliminating the need for Fleet. ### Proposal -Currently, the application registration is handled in the fleet-manager. The proposal is to move the application registration to the cluster-operator to support setting the application's destination to a cluster. - -### Design Details - -We will delve into the API design required to support setting the application's destination to a cluster. The following are the specific changes to the application: - -```go -// ApplicationDestination defines the configuration to dispatch an artifact to a fleet or specific clusters. -// Fleet and cluster are mutually exclusive. -type ApplicationDestination struct { - // Fleet defines the fleet to dispatch the artifact. - // +optional - Fleet *FleetInfo `json:"fleetInfo,omitempty"` - - // Cluster specifies a cluster to dispatch the artifact to. - // +optional - Cluster *corev1.ObjectReference `json:"clusters,omitempty"` -} - -type FleetInfo struct { - // Name identifies the name of the fleet. - // +required - Name string `json:"name"` - // ClusterSelector specifies the selectors to select the clusters within the fleet. - // If unspecified, all clusters in the fleet will be selected. - // +optional - ClusterSelector *ClusterSelector `json:"clusterSelector,omitempty"` -} -``` +Currently, the application registration is handled in the fleet-manager. The proposal is to add a new feature to deploy the application directly to the current host cluster when ApplicationDestination is not specified. The preliminary discussion results are as follows: -- The destination can only be either a fleet or a cluster. The `ApplicationWebhook.validate()` will check if only one of fleet or cluster is specified. +- If `ApplicationDestination` is not specified, the `application` is deployed directly under the current host cluster, otherwise it is deployed in `ApplicationDestination.fleet` - When updating the destination configuration, no actions will be taken on applications deployed in the old clusters (no deletion). -In the specific code, replace all `fleet *fleetapi.Fleet` type parameters in the `Reconcile` method with `destinationObject interface{}`. In functions like `fetchClusterList` (previously `fetchFleetClusterList`) that need to parse `destinationObject`, use a `switch destinationObject.(type)` statement for different logical processing to improve code reusability. + + +### Design Details + +This proposal does not involve API modification, and supports new functions in code logic. +In the specific code, if `ApplicationDestination` is empty, `handleSyncPolicyByKind` directly on the current cluster client to create Kustomization or HelmRelease resources. + #### Test Plan