Service providers integrate with Platform Mesh by exposing declarative APIs and reconciling consumer requests into real services. There are two paths today and a third under development. All paths produce the same consumer experience: declarative APIs available through APIExport and APIBinding.
Use api-syncagent when the provider already exposes Kubernetes CRDs and the standard spec-down / status-up sync pattern is enough.
Use multicluster-runtime when the provider needs custom sync logic, non-CRD APIs, or reconciliation built directly into a provider controller.
Both paths require a Kubernetes operator that reconciles your service’s resources. The paths differ in how synchronization between kcp and the service cluster is handled, not in whether you need an operator.
| Path | Best fit | Provider effort |
|---|---|---|
| api-syncagent | Existing CRD-based service APIs | Operator + deploy the sync agent; sync handled by the agent |
| multicluster-runtime | Custom controllers, non-CRD APIs, complex sync logic | Operator built with mcr libraries; sync built into the operator |
kube-bind will serve a dual role in Platform Mesh:
This integration path is currently under development. See the interaction patterns for how kube-bind will fit into provider-to-consumer and provider-to-provider topologies.