You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+15-10Lines changed: 15 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -62,23 +62,28 @@ All the actions shown between the clusters are done by the konnector, except: th
62
62
63
63
To get familiar with setting up the environment, please check out docs at [kube-bind.io](https://docs.kube-bind.io/main/setup).
64
64
65
-
## API Changes in coming v0.5.0 release
65
+
## API Changes in v0.5.0 release
66
66
67
67
Version v0.5.0 includes significant architectural improvements to the API structure:
68
68
69
69
### Major Changes
70
70
71
-
-**API Version Upgrade**: Introduced `v1alpha2` API version with improved stability and features
72
-
-**Service Exposure Refactoring**: Completely refactored the service exposure mechanism to use:
73
-
-`APIResourceSchema`: Define the schema of exported CRDs, allowing one APIServiceExport to reference multiple CRDs.
74
-
-`BoundAPIResourceSchema`: Represent bound schemas in consumer clusters and underlying status of synced resources.
71
+
-**API Version Upgrade**: Introduced `v1alpha2` API version alongside existing `v1alpha1`
72
+
-**Service Exposure Refactoring**: Refactored the service exposure mechanism from embedded CRD specifications to a resource-based model:
73
+
-`APIServiceExportSpec` now uses `Resources []APIServiceExportResource` instead of embedded CRD specs
74
+
-`BoundSchema`: New resource type in `v1alpha2` that represents bound schemas in consumer clusters and tracks the status of synced resources
75
+
- This allows one APIServiceExport to reference multiple CRDs more efficiently
76
+
77
+
### Backend Architecture Improvements
78
+
79
+
-**MultiCluster Runtime Integration**: The backend now leverages `sigs.k8s.io/multicluster-runtime` for enhanced cluster management capabilities
80
+
-**Provider Support**: Built-in support for multiple backend providers including KCP through `github.com/kcp-dev/multicluster-provider`
81
+
-**Enhanced Cluster Operations**: Improved cluster-aware resource management with dedicated manager architecture for handling multi-cluster scenarios
75
82
76
83
### Limitations
77
84
78
85
These limitations are part of the roadmap and will be addressed in the future.
79
86
80
-
* Currently we don't support related resources, like ConfigMaps, Secrets
81
-
* Currently CRD resources MUST be installed in the provider cluster, even when APIResourceSchema is used.
82
-
This is to allow the konnector to sync instances of the CRD to the consumer cluster.
83
-
This should be removed once we introduce sync policies and object wrappers.
84
-
* Currently we dont support granular permissions, like only allow to read/write certain named resources.
87
+
* Currently we don't support related resources, like ConfigMaps, Secrets.
88
+
* We don't support lifecycle of `BoundSchema` resources, like schema changes.
89
+
* Currently multicluster-runtime dependency is pointing to a fork, we will work on getting the changes merged upstream. See [PR](https://github.com/kubernetes-sigs/multicluster-runtime/pull/62) for details.
The kube-bind backend provides service export and binding capabilities for single Kubernetes clusters acting as backend or many clusters with support for multiple cluster providers through the multicluster-runtime architecture.
4
+
5
+
## Architecture
6
+
7
+
Starting with v0.5.0, the backend leverages `sigs.k8s.io/multicluster-runtime` for enhanced cluster management capabilities.
8
+
9
+
### Key Components
10
+
11
+
-**MultiCluster Runtime Integration**: Built on `sigs.k8s.io/multicluster-runtime` for provider-agnostic cluster operations
12
+
-**Provider Support**: Extensible provider system supporting different backend implementations
13
+
-**Manager Architecture**: Uses `mcmanager.Manager` for cluster-aware resource management
14
+
15
+
### Supported Providers
16
+
17
+
-**Default Provider**: Standard Kubernetes cluster support
18
+
-**KCP Provider**: Integration with [kcp](https://github.com/kcp-dev/kcp) through `github.com/kcp-dev/multicluster-provider`
19
+
20
+
## Configuration
21
+
22
+
The backend can be configured to use different providers:
23
+
24
+
```bash
25
+
./bin/backend \
26
+
--multicluster-runtime-provider kcp \
27
+
--server-url=$(kubectl get apiexportendpointslice kube-bind.io -o jsonpath="{.status.endpoints[0].url}") \
28
+
# ... other options
29
+
```
30
+
31
+
### Provider Configuration
32
+
33
+
#### KCP Provider
34
+
35
+
When using the KCP provider (`--multicluster-runtime-provider kcp`), the backend:
36
+
37
+
- Connects to kcp workspaces through APIExports
38
+
- Manages resources across logical clusters
39
+
- Supports advanced multi-tenancy features
40
+
- Enables workspace-based isolation
41
+
42
+
#### Default Provider
43
+
44
+
The default provider works with standard Kubernetes clusters and provides:
45
+
46
+
- Direct cluster connectivity
47
+
- Namespace-based isolation
48
+
- Standard RBAC integration
49
+
50
+
## API Changes
51
+
52
+
The backend now supports the v1alpha2 API with significant architectural improvements:
53
+
54
+
-**Resource-Based Exports**: APIServiceExport now uses resource references instead of embedded CRDs
55
+
-**BoundSchema Support**: Integration with BoundSchema resources for better schema management
56
+
-**Multi-Resource Support**: Single exports can reference multiple CRDs efficiently
57
+
58
+
## Controllers
59
+
60
+
The backend includes several controllers for managing the export/binding lifecycle:
0 commit comments