Merge branch 'main' into 114634

Author: paigecalvert

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-air-gap.mdx

@@ -94,30 +94,30 @@ To install with Embedded Cluster in an air gap environment:
 
      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.
 
-1. When the installation command completes, go to the URL provided in the output to access the Admin Console.
-     
-    **Example output:** 
+      **Example output:**
 
-    ```bash
-    ✔  Host files materialized
-    ? Enter an Admin Console password: ********
-    ? Confirm password: ********
-    ✔  Host files materialized!
-    ✔  Host preflights succeeded!
-    ✔  Node installation finished!
-    ✔  Storage is ready!
-    ✔  Embedded Cluster Operator is ready!
-    ✔  Admin Console is ready!
-    ✔  Additional components are ready!
-    Visit the admin console to configure and install gitea-kite: http://104.155.145.60:30000
-    ```
-    At this point, the cluster is provisioned and the KOTS Admin Console is deployed, but the application is not yet installed.
+      ```bash
+      ? Enter an Admin Console password: ********
+      ? Confirm password: ********
+      ✔  Host files materialized!
+      ✔  Running host preflights
+      ✔  Node installation finished!
+      ✔  Storage is ready!
+      ✔  Embedded Cluster Operator is ready!
+      ✔  Admin Console is ready!
+      ✔  Additional components are ready!
+      Visit the Admin Console to configure and install gitea-kite: http://104.155.145.60:30000
+      ```
+
+      At this point, the cluster is provisioned and the Admin Console is deployed, but the application is not yet installed.
+
+1. Go to the URL provided in the output to access to the Admin Console.
 
-1. Bypass the browser TLS warning by clicking **Continue to Setup**.
+1. On the Admin Console landing page, click **Start**.
 
-1. Click **Advanced > Proceed**.
+1. On the **Secure the Admin Console** screen, review the instructions and click **Continue**. In your browser, follow the instructions that were provided on the **Secure the Admin Console** screen to bypass the warning.
 
-1. On the HTTPS page, upload your own private key and certificacte or select **Self-signed**.
+1. On the **Certificate type** screen, either select **Self-signed** to continue using the self-signed Admin Console certificate or click **Upload your own** to upload your own private key and certificacte.
 
     By default, a self-signed TLS certificate is used to secure communication between your browser and the Admin Console. You will see a warning in your browser every time you access the Admin Console unless you upload your own certificate.
 
@@ -127,17 +127,11 @@ To install with Embedded Cluster in an air gap environment:
 
      Optionally, add nodes to the cluster before deploying the application. For more information about joining nodes, see [Adding and Managing Nodes with Embedded Cluster](/enterprise/embedded-manage-nodes). Click **Continue**.
 
-1. On the config screen, complete the fields for the application configuration options and then click **Continue**.
+1. On the **Configure [App Name]** screen, complete the fields for the application configuration options. Click **Continue**.
 
-1. On the **Preflight checks** page, the application-specific preflight checks run automatically. Preflight checks  are conformance tests that run against the target namespace and cluster to ensure that the environment meets the minimum requirements to support the application. Click **Deploy**.
+1. On the **Validate the environment & deploy [App Name]** screen, address any warnings or failures identified by the preflight checks and then click **Deploy**.
 
-    :::note
-    Replicated recommends that you address any warnings or failures, rather than dismissing them. Preflight checks help ensure that your environment meets the requirements for application deployment.
-    :::
-
-    :::note
-    If the application does not include preflight checks, you need to click **Deploy** then **Yes, Deploy** next to the target version on the Admin Console dashboard to install.
-    :::  
+    Preflight checks are conformance tests that run against the target namespace and cluster to ensure that the environment meets the minimum requirements to support the application.
 
 The Admin Console dashboard opens.