You are invited to contribute!
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.
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 mangodbsFor 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:
We ❤️ our contributors! If you're interested in helping us out, please check out Contributing to kube-bind and kube-bind Project Governance.
There are several ways to communicate with us:
- The
#kube-bindchannel in the Kubernetes Slack workspace - Our mailing list kube-bind-dev for development discussions.
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.
To get familiar with setting up the environment, please check out docs at kube-bind.io.
Version v0.5.0 includes significant architectural improvements to the API structure:
- API Version Upgrade: Introduced
v1alpha2API version alongside existingv1alpha1 - Service Exposure Refactoring: Refactored the service exposure mechanism from embedded CRD specifications to a resource-based model:
APIServiceExportSpecnow usesResources []APIServiceExportResourceinstead of embedded CRD specsBoundSchema: New resource type inv1alpha2that represents bound schemas in consumer clusters and tracks the status of synced resources- This allows one APIServiceExport to reference multiple CRDs more efficiently
- MultiCluster Runtime Integration: The backend now leverages
sigs.k8s.io/multicluster-runtimefor enhanced cluster management capabilities - Provider Support: Built-in support for multiple backend providers including KCP through
github.com/kcp-dev/multicluster-provider - Enhanced Cluster Operations: Improved cluster-aware resource management with dedicated manager architecture for handling multi-cluster scenarios
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
BoundSchemaresources, like schema changes. - Currently multicluster-runtime dependency is pointing to a fork, we will work on getting the changes merged upstream. See PR for details.