External And Internal CustomResourceDefinitions
In Catalogs, we created two CRDs. A public one, that users can interact with and an internal one.
This split allows the Provider to override user properties or hide settings and status information from their users.
Now we will create a
CouchDB instance and see how we work with those objects in KubeCarrier:
$ kubectl apply -n team-b --as=team-b-member \
# This is the object we just created as team-b
$ kubectl get couchdb -n team-b --as=team-b-member
NAME USERNAME PASSWORD AGE
db1 hans hans2000 4s
# There is also an internal representation, that users cannot access:
$ kubectl get couchdb.internal.eu-west-1.team-a -n team-b --as=team-b-member
Error from server (Forbidden): couchdbs.internal.eu-west-1.team-a is forbidden: User "team-b-member" cannot list resource "couchdbs" in API group "internal.eu-west-1.team-a" in the namespace "team-b"
# Only members of the Provider team (team-a) can access these objects:
$ kubectl get couchdb.internal.eu-west-1.team-a -n team-b --as=team-a-member
NAME USERNAME PASSWORD VERSION AGE
db1 hans hans2000 31s
Ok, what is happening here?
Team A is offering the
CouchDB service from their Kubernetes cluster
eu-west-1 and Team B created an instance of the
Because Team A decided to hide the
.spec.version property it’s absent from the CRD that tenants of Team A have access to. While the internal CRD retains that field, so the provider can use it to orchestrate their workload.