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
This guide walks through the full lifecycle of managing platform resources with ArgoCD, covering platform installation, cluster connections, project creation, and virtual cluster deployment. Each section references the detailed documentation for that step and provides the ArgoCD-specific configuration needed.
10
+
This guide walks through the full lifecycle of managing platform resources with ArgoCD, covering platform installation, cluster connections, project creation, and tenant cluster deployment. Each section references the detailed documentation for that step and provides the ArgoCD-specific configuration needed.
11
11
12
12
:::info
13
13
While this guide uses ArgoCD as the example, the same principles apply to other GitOps tools like Flux. Each section links to detailed documentation that includes tabs for alternative tooling.
@@ -79,9 +79,9 @@ ArgoCD does not deploy the Helm release secret. Platform configuration updates m
79
79
80
80
For the full set of Helm configuration options and alternative installation methods, see the [platform installation with ArgoCD guide](../install/gitops.mdx).
81
81
82
-
## 2. Connect a host cluster
82
+
## 2. Connect a control plane cluster
83
83
84
-
After the platform is running, connect host clusters where virtual clusters will be deployed. In a GitOps workflow, you can manage connected clusters as Kubernetes resources alongside your platform installation.
84
+
After the platform is running, connect control plane clusters where tenant clusters will be deployed. In a GitOps workflow, you can manage connected clusters as Kubernetes resources alongside your platform installation.
85
85
86
86
Each connected cluster requires two resources: a Cluster object and a Secret containing the cluster credentials.
87
87
@@ -181,7 +181,7 @@ For interactive setup methods using the UI or CLI, see the [connect a cluster gu
181
181
182
182
## 3. Create a project
183
183
184
-
Projects organize virtual clusters and control access, templates, and quotas. In a GitOps workflow, define projects as Project custom resources.
184
+
Projects organize tenant clusters and control access, templates, and quotas. In a GitOps workflow, define projects as Project custom resources.
185
185
186
186
<InterpolatedCodeBlock
187
187
code={`apiVersion: management.loft.sh/v1
@@ -211,7 +211,7 @@ spec:
211
211
212
212
### Enable ArgoCD integration on the project
213
213
214
-
To sync virtual clusters into ArgoCD as deployment targets, enable the ArgoCD integration on the project. This is configured through the project spec and allows virtual clusters to appear as available clusters in the ArgoCD UI.
214
+
To sync tenant clusters into ArgoCD as deployment targets, enable the ArgoCD integration on the project. This is configured through the project spec and allows tenant clusters to appear as available clusters in the ArgoCD UI.
215
215
216
216
See the [ArgoCD integration guide](../integrations/argocd.mdx) for UI-based setup and configuration of SSO integration and App Project mapping.
217
217
@@ -221,9 +221,9 @@ Define resources using the `management.loft.sh` API group. The `storage.loft.sh`
221
221
222
222
For interactive project creation using the UI, see the [create a project guide](../administer/projects/create.mdx).
223
223
224
-
## 4. Deploy virtual clusters
224
+
## 4. Deploy tenant clusters
225
225
226
-
With the platform, cluster, and project in place, deploy virtual clusters through ArgoCD. There are two approaches depending on how you want to manage the virtual cluster lifecycle.
226
+
With the platform, cluster, and project in place, deploy tenant clusters through ArgoCD. There are two approaches depending on how you want to manage the tenant cluster lifecycle.
227
227
228
228
### Option A: Deploy with VirtualClusterInstance
229
229
@@ -258,12 +258,12 @@ spec:
258
258
/>
259
259
260
260
:::tip
261
-
The namespace follows the pattern `loft-p-<project-name>`. The platform uses this convention to associate virtual clusters with projects.
261
+
The namespace follows the pattern `loft-p-<project-name>`. The platform uses this convention to associate tenant clusters with projects.
262
262
:::
263
263
264
264
### Option B: Deploy with Helm chart directly
265
265
266
-
Deploy the vCluster Helm chart through an ArgoCD Application. This approach gives you direct control over the Helm release but does not provide platform lifecycle features unless you [register the virtual cluster afterward](../use-platform/virtual-clusters/add-virtual-clusters.mdx).
266
+
Deploy the vCluster Helm chart through an ArgoCD Application. This approach gives you direct control over the Helm release but does not provide platform lifecycle features unless you [register the tenant cluster afterward](../use-platform/virtual-clusters/add-virtual-clusters.mdx).
267
267
268
268
<InterpolatedCodeBlock
269
269
code={`apiVersion: argoproj.io/v1alpha1
@@ -335,6 +335,6 @@ platform-gitops/
335
335
## Next steps
336
336
337
337
-[Configure platform settings](../configure/introduction.mdx) for authentication, audit logging, and more
338
-
-[Set up templates](../administer/templates/create-templates.mdx) to standardize virtual cluster configurations
338
+
-[Set up templates](../administer/templates/create-templates.mdx) to standardize tenant cluster configurations
339
339
-[Configure project quotas](../administer/projects/quotas.mdx) to control resource usage
340
-
-[Enable sleep mode](/docs/vcluster/manage/sleep-wakeup) to reduce costs on idle virtual clusters
340
+
-[Enable sleep mode](/docs/vcluster/manage/sleep-wakeup) to reduce costs on idle tenant clusters
to create a unique name. Optionally, the `--upgrade` flag can be used to reuse an existing virtual cluster instead of creating a new one.
60
+
to create a unique name. Optionally, the `--upgrade` flag can be used to reuse an existing tenant cluster instead of creating a new one.
61
61
4. Next `before_script` installs some additional tooling needed to run the end-to-end tests. For
62
62
more complex scenarios creating a custom image is recommended.
63
63
5. Then the `script` section uses `kubectl` to deploy the application to the space and waits for
64
64
the `my-app` deployment to become ready. `make` is then used to run an end-to-end test suite.
65
-
6. Finally `after_script` deletes the virtual cluster, and passes `--delete-namespace` to ensure the
66
-
corresponding namespace for the virtual cluster is deleted. By using `after_script` we can ensure the virtual cluster
67
-
is deleted even if the tests fail. You may wish to skip this step if reusing the virtual cluster with the `--upgrade` flag when creating the virtual cluster.
65
+
6. Finally `after_script` deletes the tenant cluster, and passes `--delete-namespace` to ensure the
66
+
corresponding namespace for the tenant cluster is deleted. By using `after_script` we can ensure the tenant cluster
67
+
is deleted even if the tests fail. You may wish to skip this step if reusing the tenant cluster with the `--upgrade` flag when creating the tenant cluster.
0 commit comments