Skip to content

Commit

Permalink
Proposal#1597 (#4)
Browse files Browse the repository at this point in the history
Proposal#1597
  • Loading branch information
WoShiZhangmingyu authored Sep 18, 2024
1 parent c768465 commit 6d34e55
Showing 1 changed file with 36 additions and 24 deletions.
Original file line number Diff line number Diff line change
@@ -1,8 +1,9 @@
| title | authors | reviewers | creation-date | last-updated | status |
|:-------------------------:|----------------------------------------|-------------|---------------|--------------|--------|
| Build-iot-system-configuration-isolation-on-nodepool | @WoShiZhangmingyu | @LavenderQAQ | 2024-08-19 | 2024-08-26 | |
| title | authors | reviewers | creation-date | last-updated | status |
| :--------------------------------------------------: | ----------------- | ------------ | ------------- | ------------ | ------ |
| Build-iot-system-configuration-isolation-on-nodepool | @WoShiZhangmingyu | @LavenderQAQ | 2024-08-19 | 2024-09-16 | |

# Build-iot-system-configuration-isolation-on-nodepool

## Table of Contents

- [Build-iot-system-configuration-isolation-on-nodepool](#build-iot-system-configuration-isolation-on-nodepool)
Expand All @@ -16,7 +17,6 @@
- [Test Plan](#test-plan)
- [Implementation History](#implementation-history)


## Summary

Openyurt gave users the ability to customize iot systems, but it's currently not isolated enough for nodepool.
Expand All @@ -28,15 +28,13 @@ Suppose now you need to expand several nodepools with the same configuration, th
One potential enhancement involves modifying the mapping between Platformadmin and nodepools to a one-to-many relationship, that is, changing the poolName in PlatformadminSpec to pools to correspond to multiple nodepools.
In this proposal, users can deploy multiple node pools with the same configuration by creating a single PlatformAdmin.


### Goals

- Provide multiple PlatformAdmin deployments within the same namespace

- Allow users the ability to customize the configuration of a nodepool

- Add unit test for platform_ admin_controller and modify corresponding e2e test

- Add unit test for platform\_ admin_controller and modify corresponding e2e test

## Proposal

Expand All @@ -46,23 +44,23 @@ In this proposal, users can deploy multiple node pools with the same configurati

### Implementation Details

PlatformAdmin has evolved from the previous version of the EdgeX CRD and serves as an abstraction for the edge device management platform. Users simply input the platform settings, the name of the NodePool to be deployed, the version to be deployed, and so on, to deploy a complete edge device management platform within the node pool.
PlatformAdmin has evolved from the previous version of the EdgeX CRD and serves as an abstraction for the edge device management platform. Users simply input the platform settings, the name of the NodePool to be deployed, the version to be deployed, and so on, to deploy a complete edge device management platform within the node pool.

The platformadmin-controller, integrated within yurt-manager, is responsible for parsing the PlatformAdmin CR into the corresponding configmap, service, and yurtappset, thereby realizing the deployment of the edge device management platform.
The platformadmin-controller, integrated within yurt-manager, is responsible for parsing the PlatformAdmin CR into the corresponding configmap, service, and yurtappset, thereby realizing the deployment of the edge device management platform.

Users have the capability to customize a PlatformAdminFramework that is initialized with a standard configuration, followed by the creation of a PlatformAdmin. After this step, the platformadmin-controller will automatically initiate the reconciliation process to handle services and YurtAppSets.

However, a notable drawback of this process is that, even when multiple nodepools share identical configurations, it necessitates the creation of multiple PlatformAdmins. This redundancy can lead to unnecessary administrative overhead and complexity.
However, a notable drawback of this process is that, even when multiple nodepools share identical configurations, it necessitates the creation of multiple PlatformAdmins. This redundancy can lead to unnecessary administrative overhead and complexity.

![platformadmin-old-frame](../img/20240819-build-iot-system-configuration-isolation-on-nodepool/platformadmin-old-frame.png)

- Old Platformadmin Setup(A Platformadmin is responsible for reconciling a nodepool)

![platformadmin-old](../img/20240819-build-iot-system-configuration-isolation-on-nodepool/platformadmin-old.png)

In scenarios where expansion of a nodepool with identical configuration is required, the current approach involves creating a new Platformadmin with the same configuration. This method, however, lacks operational efficiency and reusability.

A potential enhancement would be to modify the relationship between Platformadmin and nodepools from one-to-one to one-to-many. Specifically, altering the "poolName" in PlatformadminSpec to "nodePools" would allow a single Platformadmin to correspond to multiple nodepools and modify the corresponding processing logic.
A potential enhancement would be to modify the relationship between Platformadmin and nodepools from one-to-one to one-to-many. Specifically, altering the "poolName" in PlatformadminSpec to "nodePools" would allow a single Platformadmin to correspond to multiple nodepools and modify the corresponding processing logic.

Therefore, we need to modify the design of PlatformAdmin to allow a single PlatformAdmin to manage multiple nodepools with identical configurations. In the future, when faced with similar situations, we can adopt a configuration scheme as depicted in the following diagram.

Expand All @@ -75,29 +73,36 @@ Therefore, we need to modify the design of PlatformAdmin to allow a single Platf
OpenYurt extends the concept of nodepools on top of k8s, so an ideal deployment is that users can configure each nodepool iot system independently. With [#1435](https://github.com/openyurtio/openyurt/issues/1435) we can manipulate yurtappset to configure each nodepool individually. And service topology allows us to separate the traffic from each nodepool. With these two capabilities we can take a step closer to idealizing the current deployment model.

#### Modify CRD

Platformadmin needs to provide deployment for multiple nodepools, so the original **poolName** has been changed to the **nodePools** , as follows:
~~~

```
nodepools:
items:
type: string
type: array
~~~
```

A simple example:
~~~
apiVersion: iot.openyurt.io/v1alpha2

```
apiVersion: iot.openyurt.io/v1beta1
kind: PlatformAdmin
metadata:
metadata:
name: edgex-sample
spec:
version: minnesota
nodePools:
version: minnesota
nodePools:
- hangzhou
- beijing
EOF
~~~
```

#### Modify PlatformAdminSpec

Also change PoolName to NodePools:
~~~

```
type PlatformAdminSpec struct {
Version string `json:"version,omitempty"`
Expand All @@ -112,12 +117,16 @@ type PlatformAdminSpec struct {
// +optional
AdditionalDeployment []DeploymentTemplateSpec `json:"additionalDeployments,omitempty"`
}
~~~
```

#### Modify Platformadmin

In the update regarding IoT API, we have decided to remove support for version v1alpha1, while retaining support for version v1alpha2. Furthermore, we have added version v1beta1. In version v1beta1, we made modifications to the spec field of the platformadmin resource, renaming the poolName field to nodePools and changing its data type from a single string to [] string. This change aims to support more complex deployment scenarios, allowing users to configure and manage multiple node pools simultaneously, thereby significantly improving deployment scalability.

Enhance the Reconcile logic of the platformadminController to accommodate multiple nodepools, thereby enabling more refined resource management and scheduling.
for example:
~~~

```
for _, nodePool := range platformAdmin.Spec.NodePools {
exists := false
for _, pool := range yas.Spec.Pools {
Expand All @@ -138,10 +147,12 @@ yas.Spec.Workload.WorkloadTweaks = []appsv1beta1.WorkloadTweak{
},
},
}
~~~
```

### Test Plan

#### Unit Test

Create platformadmin_comtroler_test.go as a unit test file to verify if the corresponding service and yurtappset have been generated correctly.

#### E2E Test
Expand All @@ -152,3 +163,4 @@ Perform E2E testing only after ensuring that the unit test passes. Add test case

- [ ] 8/19/2024: Draft proposal created
- [ ] 8/26/2024: Update proposal
- [ ] 9/16/2024: Updated the version and version description of IoT API

0 comments on commit 6d34e55

Please sign in to comment.