This provides a standard mechanism for referring to clusters, by identifier, and determining their membership in a clusterset. The KEP states that the clusterset.k8s.io and cluster.clusterset.k8s.io properties must be set in clusters belonging to a clusterset:
clusterset.k8s.io … The identifier must exist and be immutable for the duration of a cluster’s membership in a ClusterSet.
cluster.clusterset.k8s.io … The identifier must exist and not be changed for the duration of a cluster’s membership in a ClusterSet, and as long as a clusterset.k8s.io property referring to that cluster in that ClusterSet exists.
In scenarios where Submariner provides connectivity and service discovery in support of another cluster manager such as OCM, these properties may be handled by the cluster manager. One possible approach is to manage the properties in subctl rather than the operator — the properties can be checked and set in join, cleared in uninstall, and other cluster managers which don’t use subctl won’t be affected.
What would you like to be added:
Support for KEP 2149, ClusterId.
Why is this needed:
This provides a standard mechanism for referring to clusters, by identifier, and determining their membership in a clusterset. The KEP states that the
clusterset.k8s.io
andcluster.clusterset.k8s.io
properties must be set in clusters belonging to a clusterset:In scenarios where Submariner provides connectivity and service discovery in support of another cluster manager such as OCM, these properties may be handled by the cluster manager. One possible approach is to manage the properties in
subctl
rather than the operator — the properties can be checked and set injoin
, cleared inuninstall
, and other cluster managers which don’t usesubctl
won’t be affected.To avoid having to create our own clientset, this should wait for https://github.com/kubernetes-sigs/about-api/pull/22.
Depends on https://github.com/kubernetes-sigs/about-api/pull/22