Move EC to top level

docs/enterprise/cluster-management-add-nodes.md

@@ -1,10 +1,10 @@
 # Adding Nodes to kURL Clusters
 
-This topic describes how to add primary and secondary nodes to an embedded cluster provisioned with Replicated kURL.
+This topic describes how to add primary and secondary nodes to a Replicated kURL cluster.
 
 ## Overview
 
-You can generate commands in the Replicated KOTS Admin Console to join additional primary and secondary nodes to embedded kURL clusters. Primary nodes run services that control the cluster. Secondary nodes run services that control the pods that host the application containers. Adding nodes can help manage resources to ensure that the application runs smoothly.
+You can generate commands in the Replicated KOTS Admin Console to join additional primary and secondary nodes to kURL clusters. Primary nodes run services that control the cluster. Secondary nodes run services that control the pods that host the application containers. Adding nodes can help manage resources to ensure that the application runs smoothly.
 
 For high availability clusters, Kubernetes recommends using at least three primary nodes, and that you use an odd number of nodes to help with leader selection if machine or zone failure occurs. For more information, see [Creating Highly Available Clusters with kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) in the Kubernetes documentation.
 

docs/enterprise/delete-admin-console.md

@@ -1,16 +1,20 @@
 # Deleting the Admin Console and Removing Applications
 
