Concepts - Project website doc edits
juliana-hsu opened this issue · 2 comments
Changes indicated in italics or parenthesis <>.
ManagedCluster
ManagedCluster Registration
The admin user on the hub needs to approve the authn/authz of an agent_ separately by:
- approving the certificatesigningrequest initiated by the agent so agent is authenticated to the hub.
After the admin user on the hub approves the registration of the cluster, a namespace with the same name as the cluster will be created.
By default, the agent on a cluster is only authorized to access certain resource kinds in this namespace on the hub to ensure security isolation. In addition, the agent will set a status condition in ManagedCluster as Joined and starts to update the liveness of the managed_ cluster.
In open-cluster-management, registration project implements the registration process.
It includes an agent in the managed cluster to register to the hub, a controller on the hub cluster to handle authz/authn setup for the agent.
ManagedClusterSet
ManagedClusterSet is a cluster scoped API on the hub cluster to define a group of ManagedCluster.
For instance, you can create dev, staging, prod ManagedClusterSet for different purposes.
Or you can create notrh-america, europe, apac ManagedClusterSet based on the region of the ManagedCluster.
ManagedCluster is to implement the notion in KEP-1645, but we also expand its definition scope for workload placement.
To add a ManagedCluster to a ManagedClusterSet, user needs to set a label open-cluster-management.io/clusterset={clusterset name} on the ManagedCluster.
ClusterClaim
It provides an extension point for other actors in the managed cluster to report certain properties of a managed cluster to the hub. The registration-agent collects all the ClusterClaim in the managed cluster and syncs them in the clusterClaims field in the related ManagedCluster.
ManifestWork
What is ManifestWork
ManifestWork is to define a group of Kubernetes resources on the hub to be applied to the managed cluster. In the open-cluster-management project, a ManifestWork resource must be created in the cluster namespace. A work agent implemented in work project is run on the managed cluster and monitors the ManifestWork resource in the cluster namespace on the hub cluster.
Status tracking
Work agent will track all the resources defined in ManifestWork and update its status.
resourceStatus tracks the status of each manifest in the ManifestWork <remove .> and conditions reflects the overall status of the ManifestWork. Work agent currently checks whether a resource is Available, meaning the resource exists on the managed cluster, and Applied means the resource defined in ManifestWork has been applied to the managed cluster.
Here is an example.
Garbage collection
To ensure the resources applied by ManifestWork are reliably recorded, the work agent creates an AppliedManifestWork on the managed cluster for each ManifestWork as an anchor for resources relating to ManifestWork.
Placement
Bind ManagedClusterSet to a namespace
You can create a ManagedClusterSetBinding as follows to bind the ManagedClusterSet to the default namespace.
Select clusters in ManagedClusterSet
A slice of PlacementDecision will be created by placement controller in the same namespace, each with a label of open-cluster-management.io/placement=placement1. -> not sure what "A slice" means?
PlacementDecision can be consumed by another operand to decide how the workload should be placed in multiple clusters.
Future Work
various workload spread policies.
Add-ons
What is an add-on?
Open-cluster-management has a mechanism to help developers to develop an extension based on the foundation components for the purpose of working with multiple clusters . Examples of add-ons include:
2. A network solution that uses the hub to share network info and establish connection among managed clusters.
In general, if a management tool needs a different configuration for each managed cluster or a secured communication between the managed cluster and hub cluster, it can utilize the add-on mechanism in open-cluster-management to ease the installation and day 2 operation.
Add-on enablement
Each add-on should register itself on the hub by creating a ClusterManagementAddon resource on the hub cluster. For instance, the helloworld add-on can be registered to the hub cluster by creating:
An add-on should also have a controller running on the hub taking responsibility of add-on configuration for each managed cluster. When a user wants to enable the add-on for a certain managed cluster, the user should create a ManagedClusterAddon resource on the cluster namespace. The name of the ManagedClusterAddon should be the same name as the corresponding ClusterManagementAddon. For instance, the following example enables the helloworld add-on in cluster1.
Add-on framework
Addon-framework provides a library for developers to develop an add-on in open-cluster-management more easily.
@juliana-hsu The PR has been merged.
Thanks Maggie!