more links

Author: paigecalvert

docs/enterprise/embedded-manage-nodes.mdx

@@ -113,7 +113,7 @@ Enabling high availability has the following requirements:
 
 Consider the following best practices and recommendations for creating HA clusters:
 
-* At least three _controller_ nodes that run the Kubernetes control plane are required for HA. This is because clusters use a quorum system, in which more than half the nodes must be up and reachable. In clusters with three controller nodes, the Kubernetes control plane can continue to operate if one node fails because a quorum can still be reached by the remaining two nodes. By default, with Embedded Cluster, all new nodes added to a cluster are controller nodes. For information about customizing the controller node role, see [roles](/reference/embedded-config#roles) in _Embedded Cluster Config_.
+* At least three _controller_ nodes that run the Kubernetes control plane are required for HA. This is because clusters use a quorum system, in which more than half the nodes must be up and reachable. In clusters with three controller nodes, the Kubernetes control plane can continue to operate if one node fails because a quorum can still be reached by the remaining two nodes. By default, with Embedded Cluster, all new nodes added to a cluster are controller nodes. For information about customizing the controller node role, see [roles](/reference/embedded-config#roles-beta) in _Embedded Cluster Config_.
 
 * Always use an odd number of controller nodes in HA clusters. Using an odd number of controller nodes ensures that the cluster can make decisions efficiently with quorum calculations. Clusters with an odd number of controller nodes also avoid split-brain scenarios where the cluster runs as two, independent groups of nodes, resulting in inconsistencies and conflicts.
 

docs/vendor/customer-reporting.md

@@ -56,7 +56,7 @@ For more information about how to interpret the time to install metrics, see [Ti
 ### Download Portal
 
 :::note
-If the Replicated Enterprise Portal is enabled for the customer, then an **Enterprise Portal** section is displayed instead of the **Download Portal** section. For more information, see [Enterprise Portal](#enterprise-portal) below.
+If the Replicated Enterprise Portal is enabled for the customer, then an **Enterprise Portal** section is displayed instead of the **Download Portal** section. For more information, see [Enterprise Portal](#enterprise-portal-beta) below.
 :::
 
 From the **Download portal** section, you can:
@@ -83,7 +83,7 @@ From the **Enterprise Portal** section, you can:
 * View the timestamp when the Enterprise Portal was most recently accessed by the customer
 * View the number of users with Enterprise Portal accounts
 * Click **Invite user** to invite a new user to the Enterprise Portal
-* View the number of install attempts made by the customer. The **Customer Reporting > Install Attempts** section includes additional details about install attempts. For more information, see [Install Attempts](#install-attempts) below.
+* View the number of install attempts made by the customer. The **Customer Reporting > Install Attempts** section includes additional details about install attempts. For more information, see [Install Attempts](#install-attempts-beta) below.
 * View the number of service accounts created in the Enterprise Portal
 * View the number of support bundles uploaded to the Enterprise Portal
 

docs/vendor/helm-v2-migrate.md

@@ -153,7 +153,7 @@ To migrate applications that were previously packaged as standard Kubernetes man
 
    1. In your development environment, access the Admin Console to upgrade to the second release. Upgrading to the second release migrates the installation to HelmChart v2.
 
-1. After you are done testing the migration process, promote the first release containing your application manifests with the `kots.io/keep` annotation to one or more customer-facing channels. Replicated recommends that you mark the release as required by enabling **Prevent this release from being skipped during upgrades**. For more information about required releases, see [Properties](/vendor/releases-about#properties) in _About Channels and Releases_.
+1. After you are done testing the migration process, promote the first release containing your application manifests with the `kots.io/keep` annotation to one or more customer-facing channels. Replicated recommends that you mark the release as required by enabling **Prevent this release from being skipped during upgrades**. For more information about required releases, see [Release Properties](/vendor/releases-about#release-properties) in _About Channels and Releases_.
 
 1. Promote the second release containing your Helm chart(s) to the same channels. Replicated recommends that you mark the release as required by enabling **Prevent this release from being skipped during upgrades**.
 

docs/vendor/releases-about.mdx

@@ -180,7 +180,7 @@ The following shows an example of a channel in the Vendor Portal **Channels** pa
 
 As shown in the image above, you can do the following from the **Channels** page:
 
-* Edit the channel settings by clicking on the settings icon, or archive the channel by clicking on the trash can icon. For information about channel settings, see [Settings](#settings).
+* Edit the channel settings by clicking on the settings icon, or archive the channel by clicking on the trash can icon. For information about channel settings, see [Channel Settings](#channel-settings).
 
 * In the **Adoption rate** section, view data on the adoption rate of releases promoted to the channel among customers assigned to the channel.
 

docs/vendor/releases-creating-channels.md

@@ -37,7 +37,7 @@ To edit the settings of an existing channel:
 
 1. Edit the fields and click **Save**.
 
-   For more information about channel settings, see [Settings](releases-about#settings) in _About Channels and Releases_.
+   For more information about channel settings, see [Channel Settings](releases-about#channel-settings) in _About Channels and Releases_.
 
 ## Enable Semantic Versioning
 

docs/vendor/replicated-onboarding.mdx

@@ -466,7 +466,7 @@ To support and test Helm installations:
 
 1. Add the `.tgz` file to a release. For more information, see [Manage Releases with the Vendor Portal](releases-creating-releases) or [Managing Releases with the CLI](releases-creating-cli).
 
-1. Create or get kubectl access to a cluster to test the installation. See [Create a Kubernetes Cluster](/vendor/environment-setup#create-a-kubernetes-cluster) in _Set Up Your Environment_.
+1. Create or get kubectl access to a cluster to test the installation. See [Create a Kubernetes Cluster](/vendor/environment-setup#about-creating-a-cluster) in _Set Up Your Environment_.
 
 1. In the cluster, istall the release with Helm to test your changes. For more information, see [Install with Helm](/vendor/install-with-helm).