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:

CouchDB definition

apiVersion: eu-west-1.team-a/v1alpha1
kind: CouchDB
metadata:
  name: db1
spec:
  username: hans
  password: hans2000

Management Cluster

$ kubectl apply -n team-b --as=team-b-member \
  -f https://raw.githubusercontent.com/kubermatic/kubecarrier/v0.3.0/docs/manifests/couchdb.eu-west-1.yaml
couchdb.eu-west-1.team-a/db1 created

# 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 CouchDB service.

CRDs

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.