Merge pull request #36204 from mburke5678/remove-also-known

Removing instances of *(also known as the master...)*

Author: mburke5678

_unused_topics/monitoring-configuring-etcd-monitoring.adoc

@@ -118,7 +118,7 @@ image::etcd-no-certificate.png[]
 
 While `etcd` is being monitored, Prometheus is not yet able to authenticate against `etcd`, and so cannot gather metrics. To configure Prometheus authentication against `etcd`:
 
-. Copy the `/etc/etcd/ca/ca.crt` and `/etc/etcd/ca/ca.key` credentials files from the control plane node (also known as the master node) to the local machine:
+. Copy the `/etc/etcd/ca/ca.crt` and `/etc/etcd/ca/ca.key` credentials files from the control plane node to the local machine:
 +
 [subs="quotes"]
 ----

_unused_topics/nodes-nodes-audit-log-advanced.adoc

@@ -19,7 +19,7 @@ openshift_master_audit_config={"enabled": true, "auditFilePath": "/var/lib/origi
 
 [IMPORTANT]
 ====
-The policy file *_/etc/origin/master/adv-audit.yaml_* must be available on each control plane node (also known as the master node).
+The policy file *_/etc/origin/master/adv-audit.yaml_* must be available on each control plane node.
 ====
 
 

architecture/understanding-development.adoc

@@ -124,7 +124,7 @@ so there is less overhead in running them.
 
 When you ultimately run your containers in {product-title}, you use the
 link:https://cri-o.io/[CRI-O] container engine. CRI-O runs on every worker and
-control plane machine (also known as the master machine) in an {product-title} cluster, but CRI-O is not yet supported as
+control plane machine in an {product-title} cluster, but CRI-O is not yet supported as
 a standalone runtime outside of {product-title}.
 
 [id="base-image-options"]

backup_and_restore/backing-up-etcd.adoc

@@ -19,7 +19,7 @@ Be sure to take an etcd backup after you upgrade your cluster. This is important
 
 [IMPORTANT]
 ====
-Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host (also known as the master host). Do not take a backup for each control plane host.
+Back up your cluster's etcd data by performing a single invocation of the backup script on a control plane host. Do not take a backup for each control plane host.
 ====
 
 After you have an etcd backup, you can xref:../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore to a previous cluster state].

backup_and_restore/disaster_recovery/about-disaster-recovery.adoc

@@ -13,7 +13,7 @@ state.
 
 [IMPORTANT]
 ====
-Disaster recovery requires you to have at least one healthy control plane host (also known as the master host).
+Disaster recovery requires you to have at least one healthy control plane host.
 ====
 
 xref:../../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[Restoring to a previous cluster state]::

backup_and_restore/replacing-unhealthy-etcd-member.adoc

@@ -11,7 +11,7 @@ This process depends on whether the etcd member is unhealthy because the machine
 
 [NOTE]
 ====
-If you have lost the majority of your control plane hosts (also known as the master hosts), leading to etcd quorum loss, then you must follow the disaster recovery procedure to xref:../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore to a previous cluster state] instead of this procedure.
+If you have lost the majority of your control plane hosts, leading to etcd quorum loss, then you must follow the disaster recovery procedure to xref:../backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore to a previous cluster state] instead of this procedure.
 
 If the control plane certificates are not valid on the member being replaced, then you must follow the procedure to xref:../backup_and_restore/disaster_recovery/scenario-3-expired-certs.adoc#dr-recovering-expired-certs[recover from expired control plane certificates] instead of this procedure.
 

machine_management/creating-infrastructure-machinesets.adoc

@@ -11,7 +11,7 @@ You can create a machine set to host only infrastructure components. You apply s
 
 [IMPORTANT]
 ====
-Unlike earlier versions of {product-title}, you cannot move the infrastructure components to the control plane machines (also known as the master machines). To move the components, you must create a new machine set.
+Unlike earlier versions of {product-title}, you cannot move the infrastructure components to the control plane machines. To move the components, you must create a new machine set.
 ====
 
 include::modules/infrastructure-components.adoc[leveloffset=+1]

modules/accessing-hosts-on-aws.adoc

@@ -41,7 +41,7 @@ API is responsive, run privileged pods instead.
 master. The hostname looks similar to `ip-10-0-1-163.ec2.internal`.
 
 . From the bastion SSH host you manually deployed into Amazon EC2, SSH into that
-control plane host (also known as the master host). Ensure that you use the same SSH key you specified during the
+control plane host. Ensure that you use the same SSH key you specified during the
 installation:
 +
 [source,terminal]

modules/architecture-kubernetes-introduction.adoc

@@ -15,7 +15,7 @@ deployment, scaling, and management of containerized applications. The general
 concept of Kubernetes is fairly simple:
 
 * Start with one or more worker nodes to run the container workloads.
-* Manage the deployment of those workloads from one or more control plane nodes (also known as the master nodes).
+* Manage the deployment of those workloads from one or more control plane nodes.
 * Wrap containers in a deployment unit called a pod. Using pods provides extra
 metadata with the container and offers the ability to group several containers
 in a single deployment entity.

modules/architecture-machine-roles.adoc

@@ -26,7 +26,7 @@ Machine sets are groupings of machine resources under the `machine-api` namespac
 [id="defining-masters_{context}"]
 == Cluster masters
 
-In a Kubernetes cluster, the control plane nodes (also known as the master nodes) run services that are required to control the Kubernetes cluster. In {product-title}, the control plane machines are the control plane. They contain more than just the Kubernetes services for managing the {product-title} cluster. Because all of the machines with the control plane role are control plane machines, the terms _master_ and _control plane_ are used interchangeably to describe them. Instead of being grouped into a machine set, control plane machines are defined by a series of standalone machine API resources. Extra controls apply to control plane machines to prevent you from deleting all control plane machines and breaking your cluster.
+In a Kubernetes cluster, the control plane nodes run services that are required to control the Kubernetes cluster. In {product-title}, the control plane machines are the control plane. They contain more than just the Kubernetes services for managing the {product-title} cluster. Because all of the machines with the control plane role are control plane machines, the terms _master_ and _control plane_ are used interchangeably to describe them. Instead of being grouped into a machine set, control plane machines are defined by a series of standalone machine API resources. Extra controls apply to control plane machines to prevent you from deleting all control plane machines and breaking your cluster.
 
 [NOTE]
 ====