Problem Statement:
Currently kube-bind assumes that there will be only one provider cluster for a given CRD. But it is common to have multiple provider cluster for a CRD. This proposal discusses some changes in CRDs to enable this use-case.
Proposed Solution:
There are 3 parts to the proposed solution.
-
In the BindingResponse, the provider will returns a cluster UID which is stable and unique across all the clusters from that provider. My proposal is to use kubectl get ns kube-system -o=jsonpath='{.metadata.uid}' as the cluster UID.
-
In the APIServiceBinding CRD spec is modified to list an array of all clusters that offer this CRD. This will given konnector enough information to sync CROs.
-
When consumer creates a CRO, then apply a provider.kube-bind.io/cluster-id: {uid} as annotation if a CRD is provided by multiple cluster. If only one cluster offers that CRD, it can be used without the annotation.
What this does not solve:
If multiple provider clusters have the same CRD with different schema, this does not solve that. I don't think there is any easy solution for that. I think it is reasonable to assume that consumer/provider will communicate out of band to resolve this issue.
Problem Statement:
Currently kube-bind assumes that there will be only one provider cluster for a given CRD. But it is common to have multiple provider cluster for a CRD. This proposal discusses some changes in CRDs to enable this use-case.
Proposed Solution:
There are 3 parts to the proposed solution.
In the
BindingResponse, the provider will returns a cluster UID which is stable and unique across all the clusters from that provider. My proposal is to usekubectl get ns kube-system -o=jsonpath='{.metadata.uid}'as the cluster UID.In the APIServiceBinding CRD spec is modified to list an array of all clusters that offer this CRD. This will given konnector enough information to sync CROs.
When consumer creates a CRO, then apply a
provider.kube-bind.io/cluster-id: {uid}as annotation if a CRD is provided by multiple cluster. If only one cluster offers that CRD, it can be used without the annotation.What this does not solve:
If multiple provider clusters have the same CRD with different schema, this does not solve that. I don't think there is any easy solution for that. I think it is reasonable to assume that consumer/provider will communicate out of band to resolve this issue.