kube-bind

Disclaimer: work in progress and not ready for production use.

You are invited to contribute!

What is it?

kube-bind is a prototype project that aims to provide 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 https://mangodb/exports
Redirect to the brower 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://kube-bind.io or watch the ContainerDays talk or the KubeCon talk.

The kube-bind prototype 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 kube-bind and kube-bind 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.

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 kube-bind.io.

API Changes in coming v0.5.0 release

Version v0.5.0 includes significant architectural improvements to the API structure:

Major Changes

• API Version Upgrade: Introduced v1alpha2 API version with improved stability and features
• Service Exposure Refactoring: Completely refactored the service exposure mechanism to use:
  • APIResourceSchema: Define the schema of exported CRDs, allowing one APIServiceExport to reference multiple CRDs.
  • BoundAPIResourceSchema: Represent bound schemas in consumer clusters and underlying status of synced resources.

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
• Currently CRD resources MUST be installed in the provider cluster, even when APIResourceSchema is used. This is to allow the konnector to sync instances of the CRD to the consumer cluster. This should be removed once we introduce sync policies and object wrappers.
• Currently we dont support granular permissions, like only allow to read/write certain named resources.