You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Resources rely on the registry for garbage collection, and that cannot
span namespaces. This adds in support in your bindings to define where
the registry should go, defaulting to the service broker namespace, but
allowing a hard coded value (e.g. cluster wide singletons), or per
service instance. Sadly, this does expose all the registry secrets now,
but it has to happen this way unless we want to track literally
everything.
Fixes#73
Copy file name to clipboardExpand all lines: documentation/modules/ROOT/pages/concepts/registry.adoc
+25Lines changed: 25 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -126,6 +126,31 @@ Therefore, where singleton templates have been used to generate Kubernetes resou
126
126
.Registry Ownership of Resources and Resource Sharing with Singletons
127
127
image::reg-gc.png[align="center"]
128
128
129
+
[IMPORTANT]
130
+
====
131
+
Kubernetes garbage collection only works when the registry and its dependent resources reside in the same namespace.
132
+
Failure to observe this constraint will result in your service instances and bindings being deleted erroneously.
133
+
134
+
See the https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/[offical documentation^] for additional garbage collection rules.
135
+
====
136
+
137
+
=== Registry Scoping
138
+
139
+
The namespace in which a registry is generated is fully under your control, see the documentation for the configuration bindings for more details (`kubectl explain servicebrokerconfig.spec.bindings.registryScope`)
140
+
The default option -- `BrokerLocal` -- maintains backward compatibility, and registries will be generated in the same namespace as the service broker.
141
+
This, therefore, leads to the requirement that all service instance resources must be provisioned in that namespace.
142
+
143
+
Other options include an explicit namespace -- `Explicit` -- where the registry and resources are hard coded to a specific namespace, and service instance local -- `InstanceLocal` -- where the registry will be provisioned in the same namespace as the service instance, as dictated by the namespace provided in the service instance creation context.
144
+
145
+
== Registry Directory
146
+
147
+
Garbage collection only works when the registry is located in the same namespace as the resources that it is associated with.
148
+
The Service Broker only knows the exact namespace a service will be provisioned in on service instance creation, as provided by the request context.
149
+
In order to keep track of what namespace contains the service instance and binding registries, the Service Broker maintains a directory.
150
+
151
+
The directory is a simple map from service instance ID to a JSON document that records the service instance namespace.
152
+
Thus, when a request to get or poll a service instance is made, where the namespace is unknown, the Service Broker can interrogate its directory and determine the correct namespace to use to look for the relevant registries.
153
+
129
154
== Next Steps
130
155
131
156
We have now covered all basic configuration topics.
Due to the flexibility of the Service Broker, you may choose to combine dynamically and statically namespaced configuration templates as you choose.
131
+
Mixing the two forms of namespace selection is not supported.
132
+
Read xref:concepts/registry.adoc#registry-based-garbage-collection[the registry based garbage collection] documentation for further details on why, and how to correctly configure your service instances and bindings.
0 commit comments