Update docs for v0.5

Signed-off-by: Mangirdas Judeikis <mangirdas@judeikis.lt>
On-behalf-of: @SAP mangirdas.judeikis@sap.com

Author: mjudeikis

README.md

@@ -62,23 +62,27 @@ All the actions shown between the clusters are done by the konnector, except: th
 
 To get familiar with setting up the environment, please check out docs at [kube-bind.io](https://docs.kube-bind.io/main/setup).
 
-## API Changes in coming v0.5.0 release
+## API Changes in 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.
+- **API Version Upgrade**: Introduced `v1alpha2` API version alongside existing `v1alpha1`
+- **Service Exposure Refactoring**: Refactored the service exposure mechanism from embedded CRD specifications to a resource-based model:
+  - `APIServiceExportSpec` now uses `Resources []APIServiceExportResource` instead of embedded CRD specs
+  - `BoundSchema`: New resource type in `v1alpha2` that represents bound schemas in consumer clusters and tracks the status of synced resources
+  - This allows one APIServiceExport to reference multiple CRDs more efficiently
+
+### Backend Architecture Improvements
+
+- **MultiCluster Runtime Integration**: The backend now leverages `sigs.k8s.io/multicluster-runtime` for 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
 
 ### 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.
+* Currently we don't support related resources, like ConfigMaps, Secrets.
+* We don't support lifecycle of `BoundSchema` resources, like schema changes.

contrib/kcp/deploy/resources/apiexport-kube-bind.io.yaml

@@ -74,7 +74,7 @@ spec:
       crd: {}
   - group: kube-bind.io
     name: clusterbindings
-    schema: v250809-5ed76a1.clusterbindings.kube-bind.io
+    schema: v250924-ab03f00.clusterbindings.kube-bind.io
     storage:
       crd: {}
 status: {}

contrib/kcp/deploy/resources/apiresourceschema-clusterbindings.kube-bind.io.yaml

@@ -2,7 +2,7 @@ apiVersion: apis.kcp.io/v1alpha1
 kind: APIResourceSchema
 metadata:
   creationTimestamp: null
-  name: v250809-5ed76a1.clusterbindings.kube-bind.io
+  name: v250924-ab03f00.clusterbindings.kube-bind.io
 spec:
   conversion:
     strategy: None
@@ -32,8 +32,8 @@ spec:
     name: v1alpha1
     schema:
       description: |-
-        ClusterBinding represents a bound consumer cluster. It lives in a service
-        provider cluster and is a singleton named "cluster" per namespace.
+        ClusterBinding represents a bound consumer class. It lives in a service provider cluster
+        and is a singleton named "cluster".
       properties:
         apiVersion:
           description: |-

deploy/crd/kube-bind.io_clusterbindings.yaml

@@ -34,8 +34,8 @@ spec:
     schema:
       openAPIV3Schema:
         description: |-
-          ClusterBinding represents a bound consumer cluster. It lives in a service
-          provider cluster and is a singleton named "cluster" per namespace.
+          ClusterBinding represents a bound consumer class. It lives in a service provider cluster
+          and is a singleton named "cluster".
         properties:
           apiVersion:
             description: |-

docs/content/developers/backend/index.md

@@ -1 +1,65 @@
 # Backend
+
+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.
+
+## Architecture
+
+Starting with v0.5.0, the backend leverages `sigs.k8s.io/multicluster-runtime` for enhanced cluster management capabilities.
+
+### Key Components
+
+- **MultiCluster Runtime Integration**: Built on `sigs.k8s.io/multicluster-runtime` for provider-agnostic cluster operations
+- **Provider Support**: Extensible provider system supporting different backend implementations
+- **Manager Architecture**: Uses `mcmanager.Manager` for cluster-aware resource management
+
+### Supported Providers
+
+- **Default Provider**: Standard Kubernetes cluster support
+- **KCP Provider**: Integration with [kcp](https://github.com/kcp-dev/kcp) through `github.com/kcp-dev/multicluster-provider`
+
+## Configuration
+
+The backend can be configured to use different providers:
+
+```bash
+./bin/backend \
+  --multicluster-runtime-provider kcp \
+  --server-url=$(kubectl get apiexportendpointslice kube-bind.io -o jsonpath="{.status.endpoints[0].url}") \
+  # ... other options
+```
+
+### Provider Configuration
+
+#### KCP Provider
+
+When using the KCP provider (`--multicluster-runtime-provider kcp`), the backend:
+
+- Connects to kcp workspaces through APIExports
+- Manages resources across logical clusters  
+- Supports advanced multi-tenancy features
+- Enables workspace-based isolation
+
+#### Default Provider
+
+The default provider works with standard Kubernetes clusters and provides:
+
+- Direct cluster connectivity
+- Namespace-based isolation
+- Standard RBAC integration
+
+## API Changes
+
+The backend now supports the v1alpha2 API with significant architectural improvements:
+
+- **Resource-Based Exports**: APIServiceExport now uses resource references instead of embedded CRDs
+- **BoundSchema Support**: Integration with BoundSchema resources for better schema management
+- **Multi-Resource Support**: Single exports can reference multiple CRDs efficiently
+
+## Controllers
+
+The backend includes several controllers for managing the export/binding lifecycle:
+
+- **ClusterBinding Controller**: Manages cluster binding lifecycle
+- **ServiceExport Controller**: Handles APIServiceExport resources
+- **ServiceExportRequest Controller**: Processes export requests
+- **ServiceNamespace Controller**: Manages namespace isolation

docs/content/developers/konnector/controllers/cluster/apiserviceexport.md

@@ -1,13 +1,21 @@
 # APIServiceExports
 
-The APIServiceExport controller watches `APIServiceExports` and the referenced `CustomResourceDefinitions` (CRDs) in the **provider cluster**.
+The APIServiceExport controller watches `APIServiceExports` and the referenced resources in the **provider cluster**.
 
-It is responsible for:
+Starting with v1alpha2, the APIServiceExport has been refactored to use a resource-based model instead of embedded CRD specifications.
+
+## Key Changes in v1alpha2
+
+- **Resource-Based Model**: `APIServiceExportSpec` now uses `Resources []APIServiceExportResource` instead of embedded CRD specs
+- **Multi-Resource Support**: One APIServiceExport can reference multiple CRDs more efficiently
+- **BoundSchema Integration**: Works with the new `BoundSchema` resource type for tracking bound schemas in consumer clusters
+
+## Controller Responsibilities
 
 * Ensuring the existence and validity of `APIServiceExports`.
 * Managing the lifecycle of `APIServiceExports` by starting and stopping spec and status syncers and controllers.
 * Checking `APIServiceBinding` condition and setting `ConsumerInSync` condition in `APIServiceExport`
-* Copying conditions from the referenced CRDs to the `APIServiceExport` status.
+* Managing resource references and their associated schemas.
 
 ## Overview
 

docs/content/developers/konnector/controllers/cluster/boundschema.md

@@ -0,0 +1,49 @@
+# BoundSchema
+
+The BoundSchema controller manages `BoundSchema` resources in the consumer cluster, introduced in v1alpha2.
+
+`BoundSchema` represents bound API resource schemas in consumer clusters and tracks the underlying status of synced resources.
+
+## Key Features
+
+- **Schema Validation**: Ensures the bound schema is valid and properly applied
+- **Drift Detection**: Monitors for differences between expected and actual schema state  
+- **Condition Management**: Provides status conditions for validation and drift detection
+
+## BoundSchema Structure
+
+```yaml
+apiVersion: kubebind.io/v1alpha2
+kind: BoundSchema
+metadata:
+  name: example-schema
+  namespace: kube-bind-example
+spec:
+  informerScope: Namespaced  # or Cluster
+  group: example.com
+  names:
+    kind: ExampleResource
+    plural: exampleresources
+  scope: Namespaced
+  versions:
+  - name: v1
+    served: true
+    storage: true
+    schema: # JSONSchema for validation
+status:
+  acceptedNames: # Names actually being used
+  storedVersions: []
+  conditions:
+  - type: Valid
+    status: "True"
+    reason: Accepted
+```
+
+## Integration with APIServiceExport
+
+BoundSchema works closely with the APIServiceExport resource-based model:
+
+1. APIServiceExport references multiple resources via `Resources []APIServiceExportResource`
+2. Each resource can map to a BoundSchema in the consumer cluster
+3. BoundSchema tracks the actual application and status of these schemas
+4. This enables better multi-resource management and status tracking

docs/content/setup/index.md

@@ -1,3 +1,32 @@
 # Setting Up kube-bind
 
+kube-bind supports multiple deployment scenarios and backend providers to meet different requirements.
+
+## Setup Options
+
+### Standard Kubernetes Setup
+
+- **[Quickstart](quickstart.md)**: Get started quickly with the default provider
+- **[Helm Deployment](helm.md)**: Production deployment using Helm charts
+- **[Local Setup with Kind](local-setup-with-kind.md)**: Local development environment
+- **[kubectl Plugin](kubectl-plugin.md)**: Install and use the kubectl-bind plugin
+
+### Advanced Multi-Cluster Setup
+
+- **[KCP Integration](kcp-setup.md)**: Advanced multi-tenant setup with kcp workspaces and APIExports
+
+## Architecture Overview
+
+Starting with v0.5.0, kube-bind uses a multicluster-runtime architecture that supports:
+
+- **Multiple Providers**: Choose between standard Kubernetes or KCP backends
+- **Enhanced API**: v1alpha2 API with resource-based exports and BoundSchema support
+- **Flexible Deployment**: Support for various cluster topologies and requirements
+
+Choose the setup that best fits your use case:
+
+- Use **Quickstart** or **Local Setup with Kind** for development and testing
+- Use **Helm Deployment** for production environments with standard Kubernetes
+- Use **KCP Integration** for advanced multi-tenant scenarios with workspace isolation
+
 {% include "partials/section-overview.html" %}