This repository served as an exploration into routing objects between providers using a VirtualWorkspace architecture. Following initial implementation and testing, it was determined that the current design is not viable for real-world production scenarios.
The primary challenge lies in the lack of alignment with Kubernetes Resource Model (KRM) semantics during provider transitions. Specifically:
State Discontinuity: When a user modifies a label or routing configuration, the object is immediately removed from the source provider and recreated in the destination provider.
Protocol Incompatibility: These transitions do not natively support standard KRM operations such as WATCH or DELETE. Consequently, controllers or automated systems monitoring these objects lose track of the state during the migration.
Lack of Persistence: To resolve these issues, the system would require the generation of synthetic events and the management of "shadow" objects (to handle finalizers and graceful deletions). This would necessitate a dedicated persistence layer within the workspace, which falls outside the original scope of this lightweight routing experiment.
While this project is no longer being actively maintained or updated, the underlying concepts remain open for discussion. If you are interested in evolving these ideas or addressing the persistence requirements mentioned above, please reach out to the maintainers.
The Filtered APIExport Virtual Workspace is an external virtual workspace for kcp that gives Service Providers (APIExport owners) filtered access to their resources in consumer workspaces (bound via APIBindings). This workspace is an extension of the built-in APIExport Virtual Workspace, scoped only to objects that match the provided label selector.
When a Service Provider exposes an API via an APIExport, they can use the built-in APIExport Virtual Workspace to access all resources across consumer workspaces that have bound the API. The Filtered APIExport Virtual Workspace extends this by allowing:
- Label-based Filtering: Access only objects matching a specific label selector through a dedicated virtual workspace URL
- Multiple Views: Create different filtered endpoints for different use cases (e.g., by environment, team, or region)
- Dynamic Scoping: Objects are filtered at request time based on the configured selector
- A Service Provider creates a
FilteredAPIExportEndpointSliceresource that references their APIExport and defines a label selector - The controller validates the APIExport reference and generates virtual workspace endpoint URLs in the status
- The Service Provider uses the endpoint URL to access resources across all consumer workspaces
- Only objects matching the label selector are visible through this endpoint
The FilteredAPIExportEndpointSlice resource registers endpoints in the Filtered APIExport Virtual Workspace:
apiVersion: filteredvw.kcp.io/v1alpha1
kind: FilteredAPIExportEndpointSlice
metadata:
name: example
spec:
export:
# Path to the workspace containing the APIExport
path: root:my-org
# Name of the APIExport
name: my-apiexport
objectSelector:
# Only objects matching this selector will be visible
matchLabels:
environment: "prod"
team: "platform"See the Deployment document for more details.
See the Quick Start document for more details.
# Build all binaries
make build
# Run code generation
make codegen# Run tests
./hack/run-tests.shIf you encounter problems, please file an issue.
Thanks for taking the time to start contributing!
- Please familiarize yourself with the Code of Conduct before contributing.
- See CONTRIBUTING.md for instructions on the developer certificate of origin that we require.
- We welcome pull requests. Feel free to dig through the issues and jump in.
See the list of releases to find out about feature changes.
Apache 2.0