Skip to content

Latest commit

 

History

History
123 lines (88 loc) · 5.85 KB

service-binding.adoc

File metadata and controls

123 lines (88 loc) · 5.85 KB
title authors reviewers approvers creation-date last-updated status see-also replaces superseded-by
Service Binding
@johnpoth
@lburgazzoli
TBD
2020-15-12
2020-15-12
implementable

Service Binding

Summary

This proposal aims at leveraging the Service Binding Specification in Camel K.

Terminology

  • Provisioned Service

    • A service e.g. a Database, or a Broker that can be bound to an application by means defined in the specification

  • Application

    • In the context of Camel K is an Integration

Motivation

Users should be able to connect to a Provisioned Service by specifying one or more Service Bindings from the command line, e.g.:

$ kamel run intergration --connect database,broker

The Service Binding could be referenced by name like shown above, in which case the Service Binding already exists, or it could be created and managed by Camel K in which case the user would have to explicitly specify the Provisioned Service they want to connect to:

$ kamel run intergration --connect Database.v1alpha1.postgresql.baiju.dev/db-demo

The user may then reference the binding properties inside the integration just like any other properties.

Goals

The goal of this proposal is to provide the current state of the Service Binding Specification and how it might be leveraged in Camel K to ease route configuration and facilitate their re-usability.

Context

The specification can be split into two categories: the Service Binding Operator, and the Provisioned Service implementation. Several implementations of the Service Binding Operator can be found readily available.

Two have been tried in the context of this proposal:

Provisioned Services implementations are still work in progress and aren’t readily available. A list of first and second wave of specification adopters is maintained. Knowing this, usability of the Service Binding Specification remains limited. However, an initial effort may be done in order to better understand how Camel K can benefit from it.

Workflow

Two main workflows have been identified in the specification that allows user applications to bind to a Provisioned Service. Let’s review them and see which one would suit Camel K the best.

The first way outlined in the specification is for the user to create a ServiceBinding indicating which application to bind to which set of Provisioned Services:

kind: ServiceBinding
metadata:
  name: account-service
spec:
  application:
    apiVersion: apps/v1
    kind:       Deployment
    name:       camel-k-integration

  service:
    apiVersion: com.example/v1alpha1
    kind:       Database
    name:       my-database

Once created, it is the responsibility of the Service Binding Operator to inject the binding information into the application. The application is any PodSpec-able resource e.g a Deployment. The way it does this is that it first scales the Deployment down to 0. Then it injects the binding information into the Deployment in the form of a Secret or a ConfigMap. Finally, it scales the Deployment back up.

The second way is through Custom Projection. The difference between this approach, and the first one is that the binding information injection into the application is not the responsibility of the Service Binding Operator anymore. It wil be the responsibility of another Operator. In our case it will be Camel K’s responsibility to retrieve the binding information and inject it into the Integration.

The drawback of the first approach, in the context of Camel K, is that the Integration's Deployment would be created in an incomplete state and would result in an error the first time the underlying container is started because the binding information is not present. The second drawback is that the Integration's Deployment resource should ideally not be altered by someone other than the Camel K operator itself. The advantage of using this approach is that less work is needed in Camel K as injection is taken care of by the Service Binding Operator.

Conversely, the drawback of implementing the second approach is that more work is needed as Camel K would have to retrieve and inject the binding information. The advantage would be that Camel K retains full control of the Integration's Deployment/Cron/Knative resource, and we can delay the startup until the binding information is available.

For these reasons, it seems that the second approach is preferred in the context of Camel K.

Proposal

Architecture

The proposed architecture is illustrated in the diagram below:

Camel K Integration Service Binding

where the Secret created by the Service Binding Operator holds the binding information. Quarkus' Service Binding support could then be leveraged to configure the Integration.

The steps 2-4 would not happen if the ServiceBinding is created beforehand.

In the Optional steps 2-4, Camel K will have to wait until the ServiceBinding is injected with the Secret. To avoid useless reconciliation loops, a new Phase would be added (e.g. IntegrationPhaseWaitingForServiceBinding) which would pause the integration until Camel K is notified of a change in the ServiceBinding.