Configuration Bindings
This page describes how catalog service plans are bound to templates in the service broker configuration.
In the previous section we looked, in detail, at how the service catalog is exposed to an end user. What was clear was that service plans abstract a lot of the details about a service and how it is implemented. A user need only concern themselves with a service offering and plan that suits their particular workload.
This section describes how a selected service plan starts to be translated into actual Kubernetes resources that implement that plan.
Configuration Bindings
Consider the following diagram:
Unsurprisingly, given a service plan name is unique within its parent service offering, you use a combination of service name and plan name to uniquely identify a service plan in the Service Broker. Configuration bindings use this unique identifier to map from a service plan to a configuration binding. This is a one-to-one mapping and every plan must have a binding.
Templates
Configuration bindings can be thought of as lists of Kubernetes resources.
In our example this would be a ServiceAccount, Role and all the other resources required to create our service instance in Kubernetes.
In reality, the resources the binding refers to are all templates—a base Kubernetes resource that can be modified dynamically based on request parameters. Templates are covered in more detail in the next section.
Registry Definitions
Configuration bindings may also contain lists of registry definitions. These are simple functions—based on Go language templates—that accept inputs from a number of sources, optionally apply transformations to them, then store the output to a named registry key.
These are covered in more detail in a later section, however we will mention that registry entries defined in the configuration binding may be used to generate values that can used as inputs to template rending later. Such values can be shared resource names, passwords and even TLS configuration.
Readiness Checks
The Service Broker, in simple terms, creates Kubernetes resources. This operation is almost instantaneous, however, Kubernetes is an eventually-consistent system. It may take time for volumes to be allocated, bound and then attached to a pod, for example—there is a gap between where the Service Broker reports a service instance as ready and where it is actually usable.
To solve this problem, the Service Broker allows you to specify readiness checks.
These allow you to poll resources created as part of a service instance for actual readiness.
For example a Kubernetes Deployment will report as available only when all of its pods are ready.
Readiness checks allow the Service Broker API to declare a service instance creation as successful only when its underlying resources are available to be consumed by a client.
Processing Rules
Service instances and service bindings have their own separate lists of templates and parameters for each service plan.
When configuration bindings are processed, the Service Broker guarantees some ordering constraints:
-
Configuration binding registry definitions are processed, in-order, first.
-
Configuration binding templates are processed, in-order, last.
Given processing is ordered, outputs from an earlier parameter can be used as inputs into a later one.
Both templates and registry definitions are optional. Take, for example, a service plan that has calculated its credentials while creating a service instance. When creating a service binding, in order to communicate these credentials back to an end user, the use of templates is not required. Credentials can be communicated back with only registry definitions.
Readiness checks are performed during asynchronous operation polling. This allows the client to control the duration it should poll for, rather than have the asynchronous provisioning operation poll for an arbitrary amount of time.