docs(adr): kcp-aware service provider runtime - #204
Conversation
Proposes a unified runtime abstraction covering both standard onboarding and kcp workspace modes behind a single provider seam. Signed-off-by: Moritz Marby <moritz.marby@sap.com>
| 2. When a Service API object appears in a workspace, the runtime: | ||
| - Mints a scoped `ServiceAccount` token in the consumer workspace (via TokenRequest API) so the | ||
| workload can reach back at the workspace. | ||
| - Resolves (or orders) a workload cluster if the provider requested one. |
There was a problem hiding this comment.
just to clarify: this means a service provider can choose to provision workloads in a control plane? Can a tenant mix kcp service providers with non kcp service providers? Let's say I am a tenant of OpenControlPlane and there is a new service provider that supports kcp workspaces. Can I consume that service on its own? Is that a use case we want to allow? And the other way around the question would be, does a tenant still require a ControlPlane to consume a service provider that supports kcp workspaces?
| - `MCPCluster` - ready client for the customer cluster. In standard mode: the MCP control plane. | ||
| In kcp mode: the tenant's kcp workspace. Same field, same type, either mode. |
There was a problem hiding this comment.
Answers my previous question :) There is no model where an existing tenant (with e.g. a gardener cluster) can use the kcp route of a service provider. The use case is that I start from scratch with a kcp workspace.
| - name: v1.2.3 | ||
| chartURL: oci://... | ||
| kcp: | ||
| providerWorkspace: root:my-org:services |
There was a problem hiding this comment.
This means a platform owner has to host kcp where tenants create workspaces and a tenant can't bring its own kcp workspace from its own kcp deployment?
There was a problem hiding this comment.
yes, that is also my understanding.
| - APIExport provisioning lifecycle (schema immutability, upsert). | ||
| - Workspace token minting or refresh. | ||
| - Workload cluster ordering and wait loop. | ||
| - Status patching. |
There was a problem hiding this comment.
Not sure what status this is referring to but why would a provider not need do status reporting?
There was a problem hiding this comment.
Will remove it, make it precise.
I meant the concrete status patching in kubernetes terms, but letting the runtime do the concrete thing, the service provider still reports the status.
maximiliantech
left a comment
maximiliantech
left a comment
There was a problem hiding this comment.
Thanks for this ADR @n3rdc4ptn! I really like it 🫶 Could you please have a look at my comments below?
| picks it up, orders cluster access (MCP + optional workload cluster), and installs the service. | ||
|
|
||
| There is no defined way for a service provider to expose its service into a kcp workspace. kcp | ||
| (Kubernetes Control Plane) lets tenants work in isolated logical workspaces rather than on a shared |
There was a problem hiding this comment.
| (Kubernetes Control Plane) lets tenants work in isolated logical workspaces rather than on a shared | |
| (Kubernetes-like Control Plane) lets tenants work in isolated logical workspaces rather than on a shared |
| There are two deployment patterns: | ||
|
|
||
| - **Workerless:** The service worker runs on a separate workload cluster, with its kubeconfig | ||
| pointed at the customer control plane or kcp workspace. The customer cluster is only used as an |
There was a problem hiding this comment.
| pointed at the customer control plane or kcp workspace. The customer cluster is only used as an | |
| pointed at the end user control plane or kcp workspace. The customer cluster is only used as an |
There was a problem hiding this comment.
@n3rdc4ptn Could you please make sure to switch from "customer" to "end user" in the whole document to adhere to our three personas. 🙏
MichaelSp
left a comment
MichaelSp
left a comment
There was a problem hiding this comment.
Not sure why in "classic" we cannot watch KCP in addition to the CP in-cluster?
| `Crossplane`). One type is used for both onboarding and kcp modes. | ||
| - Its **ProviderConfig** type - platform-operator configuration (available versions, kcp settings, | ||
| workload cluster preferences). | ||
| - Its **install/delete logic** - a single `Reconciler` with two methods: `CreateOrUpdate` (install |
There was a problem hiding this comment.
You use reconcile/install/createOrUpdate pretty randomly across this document. I suggest we settle on one term. I like CreateOrUpdate.
| Both discovery paths (onboarding cluster and kcp workspace) funnel into the same two methods: | ||
|
|
||
| ``` | ||
| CreateOrUpdate(ctx, serviceAPIObject, providerConfig, clusterContext) -> (result, error) |
There was a problem hiding this comment.
| CreateOrUpdate(ctx, serviceAPIObject, providerConfig, clusterContext) -> (result, error) | |
| CreateOrUpdate(ctx, serviceAPIObject) -> (result, error) |
and offer framework functions to get it from ctx like cluster.WorkloadFromCtx(ctx)
| - name: v1.2.3 | ||
| chartURL: oci://... | ||
| kcp: | ||
| providerWorkspace: root:my-org:services |
There was a problem hiding this comment.
yes, that is also my understanding.
| 1. The runtime watches for Service API objects across all bound consumer workspaces via the | ||
| `APIExport` virtual workspace (multicluster-runtime). | ||
| 2. When a Service API object appears in a workspace, the runtime: | ||
| - Mints a scoped `ServiceAccount` token in the consumer workspace (via TokenRequest API) so the |
There was a problem hiding this comment.
Can we use the workloads own service account + OIDC WebHook on the KCP side instead?
|
|
||
| ## Open Questions | ||
|
|
||
| 1. **CRD install ownership:** Should the runtime own the `init` step (install the Service API CRD |
There was a problem hiding this comment.
I would say: The runtime owns the init. We should apply Hollywood-principle here to make it a real framework and not just a lib: "Dont call us, we call you".
| on the onboarding cluster + register the GVK at the ServiceProvider), or do providers retain a | ||
| thin `init` command for custom pre-flight steps? | ||
|
|
||
| 2. **APIBinding activation:** Should the runtime watch `APIBinding` objects and trigger a |
There was a problem hiding this comment.
I think reactive is enough. Later we can still extend the framework API to include things like APIBound-events.
| reconcile when a workspace binds the APIExport (proactive first-install), or is watching the | ||
| Service API objects across virtual workspaces sufficient (reactive)? | ||
|
|
||
| 3. **ProviderConfig hot-reload in kcp mode:** When `ProviderConfig` changes (e.g. new chart |
There was a problem hiding this comment.
yes, that would be cool. Not sure how if we can capture all edge-cases tho. If not feasible -> drop it.
4 participants
Why
Defines how service providers expose their service into kcp workspaces and proposes a unified runtime abstraction so providers only write install/delete logic - for both the existing onboarding flow and the new kcp workspace flow.
What changed
adrs/2026-08-20-kcp-aware-service-provider-runtime.md- new ADR proposing unified runtime with single provider seam, kcp onboarding design, workerless vs classic deployment patterns, and unified Service API type across onboarding and kcp.