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: how-to-guides/set-up-remote-deployment.md
+41-29Lines changed: 41 additions & 29 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,47 +7,61 @@ personas: [platform-owner]
7
7
8
8
Use this how-to to deploy Platform Mesh across multiple clusters, where the operator runs on one cluster but manages resources on separate runtime and infra clusters.
9
9
10
+
## When to use this
11
+
12
+
Remote deployment fits scenarios where Platform Mesh's control-plane workloads cannot live on the same cluster as the operator. Common cases:
13
+
14
+
-**Separation of concerns** — keep kcp, OCM, and the `PlatformMesh` resource on a dedicated runtime cluster, while the operator and GitOps tooling run elsewhere.
15
+
-**Shared GitOps cluster** — a central cluster runs FluxCD or ArgoCD and rolls out releases to one or more runtime clusters.
16
+
-**Compliance or isolation** — runtime workloads must run in a network or tenant boundary that the operator cluster cannot host.
17
+
18
+
If everything runs on the same cluster, you do not need this guide.
19
+
10
20
::: warning Alpha feature
11
21
Remote deployment is functional but limited to a single remote deployment per operator instance. APIs and Helm values may change.
12
22
:::
13
23
14
24
## Prerequisites
15
25
16
-
- A running Kubernetes cluster for the operator (the **local** cluster)
26
+
- A running Kubernetes cluster for the operator (the **operator** cluster)
17
27
- A separate Kubernetes cluster for the runtime workloads (the **runtime** cluster) — this is where kcp, OCM, and the PlatformMesh resource live
18
-
- Optionally, a third cluster for FluxCD or ArgoCD (the **infra** cluster) — if not provided, the local cluster serves this role
28
+
- Optionally, a third cluster for FluxCD or ArgoCD (the **infra** cluster) — if not provided, the operator cluster serves this role
Remote deployment is considered when the **Runtime** and **Infra** clusters are different. FluxCD HelmReleases receive a `kubeConfig.secretRef` that tells FluxCD to deploy workloads to the runtime cluster. ArgoCD Applications receive a `destination.server` pointing to the runtime cluster API.
47
61
48
62
## Step 1: Create a kubeconfig secret for the runtime cluster
49
63
50
-
Generate a kubeconfig that gives the operator access to the runtime cluster. Create a Secret on the **local** cluster:
64
+
Generate a kubeconfig that gives the operator access to the runtime cluster. Create a Secret on the **operator** cluster:
@@ -69,7 +83,7 @@ This secret is referenced by every HelmRelease via `spec.kubeConfig.secretRef`.
69
83
70
84
## Step 3: (Optional) Create a kubeconfig secret for the infra cluster
71
85
72
-
If the operator does not run on the infra cluster (that is, **Local** != **Infra**), create a Secret on the local cluster with credentials to reach the infra cluster:
86
+
If the operator does not run on the infra cluster (that is, **Operator** != **Infra**), create a Secret on the operator cluster with credentials to reach the infra cluster:
| `kcp` | kcp workspace topology: provider connections, extra workspaces, API bindings |
69
-
| `values` | Free-form JSON deep-merged with the profile's `components` section and passed as Helm values to each service |
70
-
| `infraValues` | Free-form JSON merged with the profile's `infra` section |
69
+
| `values` | Free-form JSON merged with the profile's `components` section and passed as Helm values to each service. The merge is recursive — keys present in both the profile and `spec.values` are combined per nested level, and any leaf value in `spec.values` wins over the profile |
70
+
| `infraValues` | Free-form JSON recursively merged with the profile's `infra` section (same merge semantics as `values`) |
71
71
| `ocm` | OCM repository, component name, and reference path for component delivery |
72
72
| `profileConfigMap` | Optional reference to profile ConfigMap (name/namespace). Defaults to `<instance-name>-profile` in the instance namespace |
73
73
| `featureToggles` | List of named feature flags (see [Feature toggles](#feature-toggles)) |
@@ -263,7 +263,7 @@ Remote deployment is used when the **Runtime** cluster (KCP, OCM) and the **Infr
0 commit comments