You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: cncf/GTR.md
+77-46Lines changed: 77 additions & 46 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,11 @@
1
-
# General Technical Review - [Project Name] / [Level]
1
+
# General Technical Review - Open Cluster Management / Sandbox
2
2
3
3
-**Project:** Open Cluster Management
4
4
-**Project Version:** v1.0.0
5
5
-**Website:**https://open-cluster-management.io/
6
6
-**Date Updated:** 2025-8-7
7
7
-**Template Version:** v1.0
8
-
-**Description:** A lightweight and extensible multiple kubernetes cluster management tool
8
+
-**Description:** A lightweight and extensible multi-cluster Kubernetes management tool
9
9
10
10
## Day 0 - Planning Phase
11
11
@@ -25,29 +25,29 @@
25
25
* Describe the target persona or user(s) for the project?
26
26
27
27
The target users of the project are those who have multiple Kubernetes clusters and want to manage them easily,
28
-
and also those who provide kubernetes cluster management platform
28
+
and also those who provide Kubernetes cluster management platforms
29
29
30
30
* Explain the primary use case for the project. What additional use cases are supported by the project?
31
31
32
-
1.Admin is able to manage and monitor multiple kubernetes cluster in a centralized control plane
32
+
1.Administrators are able to manage and monitor multiple Kubernetes clusters in a centralized control plane
33
33
2. Users are able to deploy their workload across multiple clusters.
34
34
3. Users are able to define a cluster selection criteria to deploy different workloads.
35
-
4. Users are able to easily extend the control plane by adding more management functionality across multiple cluster.
35
+
4. Users are able to easily extend the control plane by adding more management functionality across multiple clusters.
36
36
37
37
* Explain which use cases have been identified as unsupported by the project.
38
38
39
-
Provisioning/lifecycling the kubernetes cluster is not the scope of this project.
39
+
Provisioning/lifecycle management of Kubernetes clusters is not the scope of this project.
40
40
41
41
* Describe the intended types of organizations who would benefit from adopting this project. (i.e. financial services, any software manufacturer, organizations providing platform engineering services)?
42
42
43
-
- Entities, e.g. financial institutions, internet companies, with many kubernetes clusters.
43
+
- Entities, e.g. financial institutions, internet companies, with many Kubernetes clusters.
44
44
- Vendors that provide platform engineering services.
45
45
46
46
* Please describe any completed end user research and link to any reports.
47
47
48
48
- AppsCode held a webinar on "Managing Many Clusters using Open Cluster Management" on 15th June 2023.
integrates Open-Telemetry by deploying its operator through an addon, allowing centralized observability and telemetry data
@@ -83,9 +83,17 @@
83
83
- hub-spoke architecture: the hub component is lightweight to let users set instructions to the spoke via CRD mechanism,
84
84
and the spoke agent acts based on the hub’s instructions.
85
85
- Extensible: another design principle of the projects is to keep the core components as simple and lightweight as possible,
86
-
but with extension point to easily adding customized functionality.
86
+
but with extension points to easily add customized functionality.
87
87
88
-
* Outline or link to the project’s architecture requirements? Describe how they differ for Proof of Concept, Development, Test and Production environments, as applicable.
88
+
* Outline or link to the project's architecture requirements? Describe how they differ for Proof of Concept, Development, Test and Production environments, as applicable.
89
+
90
+
The OCM architecture consists of a hub-spoke model documented at https://open-cluster-management.io/docs/concepts/architecture/.
91
+
92
+
For different environments:
93
+
-**Proof of Concept**: Single hub cluster with 1-3 spoke clusters, minimal resource allocation (2 CPU, 4GB RAM per hub component)
94
+
-**Development**: Similar to PoC but with additional development addons and potentially multiple hub clusters for testing
95
+
-**Test**: Multi-hub setup with various addon configurations to test different scenarios and upgrade paths
96
+
-**Production**: High availability hub clusters with proper resource allocation, backup/restore procedures, and monitoring across potentially hundreds of managed clusters
89
97
90
98
* Define any specific service dependencies the project relies on in the cluster.
91
99
@@ -102,12 +110,12 @@
102
110
103
111
* Describe any compliance requirements addressed by the project.
104
112
105
-
OCM has a policy add-on component that can integrate with Open policy agent or kyverno to manage the compliance
106
-
policy across multiple clusters. Details is documented here https://open-cluster-management.io/docs/getting-started/integration/policy-controllers/
113
+
OCM has a policy add-on component that can integrate with Open Policy Agent or Kyverno to manage compliance
114
+
policies across multiple clusters. Details are documented here https://open-cluster-management.io/docs/getting-started/integration/policy-controllers/
107
115
108
116
* Describe the project’s High Availability requirements.
109
117
110
-
OCM controlplane is based on the kubernetes controlplane. The controller of OCM hub and agent on the spoke cluster
118
+
OCM control plane is based on the Kubernetes control plane. The controller of OCM hub and agent on the spoke cluster
111
119
can run in multiple replicas with leader election.
112
120
113
121
In addition, there is also a requirement that OCM hub clusters can be recovered upon disaster, which needs API
@@ -118,7 +126,7 @@
118
126
119
127
OCM has controllers on the hub cluster, and agents on spoke clusters. Each has its own CPU/memory requirements.
120
128
The CPU/memory of the hub and agent can be set in ClusterManager/Klusterlet API or using clusteradm.
121
-
OCM requires the spoke cluster is able to reach to the apiserver of the hub cluster directly or via http proxy.
129
+
OCM requires the spoke cluster to be able to reach the API server of the hub cluster directly or via HTTP proxy.
122
130
123
131
* Describe the project’s storage requirements, including its use of ephemeral and/or persistent storage.
* How do you recommend users alter security defaults in order to "loosen" the security of the project? Please link to any documentation the project has written concerning these use cases.
268
299
269
300
We do not recommend or document methods to "loosen" the security of the project, as our defaults are designed to be secure. However,
270
-
OCM is highly configurable; in some cases, a user needs to grant Klusterlet agent permissions to manage their resources. We recommend users
271
-
only grant permissions with the least privilege, referencing the doc permission setting for work agent, but for purposes like testing, users
301
+
OCM is highly configurable; in some cases, users need to grant Klusterlet agent permissions to manage their resources. We recommend users
302
+
only grant permissions with the least privilege, referencing the documentation permission setting for work agent. For purposes like testing, users
272
303
can grant sufficient privileges to the Klusterlet agent that could intentionally create a less secure configuration.
273
304
274
305
These actions require deliberate and explicit configuration by a cluster administrator. Our documentation focuses on how to configure
* Describe how the project has evaluated which features will be a security risk to users if they are not maintained by the project?
290
321
291
-
The ManifestWork API feature. It was designed to dispatch/manage Kubernetes resources on the managed cluster, since it can dispatch/manage any resources,
292
-
the work-agnet might need wide permission for the managed clusters. To mitigate the risk, we ensured that:
293
-
- The agent on the spoke cluster to apply the manifests has the admin permission, instead of the cluster-admin, so that it can apply most Kubernetes resources.
294
-
- For some specific resources, like some CustomResourceDefinition, users need to explicitly grant the permission to the work agent referencing the doc permission setting for work agent
322
+
The ManifestWork API featurewas designed to dispatch/manage Kubernetes resources on the managed cluster. Since it can dispatch/manage any resources,
323
+
the work-agent might need wide permissions for the managed clusters. To mitigate the risk, we ensured that:
324
+
- The agent on the spoke cluster to apply the manifests has admin permission, instead of cluster-admin, so that it can apply most Kubernetes resources.
325
+
- For some specific resources, like some CustomResourceDefinitions, users need to explicitly grant permission to the work agent referencing the documentation permission setting for work agent
295
326
- Users can delegate manifest application to a specific identity on the spoke cluster, further sandboxing the operation, see dynamic identity authorization.
All charts are uploaded to https://artifacthub.io/packages/search?org=open-cluster-management&sort=relevance&page=1, which provides the community with a trusted, versioned, and verifiable source to deploy the OCM components,
341
372
ensuring they are using official project artifacts.
* Describe how the project handles rollback procedures.
380
411
381
-
OCM handles the rollback the same as upgrades, but need to specify a lower version https://open-cluster-management.io/docs/getting-started/administration/upgrading/ .
412
+
OCM handles rollbacks the same as upgrades, but needs to specify a lower version:https://open-cluster-management.io/docs/getting-started/administration/upgrading/
382
413
383
414
* How can a rollout or rollback fail? Describe any impact to already running workloads.
384
415
385
-
If a rollout or rollback fails, the spoke cluster may lose connection with the hub, and can not be managed anymore. The already running
386
-
workloads will keep running, but will not be managed by the hub and status will not be reported back to the hub.
416
+
If a rollout or rollback fails, the spoke cluster may lose connection with the hub and cannot be managed anymore. The already running
417
+
workloads will keep running, but will not be managed by the hub and their status will not be reported back to the hub.
387
418
388
419
* Describe any specific metrics that should inform a rollback.
389
420
390
-
Clusteradm provides command to check the cluster info after upgrade and rollback.https://open-cluster-management.io/docs/getting-started/administration/upgrading/
391
-
The managedcluster status will also reflect whether a cluster is available or not after the upgrade.
421
+
Clusteradm provides commands to check the cluster info after upgrade and rollback:https://open-cluster-management.io/docs/getting-started/administration/upgrading/
422
+
The ManagedCluster status will also reflect whether a cluster is available or not after the upgrade.
392
423
393
424
* Explain how upgrades and rollbacks were tested and how the upgrade-\>downgrade-\>upgrade path was tested.
394
425
395
-
The user should run `clusteradm upgrade` on the test environment before upgrading in the product environment.
426
+
Users should run `clusteradm upgrade` on the test environment before upgrading in the production environment.
396
427
397
428
* Explain how the project informs users of deprecations and removals of features and APIs.
398
429
399
-
We will log issues in the community for the features/API deprecations and removals plan, add it to the roadmap, and inform users in the community meeting and Slack channel as well.
430
+
We will log issues in the community for features/API deprecations and removal plans, add them to the roadmap, and inform users in community meetings and Slack channels as well.
400
431
401
432
* Explain how the project permits utilization of alpha and beta capabilities as part of a rollout.
402
433
403
-
The project should follow the API upgrade flow https://github.com/open-cluster-management-io/api/blob/main/docs/development.md#api-upgrade-flow to rollout from alpha to beta.
404
-
Feature gates alpha to beta follow a standard lifecycle
434
+
The project follows the API upgrade flow https://github.com/open-cluster-management-io/api/blob/main/docs/development.md#api-upgrade-flow to rollout from alpha to beta.
435
+
Feature gates from alpha to beta follow a standard lifecycle:
0 commit comments