How to tell different child clusters in parent cluster? about clusternet

[dixudx]

If there're multiple child clusters, how can I tell which clsrr/mcls belongs to which child cluster?

$ kubectl get clsrr
NAME                                              CLUSTER ID                             STATUS     AGE
clusternet-dc91021d-2361-4f6d-a404-7c33b9e01118   dc91021d-2361-4f6d-a404-7c33b9e01118   Approved   3d6h
$ kubectl get mcls -A -o wide
NAMESPACE          NAME                       CLUSTER ID                             CLUSTER TYPE                 SYNC MODE   KUBERNETES   READYZ   AGE
clusternet-dhxfs   clusternet-cluster-dzqkw   dc91021d-2361-4f6d-a404-7c33b9e01118   EdgeClusterSelfProvisioned   Dual        v1.19.10     true     7d23h

The auto-generated unique clusterID is a inline field for ClusterRegistrationRequest.Spec and ManagedCluster.Spec. Moreover, label clusters.clusternet.io/cluster-id=<a-cluster-uid> is appended for every ClusterRegistrationRequest and ManagedCluster object. With this label, you can also use label selector to filter target objects.

Is there anyway I can specify this clusterID in clusternet-agent manifest?

Currently, no and won't. The reason why we don't provider clusterID customization is that this clusterID is critically important for Clusternet, where we must make sure it is unique.

But you can specify clusterName in clusternet-agent command line.

[fengye87]

So the short answer is, I should specify cluster-reg-name in the clusternet-agent manifest and match that name with clsrr.Spec.ClusterName to find out the corresponding clusterID?

[dixudx]

@fengye87 A short answer is,

$ kubectl get clsrr -l clusters.clusternet.io/cluster-name=YOUR-CLUSTER-NAME
$ kubectl get mcls -A -l clusters.clusternet.io/cluster-name=YOUR-CLUSTER-NAME

If you get your clusterID, you can also query like this,

$ kubectl get clsrr -l clusters.clusternet.io/cluster-id=YOUR-CLUSTER-ID
$ kubectl get mcls -A -l clusters.clusternet.io/cluster-id=YOUR-CLUSTER-ID

[fengye87]

@dixudx Got it, thanks! I'm closing this issue.