Topology OCM
The Open Cluster Management (OCM) topology policy enables multi-cluster-aware Workload deployment by creating OCM resources. This policy will automatically create a Placement and a ManifestWorkReplicaSet that targets the Placement and contains the Workload. The topology-ocm policy also supports automatic namespace creation and other workload lifecycle settings.
Example Usage
The following examples display the different ways to use the topology-ocm policy.
Number of Clusters
In the example the number of clusters to target is specified as 3. If the property numberOfClusters is not specified, the policy will target all clusters in the clustersetbinding specified in the hubNamespace property.
apiVersion: spectrocloud.com/v1beta1
kind: Environment
metadata:
name: demo
namespace: demo-workload
spec:
topology:
type: topology-ocm
properties:
manifestWorkReplicaSet:
manifestWorkTemplate:
lifecycle:
spokeNamespace:
create: true
orphan: false
workload:
orphan: false
rolloutStrategy:
all: {}
type: All
hubNamespace: managed-cluster-set-global
placement:
numberOfClusters: 3
The environment is considered to be "Ready" if the environment Placement can reports back with the same number of clusters as the number specified in the numberOfClusters property.
Otherwise, the environment will be "Not Ready" until environment Placement can report back with the same number of clusters as the number specified in the numberOfClusters property.
ClusterSets
An example of a cluster selection strategy that targets all clusters in the cluster set spokes. The hubNamespace references the namespace on the hub that contains the clusterset binding.
apiVersion: spectrocloud.com/v1beta1
kind: Environment
metadata:
name: demo
namespace: demo-workload
spec:
topology:
type: topology-ocm
properties:
manifestWorkReplicaSet:
manifestWorkTemplate:
lifecycle:
spokeNamespace:
create: true
orphan: false
workload:
orphan: false
rolloutStrategy:
all: {}
type: All
hubNamespace: managed-cluster-set-spokes
placement:
clusterSets:
- spokes
Label Filtering
An example of a Cluster Selection Strategy based on label filtering that targets managed clusters that have both the environment: dev and region: south-america-dev labels. The numberOfClusters property is set to 1 to ensure that only one cluster is targeted.
Take note of the hubNamespace property that references the namespace on the hub that contains the clusterset binding. The example uses the managed-cluster-set-global which makes all spokes eligible for the placement if they meet the label filtering criteria.
apiVersion: spectrocloud.com/v1beta1
kind: Environment
metadata:
name: demo
namespace: demo-workload
spec:
topology:
type: topology-ocm
properties:
hubNamespace: managed-cluster-set-global
manifestWorkReplicaSet:
rolloutStrategy:
all: {}
type: All
placement:
predicates:
- requiredClusterSelector:
labelSelector:
matchLabels:
environment: dev
region: south-america-dev
numberOfClusters: 1
Placement Tolerations
OCM uses cluster-level taints and tolerations to manage workload distribution. When a spoke cluster becomes unavailable, OCM applies system taints such as cluster.open-cluster-management.io/unreachable and cluster.open-cluster-management.io/unavailable to the ManagedCluster resource.
The topology-ocm policy automatically configures Placement resources to tolerate these two system taints for up to 600 seconds. This prevents immediate deselection during transient unavailability; unrelated taints, including maintenance taints, remain respected.
You can provide additional custom tolerations through the parameter.placement.tolerations property. Any user-supplied tolerations are appended to these default tolerations.
Parameters
Template
The following tabs display the definition's Cue template and the rendered YAML. The rendered YAML is the output of the Cue template when the definition is applied to a cluster.