docs: stop avoiding the word cluster

Tried to avoid using the word cluster in the docs so many times but it
really doesn't make sense. Just embrace it and use it while making a
note that its possible to use one cluster in place of multiple clusters.

Author: cardoe

docs/deploy-guide/getting-started.md

@@ -57,7 +57,7 @@ The layout of this repo will be something like:
 
 To get started, you'll need a Deploy Repository that you can commit to. This means you should have write access to this repository.
 
-For the deployment tool, [ArgoCD](./argocd.md), you'll need to set up read-only credentials. This allows ArgoCD to fetch the necessary data without making any changes to your repository. One way to achieve this is by using [GitHub Deploy Keys][gh-deploy-keys] or similar solutions.
+For the deployment tool, [ArgoCD][argocd], you'll need to set up read-only credentials. This allows ArgoCD to fetch the necessary data without making any changes to your repository. One way to achieve this is by using [GitHub Deploy Keys][gh-deploy-keys] or similar solutions.
 
 [GitHub Deploy Keys][gh-deploy-keys] will work.
 

docs/deploy-guide/argocd.md renamed to docs/deploy-guide/management-cluster.md

@@ -1,8 +1,8 @@
-# ArgoCD
+# Management Cluster
 
 The deployment of all the services into your Kubernetes cluster is handled
 by [ArgoCD][argocd]. The [System Division](./welcome.md#system-division)
-defines the location where [ArgoCD][argocd] runs as the __Management__ cluster.
+defines the location where [ArgoCD][argocd] runs as the __Management__ role.
 While it is possible to run ArgoCD from the same cluster that your services
 will run in, it is not advisable outside of a development setup. The
 approach that UnderStack uses to deploy it's services with ArgoCD is the

docs/deploy-guide/welcome.md

@@ -14,7 +14,7 @@ with a production best practices installation. Improvements are always welcome.
 
 ## System Division
 
-A fully deployed UnderStack is divided into three distinct parts, or tiers,
+A fully deployed UnderStack is divided into three distinct parts, or clusters,
 that are referred to in the documentation as:
 
 - Management
@@ -30,19 +30,19 @@ flowchart TD
   B[Global] --> E[Site N];
 ```
 
-A fully functioning system only needs one _Management_ tier, one _Global_
-tier and one or more _Site_ tier(s). In this configuration,
-the _Management_ tier is responsible for utilizing our [GitOps][gitops]
-tool, [ArgoCD][argocd] to deploy the expected state to all other tier.
-While the _Global_ tier is
+A fully functioning system only needs one _Management_ cluster, one _Global_
+cluster and one or more _Site_ cluster(s). In this configuration,
+the _Management_ cluster is responsible for utilizing our [GitOps][gitops]
+tool, [ArgoCD][argocd] to deploy the expected state to all other clusters.
+While the _Global_ cluster is
 responsible for hosting any services that are expected to exist only once
 for a whole system deployment such as the DCIM/IPAM tool. While the _Site_
-tiers will run the tools and services that need to live close to the
+clusters will run the tools and services that need to live close to the
 actual hardware.
 
-In fact, one _Management_ tier can control multiple _Global_ tiers
-and their associated _Site_ tiers. We call the grouping of the _Global_
-tier and it's associated _Site_ tiers a _partition_. An example
+In fact, one _Management_ cluster can control multiple _Global_ clusters
+and their associated _Site_ clusters. We call the grouping of the _Global_
+cluster and it's associated _Site_ clusters a _partition_. An example
 would be a staging partition and a production partition.
 
 ```mermaid

mkdocs.yml

@@ -121,7 +121,7 @@ nav:
     - deploy-guide/welcome.md
     - deploy-guide/getting-started.md
     - Quick Start: deploy-guide/gitops-install.md
-    - deploy-guide/argocd.md
+    - deploy-guide/management-cluster.md
     - deploy-guide/auth.md
     - deploy-guide/extra-sites.md
     - deploy-guide/add-remove-app.md