Skip to content

kbind Documentation

Overview

kbind (formerly known as kube-bind) is a project that aims to provide better support for service providers and consumers that reside in distinct Kubernetes clusters. We are actively working towards a stable release, and welcome feedback from the community.

This documentation covers v2. The 0.x documentation remains the default. See Moving from 0.x before upgrading an existing installation.

High-level architecture diagram

The diagram illustrates provider/consumer separation. In v2, authentication through an identity provider is optional, and namespace isolation must be arranged by the deployment rather than automatic namespace remapping.

  • A service provider defines its API contract in terms of CRDs and credential RBAC, and labels the CRDs for export.
  • Service consumers identify the services they want to consume using the optional catalog, CLI or Web UI, or apply core bindings directly through GitOps.
  • 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 - konnector per consumer cluster connects it with the requested services.

The v2 core consumes a kubeconfig Secret, a Connection, and ClusterBinding or namespaced Binding objects. The backend is optional, and the shipped syncer preserves resource scope, namespace, and name.

v2 Architecture

flowchart LR
  subgraph Consumer
    B["Secret + Connection + bindings"]
    K[Konnector]
    C[Custom resources]
    B --> K
    C --> K
  end
  subgraph Provider
    P[Custom resources]
    O[Service operator]
    G["Optional backend: catalog, auth, issuer, reaper"]
    P <--> O
  end
  K -- "spec up" --> P
  P -- "status down" --> K
  K --> C
  G -. "one-apply bundle" .-> B

The optional backend produces the bundle, synchronization runs directly between the consumer's konnector and the provider API server, not through the gateway. See Architecture Overview for the controller layout.

Getting Started

Contributing

We ❤️ our contributors! If you're interested in helping us out, please head over to our Contributing guide.

Getting in touch

There are several ways to communicate with us:

See the community page for more details.