Merge pull request #3001 from replicatedhq/hide-v2-arch-diagrams

paigecalvert · web-flow · commit 7fcd06bc1575 · 2025-01-27T10:49:43.000-07:00
Hide v2 arch diagrams
diff --git a/docs/enterprise/installing-embedded-air-gap.mdx b/docs/enterprise/installing-embedded-air-gap.mdx
@@ -92,7 +92,7 @@ To install with Embedded Cluster in an air gap environment:
 
 1. When prompted, enter a password for accessing the KOTS Admin Console.
 
-     The installation command takes a few minutes to complete. During installation, Embedded Cluster completes tasks to prepare the cluster and install KOTS in the cluster. Embedded Cluster also automatically runs a default set of [_host preflight checks_](/vendor/embedded-overview#about-host-preflight-checks) which verify that the environment meets the requirements for the installer.
+     The installation command takes a few minutes to complete. During installation, Embedded Cluster completes tasks to prepare the cluster and install KOTS in the cluster. Embedded Cluster also automatically runs a default set of [_host preflight checks_](/vendor/embedded-using#about-host-preflight-checks) which verify that the environment meets the requirements for the installer.
 
       **Example output:**
 
diff --git a/docs/enterprise/installing-embedded.mdx b/docs/enterprise/installing-embedded.mdx
@@ -10,7 +10,7 @@ Before you install, complete the following prerequisites:
 
 <Prerequisites/>
 
-* Ensure that the required domains are accessible from servers performing the installation. See [Firewall Openings for Online Installations](/enterprise/installing-embedded-requirements#firewall-openings-for-online-installations).
+* Ensure that the required domains are accessible from servers performing the installation. See [Firewall Openings for Online Installations](/enterprise/installing-embedded-requirements#firewall).
 
 ## Install
 
@@ -54,7 +54,7 @@ To install an application with Embedded Cluster:
 
 1. When prompted, enter a password for accessing the KOTS Admin Console.
 
-     The installation command takes a few minutes to complete. During installation, Embedded Cluster completes tasks to prepare the cluster and install KOTS in the cluster. Embedded Cluster also automatically runs a default set of [_host preflight checks_](/vendor/embedded-overview#about-host-preflight-checks) which verify that the environment meets the requirements for the installer.
+     The installation command takes a few minutes to complete. During installation, Embedded Cluster completes tasks to prepare the cluster and install KOTS in the cluster. Embedded Cluster also automatically runs a default set of [_host preflight checks_](/vendor/embedded-using#about-host-preflight-checks) which verify that the environment meets the requirements for the installer.
 
       **Example output:**
 
diff --git a/docs/intro-replicated.mdx b/docs/intro-replicated.mdx
@@ -51,7 +51,7 @@ Replicated Embedded Cluster is a Kubernetes installer based on the open source K
 
 Additionally, each version of Embedded Cluster includes a specific version of [Replicated KOTS](#kots) that is installed in the cluster during installation. KOTS is used by Embedded Cluster to deploy the application and also provides the Admin Console UI where users can manage both the application and the cluster.
 
-For more information, see [Using Embedded Cluster](/vendor/embedded-overview).
+For more information, see [Embedded Cluster Overview](/vendor/embedded-overview).
 
 ### KOTS (Admin Console) {#kots}
 
@@ -147,7 +147,7 @@ For more information about working with customers and custom license fields, see
 
 Applications distributed with the Replicated Platform can support multiple different installation methods from the same application release, helping you to meet your customers where they are. For example:
 
-* Customers who are not experienced with Kubernetes or who prefer to deploy to a dedicated cluster in their environment can install on a VM or bare metal server with the Replicated Embedded Cluster installer. For more information, see [Using Embedded Cluster](/vendor/embedded-overview).
+* Customers who are not experienced with Kubernetes or who prefer to deploy to a dedicated cluster in their environment can install on a VM or bare metal server with the Replicated Embedded Cluster installer. For more information, see [Embedded Cluster Overview](/vendor/embedded-overview).
 * Customers familiar with Kubernetes and Helm can install in their own existing cluster using Helm. For more information, see [Installing with Helm](/vendor/install-with-helm).
 * Customers installing into environments with limited or no outbound internet access (often referred to as air-gapped environments) can securely access and push images to their own internal registry, then install using Helm or a Replicated installer. For more information, see [Air Gap Installation with Embedded Cluster](/enterprise/installing-embedded-air-gap) and [Installing and Updating with Helm in Air Gap Environments (Alpha)](/vendor/helm-install-airgap).
 
diff --git a/docs/intro.md b/docs/intro.md
@@ -145,7 +145,7 @@ pagination_next: null
         <p>Embed Kubernetes with your application to support installations on VMs or bare metal servers.</p>
     </li>
     <li>
-      <a href="/vendor/embedded-overview">Using Embedded Cluster</a>
+      <a href="/vendor/embedded-overview">Embedded Cluster Overview</a>
     </li>
     <li>
       <a href="/enterprise/installing-embedded">Installing with Embedded Cluster</a>
diff --git a/docs/vendor/ci-workflows.mdx b/docs/vendor/ci-workflows.mdx
@@ -299,4 +299,4 @@ Consider the following requirements and recommendations:
 
 Finally, add a job to archive the temporary channel and customer that you created. This ensures that these artifacts are removed from your Replicated team and that they do not have to be manually archived after the release is promoted.
 
-See the [channel delete](/reference/replicated-cli-channel-delete) Replicated CLI command and the [customer/\{customer_id\}/archive](https://replicated-vendor-api.readme.io/reference/archivecustomer) endpoint in the Vendor API v3 documentation. Or, for GitHub Actions workflows, see the [archive-channel](https://github.com/replicatedhq/replicated-actions/tree/main/archive-channel) and [archive-customer](https://github.com/replicatedhq/replicated-actions/tree/main/archive-customer) actions.
+See the [channel rm](/reference/replicated-cli-channel-rm) Replicated CLI command and the [customer/\{customer_id\}/archive](https://replicated-vendor-api.readme.io/reference/archivecustomer) endpoint in the Vendor API v3 documentation. Or, for GitHub Actions workflows, see the [archive-channel](https://github.com/replicatedhq/replicated-actions/tree/main/archive-channel) and [archive-customer](https://github.com/replicatedhq/replicated-actions/tree/main/archive-customer) actions.
diff --git a/docs/vendor/embedded-overview.mdx b/docs/vendor/embedded-overview.mdx
@@ -14,7 +14,7 @@ If you are instead looking for information about creating Kubernetes Installers
 
 <EmbeddedCluster/>
 
-## Architecture and Built-In Extensions
+{/* [V2 ARCHITECTURE CONTENT] ## Architecture and Built-In Extensions
 
 This section describes the Embedded Cluster architecture, including the built-in extensions deployed by Embedded Cluster.
 
@@ -30,7 +30,11 @@ As shown in the diagram above, the user downloads the Embedded Cluster installat
 
 When the user runs the Embedded Cluster install command, the Embedded Cluster binary first installs the k0s cluster as a systemd service. This systemd service is named using the slug of the application (for example, `gitea`).
 
-After all the Kubernetes components for the cluster are available, the Embedded Cluster binary then installs the Embedded Cluster built-in extensions and any Helm extensions that were included in the [`extensions`](/reference/embedded-config#extensions) field of the Embedded Cluster Config. Each built-in extension is installed in its own namespace. The namespace or namespaces where Helm extensions are installed is defined by the vendor in the Embedded Cluster Config.
+After all the Kubernetes components for the cluster are available, the Embedded Cluster binary then installs the Embedded Cluster built-in extensions and any Helm extensions that were included in the [`extensions`](/reference/embedded-config#extensions) field of the Embedded Cluster Config. Each built-in extension is installed in its own namespace. The namespace or namespaces where Helm extensions are installed is defined by the vendor in the Embedded Cluster Config. */}
+
+## Embedded Cluster Built-In Extensions
+
+Embedded Cluster deploys built-in extensions to provide capabilities such as application management and storage. These extensions are deployed by default and do not require configuration.
 
 The built-in extensions include:
 
@@ -42,7 +46,7 @@ The built-in extensions include:
 
 * **(Air Gap Only) Image registry:** For air gap installations in environments with limited or no outbound internet access, Embedded Cluster installs an image registry where the images required to install and run the application are pushed. For more information about installing in air-gapped environments, see [Air Gap Installation with Embedded Cluster](/enterprise/installing-embedded-air-gap).
 
-Finally, after the built-in extensions and any Helm extensions are installed, The Embedded Cluster binary deploys a second systemd service on the node named `APP_SLUG-manager` (for example, `gitea-manager`). This manager service orchestrates Embedded Cluster and communicates with the KOTS instance running in the cluster through a websocket.
+{/* [V2 ARCHITECTURE CONTENT] Finally, after the built-in extensions and any Helm extensions are installed, The Embedded Cluster binary deploys a second systemd service on the node named `APP_SLUG-manager` (for example, `gitea-manager`). This manager service orchestrates Embedded Cluster and communicates with the KOTS instance running in the cluster through a websocket.
 
 ### Multi-Node Architecture
 
@@ -58,7 +62,7 @@ High availability (HA) for multi-node installations with Embedded Cluster is Alp
 
 As shown in the diagram above, in multi-node installations, an instance of the Embedded Cluster manager systemd service runs on each node and communicates with the KOTS instance running on the primary node through a websocket. This allows Embedded Cluster and KOTS to manage installations where workloads are running on multiple nodes in a cluster.
 
-Additionally, for installations that include disaster recovery with Velero, the Velero Node Agent also runs on each node in the cluster. The Node Agent is a Kubernetes DaemonSet that performs backup and restore tasks such as creating snapshots and transferring data during restores.
+Additionally, for installations that include disaster recovery with Velero, the Velero Node Agent also runs on each node in the cluster. The Node Agent is a Kubernetes DaemonSet that performs backup and restore tasks such as creating snapshots and transferring data during restores. */}
 
 ## Comparison to kURL
 
diff --git a/docs/vendor/embedded-using.mdx b/docs/vendor/embedded-using.mdx
@@ -98,7 +98,7 @@ During installation, Embedded Cluster automatically runs a default set of _host
 * The system has at least 2G of memory and 2 CPU cores
 * The system clock is synchronized
 
-For Embedded Cluster requirements, see [Requirements](#requirements). For the full default host preflight spec for Embedded Cluster, see [`host-preflight.yaml`](https://github.com/replicatedhq/embedded-cluster/blob/main/pkg/preflights/host-preflight.yaml) in the `embedded-cluster` repository in GitHub.
+For Embedded Cluster requirements, see [Embedded Cluster Installation Requirements](/enterprise/installing-embedded-requirements). For the full default host preflight spec for Embedded Cluster, see [`host-preflight.yaml`](https://github.com/replicatedhq/embedded-cluster/blob/main/pkg/preflights/host-preflight.yaml) in the `embedded-cluster` repository in GitHub.
 
 If any of the host preflight checks fail, installation is blocked and a message describing the failure is displayed. For more information about host preflight checks for installations on VMs or bare metal servers, see [About Host Preflights](preflight-support-bundle-about#host-preflights).
 
diff --git a/docs/vendor/kots-faq.mdx b/docs/vendor/kots-faq.mdx
@@ -138,15 +138,15 @@ Replicated Embedded Cluster is a successor to Replicated kURL. Compared to kURL,
 
 <KurlAvailability/>
 
-For more information, see [Using Embedded Cluster](/vendor/embedded-overview).
+For more information, see [Embedded Cluster Overview](/vendor/embedded-overview).
 
 ### How do I enable Embedded Cluster and KOTS installations for my application?
 
 Releases that support installation with KOTS include the manifests required by KOTS to define the Admin Console experience and install the application.
 
 In addition to the KOTS manifests, releases that support installation with Embedded Cluster also include the Embedded Cluster Config. The Embedded Cluster Config defines aspects of the cluster that will be provisioned and also sets the version of KOTS that will be installed.
 
-For more information, see [Using Embedded Cluster](/vendor/embedded-overview).
+For more information, see [Embedded Cluster Overview](/vendor/embedded-overview).
 
 ### Can I use my own branding?
 
diff --git a/docs/vendor/licenses-about-types.md b/docs/vendor/licenses-about-types.md
@@ -1,6 +1,6 @@
 # About Community Licenses
 
-This topic describes community licenses. For more information about other types of licenses, see [License Types](licenses-about#license-types) in _About Customers_.
+This topic describes community licenses. For more information about other types of licenses, see [Customer Types](licenses-about#customer-types) in _About Customers_.
 
 ## Overview
 
diff --git a/docs/vendor/licenses-about.mdx b/docs/vendor/licenses-about.mdx
@@ -102,9 +102,9 @@ From the **Customers** page, you can do the following:
 * Archive customers. For more information, see [Creating and Managing Customers](releases-creating-customer).
 
 * Click on a customer on the **Customers** page to access the following customer-specific pages:
-  * [Reporting](#reporting-page)
-  * [Manage customer](#manage-customer-page)
-  * [Support bundles](#support-bundles-page)
+  * [Reporting](#about-the-customer-reporting-page)
+  * [Manage customer](#about-the-manage-customer-page)
+  * [Support bundles](#about-the-customer-support-bundles-page)
 
 ### About the Customer Reporting Page
 
@@ -163,7 +163,7 @@ For more information, see [Updating Licenses in the Admin Console](/enterprise/u
 
 The [Replicated SDK](replicated-sdk-overview) includes an in-cluster API that can be used to retrieve up-to-date customer license information from the Vendor Portal during runtime through the [`license`](/reference/replicated-sdk-apis#license) endpoints. This means that you can add logic to your application to get the latest license information without the customer needing to perform a license update. The SDK API polls the Vendor Portal for updated data every four hours.
 
-In KOTS installations that include the SDK, users need to update their licenses from the Admin Console as described in [License Updates with KOTS](#license-updates-with-kots) above. However, any logic in your application that uses the SDK API will update the user's license information without the customer needing to deploy a license update in the Admin Console.
+In KOTS installations that include the SDK, users need to update their licenses from the Admin Console as described in [About Syncing Licenses](#about-syncing-licenses) above. However, any logic in your application that uses the SDK API will update the user's license information without the customer needing to deploy a license update in the Admin Console.
 
 For information about how to use the SDK API to query license entitlements at runtime, see [Querying Entitlements with the Replicated SDK API](/vendor/licenses-reference-sdk).
 
diff --git a/docs/vendor/preflight-host-preflights.md b/docs/vendor/preflight-host-preflights.md
@@ -1,6 +1,6 @@
 # Customizing Host Preflight Checks for kURL
 
-This topic provides information about how to customize host preflight checks for installations with Replicated kURL. For information about the default host preflight checks that run for installations with Replicated Embedded Cluster, see [About Host Preflight Checks](/vendor/embedded-overview#about-host-preflight-checks) in _Using Embedded Cluster_.
+This topic provides information about how to customize host preflight checks for installations with Replicated kURL. For information about the default host preflight checks that run for installations with Replicated Embedded Cluster, see [About Host Preflight Checks](/vendor/embedded-using#about-host-preflight-checks) in _Using Embedded Cluster_.
 
 ## About Host Preflight Checks
 You can include host preflight checks with kURL to verify that infrastructure requirements are met for:
diff --git a/docs/vendor/preflight-support-bundle-about.mdx b/docs/vendor/preflight-support-bundle-about.mdx
@@ -63,7 +63,7 @@ _Host preflight checks_ automatically run during [Replicated Embedded Cluster](/
 
 Host preflight checks are separate from any application-specific preflight checks that are defined in the release, which run in the Admin Console before the application is deployed with KOTS. Both Embedded Cluster and kURL have default host preflight checks that are specific to the requirements of the given installer. For kURL installations, it is possible to customize the default host preflight checks.
 
-For more information about the default Embedded Cluster host preflight checks, see [Host Preflight Checks](/vendor/embedded-overview#about-host-preflight-checks) in _Using Embedded Cluster_.
+For more information about the default Embedded Cluster host preflight checks, see [Host Preflight Checks](/vendor/embedded-using#about-host-preflight-checks) in _Using Embedded Cluster_.
 
 For more information about kURL host preflight checks, including information about how to customize the defaults, see [Customizing Host Preflight Checks for kURL](/vendor/preflight-host-preflights).
 
diff --git a/docs/vendor/releases-creating-channels.md b/docs/vendor/releases-creating-channels.md
@@ -67,4 +67,4 @@ To archive a channel with the Vendor Portal or the Replicated CLI:
      ```
      Replace `CHANNEL_ID` with the channel ID that you retrieved in the previous step.
 
-     For more information, see [channel delete](/reference/replicated-cli-channel-delete) in the Replicated CLI documentation.
+     For more information, see [channel rm](/reference/replicated-cli-channel-rm) in the Replicated CLI documentation.
diff --git a/docs/vendor/releases-creating-customer.mdx b/docs/vendor/releases-creating-customer.mdx
@@ -56,7 +56,7 @@ To create a customer:
 
 ## Edit a Customer
 
-You can edit the built-in and custom license fields for a customer at any time by going to the **Manage customer** for a customer. For more information, see [Manage Customer Page](licenses-about#manage-customer-page) in _About Customers_.
+You can edit the built-in and custom license fields for a customer at any time by going to the **Manage customer** for a customer. For more information, see [Manage Customer Page](licenses-about#about-the-manage-customer-page) in _About Customers and Licensing_.
    
 Replicated recommends that you test any licenses changes in a development environment. If needed, install the application using a developer license matching the current customer's entitlements before editing the developer license. Then validate the updated license.
 
diff --git a/docs/vendor/testing-supported-clusters.md b/docs/vendor/testing-supported-clusters.md
@@ -209,7 +209,7 @@ By default, kubeconfig context is set to the `kubeadmin` user. To switch to the
 
 ### Embedded Cluster
 
-Compatibility Matrix supports creating clusters with Replicated Embedded Cluster. For more information, see [Using Embedded Cluster](/vendor/embedded-overview).
+Compatibility Matrix supports creating clusters with Replicated Embedded Cluster. For more information, see [Embedded Cluster Overview](/vendor/embedded-overview).
 
 <table>
   <tr>
diff --git a/docs/vendor/tutorial-embedded-cluster-install.mdx b/docs/vendor/tutorial-embedded-cluster-install.mdx
@@ -101,11 +101,11 @@ To install the release with Embedded Cluster:
 
 ## Summary
 
-Congratulations! As part of this tutorial, you created a release in the Replicated Vendor Portal and installed the release with Replicated Embedded Cluster in a VM. To learn more about Embedded Cluster, see [Using Embedded Cluster](embedded-overview).
+Congratulations! As part of this tutorial, you created a release in the Replicated Vendor Portal and installed the release with Replicated Embedded Cluster in a VM. To learn more about Embedded Cluster, see [Embedded Cluster Overview](embedded-overview).
 
 ## Related Topics
 
-* [Using Embedded Cluster](embedded-overview)
+* [Embedded Cluster Overview](embedded-overview)
 * [Customer Reporting](/vendor/customer-reporting)
 * [Instance Details](/vendor/instance-insights-details)
-* [Reset a Node](/vendor/embedded-overview#reset-a-node)
+* [Reset a Node](/vendor/embedded-using#reset-a-node)

Original file line number	Diff line number	Diff line change
`@@ -299,4 +299,4 @@ Consider the following requirements and recommendations:`
`299`	`299`
`300`	`300`	`Finally, add a job to archive the temporary channel and customer that you created. This ensures that these artifacts are removed from your Replicated team and that they do not have to be manually archived after the release is promoted.`
`301`	`301`
`302`		`-See the [channel delete](/reference/replicated-cli-channel-delete) Replicated CLI command and the [customer/\{customer_id\}/archive](https://replicated-vendor-api.readme.io/reference/archivecustomer) endpoint in the Vendor API v3 documentation. Or, for GitHub Actions workflows, see the [archive-channel](https://github.com/replicatedhq/replicated-actions/tree/main/archive-channel) and [archive-customer](https://github.com/replicatedhq/replicated-actions/tree/main/archive-customer) actions.`
	`302`	`+See the [channel rm](/reference/replicated-cli-channel-rm) Replicated CLI command and the [customer/\{customer_id\}/archive](https://replicated-vendor-api.readme.io/reference/archivecustomer) endpoint in the Vendor API v3 documentation. Or, for GitHub Actions workflows, see the [archive-channel](https://github.com/replicatedhq/replicated-actions/tree/main/archive-channel) and [archive-customer](https://github.com/replicatedhq/replicated-actions/tree/main/archive-customer) actions.`