Specification for binding services to runtime applications running in Kubernetes.
- service - any software that is exposing functionality. Could be a RESTful application, a database, an event stream, etc.
- application - in this specification we refer to a single runtime-based microservice (e.g. MicroProfile app, or Node Express app) as an application. This is different than an umbrella (SIG) Application which refers to a set of microservices.
- binding - providing the necessary information for an application to connect to a service.
- secret - refers to a Kubernetes Secret.
- config map - refers to a Kubernetes ConfigMap.
- Need a consistent way to bind k8s application to services (applications, databases, event streams, etc)
- A standard / spec / RFC will enable adoption from different service providers
- Cloud Foundry has done this well. The equivalent is not available for k8s.
Main section of the doc. Has sub-section that outline the design.
- What metadata is needed for a service to be bindable (e.g. name of fields it supports, name of secret it produces, etc)
- Where is this information located
- What is the schema of a Service Binding object / structure.
- What metadata goes along that describes it
- How do we request a binding from a service (assume the service has been provisioned)
- Where in the container do we mount the binding information (e.g. what is the structure of the folders / files)
- Consideration with clusters, namespaces, or VMs
- How are application expected to consume binding information
- Each framework may take a different approach, so this is about samples & recommendations (best practices)
- Validates the design