[Features] integrating servicebinding.io

[skortobi]

What is the user interaction of your feature
As a developper i want to have a secret exposed by the operator in the servicebinding.io format containing type,host,username,password,uri fields

Is your feature request related to a problem? Please describe.
Today the operator only expose username and password fields as a secret, user must create manualy a secret with type, host and uri to be fully compatible with servicebinding

Describe the solution you'd like
Kubeblocks operator to expose the secret to developper in servicebindings.io format

[shanshanying]

HI @skortobi

This feature reminds me of a deprecated API that KubeBlocks previously supported: ConnectionCredential. It provides similar capabilities.
User can define the template of the secret, e.g.

  connectionCredential:
    username: root
    password: "$(RANDOM_PASSWD)"
    endpoint: "$(SVC_FQDN):$(SVC_PORT_mysql)"
    host: "$(SVC_FQDN)"
    port: "$(SVC_PORT_mysql)"

And when the cluster is created, KubeBlocks will render a secret w.r.t. the template defined in this API.

It is quite useful at the beginning. But with more and more Addons added, we found it is not a good idea for KubeBlocks to generate such a connection secret

1. Security of Root Account. KB only generates root/admin account on provisiong, and it is not safe to provide this account to applications.
2. Variance of Services. Observed applications and database engines are usually deployed in different K8s Clusters. it is hard for us decide ahead how to expose the svc (LB/NodePort/ClusterIP, etc) the default-generated endpoint does not users's needs.
3. Variance of ports. Many database engine have multiple ports, the list goes longer and longer, e.g. clickhouse porvide both pg/mysql ports
   then KB should define the crecential like

     connectionCredential:
       username: "admin"
       password: "$(RANDOM_PASSWD)"
       endpoint: "http://$(SVC_FQDN):$(SVC_PORT_http)"
       tcpEndpoint: "$(SVC_FQDN):$(SVC_PORT_tcp)"
       mysqlEndpoint: "$(SVC_FQDN):$(SVC_PORT_tcp-mysql)"
       pgEndpoint: "$(SVC_FQDN):$(SVC_PORT_tcp-postgresql)"

   and it's hard for KB to maintain them all.

Hence since KB 09 it is discouraged to use this connection credential API.
and users can generate/customize a secret meeting their needs.

What do you think ? feedbacks or dicusssions are appreciated.