kbind

You are invited to contribute!

What is it?

kbind (formerly known as kube-bind) provides better support for service providers and consumers that reside in distinct Kubernetes clusters.

A service provider defines its API in terms of CRDs and associated permission claims/limitations, and exports it for use from other clusters.
Service consumers identify the services they want to consume.
The service CRDs get installed in the service consumer clusters, with objects of the defined kinds written and read by the service consumers.
The service provider indirectly reads and writes those objects as the interface to the service that it provides.
The service provider does not inject controllers/operators into the service consumer's cluster.
A single vendor-neutral, OpenSource agent per consumer cluster connects it with the requested services.

Try it out

This is the 3 line pitch:

$ kubectl krew index add bind https://github.com/kube-bind/krew-index.git
$ kubectl krew install bind/bind
$ kubectl bind login https://mangodb
$ kubectl bind
Redirect to the browser to authenticate via OIDC.
BOOM – the MangoDB API is available in the local cluster,
       without anything MangoDB-specific running.
$ kubectl get mangodbs

For more information

For more information go to https://kbind.dev or watch the ContainerDays talk or the KubeCon talk.

kbind is following this manifesto from the linked talk:

Contributing

We ❤️ our contributors! If you're interested in helping us out, please check out Contributing to kbind and kbind Project Governance.

Getting in touch

There are several ways to communicate with us:

The #kube-bind channel in the Kubernetes Slack workspace
Our mailing list kube-bind-dev for development discussions.
Our bi-weekly community meetings — every second Thursday at 11am EST (5pm CET).
- By joining the kube-bind-dev mailing list, you should receive an invite.
- See our community meeting notes document for upcoming and past agendas.

See the community page for more details.

Technical Overview

All the actions shown between the clusters are done by the konnector, except: the pull at the start is done by the kubectl plugin that installs the konnector.

Usage

To get familiar with setting up the environment, please check out docs at kbind.dev.

Limitations

These limitations are part of the roadmap and will be addressed in the future.

Currently we don't support related resources, like ConfigMaps, Secrets.
We don't support lifecycle of BoundSchema resources, like schema changes.
The backend currently does not support running with replicas > 1 due to missing external session storage implementation. Session storage is currently in-memory only, which prevents proper session sharing across multiple backend instances.