-This topic describes how to remove installed applications and delete the Replicated Admin Console from a cluster. See the following sections:
-* [Remove an Application](#remove-an-application)
-* [Delete the Admin Console](#delete-the-admin-console)
+This topic describes how to remove installed applications and delete the Replicated Admin Console from a cluster.
 
 ## Remove an Application
 
+This section describes how to remove an application instance that was installed with KOTS in an existing cluster.
+
+### About Removing an Installed Application Instance
+
 The Replicated KOTS CLI `kots remove` command removes the reference to an installed application from the Admin Console. When you use `kots remove`, the Admin Console no longer manages the application because the record of that application’s installation is removed. This means that you can no longer manage the application through the Admin Console or through the KOTS CLI.
 
 By default, `kots remove` does not delete any of the installed Kubernetes resources for the application from the cluster. To remove both the reference to an application from the Admin Console and remove any resources for the application from the cluster, you can run `kots remove` with the `--undeploy` flag.
 
 It can be useful to remove only the reference to an application from the Admin Console if you want to reinstall the application, but you do not want to recreate the namespace or other Kubernetes resources. For example, if you installed an application using an incorrect license file and need to reinstall with the correct license.
+
+### Procedure
 
 To remove an application:
 
@@ -46,43 +50,39 @@ To remove an application:
 
 ## Delete the Admin Console
 
-When you install an application with the Admin Console, Replicated KOTS also creates the Kubernetes resources for the Admin Console itself on the cluster. The Admin Console includes Deployments and Services, Secrets, and other resources such as StatefulSets and PersistentVolumeClaims.
-
-By default, KOTS also creates Kubernetes ClusterRole and ClusterRoleBinding resources that grant permissions to the Admin Console on the cluster level. These `kotsadm-role` and `kotsadm-rolebinding` resources are managed outside of the namespace where the Admin Console is installed. Alternatively, when the Admin Console is installed with namespace-scoped access, KOTS creates Role and RoleBinding resources inside the namespace where the Admin Console is installed.
-
-If you need to completely delete the Admin Console and an application installation, such as during testing, follow one of these procedures depending on the type of cluster where you installed the Admin Console:
-
-* **Existing cluster**: Manually delete the Admin Console Kubernetes objects and resources from the cluster. See [Delete from an Existing Cluster](#existing) below.
-* **Embedded cluster**: Remove Kubernetes from the VM where the cluster is installed. See [Delete from an Embedded Cluster](#embedded) below.
+This section describes how to remove the KOTS Admin Console from an existing cluster.
 
-:::note
-These procedures do not uninstall the KOTS CLI. To uninstall the KOTS CLI, see [Uninstall](https://docs.replicated.com/reference/kots-cli-getting-started#uninstall) in _Installing the KOTS CLI_.
-:::
+### About Deleting the Admin Console from an Existing Cluster
 
-### Delete from an Existing Cluster {#existing}
+When you install an application, KOTS creates the Kubernetes resources for the Admin Console itself on the cluster. The Admin Console includes Deployments and Services, Secrets, and other resources such as StatefulSets and PersistentVolumeClaims.
 
-In existing cluster installations, if the Admin Console is not installed in the `default` namespace, then you delete the Admin Console by deleting the namespace where it is installed. 
+By default, KOTS also creates Kubernetes ClusterRole and ClusterRoleBinding resources that grant permissions to the Admin Console on the cluster level. These `kotsadm-role` and `kotsadm-rolebinding` resources are managed outside of the namespace where the Admin Console is installed. Alternatively, when the Admin Console is installed with namespace-scoped access, KOTS creates Role and RoleBinding resources inside the namespace where the Admin Console is installed.
 
-If you installed the Admin Console with namespace-scoped access, then the Admin Console Role and RoleBinding RBAC resources are also deleted when you delete the namespace. Alternatively, if you installed with the default cluster-scoped access, then you manually delete the Admin Console ClusterRole and ClusterRoleBindings resources from the cluster.
+In existing cluster installations, if the Admin Console is not installed in the `default` namespace, then you delete the Admin Console by deleting the namespace where it is installed.
 
-The application vendor can require, support, or not support namespace-scoped installations. For more information, see [supportMinimalRBACPrivileges](/reference/custom-resource-application#supportminimalrbacprivileges) and [requireMinimalRBACPrivileges](/reference/custom-resource-application#requireminimalrbacprivileges) in _Application_.
+If you installed the Admin Console with namespace-scoped access, then the Admin Console Role and RoleBinding RBAC resources are also deleted when you delete the namespace. Alternatively, if you installed with the default cluster-scoped access, then you manually delete the Admin Console ClusterRole and ClusterRoleBindings resources from the cluster. For more information, see [supportMinimalRBACPrivileges](/reference/custom-resource-application#supportminimalrbacprivileges) and [requireMinimalRBACPrivileges](/reference/custom-resource-application#requireminimalrbacprivileges) in _Application_.
 
 For more information about installing with cluster- or namespace-scoped access, see [RBAC Requirements](/enterprise/installing-general-requirements#rbac-requirements) in _Installation Requirements_.
 
-To delete the Admin Console from an existing cluster:
+### Procedure
+
+To completely delete the Admin Console from an existing cluster:
 
 1. Run the following command to delete the namespace where the Admin Console is installed:
 
-   :::note
-   * You cannot delete the `default` namespace.
-   * This command deletes everything inside the specified namespace, including the Admin Console Role and RoleBinding resources if you installed with namespace-scoped access.
+   :::important
+   This command deletes everything inside the specified namespace, including the Admin Console Role and RoleBinding resources if you installed with namespace-scoped access.
    :::
 
    ```
    kubectl delete ns NAMESPACE
    ```
    Replace `NAMESPACE` with the name of the namespace where the Admin Console is installed.
 
+   :::note
+   You cannot delete the `default` namespace.
+   :::
+
 1. (Cluster-scoped Access Only) If you installed the Admin Console with the default cluster-scoped access, run the following commands to delete the Admin Console ClusterRole and ClusterRoleBinding from the cluster:
 
    ```
@@ -93,28 +93,4 @@ To delete the Admin Console from an existing cluster:
    kubectl delete clusterrolebinding kotsadm-rolebinding
    ```
 
-### Delete from an Embedded Cluster {#embedded}
-
-If you installed on a cluster created by Replicated kURL, KOTS installs the Admin Console in the `default` namespace. Kubernetes does not allow the `default` namespace to be deleted.
-
-To delete the Admin Console from an embedded cluster, use the kURL `tasks.sh` `reset` command to remove Kubernetes from the system.
-
-:::important
-The `reset` command is intended to be used only on development servers. It has the potential to leave your machine in an unrecoverable state. It is not recommended unless you are able to discard this server and provision a new one.
-:::
-
-Instead of using the `reset` command, you can also discard your current VM (if you are using one) and recreate the VM with a new OS to reinstall the Admin Console and an application.
-
-For more information about the `reset` command, see [Resetting a Node](https://kurl.sh/docs/install-with-kurl/managing-nodes#reset-a-node) in the kURL documentation.
-
-To delete the Admin Console from an embedded cluster:
-
-1. Run the following command to remove Kubernetes from the system:
-
-   ```
-   curl -sSL https://k8s.kurl.sh/latest/tasks.sh | sudo bash -s reset
-   ```
-
-1. Follow the instructions in the output of the command to manually remove any files that the `reset` command does not remove.
-
-If the `reset` command is unsuccessful, discard your current VM, and recreate the VM with a new OS to reinstall the Admin Console and an application.  
+1. (Optional) To uninstall the KOTS CLI, see [Uninstall](https://docs.replicated.com/reference/kots-cli-getting-started#uninstall) in _Installing the KOTS CLI_.   

docs/enterprise/image-registry-kurl.md

@@ -1,4 +1,4 @@
-# Image Registry for kURL Clusters
+# Working with the kURL Image Registry
 
 This topic describes the Replicated kURL registry for kURL clusters.
 
@@ -26,7 +26,7 @@ For more information, see [admin-console garbage-collect-images](/reference/kots
 
 ## Disable Image Garbage Collection
 
-Image garbage collection is enabled by default for embedded kURL clusters that use the kURL registry.
+Image garbage collection is enabled by default for kURL clusters that use the kURL registry.
 
 To disable image garbage collection:
 
@@ -56,8 +56,8 @@ The kURL registry image garbage collection feature has following limitations:
 
    To prevent this from happening, include the optional images in the `additionalImages` list of the Application custom resource. For more information, see [`additionalImages`](/reference/custom-resource-application#additionalimages) in _Application_.
 
-* **Shared Image Registries**: The image garbage collection process assumes that the registry is not shared with any other instances of Replicated KOTS, nor shared with any external applications. If the embedded kURL registry is used by another external application, disable garbage collection to prevent image loss.
+* **Shared Image Registries**: The image garbage collection process assumes that the registry is not shared with any other instances of Replicated KOTS, nor shared with any external applications. If the built-in kURL registry is used by another external application, disable garbage collection to prevent image loss.
 
-* **Customer Supplied Registries**: Image garbage collection is supported only when used with the embedded kURL registry. If the KOTS instance is configured to use a different registry, disable garbage collection to prevent image loss.
+* **Customer Supplied Registries**: Image garbage collection is supported only when used with the built-in kURL registry. If the KOTS instance is configured to use a different registry, disable garbage collection to prevent image loss.
 
 * **Application Rollbacks**: Image garbage collection has no effect when the `allowRollback` field in the KOTS Application custom resource is set to `true`. For more information, see [Application](/reference/custom-resource-application) in _KOTS Custom Resources_.

docs/enterprise/image-registry-settings.mdx

@@ -8,11 +8,11 @@ This topic describes how to configure private registry settings in the Replicate
 
 Using a private registry lets you create a custom image pipeline. Any proprietary configurations that you make to the application are shared only with the groups that you allow access, such as your team or organization. You also have control over the storage location, logging messages, load balancing requests, and other configuration options.
 
-Private registries can be used with online or air gap clusters. For embedded kURL clusters, if the Replicated kURL installer spec includes the kURL Registry add-on, then the embedded registry is used to host the application images. For more information about the kURL Registry add-on, see [Image Registry for kURL Clusters](image-registry-kurl).
+Private registries can be used with online or air gap clusters. For kURL clusters, if the Replicated kURL installer spec includes the kURL Registry add-on, then the built-in kURL registry is used to host the application images. For more information, see [Working with the kURL Image Registry](image-registry-kurl).
 
 ## Prerequisites
 
-Your domain must support a Docker V2 protocol. For more information, see [Private Registry Requirements](installing-general-requirements#private-registry-requirements) in _Installation Requirements_.
+Your domain must support a Docker V2 protocol. For more information, see [Compatible Image Registries](installing-general-requirements#registries) in _KOTS Installation Requirements_.
 
 ## Configure Private Registries in Online Clusters
 

docs/enterprise/installing-embedded-automation.mdx

@@ -0,0 +1,64 @@
+import ConfigValuesExample from "../partials/configValues/_configValuesExample.mdx"
+import ConfigValuesProcedure from "../partials/configValues/_config-values-procedure.mdx"
+
+# Installing with Embedded Cluster from the Command Line
+
+This topic describes how to install an application with Replicated Embedded Cluster from the command line.
+
+## Overview
+
+You can use the command line to install an application with Replicated Embedded Cluster. A common use case for installing from the command line is to automate installation, such as performing headless installations as part of CI/CD pipelines.
+
+To install from the command line, you provide all the necessary installation assets, such as the license file and the application config values, with the installation command rather than through the Admin Console UI. Any preflight checks defined for the application run automatically during headless installations from the command line rather than being displayed in the Admin Console.
+
+## Prerequisite
+
+Create a ConfigValues YAML file to define the configuration values for the application release. The ConfigValues file allows you to pass the configuration values for an application from the command line with the install command, rather than through the Admin Console UI. For air-gapped environments, ensure that the ConfigValues file can be accessed from the installation environment. 
+
+The KOTS ConfigValues file includes the fields that are defined in the KOTS Config custom resource for an application release, along with the user-supplied and default values for each field, as shown in the example below:
+
+<ConfigValuesExample/>
+
+<ConfigValuesProcedure/>
+
+## Online (Internet-Connected) Installation
+
+To install with Embedded Cluster in an online environment:
+
+1. Follow the steps provided in the Vendor Portal to download and untar the Embedded Cluster installation assets. For more information, see [Online Installation with Embedded Cluster](/enterprise/installing-embedded).
+
+1. Run the following command to install:
+
+    ```bash
+    sudo ./APP_SLUG install --license-file PATH_TO_LICENSE \
+      --config-values PATH_TO_CONFIGVALUES \
+      --admin-console-password ADMIN_CONSOLE_PASSWORD
+    ```
+
+    Replace:
+    * `APP_SLUG` with the unique slug for the application.
+    * `LICENSE_FILE` with the customer license.
+    * `ADMIN_CONSOLE_PASSWORD` with a password for accessing the Admin Console.
+    * `PATH_TO_CONFIGVALUES` with the path to the ConfigValues file.
+
+## Air Gap Installation
+
+To install with Embedded Cluster in an air-gapped environment:
+
+1. Follow the steps provided in the Vendor Portal to download and untar the Embedded Cluster air gap installation assets. For more information, see [Air Gap Installation with Embedded Cluster](/enterprise/installing-embedded-air-gap).
+
+1. Ensure that the Embedded Cluster installation assets are available on the air-gapped machine, then run the following command to install:
+
+    ```bash
+    sudo ./APP_SLUG install --license-file PATH_TO_LICENSE \
+      --config-values PATH_TO_CONFIGVALUES \
+      --admin-console-password ADMIN_CONSOLE_PASSWORD \
+      --airgap-bundle PATH_TO_AIRGAP_BUNDLE
+    ```
+
+    Replace:
+    * `APP_SLUG` with the unique slug for the application.
+    * `LICENSE_FILE` with the customer license.
+    * `PATH_TO_CONFIGVALUES` with the path to the ConfigValues file.
+    * `ADMIN_CONSOLE_PASSWORD` with a password for accessing the Admin Console.
+    * `PATH_TO_AIRGAP_BUNDLE` with the path to the Embedded Cluster `.airgap` bundle for the release.

docs/enterprise/installing-embedded-requirements.mdx

@@ -0,0 +1,19 @@
+import EmbeddedClusterRequirements from "../partials/embedded-cluster/_requirements.mdx"
+import EmbeddedClusterPortRequirements from "../partials/embedded-cluster/_port-reqs.mdx"
+import FirewallOpenings from "../partials/install/_firewall-openings.mdx"
+
+# Embedded Cluster Installation Requirements
+
+This topic lists the installation requirements for Replicated Embedded Cluster. Ensure that the installation environment meets these requirements before attempting to install.
+
+## System Requirements
+
+<EmbeddedClusterRequirements/>
+
+## Port Requirements
+
+<EmbeddedClusterPortRequirements/>
+
+## Firewall Openings for Online Installations
+
+<FirewallOpenings/>

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-general-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-openings-for-online-installations).
 
 ## Install
 

docs/enterprise/installing-existing-cluster-airgapped.mdx

@@ -14,7 +14,7 @@ import PushKotsImages from "../partials/install/_push-kotsadm-images.mdx"
 import PlaceholderRoCreds from "../partials/install/_placeholder-ro-creds.mdx"
 import KotsVersionMatch from "../partials/install/_kots-airgap-version-match.mdx"
 
-# Air Gap Installation in Existing Clusters
+# Air Gap Installation in Existing Clusters with KOTS
 
 <IntroExisting/>
 
@@ -26,7 +26,7 @@ Complete the following prerequisites:
 
 <PrereqsExistingCluster/>
 
-* Ensure that there is a compatible Docker image registry available inside the network. For more information about Docker registry compatibility, see [Private Registry Requirements](/enterprise/installing-general-requirements#private-registry-requirements).
+* Ensure that there is a compatible Docker image registry available inside the network. For more information about Docker registry compatibility, see [Compatible Image Registries](/enterprise/installing-general-requirements#registries).
 
     KOTS rewrites the application image names in all application manifests to read from the on-premises registry, and it re-tags and pushes the images to the on-premises registry. When authenticating to the registry, credentials with `push` permissions are required.